Re: Supporting :eval

The following message is a courtesy copy of an article
that has been posted to comp.emacs.xemacs as well.

Hi,

For the newcomers, here is the relevant section from C-h v
modeline-format (Gnu Emacs).

For a list of the form `(:eval FORM)', FORM is evaluated and the
result is used as a mode line element.


"Stephen J. Turnbull" <[email protected]> writes:

> If you really want something to happen, please move the thread to
> [email protected].

I have put a CC, this should be on xemacs-devel and c.e.x now.

Anyone replying -- please decide *which* thread you want to reply to
(I have just subscribed).

> >>>>> "Jóhann" == Jóhann Gunnar <[email protected]> writes:
> 
>     Jóhann> I think ":eval" is the cleanest solution, any alternative
>     Jóhann> should be using window-configuration-change-hook, which
>     Jóhann> XEmacs is also lacking.
> 
>:eval is unclean here.  We should not be running code to recompute a
> constant.  :eval is the right solution for things that might change
> even though the window's identity doesn't change.  But what you are
> doing is providing the window with a convenient identifier that
> doesn't change, right?

Right, this only changes when I use any of C-x [0123] + some stuff
like escreen.

> Specifiers are the right solution, but may require additional support
> such as window-configuration-hook (note how quickly XEmacs tastes
> diverge from GNU's---"change" is redundant here IMO because hooks
> happen during actions, and "window configuration" can easily be
> understood as "the act of configuring windows").

K, I'll read about specifiers -- hopefully that works.  But this looks
like I'll need to add run-hooks to some built in functions -- or is
this something I wouldn't need to do myself?

I have already ported the :eval support to XEmacs, and a patch is
ready to be sent.  Unfortunately, every modeline displays the number
of the current-window (changes when I select another window).  This
was an *unexpected* bug.  Perhaps XEmacs' redisplay engine is designed
completely different?  (I mean, different in a way to make this
impossible) Or the lisp I wrote to port the mode is causing the bug
with some side effects.  On another note, using it to dispaly the
window number seems to put XEmacs in an endless loop (I hope that is
some sort of a lisp bug in the mode).  Not using the feature is of
course, not causing any bugs (I hope).

The actual window numbers as such come from Gnu Emacs' (window-list),
which returns a fixed list (independent of current-window).  In
XEmacs, I did the same thing by starting the window list with the
minibuffer; then moving the minibuffer to the end of the list to get
the same numericals as in Gnu.

> You misunderstand.  GNU compatibility gets the feature discussed, but
> it is not anywhere near close to a sufficient argument for inclusion.
> Frequently GNU features are undesigned and incoherent, or they
> conflict with or duplicate existing XEmacs functionality, and XEmacs
> tries to support the functionality in a different way.

Oh, well, I guess that't not really a problem.


Have fun,

Johann

-- 
Emacs is not a text editor -- it's a way of life