EMacro

I thank everyone on the EMacro team. With all your help, I have not
recieved
one outside bug report.
To date, there is only one bug report on the SourceForge web, and that
was for
a beta release, and something that had already been fixed.
I'm sure as EMacro becomes more popular, this will change.

There is no rest for the wicked.
As soon as EMacro went golden, Vishy released tips.html, which is
checked into
CVS, so you can see where our web, and online docs are headed.
Below is a list of items for the team to consider.

I upgraded John, my co-worker's version of EMacro to 2.0.6 release.
The biggest problem is that I had to hack up html-helper-mode, in order
to
get it to byte-compile and load on my machine.
I'll have to figure out what happened, but I suspect the problem is more
html-helper-mode than it is EMacro.

However, I did get some nice usability critiques.
1) home.el is the scratchpad for user customizations. I had thought of
calling
  it "user.el". Maybe one of you can come up with a catchier name-
  "customize-me.el"?
  I have a skeleton there, to make it easy to set up home.el for your
emacs
  use anywhere (should you move from emacs to xemacs or w32 to linux).
  However, I am thinking of ripping out all that skeleton code, so that
  home.el is simple, and people will start using it.

2) John suggested that EMacro go into a subdirectory of ~/emacs, for
cleaner
   organization

3) John suggested further, that I bundle all supported libraries with
EMacro.
   While this is convenient, and pretested, this can lead to much disk
space
   and download bloat, with files you are not likely to use, such as
delphi.el
   and modula3.el. However, if I tested html-helper-mode on my machine,
then
   presumably, you can plug it in, and use it on your machine.
   Then there are binary add-ons, such as ispell and Internet
Explorer(tm).
   I don't see including them as worth while.

4) John also suggested that we use condition-case() [the elisp
equivalent of
   exception handling] to try catching failed packages, and
automatically turn
    them off in ?cache.el.
   So, for example, cache-locate-library() detects html-helper-mode in
   load-path, so (defconst cache-html-helper-mode t) is set in
   ~/emacs/xcache.el. However, I would later add code, that catches this
   problem, and appends (setq cache-html-helper-mode nil) to xcache.el.

   Frankly, I suspect that this will lead to much code bloat, and
therefore,
   increased maintenance.

And then there is the future of EMacro:

5) I hope to internationalize EMacro. I have already included files to
   support European dates and phone numbers and Chinese & Japanese.
   Much of this may fall outside the scope of EMacro.
   However, I could set all prompts and EMacro menus in a language file,
in
   the i18n directory (I may need to rename files there).
   Is there something more?

6) I'll be rolling in Jan's C++ code into ~/emacs/programmer/e-c.el

7) Jan has written e-options.el, which lets you turn things on and off
from the
   menu. This works nicely for dynamic items that have either a 'nil or
't
   state. However, some items are more static in nature, such as
"disable
   loading e-perl.el for faster startup", which would not have any
effect,
   until you restart Emacs.
   The issue here, is that the user may end up expecting that everything
will
   be invoked, as soon as they exit the menu.
   I could invoke prompts that do nothing, with something like:
	"Changes take effect when you restart Emacs (hit enter)"

8) I'm sure you can add some creative ideas, including now that EMacro
invokes
   a browser from the help menu, we can exploit hooks to our SourceForge
web.

9) The EMacro website is pretty sad, but Vishy is doing a good job of
starting to
   clean up the html. I hope we can figure out how to work on the
SourceForge site;
   it does allow us to install CGIs, so I'm open to ideas here, too.

Again, thanks, and I hope you are enjoying EMacro as much as I am.
-- 
EMacro remakes Emacs http://www.sourceforge.net/projects/emacro/