Re: [Emacro-devel] EMacro 2.1.4 beta

[Bruce I. <bin...@pa...>]

Vishwanathan SVN wrote:

>Hi!
>
>I think what we need to do is to restrict ourselves to a version of (X)Emacs
>and support only that. Besides that we need to ensure that we thoroughly
>test EMacro on various platforms before we do a release.
>
Yes. I was paranoid about the quality of the base release of EMacro. I 
tried to switch to a less quality intensive "release early, release 
often" paradigm, but this may not have worked, as I haven't responded 
with bug fixes fast enough.
Basically, I need to upgrade my machine, so that I can have enough 
Windows disk space,
to test that too. I know that there is a problem, but I have to install 
Emacs, so that I can
figure out what I need to fix.

> Today in the JDE mailing list there was a comment which says that EMacro is not ready for prime time and I had to agree because it requires some code tweak to make it work.
>
I'd agree that it is not complete/ready. OTOH, complaints aren't much 
good, unless a
maintainer, such as myself, hears them. There are 2 issues I need to 
resolve, before I believe
that EMacro can start considering itself foolproof:
1) Integrate tinytool's tinypath, to automatically generate loadpath.el
2) Integrate menu choices, so that people can change EMacro's defaults 
thru a GUI.

There is a third issue: EMacro doesn't always play well with existing 
(legacy) .emacs files.
I had chose "home.el", because it is more posix sounding, than the 
microsoft style of
"MyDotEmacs.el". I am acccepting suggestions for new names. The new 
configuration will
allow users to easily put code that executes before, as well as after 
EMacro.
Currently, you can do this by putting "before" code at the end of 
.emacs, and your "after"
code in home.el. I am thinking of calling the new files
    pre.el
    post.el
but these names do not make it clear that these files are intended to be 
edited by users.

> So maybe instead of being too ambitious with what we want to do we should ask the user to do the following:
>
>1) Download and install a version of (X)Emacs that we support 
>2) Download and install all/some the packages that EMacro supports
>3) Install EMacro out of the Box and use it.
>
>For that we need to test out EMacro on as many platforms as we can. I can
>volunteer to test out on the following platforms:
>
>1) Windoze 2000 Professional SP2
>2) NT and variants
>3) Red Hat Linux 6.1 and above
>
>4) Mandrake Linux 8.0
>
Thanks. That will help. I do have docs/release_procedure.txt, which 
outlines everthing I
make sure to test, before releasing. Ideally, we should have a makefile 
or other means to
regression test everything, but

>
>The target users of EMacro are ones who are newbies to emacs and hence dont
>know how to customize it. So I am sure they are more than willing to install
>a supported version of (X)Emacs to get an out of the box experience. For the
>others we always have the older (and possibly more portable) versions of
>EMacro which they can tweak and use if they want.
>
>We should also provide pointers on our web page to the various packages and
>the versions of those packages that we support.
>
>In case this is acceptable to everyone I can start making due modifications
>to the home page. I have made some code changes also which I sent out to the
>list yesterday. But unfortunately there was some problem because of which it
>bounced back. I dont want to check them into CVS without prior approval from
>Bruce or Jan.
>
Yes, the list has a 40K limit on mailings. I seem to be having problems 
maintaining the mail list, and have asked Jan "Amos" for help. You can 
either send the attachment directly to me.
Placing a new version into CVS should not be a problem; you are not 
erasing previous versions. Just make sure that you are working from the 
latest release available.

Otherwise, you need to grab the latest release, and run (x)emacs ediff, 
and merge changes.
This is the proper way to check into CVS, but I am happy to help you 
thru it.
---

I don't think that dropping support for emacs or xemacs will 
significantly speed development.
I am not putting in as much time as last year, and I don't quite have 
the same hardware
(in particular, I need to find a job & upgrade my machine).

Some features are only available on one or the other, which, of course, 
is the problem.
Emacs has a natural language translator, where XEmacs has nice CVS menus.
I personally jump ship, as competitive developments leapfrog each other; 
XEmacs 21.4.x is quite nice, but I expect that Emacs 21 [due last spring 
:( ]will be a killer app.

I am already dropping support for old elisp libraries. This has speeded 
development. You will
notice that ver.el has all but gone away. Unfortunately, I don't 
specifically mention in the documentation, as to which versions that 
EMacro requires.
Frankly, I don't believe in doing this in documentation; the whole point 
is that EMacro is supposed to take care of you, so that you don't have 
to read documentation.

So yes, the proper way is to detect versions of dependent elisp 
libraries in EMacro's code.
Unfortunately, I have not been able to convince the maintainers of emacs 
nor the various libraries, that a standard for this, is a good idea.
The best that I have been able to accomplish, is a compromise, to take 
the part of XEmacs packaging system, largely written in C, which reads 
package versions, and *I* do all the
work of porting it to elisp, and then I would include it in EMacro, 
because the Emacs folks are not interested. The last part, is that I 
would have to convince packagers of Emacs elisp code to follow this 
convention, and hopefully critical mass will be reached, eventually.

Bear in mind, that currently, there is no conventional packaging of 
Emacs elisp, and on the XEmacs side, where they do have such packaging, 
it creates a Makefile nightmare maintenance scenario.

Sadly, this means that, for the forseeable future, when your (x)emacs 
system crashes with a mysterious error, you should go thru and upgrade 
all your elisp files to the latest versions.

XEmacs's packaging system does let you automagically check for the 
latest versions of its supported libraries, but not 3rd party libraries, 
such as tiny-tools. It is rare to see a problem
of having a library that is /too_new/.

About the only solution I can think of, is to put in the docs a generic 
recommendation that users upgrade all their libraries, when they upgrade 
EMacro.

-- 
NY Harbor 2001-9-11 facts & photos  http://www.panix.com/~bingalls/