EMacro

I put quite a bit of effort into this release.
It now supports most of tiny tools; you may notice some interesting new
effects.
Unfortunately, I've been working closely with Jaari Alto, and you may not
be able to get these latest changes, so just go into your
~/emacs/?cache.el file and change the setq settings to "nil".

This also supports xemacs v21.2 beta; you will have to copy your ~/.emacs
to ~/.xemacs/init.el.

Finally, I have quickly copied Jan's code into e-c.el. I also came up with
a trick that it won't slow initial load time, no matter how big it gets.

I don't do much QT development, and haven't done much C++ these days :o(
I am relying on Jan to clean up and test this section of EMacro.
I've only included code from his .emacs, the other support files will have
to be added.

I've also cleaned up comments. About all that remains, is cleanup,
tinypath (so you don't have to edit loadpath.el) and e-options.el.

I put all this into ftp://ftp.cppsig.org/pub/tools/emacs/
I am rushing, and I have to make a change in CVS: xemacs.el is now called
e-xemacs.el.

I discovered while composing this email, that there are definite bugs in
the way I copied Jan's code into "Misc Functions" at the end of e-c.el, so
remove that section, if you do C or C++ programming.

If you don't, you shouldn't notice.

Here are some questions for Jan:

What do these do?

check-file
scan-directory
check-file-string
scan-directory-string


Is programmer.el's time-stamp() preferable to insert-creation-date() ?
What is the impact of the find-file-hook() on programs other than C?
(see .emacs, line 2157)

Are the font-lock-face definitions portable?
(End of .emacs, around 2200 - 2250)

The latest emacro beta is available at sourceforge's cvs, and at
ftp://ftp.cppsig.org/pub/tools/emacs/

The biggest changes are that I fixed some windows bugs
(no more prompting for sql), and EMacro now supports Tramp, which allows
editing over SSH.

I also ripped out many comments, and the compressed file is 7K smaller.

After looking into tiny-tools, I've discovered that it will really make
EMacro work well. In particular, tiny-path will prevent you from having to
edit loadpath.el, which is about the only file that does require editing.

I think the biggest issue that is currently facing EMacro is portablility. I
just simply dont seem to be able to run EMacro out of the box as the website
promises. I have tried that on both my Windoze box running Windows 2000
Advanced Server on my Linux box running Redhat 6.2. I will send out specific
details in my next mail. Most of the problems are caused due to pcl-cvs
related calls. We must analyse and see if its worth it to put those calls
there and sacrifice portablity.

Another problem is that too much of code is commented out and left lying
around. We need to clean that up. We must also look at modularizing the code
so that the functions in various files do not clash. We should also provide
finer granularity for users to configure EMacro. A good example to see would
be the JDE customization facility. For example we should allow the users to
customize key bindings using M-X customize EMacro etc.

We should also try for closer integration with packages like JDE so that
when we ultimately come up with a C++ mode it does not throw up surprises
for users.

These are random thoughts that I have put down. Please feel free to respond
with your views.

thanks
vishy

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
EMacro.
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).