problems with easy-menu-add on --without-x emacs

problems with easy-menu-add on --without-x emacs

[Miles Bader]

I notice several cases where things fail on an emacs compiled without X
support, because they call `easy-menu-add', and it calls `x-popup-menu'
which isn't defined when X support is disabled.  I don't recall such
failures the last time I tried to make a no-X emacs, so maybe something
has changed recently.

Specifically:

  (1) If I try to compose mail with `mail-user-agent' set to
      message-user-agent, I get the following backtrace:

        Debugger entered--Lisp error: (void-function x-popup-menu)
          x-popup-menu(nil (keymap "Message" (sort\ headers menu-item "Sort ...
          easy-menu-add((keymap "Message" (sort\ headers menu-item "Sort He ...
          message-mode()
          message-pop-to-buffer("*mail*")
          message-mail(nil nil nil nil nil nil nil)
          compose-mail(nil nil nil nil)
        * call-interactively(compose-mail)

      I'd think `easy-menu-add' should work regardless of X or no X,
      but it indeed calls x-popup-menu.

  (2) _Compiling_ `progmodes/ada-prj.el' fails, because it does (require
      'ada-mode), and progmodes/ada-mode.el contains a top-level call to

         (ada-create-menu)

      and `ada-create-menu' calls easy-menu-add.

Oddly, `easy-menu-add' contains the comment that "This is a nop on
emacs", but obviously it isn't!

Thanks,

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche

Re: problems with easy-menu-add on --without-x emacs

[Stefan Monnier]

> I notice several cases where things fail on an emacs compiled without X
> support, because they call `easy-menu-add', and it calls `x-popup-menu'
> which isn't defined when X support is disabled.  I don't recall such
> failures the last time I tried to make a no-X emacs, so maybe something
> has changed recently.

I've just removed the unnecessary call to x-popup-menu yesterday, as
a matter of fact, so things should work again.


        Stefan

Re: problems with easy-menu-add on --without-x emacs

[Richard Stallman]

    > I notice several cases where things fail on an emacs compiled without X
    > support, because they call `easy-menu-add', and it calls `x-popup-menu'
    > which isn't defined when X support is disabled.  I don't recall such
    > failures the last time I tried to make a no-X emacs, so maybe something
    > has changed recently.

    I've just removed the unnecessary call to x-popup-menu yesterday, as
    a matter of fact, so things should work again.

The call to x-popup-menu was intended to precompute info cached in the
menu, so that the menu would display more quickly.

Why do you think it was unnecessary?

Re: problems with easy-menu-add on --without-x emacs

[Stefan Monnier]

>> I notice several cases where things fail on an emacs compiled without X
>> support, because they call `easy-menu-add', and it calls `x-popup-menu'
>> which isn't defined when X support is disabled.  I don't recall such
>> failures the last time I tried to make a no-X emacs, so maybe something
>> has changed recently.

>     I've just removed the unnecessary call to x-popup-menu yesterday, as
>     a matter of fact, so things should work again.

> The call to x-popup-menu was intended to precompute info cached in the
> menu, so that the menu would display more quickly.

> Why do you think it was unnecessary?

I haven't been able to measure any actual speed difference on any machine
I have access to.  Maybe some years ago it made a difference, but it's lost
in the noise now.


        Stefan


PS: I also remember of a case where the precomputation was wrong because it
did not know that the menu was always going to be used when some other minor
mode was ON, and all the keybindings for the menu were provided by the minor
mode's map.  I can't remember the details, but my conclusion at that time
was that this specific optimization was not worth the trouble any more.

Re: problems with easy-menu-add on --without-x emacs

[Richard Stallman]

    I haven't been able to measure any actual speed difference on any machine
    I have access to.  Maybe some years ago it made a difference, but it's lost
    in the noise now.

You may be right.  If so, we might want to undocument that use
of x-popup-menu and remove all such calls.

But we should not be hasty in deciding this.  First let's verify that
this is generally true.  Did the machines you tested this on include
some that were rather slow by today's standards?  For instance,
machines of standard power for 5 years ago?

If the precomputation is still useful on 5% of machines in use, it is
worth keeping.  If it is still useful on 3% of machines in use, maybe
it is worth keeping.  If it is only 1%, then I think it is not worth
keeping.  I would think that 5-year-old PCs are several percent of the
PCs in use now, at least; that statistic ought to be available from
some sort of commercial statistics source.  Could someone please look
for this?

Until we determine what's right to do about menu precomputation,
please don't remove calls to x-popup-menu one by one.  The right fix
for this is to make that kind of call to x-popup-menu a no-op when not
using a window system, and put the call back where it was for the time
being.  Ok?

Re: problems with easy-menu-add on --without-x emacs

[Stefan Monnier]

> this is generally true.  Did the machines you tested this on include
> some that were rather slow by today's standards?  For instance,
> machines of standard power for 5 years ago?

I originally tested it on my trusty biprocessor 266Mhz Pentium II GNU/Linux
machine, which was pretty powerful 7 years ago.


        Stefan

Re: problems with easy-menu-add on --without-x emacs

[Alex Schroeder]

Richard Stallman <rms@gnu.org> writes:

> If the precomputation is still useful on 5% of machines in use, it is
> worth keeping.  If it is still useful on 3% of machines in use, maybe
> it is worth keeping.  If it is only 1%, then I think it is not worth
> keeping.  I would think that 5-year-old PCs are several percent of the
> PCs in use now, at least; that statistic ought to be available from
> some sort of commercial statistics source.  Could someone please look
> for this?

I don't have information from a commercial statistics source.
However:  One college I taught at two years ago here in Switzerland
*had* to use computers for at least five years.  This was some
government decision.  Therefore, you would expect a significant
percentage of five year old computers in some Swiss schools.  They
made significant efforts to extend the lifespan of their hardware.

Alex.
-- 
.O.  http://www.emacswiki.org/alex/
..O  Schroeder's fourth law:
OOO  None of your friends and coworkers share your taste in music.

Re: problems with easy-menu-add on --without-x emacs

[Richard Stallman]

    I originally tested it on my trusty biprocessor 266Mhz Pentium II GNU/Linux
    machine, which was pretty powerful 7 years ago.

Does anyone have access to info about what fraction of machines
in use today are less powerful than that?

Re: problems with easy-menu-add on --without-x emacs

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I originally tested it on my trusty biprocessor 266Mhz Pentium
>     II GNU/Linux machine, which was pretty powerful 7 years ago.
> 
> Does anyone have access to info about what fraction of machines
> in use today are less powerful than that?

Well, my desktop machine is a 133MHz Pentium.  My notebook is a
600MHz processor, but I doubt it would be faster in things like
kernel compilation that a dual 266MHz machine.

But "fraction of machines in use today" would be a totally misleading
number: probably most of today's machines are used for "simple text
processing under Windows", meaning that they have awful processing
requirements for tolerable updates.  I know that in most shops I've
been working, the most powerful machines were used by the secretaries.

In short: I think that the average processing power of machines
typically running Emacs might be severely below the average of "in use
today".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: problems with easy-menu-add on --without-x emacs

[Richard Stallman]

    Well, my desktop machine is a 133MHz Pentium.

It would be useful for you to try nulling out menu bar precomputation,
and see if you notice any slowdown on that machine.

    In short: I think that the average processing power of machines
    typically running Emacs might be severely below the average of "in use
    today".

It could well be true.

Re: problems with easy-menu-add on --without-x emacs

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Well, my desktop machine is a 133MHz Pentium.
> 
> It would be useful for you to try nulling out menu bar
> precomputation, and see if you notice any slowdown on that machine.

I almost never used the menu-bar, and yes, when I did, clicking on it
for the first time always caused a significant delay.  Quite enough to
make you realize "uh, that's the first time in that session".  That's
with 21.3 IIRC (the machine is currently down).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: problems with easy-menu-add on --without-x emacs

[Richard Stallman]

    I almost never used the menu-bar, and yes, when I did, clicking on it
    for the first time always caused a significant delay.

The idea of the precomputation is to avoid most of that delay (to
cause it to happen before Emacs is dumped, in fact).  So I wonder
whether precomputation is really operating properly for you.  It
sounds like maybe it is not.