bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30078: 27.0.50; Use lexical-binding for M-:


From: Stefan Monnier
Subject: bug#30078: 27.0.50; Use lexical-binding for M-:
Date: Fri, 12 Jan 2018 13:47:07 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> Don't you also want to change this occurrence in `command-line'?
>
> #+begin_src emacs-lisp
>   ;; If *scratch* exists and init file didn't change its mode, initialize it.
>   (if (get-buffer "*scratch*")
>       (with-current-buffer "*scratch*"
>       (if (eq major-mode 'fundamental-mode)
>           (funcall initial-major-mode))))
> #+end_src

Ah, so that's where it is, thanks.

> So far, lexical-binding in *scratch* is nil with emacs -Q with your
> patch.

That's what I was seeing as well, indeed :-(

> Maybe also check that evaluating the expression `lexical-binding'
> returns a result that is consistent with the evaluation behavior.

I already know that the check will fail.  Is it important?

In general the value of the variable lexical-binding during evaluation
of the code is not directly related to whether the code is evaluated
using lexical rules or not.  Within macros, Emacs tries to make sure
that lexical-binding reflects whether the code returned by the macro
will use lexical scoping or not (so that the macro can adjust the code
it generates accordingly), but other than that, the two are
largely independent (which is why (setq lexical-binding t) is not the
right way to enable lexical scoping in a file).

> In particular, evaluating lexical-binding in M-x ielm RET still gives
> nil - that's confusing.

Right (well, it doesn't always give you nil: it depends on the value of
lexical-binding in the buffer currently selected to evaluate the IELM
expressions).
But this discrepancy also shows up in various other contexts.  Eg.:

    ;; -*- lexical-binding:t -*-
    (defun my-test ()
      (interactive)
      (message "%S" lexical-binding))

will give you a lexically scoped command which will tell you the value
of lexical-binding at the time&place you run the command, which will
sometimes be t and sometimes not.

I'm not sure we should try to encourage the user to think a piece of
code can check the value of `lexical-binding` to know if it's being
evaluated using lexical scoping rules.


        Stefan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]