I am happy that EMacro v2.0.6(?), the first sourceforge release has not
had any serious bugs. I thank you for your help in testing; I feel that it
is important to have a stable base release that we can always roll back to.
I am thinking of making Jan's C++ code a separate subproject, as well as
a2ps-print.el (which is too small for its own sourceforge site).
You should also give Jaari Alto's <url: http://tiny-tools.sourceforge.net/ > a
look; I am going to integrate them a little better in the next release of
I think EMacro can be made a little easier to use. About the only thing
that still _requires_ editing is loadpath.el. Preferences.el, ?cache.el
and home.el are useful to edit, but optional.
Fortunately, Jari has tiny-path.el, which generates a load-path
automagically. I haven't tried it yet, but I understand it to do this
every time, which sounds slow to me.
I will probably code EMacro to grab subdirectories of 'use-home (typically
~/emacs) on a virgin invocation, and save them into loadpath.el.
Thereafter, I expect to have a menu option to run tiny-path again. I
could also use Jan's e-options.el, so that users can edit load-path via
emacs's menu, by enabling or disabling (check/uncheck) various paths.
Now that EMacro's features are stabilizing, I have looked a little more at
e-options, and considered how I would use it.
Currently, I can see how I can use it to edit ?cache.el and much of
preferences.el (not sure how to deal yet with strings, such as printer
name, which perhaps need to be customization variables). I will need a
list sorting defun; let me know if you see one.
Comments in these files would get wiped out.
I also see where I can use e-options to disable loading of the various
emacro files, such as e-sql.el, if you don't use a database or inet.el, if
you don't connect to a network.
Let me know if you feel it is necessary to have finer grained control of
EMacro. For example, you want from inet.el, email capability, but not gnus
usenet news capability.
To do this correctly will take developer time, and also can bloat EMacro's
already heavy code. Alternate solutions are for advanced users to edit
EMacro's code (makes it tougher to upgrade); Split EMacro into finer
grained files (ex: an inet directory with e-mail.el and e-gnus.el).