Feature Request : autoload-form

Feature Request : autoload-form

[paul r]

Dear list,

autoload is a very convenient feature to pseudo-defun a function until
it is called for real for the first time. I have been using it happily
until today, when I came accross a need I can not suit with autoload.
Here is why :
There is a file B that does some (require ...) and some (load ...). In
one of the loaded files, function F will be defined.
There is a file A that changes the load-path, which is required before
loading B.
B does not depend on a predefined A file, therefore I can not put a
(load A) in B.
The only way I have to carry a proper load is to do (load A)(load B).
After that, I'm sure F will be defined the way I want. I can really
not do that with a single file.
Hence my need : I think it would be convenient to have a variant of
autoload, let's call it 'autoload-form'.
Its look would be :
(autoload-form function form &optional docstring interactive type)
IOW, exactly the same as autoload, except that FILE becomes FORM.
It is a kind a generalization of autoload, in which it is up to FORM
to do what is needed to provide a side-effect of having FUNCTION
defined. To make sure I am clear, the following two lines have the
same effect
(autoload foo "bar.el")
(autoload-form foo (load-file "bar.el"))

With that, I could do a (autoload-form F (load-file "A")(load-file "B"))
Without, the only alternative I see is to write  (load-file
"A")(load-file "B") in a dummy file, then register it with autoload.

I really want to do that myself, but autoload belongs to the C part of
emacs, and I lack knowledge to change anything in it. I do not know
how to do this in emacs lisp, whenever it is possible.

I would like to know what you think about that. If you think I can do
something clean in lisp, please give me some hints, I do not know
where to start.

Regards,


-- Paul

Re: Feature Request : autoload-form

[Stefan Monnier]

> (autoload foo "bar.el")
> (autoload-form foo (load-file "bar.el"))

You could just change autoload to do that.  It's a pretty simple change
in the C code.


        Stefan

Re: Feature Request : autoload-form

[paul r]

2008/3/29, Stefan Monnier <monnier@iro.umontreal.ca>:
> > (autoload foo "bar.el")
>  > (autoload-form foo (load-file "bar.el"))
>
>
> You could just change autoload to do that.  It's a pretty simple change
>  in the C code.
>

I'm totally unskilled when it comes to the C code. I admit it is not
so-hard, but it will probably take me several hours to get it right.
Having a clean solution to my problem is not worth several hours. So
I'm willing to spend this time if you think it can bring something
useful to emacs. What do you think ?

Re: Feature Request : autoload-form

[Stefan Monnier]

>> > (autoload foo "bar.el")
>> > (autoload-form foo (load-file "bar.el"))
>> You could just change autoload to do that.  It's a pretty simple change
>> in the C code.
> I'm totally unskilled when it comes to the C code.  I admit it is not
> so-hard, but it will probably take me several hours to get it right.
> Having a clean solution to my problem is not worth several hours. So
> I'm willing to spend this time if you think it can bring something
> useful to emacs. What do you think ?

If it's done well, we could install it in the trunk (you'd probably
have to sign copyright paperwork for that, of course).

In any case, grep for `do_autoload' in the src/*.c files to see where
the autoloading is done.  That's probably the main part of the code
you'll need to change.  But change should be fairly small.


        Stefan

Re: Feature Request : autoload-form

[Richard Stallman]

    > (autoload foo "bar.el")
    > (autoload-form foo (load-file "bar.el"))

    You could just change autoload to do that.  It's a pretty simple change
    in the C code.

I don't think we should install this in Emacs, though.  Something like
autoload should be kept simple and limited.

If loading a certain file needs load-path to be set a certain way,
the user should simply set load-path that way, perhaps in .emacs.
It is a bad idea to have files that only work right if load-path
is temporarily changed; rather than adding a new file to Emacs
to cope with that situation, it would be better to redesign the
Lisp code that appears to need it.

Re: Feature Request : autoload-form

[paul r]

2008/3/30, Richard Stallman <rms@gnu.org>:

> I don't think we should install this in Emacs, though.  Something like
>  autoload should be kept simple and limited.

I think of autoload as a particular case of the general need to
"eval-on-event-then-call". Therefore, I do not see why evaluating a
form is less simple than loading a file. Form evaluation is, indeed,
less limited but I don't see why it should be a disadvantage here.

>  If loading a certain file needs load-path to be set a certain way,
>  the user should simply set load-path that way, perhaps in .emacs.
>  It is a bad idea to have files that only work right if load-path
>  is temporarily changed; rather than adding a new file to Emacs
>  to cope with that situation, it would be better to redesign the
>  Lisp code that appears to need it.

You are understanding most of the problem I'm facing. I'll try to give
you some more information in a manner as concise as possible.
I wrote a system called TidyConfig for emacs. It is not a mode, it is
a system. Its ultimate goal is to allow people to share effectively
what usualy resides in .emacs. Some people want to do that, because
they have very similar usage profiles, although not exactly the same.
Users copies can be synced using a DVCS. The best example I see is
people in my company, who all use TidyConfig and this way avoid
duplicated efforts. To achieve that :
  - I got rid of the monolithic .emacs, so that bits of configuration
go into dedicated "modules". There is a module for C-mode, one for
Muse-mode etc. One module resides in one file. Modules are shared in
your network of friends/colleagues ... anybody syncing with you, so
they are "network-specific" but not "user-specific".
  - To allow fine-tuning, a user can use "module configuration file",
which is an other file, with personal tweaking in it. Those conf files
are not shared and are usually optional. They are user specific, and
private. Exemple : the ERC module does a lot of configuration, but it
can not set up username, password etc because this information is
user-specific.

Any module is optional, this is the whole point of this project. Each
user simply choose in a list what modules he wants to use. He can
chose to load them at startup time, or "later when needed". In this
last case, I obviously use autoload.

I could put, at beginning of *every* modules, a (load-file
"thisModuleConfigurationFile" t). This is what I did before, but I do
not find that elegant, nor fully satisfactory in many ways for the
needs, so it now is to the TidyConfig system to carry proper loading
of modules.

Here we are. I currently have no option to do so, except putting the
form I want to eval in a dummy file and registering this file with
autoload. This is now what I do, and please believe I don't feel
pround of that ugly hack :)

If you want to visit my upstream TidyConfig repository, and why not
give it a try, you can go to
http://emacs.kekerekex.net:8008/tidyconfig-vanilla/summary . It is
versionned through mercurial, so you can also do a "hg clone" of this
url. It could maybe be used as a playground for people here to try and
share some lisp before checking in into the trunk, and also to get
hands on DVCS. There is an up to date documentation in english.

Hope that was not too long ... Thanks.

-- Paul

Re: Feature Request : autoload-form

[Stefan Monnier]

> I think of autoload as a particular case of the general need to
> "eval-on-event-then-call". Therefore, I do not see why evaluating a
> form is less simple than loading a file. Form evaluation is, indeed,
> less limited but I don't see why it should be a disadvantage here.

By the way, instead of

  (autoload <fun> <exp> <doc>)

you can do

  (defun <fun> (&rest args)
    <doc>
    <exp>
    (apply <fun> args))


-- Stefan

Re: Feature Request : autoload-form

[Richard Stallman]

    I think of autoload as a particular case of the general need to
    "eval-on-event-then-call".

Looking for the most general way to think of this is not a good
practice.

Please listen to my experience.  Features like autoload should be kept
as limited as possible.

Re: Feature Request : autoload-form

[Mike Mattie]

[-- Attachment #1: Type: text/plain, Size: 4146 bytes --]

On Sun, 30 Mar 2008 12:24:19 +0100
"paul r" <paul.r.ml@gmail.com> wrote:

> 2008/3/30, Richard Stallman <rms@gnu.org>:
> 
> > I don't think we should install this in Emacs, though.  Something
> > like autoload should be kept simple and limited.
> 
> I think of autoload as a particular case of the general need to
> "eval-on-event-then-call". Therefore, I do not see why evaluating a
> form is less simple than loading a file. Form evaluation is, indeed,
> less limited but I don't see why it should be a disadvantage here.
> 
> >  If loading a certain file needs load-path to be set a certain way,
> >  the user should simply set load-path that way, perhaps in .emacs.
> >  It is a bad idea to have files that only work right if load-path
> >  is temporarily changed; rather than adding a new file to Emacs
> >  to cope with that situation, it would be better to redesign the
> >  Lisp code that appears to need it.
> 
> You are understanding most of the problem I'm facing. I'll try to give
> you some more information in a manner as concise as possible.
> I wrote a system called TidyConfig for emacs. It is not a mode, it is
> a system. Its ultimate goal is to allow people to share effectively
> what usualy resides in .emacs. Some people want to do that, because
> they have very similar usage profiles, although not exactly the same.
> Users copies can be synced using a DVCS. The best example I see is
> people in my company, who all use TidyConfig and this way avoid
> duplicated efforts. To achieve that :
>   - I got rid of the monolithic .emacs, so that bits of configuration
> go into dedicated "modules". There is a module for C-mode, one for
> Muse-mode etc. One module resides in one file. Modules are shared in
> your network of friends/colleagues ... anybody syncing with you, so
> they are "network-specific" but not "user-specific".
>   - To allow fine-tuning, a user can use "module configuration file",
> which is an other file, with personal tweaking in it. Those conf files
> are not shared and are usually optional. They are user specific, and
> private. Exemple : the ERC module does a lot of configuration, but it
> can not set up username, password etc because this information is
> user-specific.
> 
> Any module is optional, this is the whole point of this project. Each
> user simply choose in a list what modules he wants to use. He can
> chose to load them at startup time, or "later when needed". In this
> last case, I obviously use autoload.
> 
> I could put, at beginning of *every* modules, a (load-file
> "thisModuleConfigurationFile" t). This is what I did before, but I do
> not find that elegant, nor fully satisfactory in many ways for the
> needs, so it now is to the TidyConfig system to carry proper loading
> of modules.
> 
> Here we are. I currently have no option to do so, except putting the
> form I want to eval in a dummy file and registering this file with
> autoload. This is now what I do, and please believe I don't feel
> pround of that ugly hack :)
> 
> If you want to visit my upstream TidyConfig repository, and why not
> give it a try, you can go to
> http://emacs.kekerekex.net:8008/tidyconfig-vanilla/summary . It is
> versionned through mercurial, so you can also do a "hg clone" of this
> url. It could maybe be used as a playground for people here to try and
> share some lisp before checking in into the trunk, and also to get
> hands on DVCS. There is an up to date documentation in english.
> 
> Hope that was not too long ... Thanks.

I wrote something very similar, but different on some design points. It boiled down
to my "modules" having a three part form:

[define meta-data & hooks ]

[ load w/require ]

[ setup ]

I would define things like install hooks before the loading part. If anything went wrong with loading
needed libraries, my load function could execute the install hooks, and re-evaluate the module.

loading would be a bunch of require forms.

The setup would configure and integrate the features.

If you want to know more drop me a mail off-list.

> -- Paul
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Feature Request : autoload-form

[paul r]

2008/3/30, Stefan Monnier <monnier@iro.umontreal.ca>:
> > I think of autoload as a particular case of the general need to
>  > "eval-on-event-then-call". Therefore, I do not see why evaluating a
>  > form is less simple than loading a file. Form evaluation is, indeed,
>  > less limited but I don't see why it should be a disadvantage here.
>
>
> By the way, instead of
>
>   (autoload <fun> <exp> <doc>)
>
>  you can do
>
>   (defun <fun> (&rest args)
>     <doc>
>     <exp>
>     (apply <fun> args))
>

I needed to do a macro for that, because <fun> name is known at
runtime, but at the end it works.
Thank you.

Re: Feature Request : autoload-form

[Levin Du]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

We currenly have (eval-after-load file form), what about:

   (eval-before-load file form)

to make things easier?


2008/3/31, paul r <paul.r.ml@gmail.com>:
>
> 2008/3/30, Stefan Monnier <monnier@iro.umontreal.ca>:
> > > I think of autoload as a particular case of the general need to
> >  > "eval-on-event-then-call". Therefore, I do not see why evaluating a
> >  > form is less simple than loading a file. Form evaluation is, indeed,
> >  > less limited but I don't see why it should be a disadvantage here.
> >
> >
> > By the way, instead of
> >
> >   (autoload <fun> <exp> <doc>)
> >
> >  you can do
> >
> >   (defun <fun> (&rest args)
> >     <doc>
> >     <exp>
> >     (apply <fun> args))
> >
>
> I needed to do a macro for that, because <fun> name is known at
> runtime, but at the end it works.
> Thank you.


--
Levin

[-- Attachment #2: Type: text/html, Size: 1507 bytes --]

Re: Feature Request : autoload-form

[Richard Stallman]

      - I got rid of the monolithic .emacs, so that bits of configuration
    go into dedicated "modules". There is a module for C-mode, one for
    Muse-mode etc. One module resides in one file. Modules are shared in
    your network of friends/colleagues ... anybody syncing with you, so
    they are "network-specific" but not "user-specific".

I think I understand what these do.  I'm not completely sure why you
want them, though.  What job do these do, which you couldn't do by
installing some Lisp libraries in the usual way?

      - To allow fine-tuning, a user can use "module configuration file",
    which is an other file, with personal tweaking in it. Those conf files
    are not shared and are usually optional. They are user specific, and
    private. Exemple : the ERC module does a lot of configuration, but it
    can not set up username, password etc because this information is
    user-specific.

Why not put this stuff directly in .emacs?

    I could put, at beginning of *every* modules, a (load-file
    "thisModuleConfigurationFile" t).

I don't see why you want to do that, rather than putting the
"module configuration" expressions directly in .emacs.
What do you gain?

     This is what I did before, but I do
    not find that elegant, nor fully satisfactory in many ways for the
    needs, so it now is to the TidyConfig system to carry proper loading
    of modules.

I am confused.  Are you talking about making a module load its module
configuration expressions, or are you talking about how to load the
module itself when it is needed?  Those are two different issues, right?
Some of your words seem to imply one, and some seem to imply the other.

    Here we are. I currently have no option to do so, except putting the
    form I want to eval in a dummy file and registering this file with
    autoload.

I have lost you completely here.

Re: Feature Request : autoload-form

[paul r]

2008/3/31, Richard Stallman <rms@gnu.org>:

I'll try to make things more clear below, but before reading the whole
message, be warned :
 - it is long and unlikely to interest you, so you can safely skip it
 - I solved the original problem of this thread.

> I think I understand what these do.  I'm not completely sure why you
>  want them, though.  What job do these do, which you couldn't do by
>  installing some Lisp libraries in the usual way?

What usual way ?

>
> Why not put this stuff directly in .emacs?

TidyConfig IS a .emacs splited into many files. Each file has a role.
You may want to load some of them, and not some others. As an exemple,
the upstream repository provides more than 20 modules, but usualy
people use around 10 modules. For exemple, you can load 4 of them at
startup time, then the 6 remaining dynamically when needed (thanks to
autoload / automode etc). Any configuration should not be read -at
all- if not needed yet.

> I don't see why you want to do that, rather than putting the
>  "module configuration" expressions directly in .emacs.
>  What do you gain?

Fine grained, per-feature, configuration "cherry-picking". But you are
right that I could.

> I am confused.  Are you talking about making a module load its module
>  configuration expressions, or are you talking about how to load the
>  module itself when it is needed?  Those are two different issues, right?
>  Some of your words seem to imply one, and some seem to imply the other.

Sorry for not being clear. This system uses some conventions. Here is
an exemple of a use case :
 - I sometime use latex-mode
 - I do not want it to be loaded at startup time because it would slow
down for nothing
 - Some of the configuration should be shared with other users

To do so :
 - I have some customization for this mode, that is shared by
everybody in my company. This configuration is some lisp written in
mod.latex.el. At the beginning of this file, there is (require 'latex)
 - I have personal preferences that are not shared, it goes to conf.latex.el
 - I need the actual latex mode librairy, so I download it from Auctex
to my "modes" directory and name the directory "latex".
 - I register "metadata" which is a list of 3 elements  '( module
autoload-function automode-extension ), with following meaning : "load
module on autoload-function call" and "call autoload-function on file
matching automode-extension". Is this case, it will be basicaly
'(latex latex-mode ".tex")

And that's it. Nothing about latex will be loaded at emacs startup
time, except "metadata". Then, when autoload-function is called for
the first time, is does the "proper loading of module" that confused
you, which is detailled below :
 1 - load conf.latex.el (again, this is a per-user optional file)
 2 - unless tidyconfig-avoid-local-mode has been set to 't in
conf.latex.el, look for a directory in modes directory which name is
"latex". If found, add it to load-path.
 3 - load mod.latex.el. This module does (require 'latex), which in
turn will define real latex-mode.
 4 - call latex-mode

The file mentionned above can be visited from [2].

So why do I have all this system ? Because, as strange as it can look
at first glance, it provides strong consistency over how emacs config
is managed as a whole, for me and for my "network". As well as easier
portability over systems.

I did not invente anything, 99% of the goodness is due to emacs clean
design. I just did the last 1% to make it easier to access. I think it
might be surprising mainly because it uses some conventions for
loading process, while conventional lisp librairy explicitly express
their dependencies through load-path settings, (require ...)  (load
...) etc. Although I think the later is more robust, so is the right
choice in most cases, I think the former is easier to maintain, for
me, in the particular case of .emacs configuration.

> I have lost you completely here.

I'm sorry about that. If you have a web browser and want to give it a
try, please go to [1], download a snapshot clicking on "zip" or "gz",
extract in any directory, cd to this directory, and enter
   emacs -q -l tidyconfig.start.el

Regards,

-- Paul

[1] http://emacs.kekerekex.net:8008/tidyconfig-vanilla/summary
[2] http://emacs.kekerekex.net:8008/tidyconfig-vanilla/file

Re: Feature Request : autoload-form

[Mike Mattie]

[-- Attachment #1: Type: text/plain, Size: 2849 bytes --]

On Mon, 31 Mar 2008 12:24:45 -0400
Richard Stallman <rms@gnu.org> wrote:

>       - I got rid of the monolithic .emacs, so that bits of
> configuration go into dedicated "modules". There is a module for
> C-mode, one for Muse-mode etc. One module resides in one file.
> Modules are shared in your network of friends/colleagues ... anybody
> syncing with you, so they are "network-specific" but not
> "user-specific".
> 
> I think I understand what these do.  I'm not completely sure why you
> want them, though.  What job do these do, which you couldn't do by
> installing some Lisp libraries in the usual way?

There isn't a usual way for installing elisp libraries, just whatever
the user has slapped together out of necessity. The closest way to
any usual way AFAICT is ELPA.

The Emacs developers use trees of elisp source managed by CVS regularly, 
it is somewhat curious that a single .emacs file is considered adequate
the user.

In fact I think a single .emacs file discourages sharing emacs elisp
because it contradicts directly the kind of modularity and organization
essential to sharing.

If I had not broken out of a single .emacs file long ago I never would
have posted any elisp, because it was always a big hair-ball in a giant
file.

Something to consider at least. The rest of this line of thought is
to off-topic for me to continue, but I will share ideas and code off-list.

>       - To allow fine-tuning, a user can use "module configuration
> file", which is an other file, with personal tweaking in it. Those
> conf files are not shared and are usually optional. They are user
> specific, and private. Exemple : the ERC module does a lot of
> configuration, but it can not set up username, password etc because
> this information is user-specific.
> 
> Why not put this stuff directly in .emacs?
> 
>     I could put, at beginning of *every* modules, a (load-file
>     "thisModuleConfigurationFile" t).
> 
> I don't see why you want to do that, rather than putting the
> "module configuration" expressions directly in .emacs.
> What do you gain?
> 
>      This is what I did before, but I do
>     not find that elegant, nor fully satisfactory in many ways for the
>     needs, so it now is to the TidyConfig system to carry proper
> loading of modules.
> 
> I am confused.  Are you talking about making a module load its module
> configuration expressions, or are you talking about how to load the
> module itself when it is needed?  Those are two different issues,
> right? Some of your words seem to imply one, and some seem to imply
> the other.
> 
>     Here we are. I currently have no option to do so, except putting
> the form I want to eval in a dummy file and registering this file with
>     autoload.
> 
> I have lost you completely here.
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Feature Request : autoload-form

[Richard Stallman]

    There isn't a usual way for installing elisp libraries,

The standard way is to put them in the directories that Emacs looks in:
/usr/local/share/emacs/VERSION/site-lisp and
/usr/local/share/emacs/site-lisp.

Re: Feature Request : autoload-form

[paul r]

2008/4/2, Richard Stallman <rms@gnu.org>:

> The standard way is to put them in the directories that Emacs looks in:
>  /usr/local/share/emacs/VERSION/site-lisp and
>  /usr/local/share/emacs/site-lisp.

 - It is not writable as a user
 - it is not user-specific
 - there is no standard repository where to get librairies from
 - there is no standard way to fetch them
 - there is no automatic mean to keep them up to date.

Emacs need a packaging system to give satisfactory solution to all
theses problems. I know it has already been discussed here, and I do
not aim to restart the debate (yet). But the proper, and universal
way, to distribute such a large piece of software, is through a
packaging system. Be the repositories under full control of the FSF.

Re: Feature Request : autoload-form

[Richard Stallman]

     - It is not writable as a user
     - it is not user-specific

It would be useful to set up conventional per-user libraries
that go in load-path.

     - there is no standard repository where to get librairies from

We do not want one.  Anything that WE want to distribute,
we put into Emacs.

Re: Feature Request : autoload-form

[paul r]

2008/4/2, Richard Stallman <rms@gnu.org>:

> It would be useful to set up conventional per-user libraries
>  that go in load-path.

It could help, yes.

>      - there is no standard repository where to get librairies from
>
> We do not want one.  Anything that WE want to distribute,
>  we put into Emacs.

Are you planing to impose this ditribution policy for gNewSens /
gobuntu as well ? For the whole GNU OS ? I guess you don't.
If you think Gnu/Linux distribution requirements differ from Gnu Emacs
distribution requirements, could you please explain me how ? At this
time, I can only see numerous similarities.
Thanks

-- Paul

Re: Feature Request : autoload-form

[Don Armstrong]

On Wed, 02 Apr 2008, paul r wrote:
> Are you planing to impose this ditribution policy for gNewSens /
> gobuntu as well ? For the whole GNU OS ? I guess you don't. If you
> think Gnu/Linux distribution requirements differ from Gnu Emacs
> distribution requirements, could you please explain me how ? At this
> time, I can only see numerous similarities.

There are similarities, but the differences is wherein the problems
lie. There's pretty much no sane way to handle distribution in
something besides a tarball which does not get into the way of what
distributions are doing. [And really, packaging for distribution is
what the distributions are (or at least should be) best at.]

The distribution of emacs and packages which are used for emacs but
are not part of emacs have largely been solved by distributions
already. See Debian's emacs policy, for example.


Don Armstrong

-- 
Mozart tells us what it's like to be human, Beethoven tells us what
it's like to be Beethoven, and Bach tells us what it's like to be the
universe.
 -- Douglas Adams

http://www.donarmstrong.com              http://rzlab.ucr.edu

Re: Feature Request : autoload-form

[Stephen J. Turnbull]

Don Armstrong writes:

 > The distribution of emacs and packages which are used for emacs but
 > are not part of emacs have largely been solved by distributions
 > already. See Debian's emacs policy, for example.

I have.  Debian's emacs policy is a frequent source of annoyance to
XEmacs.  The policy of trying to use a single package to serve both
Emacsen, especially when it's a package we provide but GNU does not,
often results in buggy behavior.  I don't know that it can be done
better from Debian's point of view, but from XEmacs's point of view,
"largely solved" is an overstatement.

Re: Feature Request : autoload-form

[Don Armstrong]

On Thu, 03 Apr 2008, Stephen J. Turnbull wrote:
> Don Armstrong writes:
> > The distribution of emacs and packages which are used for emacs
> > but are not part of emacs have largely been solved by
> > distributions already. See Debian's emacs policy, for example.
> 
> I have. Debian's emacs policy is a frequent source of annoyance to
> XEmacs. The policy of trying to use a single package to serve both
> Emacsen,

First off, we distribute at least four flavors of emacsen, sometimes
even 6 or 8.

> especially when it's a package we provide but GNU does not, often
> results in buggy behavior.

In the cases where the addon package should not be loaded in xemacs,
this can indeed be done using the existing system. When it's not known
that it shouldn't be used in a particular flavor, splitting it out
won't help, as the default would still be to have it work on all
flavors of emacs (but with 4-8 times as many packages). [Flavor
specific code sections can also be done, of course.]

> I don't know that it can be done better from Debian's point of view,
> but from XEmacs's point of view, "largely solved" is an
> overstatement.

If there are particular things that are suboptimal, filing bugs is the
best way to document them and hopefully get them fixed. [I personally
don't use Xemacs, so I'm not in a position to file them.]


Don Armstrong

-- 
"There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence."
 -- Jeremy S. Anderson

http://www.donarmstrong.com              http://rzlab.ucr.edu