bug#45125: Subject: 28.0.50; defvar dynamics

bug#45125: Subject: 28.0.50; defvar dynamics

[Andreas Röhler]

Recipe:

Evaluate defvar forms at bottom in order using C-x C-e, which runs 
command eval-last-sexp here.

Evaluate the message-form C-x C-e

message-form outputs "a: 2",  i.e. "a" was dynamically updated
This contradicts saying in File: elisp.info,  Node: Defining Variables:

"But if SYMBOL is not void, VALUE is not evaluated, and SYMBOL’s value 
is left unchanged."

(defvar a 0)
(defvar a 1)
(defvar a 2)

(message "a: %s" a)

---

In GNU Emacs 28.0.50 (build 1, i686-pc-linux-gnu, GTK+ Version 3.14.5, 
cairo version 1.14.0)
  of 2020-11-19
Repository revision: 3963aea4f4a22da0c1fb8ca8ca80b59c58373811
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11604000
System Description: Debian GNU/Linux 8 (jessie)

Configured using:
  'configure --with-modules --with-mailutils'

Configured features:
XPM JPEG TIFF GIF PNG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY ACL
GNUTLS LIBXML2 FREETYPE LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE
XIM MODULES THREADS PDUMPER

Important settings:
   value of $LANG: de_DE.UTF-8
   locale-coding-system: utf-8-unix

Major mode: ELisp/d

Minor modes in effect:
   tooltip-mode: t
   global-eldoc-mode: t
   eldoc-mode: t
   electric-indent-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

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml easymenu mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 8 146139 6477)
  (symbols 24 30198 1)
  (strings 16 65257 1523)
  (string-bytes 1 1053500)
  (vectors 8 12265)
  (vector-slots 4 176703 11288)
  (floats 8 22 41)
  (intervals 28 209 13)
  (buffers 560 11)
  (heap 1024 12583 926))

bug#45125: Subject: 28.0.50; defvar dynamics

[Lars Ingebrigtsen]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> Evaluate defvar forms at bottom in order using C-x C-e, which runs
> command eval-last-sexp here.
>
> Evaluate the message-form C-x C-e
>
> message-form outputs "a: 2",  i.e. "a" was dynamically updated
> This contradicts saying in File: elisp.info,  Node: Defining Variables:
>
> "But if SYMBOL is not void, VALUE is not evaluated, and SYMBOL’s value
> is left unchanged."

See NEWS:

** 'eval-last-sexp' now handles 'defvar'/'defcustom'/'defface' specially.
This command would previously not redefine values defined by these
forms, but this command has now been changed to work more like
'eval-defun', and reset the values as specified.


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45125: Subject: 28.0.50; defvar dynamics

[Drew Adams]

> See NEWS:
> 
> ** 'eval-last-sexp' now handles 'defvar'/'defcustom'/'defface'
> specially.
> This command would previously not redefine values defined by these
> forms, but this command has now been changed to work more like
> 'eval-defun', and reset the values as specified.

Yes, well, this does mean that you can no longer realize
the old behavior.

It's good to be able to interactively evaluate an
individual defvar, to have updated text take effect.

But by putting this on `C-x C-e' it means that you can no
longer select a whole bunch of code that might include
some defvars, and be able to count on the defvars having
their normal behavior (eval only when not yet initialized).

It might be good to have some way of getting the best of
both worlds.  Unfortunately, prefix args of various sorts
are already defined, and there's no easy way to have a
prefix arg that's orthogonal (i.e., can apply across the
other prefix-arg behaviors).

Of course, we still have `eval-region'.  Still, there's a
loss here, even if there's some gain.

IIRC, the main motivation for this change was the repeated
complaint that `C-M-x' doesn't update a `defface'.  How we
ended up with a wholesale change of `C-x C-e', including
for `defvar', I'm not certain.  Seems a bit of a shame, no?

bug#45125: Subject: 28.0.50; defvar dynamics

[Andreas Röhler]

IAW: evaluating interactively may yield a different result than loading 
that code from a script?

bug#45125: Subject: 28.0.50; defvar dynamics

[Lars Ingebrigtsen]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> IAW: evaluating interactively may yield a different result than
> loading that code from a script?

That has always been the case with the C-M-x command.  C-x C-e is now
consistent with that command.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45125: Subject: 28.0.50; defvar dynamics

[Andreas Röhler]

On 09.12.20 13:56, Lars Ingebrigtsen wrote:
> Andreas Röhler <andreas.roehler@easy-emacs.de> writes:
>
>> IAW: evaluating interactively may yield a different result than
>> loading that code from a script?
> That has always been the case with the C-M-x command.  C-x C-e is now
> consistent with that command.
>
Understand that thought as kind of convenience-feature. However, 
problems for testing and debugging arise from this inconsistency.

bug#45125: Subject: 28.0.50; defvar dynamics

[Lars Ingebrigtsen]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> Understand that thought as kind of convenience-feature. However,
> problems for testing and debugging arise from this inconsistency.

Eval-region and friends still work the same as before.

If you're doing an `C-x C-e' on a `defvar' form, it doesn't seem like it
should be surprising that something happens.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#45125: Subject: 28.0.50; defvar dynamics

[Drew Adams]

> > Understand that thought as kind of convenience-feature. However,
> > problems for testing and debugging arise from this inconsistency.
> 
> Eval-region and friends still work the same as before.
> 
> If you're doing an `C-x C-e' on a `defvar' form, it doesn't seem like
> it should be surprising that something happens.

What if you do `C-x C-e' on a `let' or a `progn' or
a `when' or a <whatever> that contains a `defvar'?

For acting on a single `defvar' we already had (and
still have) `C-M-x'.  Now we've lost the ability to
use `C-x C-e' on an arbitrary sexp and have its
contained `defvar's be handled as they would be by
`eval-region'.

At the very least, I think this (big) difference
should be prominently called out in the doc (not
just doc strings) - letting users know that, in
effect', `C-x C-e' (now) behaves differently from
`eval-region'.

Some differences in behavior can be handy.  But
quirks can also lead to confusion.  The previous
behavior has existed for decades, and I'm not
aware of any complaints about it.

The case of `defface' is different.  There, the
(longstanding) complaint has been that it is the
outlier (IOW, a complaint _against_ an exception)
when it comes to `C-M-x'.  (And that odd behavior
is all the worse because `C-M-x' on a `defface'
echoes the face name, just as if it actually did
update the face definition.)

Really, these constructs deserved (still deserve?)
a serious general reconsideration, to perhaps
increase consistency and user-friendly behavior.
Instead, it looks like we got a quick reflex to a
request out of the blue - after long longstanding
behavior.

Don't get me wrong.  I'm glad that the question
was at least raised again and finally considered.
I just don't think we're really there yet.