unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#14694: 24.3; format-mode-line failing with :eval form via a variable in a conditional construct
@ 2013-06-23  5:11 Phil Sainty
  2013-06-23 15:26 ` Eli Zaretskii
  2013-06-23 16:45 ` Stefan Monnier
  0 siblings, 2 replies; 4+ messages in thread
From: Phil Sainty @ 2013-06-23  5:11 UTC (permalink / raw)
  To: 14694

 From emacs -Q the following returns an empty string, which seems
like a bug:

ELISP> (setq indirect-eval '(:eval "indirect eval"))
ELISP> (format-mode-line '(t indirect-eval "else"))
""


Other tests have worked as expected:

ELISP> (format-mode-line '(t "then" "else"))
"then"

ELISP> (setq indirect-string "indirect string")
ELISP> (format-mode-line '(t indirect-string "else"))
"indirect string"

ELISP> (format-mode-line '(:eval "direct eval"))
"direct eval"

ELISP> (format-mode-line '(t (:eval "direct eval") "else"))
"direct eval"

ELISP> (setq indirect-eval '(:eval "indirect eval"))
ELISP> (format-mode-line indirect-eval)
"indirect eval"


It just seems to be the combination of the (:eval) form as the value
of a variable in a conditional form which is failing.



And a related question, if I may: Other than wrapping advice around
format-mode-line to let-bind a variable, is there any way for me to
ascertain whether a mode line construct is being processed for an
actual mode line redraw (in which case format-mode-line is not called),
as opposed to some other situation (e.g. describe-mode) in which
format-mode-line will be used?

My goal is to use the conditional construct to display the original
value when calling format-mode-line, but an alternative value in the
mode line itself, with the two values being stored in buffer local
variables. At the moment I'm using advice to supply the condition
(and of course I found the above bug when testing that my code worked
for the different types of construct).


thanks,
-Phil





In GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.10)
  of 2013-06-23 on xerxes
Windowing system distributor `The X.Org Foundation', version 11.0.11300000
System Description:	Ubuntu 12.04.2 LTS

Important settings:
   value of $LANG: en_NZ.UTF-8
   locale-coding-system: utf-8-unix
   default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
   tooltip-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
M-x <up> r e p o r t - e m a <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
user-error: Beginning of history; no preceding item

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)






^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#14694: 24.3; format-mode-line failing with :eval form via a variable in a conditional construct
  2013-06-23  5:11 bug#14694: 24.3; format-mode-line failing with :eval form via a variable in a conditional construct Phil Sainty
@ 2013-06-23 15:26 ` Eli Zaretskii
  2013-06-23 16:45 ` Stefan Monnier
  1 sibling, 0 replies; 4+ messages in thread
From: Eli Zaretskii @ 2013-06-23 15:26 UTC (permalink / raw)
  To: Phil Sainty; +Cc: 14694

> Date: Sun, 23 Jun 2013 17:11:57 +1200
> From: Phil Sainty <psainty@orcon.net.nz>
> 
>  From emacs -Q the following returns an empty string, which seems
> like a bug:
> 
> ELISP> (setq indirect-eval '(:eval "indirect eval"))
> ELISP> (format-mode-line '(t indirect-eval "else"))
> ""

It's not a bug.  The Lisp expressions supported in mode-line format
are those documented in the manual, and nothing else.  In particular,
the ':eval' part must appear explicitly, and any symbol stands for its
value (which is not eval'ed).

IOW, you seem to expect a full-blown Lisp evaluation there, but that
was never implemented or intended.

> And a related question, if I may: Other than wrapping advice around
> format-mode-line to let-bind a variable, is there any way for me to
> ascertain whether a mode line construct is being processed for an
> actual mode line redraw (in which case format-mode-line is not called),
> as opposed to some other situation (e.g. describe-mode) in which
> format-mode-line will be used?
> 
> My goal is to use the conditional construct to display the original
> value when calling format-mode-line, but an alternative value in the
> mode line itself, with the two values being stored in buffer local
> variables. At the moment I'm using advice to supply the condition
> (and of course I found the above bug when testing that my code worked
> for the different types of construct).

I don't understand: format-mode-line is a function you cannot change
or hook, so where exactly do you want to display a different value?
Both format-mode-line and the internal code that processes the mode
line format in the display engine access the same variable.

And anyway, why would you need format-mode-line to produce a different
value?





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#14694: 24.3; format-mode-line failing with :eval form via a variable in a conditional construct
  2013-06-23  5:11 bug#14694: 24.3; format-mode-line failing with :eval form via a variable in a conditional construct Phil Sainty
  2013-06-23 15:26 ` Eli Zaretskii
@ 2013-06-23 16:45 ` Stefan Monnier
  2013-06-23 17:48   ` Phil Sainty
  1 sibling, 1 reply; 4+ messages in thread
From: Stefan Monnier @ 2013-06-23 16:45 UTC (permalink / raw)
  To: Phil Sainty; +Cc: 14694

ELISP> (setq indirect-eval '(:eval "indirect eval"))
ELISP> (format-mode-line '(t indirect-eval "else"))
> ""

You need (put 'indirect-eval 'risky-local-variable t)


        Stefan





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#14694: 24.3; format-mode-line failing with :eval form via a variable in a conditional construct
  2013-06-23 16:45 ` Stefan Monnier
@ 2013-06-23 17:48   ` Phil Sainty
  0 siblings, 0 replies; 4+ messages in thread
From: Phil Sainty @ 2013-06-23 17:48 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 14694

On 24/06/2013 04:45, Stefan Monnier wrote:
> ELISP> (setq indirect-eval '(:eval "indirect eval"))
> ELISP> (format-mode-line '(t indirect-eval "else"))
>> ""
>
> You need (put 'indirect-eval 'risky-local-variable t)

Argh, I see that in the documentation now. Thank you Stefan
(and Eli).

I'm afraid I made an embarrassing rookie mistake in checking
the result of (format-mode-line indirect-eval) instead of
(format-mode-line 'indirect-eval), and thinking that I was
seeing an inconsistency when there was none. Otherwise I'd no
doubt have spotted the information about that property.

My apologies; please close.


Eli asked:
 > And anyway, why would you need format-mode-line to produce a
 > different value?

The specific goal was to enable customisation of the display of
`mode-name' in the mode line (generally to abbreviate it and reduce
the space used) *without* also affecting what is displayed when that
variable is processed in other contexts (such as by `describe-mode'),
in which cases `format-mode-line' will be called.

Advising `format-mode-line' to provide an indicator variable to use
in a conditional construct does facilitate this. I just wanted check
that I wasn't missing another approach which didn't require the advice.


-Phil







^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2013-06-23 17:48 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-23  5:11 bug#14694: 24.3; format-mode-line failing with :eval form via a variable in a conditional construct Phil Sainty
2013-06-23 15:26 ` Eli Zaretskii
2013-06-23 16:45 ` Stefan Monnier
2013-06-23 17:48   ` Phil Sainty

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).