Extended menu items, when are :enable and :filter computed?

Extended menu items, when are :enable and :filter computed?

[Lennart Borgman]

I think at least for me it is impossible to understand from the 
documentation when :enable and :filter in a menu-item list is computed. 
I believe the documentation should be improved.

 From my simple tests is seems like the argument to :filter is computed 
every time the menubar is accessed. It is not really what I would expect 
when this is in a submenu. Is this behaviour intentional?

The same seems to be true for the argument to :enable. Is this intentional?

What I mean is that I would expect those argument to be computed when 
they are needed, ie when the submenu is displayed.

Re: Extended menu items, when are :enable and :filter computed?

[Stefan Monnier]

> I think at least for me it is impossible to understand from the
> documentation when :enable and :filter in a menu-item list is
> computed. I believe the documentation should be improved.

>  From my simple tests is seems like the argument to :filter is computed
>  every time the menubar is accessed. It is not really what I would expect
>  when this is in a submenu. Is this behaviour intentional?

Depends what you mean by "intentional".
When the menubar is accessed, the whole menu tree is computed before handing
it to the toolkit: submenus are precomputed rather than being computed on
the fly when the user actually accesses them.

> The same seems to be true for the argument to :enable. Is this intentional?

Same thing.

I don't think this is considered as a feature (and I thought it was in
the TODO list to change it so that submenus are only constructed when
needed, but I can't seem to find it in the TODO file), but nobody's worked
on changing it.

Note that in most cases this only matters for reasons of performance.


        Stefan

Re: Extended menu items, when are :enable and :filter computed?

[Richard Stallman]

    I don't think this is considered as a feature (and I thought it was in
    the TODO list to change it so that submenus are only constructed when
    needed, but I can't seem to find it in the TODO file),

The reason for precomputing all the submenus is so that the toolkit
can display them all autonomously.  I think that's the only way some
toolkits can do it, so the idea of changing this is a non-starter.

Re: Extended menu items, when are :enable and :filter computed?

[Stefan Monnier]

>     I don't think this is considered as a feature (and I thought it was in
>     the TODO list to change it so that submenus are only constructed when
>     needed, but I can't seem to find it in the TODO file),

> The reason for precomputing all the submenus is so that the toolkit
> can display them all autonomously.  I think that's the only way some
> toolkits can do it, so the idea of changing this is a non-starter.

If the only toolkits which could do it are non-free or "insignificant", then
I agree, but otherwise it may still make sense to provide it as
a toolkit-dependent optimization.  But indeed, it means that even if we
manage to change it for some toolkits, you won't be able to rely on
your :filters and :enables being called only when strictly necessary.

I've always viewed such a change as a performance improvement for those
cases where we use large dynamically-generated menus or menus with lots of
shortcuts to compute (X-Symbol comes to mind).

AFAIK XEmacs does compute menus on-demand.


        Stefan

Re: Extended menu items, when are :enable and :filter computed?

[Richard Stallman]

    I've always viewed such a change as a performance improvement for those
    cases where we use large dynamically-generated menus or menus with lots of
    shortcuts to compute (X-Symbol comes to mind).

Is this optimization really worth while on modern computers?

Re: Extended menu items, when are :enable and :filter computed?

[Lennart Borgman]

Richard Stallman wrote:
>     I've always viewed such a change as a performance improvement for those
>     cases where we use large dynamically-generated menus or menus with lots of
>     shortcuts to compute (X-Symbol comes to mind).
>
> Is this optimization really worth while on modern computers?
>   
Yes, I believe so. If the building involves accessing the file system 
(which is rather likely for a program like Emacs) then it could take 
some time.

Re: Extended menu items, when are :enable and :filter computed?

[Richard Stallman]

    > Is this optimization really worth while on modern computers?

    Yes, I believe so. If the building involves accessing the file system 
    (which is rather likely for a program like Emacs) then it could take 
    some time.

I am not sure what "building" refers to here.  We are talking
about testing whether menu items are active.

You seem to say that you speculate this is likely to mean looking at
the file system.  However, to me that seems like a rather unlikely way
to control activity of Emacs menu items.

Are there really Emacs Lisp programs that control menu item activity
based on looking for files?

Re: Extended menu items, when are :enable and :filter computed?

[Stefan Monnier]

>     I've always viewed such a change as a performance improvement for
>     those cases where we use large dynamically-generated menus or menus
>     with lots of shortcuts to compute (X-Symbol comes to mind).

> Is this optimization really worth while on modern computers?

Of course.  The speed of the average computer is not relevant since faster
computers simply means that the package authors can put more complex code in
:enable and :filter.


        Stefan

Re: Extended menu items, when are :enable and :filter computed?

[Richard Stallman]

    > Is this optimization really worth while on modern computers?

    Of course.  The speed of the average computer is not relevant since faster
    computers simply means that the package authors can put more complex code in
    :enable and :filter.

They can, but I suspect most of them do not.

Re: Extended menu items, when are :enable and :filter computed?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I've always viewed such a change as a performance improvement
>     for those cases where we use large dynamically-generated menus
>     or menus with lots of shortcuts to compute (X-Symbol comes to
>     mind).
>
> Is this optimization really worth while on modern computers?

Computing menus might require loading Lisp packages.  And many free
software developers are not particularly wealthy and able to keep up
with the trends in current hardware, which are mostly due to playing
games (running Windows XP with its compulsory registration and
security problems might be considered a special case of online
gambling).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Extended menu items, when are :enable and :filter computed?

[Richard Stallman]

    Computing menus might require loading Lisp packages.

Theoretically true, but seems unlikely in practice.  Anyway, it will
only be necessary to load them once, the first time.

      And many free
    software developers are not particularly wealthy and able to keep up
    with the trends in current hardware,

So maybe they have machines a few years old.  The question is still
important.

I think this optimization is not needed any more, so I don't want to
put it in etc/TODO.  I don't want to do it at all, unless people show
there is a real need for it today.  Not just a theoretical need, but a
substantial practical need.  Not just a speculation but actual facts.

Re: Extended menu items, when are :enable and :filter computed?

[Lennart Borgman]

Richard Stallman wrote:
> I think this optimization is not needed any more, so I don't want to
> put it in etc/TODO.  I don't want to do it at all, unless people show
> there is a real need for it today.  Not just a theoretical need, but a
> substantial practical need.  Not just a speculation but actual facts.
>   
I do not know if my example is important, but here is how this problem 
came to my mind:

I am trying to use the excellent nxml-mode to build a web authoring 
environment in Emacs. This mode can tell what tags are allowed at a 
certain position in an XHTML document. This information could be used 
for building menus which perhaps would be good for beginners. However 
there are some computations required for that of course.

In this web authoring environment there are also cases when the 
existence of certain files could make difference for what to enable in 
the menus.

I realize this is not a very strong case. I could for example use a 
popup menu instead to show what tags are allowed. And the normal way to 
check this in nxhtml-mode is just completion the normal way in Emacs.

Re: Extended menu items, when are :enable and :filter computed?

[Richard Stallman]

    This mode can tell what tags are allowed at a 
    certain position in an XHTML document. This information could be used 
    for building menus which perhaps would be good for beginners. However 
    there are some computations required for that of course.

If you really implement this, we can see how fast it runs
and whether it needs optimization.

Re: Extended menu items, when are :enable and :filter computed?

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

>     Computing menus might require loading Lisp packages.
>
> Theoretically true, but seems unlikely in practice.  Anyway, it will
> only be necessary to load them once, the first time.

The Customize menus basically needs to load everything.  They have
been disabled for GNU Emacs for that reason, but was fully enabled for
XEmacs (with delayed generation) last time I checked (many years ago).

They are not really that practical though, the menu structure becomes
too deeply nested to be useful.

Re: Extended menu items, when are :enable and :filter computed?

[Richard Stallman]

    The Customize menus basically needs to load everything.

Sorry, what is the "Customize menus"?

Re: Extended menu items, when are :enable and :filter computed?

[Per Abrahamsen]

Richard Stallman <rms@gnu.org> writes:

>     The Customize menus basically needs to load everything.
>
> Sorry, what is the "Customize menus"?

>From a *Customize* buffer, select Custom -> Customize.  You get a the
'customize' custom group as a menu structure.  The code that generates
this menu structure works (or worked) for any custom group group,
including 'emacs'.  That way you basically get a menu structure with
all customize options as leaves.

Re: Extended menu items, when are :enable and :filter computed?

[Richard Stallman]

    >From a *Customize* buffer, select Custom -> Customize.  You get a the
    'customize' custom group as a menu structure.  The code that generates
    this menu structure works (or worked) for any custom group group,
    including 'emacs'.  That way you basically get a menu structure with
    all customize options as leaves.

It sounds like that duplicates the navigation facilities of the Custom
buffers and customize-browse.  It seems superfluous.

It seems to me we might as well get rid of this entirely.

Does anyone disagree?

Re: Extended menu items, when are :enable and :filter computed?

[Richard Stallman]

     From my simple tests is seems like the argument to :filter is computed 
    every time the menubar is accessed. It is not really what I would expect 
    when this is in a submenu. Is this behaviour intentional?

Yes.  The toolkit displays the menus, and Emacs does not even know which
ones it displays.  Emacs must provide the full info in advance.

There is no choice about this.

Why do you care?  The user COULD look at all the submenus at any time,
so why do you care whether he does look at them all, or only at some?