unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Gnus using lexical-binding
@ 2021-01-29 23:11 Stefan Monnier
  2021-01-30  6:34 ` Lars Ingebrigtsen
                   ` (4 more replies)
  0 siblings, 5 replies; 27+ messages in thread
From: Stefan Monnier @ 2021-01-29 23:11 UTC (permalink / raw)
  To: emacs-devel

I'm working on converting all the lisp/gnus files to use
lexical-binding.  I have a first version of the code ready and pushed to
`scratch/lexical-gnus`.  It works for me, but please test it because my
use of Gnus only exercises a small fraction of its functionality
and packages.

And please, after testing it, tell me how it went, regardless if you
encountered problems or not.

I'll be rebasing that branch as I split it into a few separate commits
to clean up its history, so don't expect to be able to track it
with merges.


        Stefan




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

* Re: Gnus using lexical-binding
  2021-01-29 23:11 Gnus using lexical-binding Stefan Monnier
@ 2021-01-30  6:34 ` Lars Ingebrigtsen
  2021-01-30  8:35 ` Eli Zaretskii
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 27+ messages in thread
From: Lars Ingebrigtsen @ 2021-01-30  6:34 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'm working on converting all the lisp/gnus files to use
> lexical-binding.  I have a first version of the code ready and pushed to
> `scratch/lexical-gnus`.  It works for me, but please test it because my
> use of Gnus only exercises a small fraction of its functionality
> and packages.

I gave it a brief spin now, and I didn't encounter any problems.

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



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

* Re: Gnus using lexical-binding
  2021-01-29 23:11 Gnus using lexical-binding Stefan Monnier
  2021-01-30  6:34 ` Lars Ingebrigtsen
@ 2021-01-30  8:35 ` Eli Zaretskii
  2021-01-30 13:43   ` Stefan Kangas
  2021-01-30 15:07 ` Basil L. Contovounesios
                   ` (2 subsequent siblings)
  4 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2021-01-30  8:35 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 29 Jan 2021 18:11:35 -0500
> 
> I'm working on converting all the lisp/gnus files to use
> lexical-binding.  I have a first version of the code ready and pushed to
> `scratch/lexical-gnus`.  It works for me, but please test it because my
> use of Gnus only exercises a small fraction of its functionality
> and packages.

Thanks.

Btw, I think we could benefit from a detailed guide for how to convert
a package to lexical-binding, enumerating the steps to take, tools and
Emacs commands to use, possible problems and how to solve them, etc.
Somewhere in admin/notes/, perhaps?



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

* Re: Gnus using lexical-binding
  2021-01-30  8:35 ` Eli Zaretskii
@ 2021-01-30 13:43   ` Stefan Kangas
  2021-01-30 13:52     ` Eli Zaretskii
  2021-01-30 15:24     ` Stefan Monnier
  0 siblings, 2 replies; 27+ messages in thread
From: Stefan Kangas @ 2021-01-30 13:43 UTC (permalink / raw)
  To: Eli Zaretskii, Stefan Monnier; +Cc: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> Btw, I think we could benefit from a detailed guide for how to convert
> a package to lexical-binding, enumerating the steps to take, tools and
> Emacs commands to use, possible problems and how to solve them, etc.
> Somewhere in admin/notes/, perhaps?

What about `(elisp) Converting to Lexical Binding'?

Should we perhaps just expand that?  I'm sure third-party package
developers could also benefit from any details we would like to add.



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

* Re: Gnus using lexical-binding
  2021-01-30 13:43   ` Stefan Kangas
@ 2021-01-30 13:52     ` Eli Zaretskii
  2021-01-30 14:08       ` Eli Zaretskii
  2021-01-30 15:24     ` Stefan Monnier
  1 sibling, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2021-01-30 13:52 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: monnier, emacs-devel

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sat, 30 Jan 2021 05:43:13 -0800
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Btw, I think we could benefit from a detailed guide for how to convert
> > a package to lexical-binding, enumerating the steps to take, tools and
> > Emacs commands to use, possible problems and how to solve them, etc.
> > Somewhere in admin/notes/, perhaps?
> 
> What about `(elisp) Converting to Lexical Binding'?

Is that all we have to say on that topic?

It also says "experimental" about some part of it, which to me spells
"use at your own peril".

> Should we perhaps just expand that?  I'm sure third-party package
> developers could also benefit from any details we would like to add.

I think any experience with this job should be beneficial.  Not sure
it all belongs to the manual, though, which is why I suggested to put
it in admin/notes.

Thanks.



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

* Re: Gnus using lexical-binding
  2021-01-30 13:52     ` Eli Zaretskii
@ 2021-01-30 14:08       ` Eli Zaretskii
  0 siblings, 0 replies; 27+ messages in thread
From: Eli Zaretskii @ 2021-01-30 14:08 UTC (permalink / raw)
  To: stefankangas, monnier; +Cc: emacs-devel

> Date: Sat, 30 Jan 2021 15:52:15 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> > What about `(elisp) Converting to Lexical Binding'?
> 
> Is that all we have to say on that topic?

And btw, why is this only on master?  Chances are, when Emacs 28 will
be out, most of the conversion will have happened already.  So people
will need this information *now*, and we should backport this to the
emacs-27 branch, I think.



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

* Re: Gnus using lexical-binding
  2021-01-29 23:11 Gnus using lexical-binding Stefan Monnier
  2021-01-30  6:34 ` Lars Ingebrigtsen
  2021-01-30  8:35 ` Eli Zaretskii
@ 2021-01-30 15:07 ` Basil L. Contovounesios
  2021-01-30 17:40   ` Stefan Monnier
  2021-01-30 16:10 ` Andy Moreton
  2021-01-31  9:13 ` David Engster
  4 siblings, 1 reply; 27+ messages in thread
From: Basil L. Contovounesios @ 2021-01-30 15:07 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'm working on converting all the lisp/gnus files to use
> lexical-binding.  I have a first version of the code ready and pushed to
> `scratch/lexical-gnus`.  It works for me, but please test it because my
> use of Gnus only exercises a small fraction of its functionality
> and packages.

Thanks.

> And please, after testing it, tell me how it went, regardless if you
> encountered problems or not.

Bootstrapping emits the following warnings:

  In mail-add-attachment:
  mail/sendmail.el:1809:25: Warning: ‘mm-default-file-encoding’ is an obsolete
      function (as of future); use ‘mm-default-file-type’ instead.

  In mh-minibuffer-read-type:
  mh-e/mh-mime.el:1728:24: Warning: ‘mm-default-file-encoding’ is an obsolete
      function (as of future); use ‘mm-default-file-type’ instead.

and starting Gnus only gets me as far as the splash screen; see the
attached backtrace, which I'm guessing is related to the following
setting:

  (setq-default
   gnus-group-line-format
   (concat "%M"           ; Marked articles
           "%S"           ; Subscription
           "%p"           ; Marked for processing
           "%m"           ; New mail
           "%B"           ; Open summary buffer
           "%P"           ; Topic indentation
           "%5y? %3T!"    ; Unread and ticked articles
           " : "          ; Colon
           "%(%-40,40c%)" ; Collapsed group name
           "%9u&dgroup;"  ; Last read
           "\n"))

(The last %-sequence is just a custom timestamp format.)

Let me know if you want me to test anything else out.

-- 
Basil


[-- Attachment #2: backtrace.el --]
[-- Type: application/emacs-lisp, Size: 2154 bytes --]

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

* Re: Gnus using lexical-binding
  2021-01-30 13:43   ` Stefan Kangas
  2021-01-30 13:52     ` Eli Zaretskii
@ 2021-01-30 15:24     ` Stefan Monnier
  1 sibling, 0 replies; 27+ messages in thread
From: Stefan Monnier @ 2021-01-30 15:24 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Eli Zaretskii, emacs-devel

>> Btw, I think we could benefit from a detailed guide for how to convert
>> a package to lexical-binding, enumerating the steps to take, tools and
>> Emacs commands to use, possible problems and how to solve them, etc.
>> Somewhere in admin/notes/, perhaps?
>
> What about `(elisp) Converting to Lexical Binding'?
>
> Should we perhaps just expand that?  I'm sure third-party package
> developers could also benefit from any details we would like to add.

In terms of tools and commands, this section indeed describes what
I use.

I'm not sure how much further we want to go with that.
The main other tool I use is my intuition and various heuristics:

For the "unused var" warning, I can usually guess based on the name
whether it should have a `defvar` or not: variables whose name has
a "package prefix" should almost always have a `defvar` while those who
have a short name should almost always use lexical scoping.
Adding more `defvar`s than needed is largely harmless during conversion
(it's arguably harmful in the long run, but that can be addresses
later), so the main risk is for those variables with a non-prefixed name
where we normally presume they can use lexical scoping but which may
nevertheless require dynamic scoping.  Furthermore, some of those cases
can occur without triggering any warning from the byte-compiler because
the var is not locally unused.

This can happen typically with code like

    (let ((foo X)
          (bar Y))
      ...
      (eval config-var)
      ...)

where `config-var` is defined to hold an ELisp form which has access to
variables `foo` and `bar`.  If you're the package author or are a heavy
user of the package there's a chance you know about it and can take it into
account when performing the conversion, but otherwise it can be tricky
to figure it out.

The only way I know is to search for uses of `eval`, `symbol-value`,
`intern`, and `set` (this list is sadly not exhaustive, e.g. some uses
may occur via `run-hooks`) to try and find code that relies on access to
variables via dynamic scoping and then examine each one to try and see
which variables it may refer to, which is sometimes documented in
comments or docstrings.

This last part is tedious and rarely necessary, so I do it lazily,
i.e. when something indicates that it's probably necessary (e.g. because
of a regression found during testing, or because of some odd patterns in
the "unused variables" warnings, e.g. when the same set of unused
variable names appear a few times, tho sometimes these patterns are due
to copy&paste as well).


        Stefan




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

* Re: Gnus using lexical-binding
  2021-01-29 23:11 Gnus using lexical-binding Stefan Monnier
                   ` (2 preceding siblings ...)
  2021-01-30 15:07 ` Basil L. Contovounesios
@ 2021-01-30 16:10 ` Andy Moreton
  2021-01-30 17:35   ` Stefan Monnier
  2021-01-31  9:13 ` David Engster
  4 siblings, 1 reply; 27+ messages in thread
From: Andy Moreton @ 2021-01-30 16:10 UTC (permalink / raw)
  To: emacs-devel

On Fri 29 Jan 2021, Stefan Monnier wrote:

> I'm working on converting all the lisp/gnus files to use
> lexical-binding.  I have a first version of the code ready and pushed to
> `scratch/lexical-gnus`.  It works for me, but please test it because my
> use of Gnus only exercises a small fraction of its functionality
> and packages.
>
> And please, after testing it, tell me how it went, regardless if you
> encountered problems or not.

Fails starting gnus for me. Setting `debug-on-error' gives backtrace:

Debugger entered--Lisp error: (void-variable gnus-tmp-level)
  (format "%c%c%d%c %6s %7d %s%c" gnus-tmp-marked-mark gnus-tmp-subscribed gnus-tmp-level gnus-tmp-process-marked (cond ((eq number t) "*") ((numberp number) (int-to-string (+ number (gnus-range-length (cdr (assq ... gnus-tmp-marked))) (gnus-range-length (cdr (assq ... gnus-tmp-marked)))))) (t number)) gnus-tmp-number-total gnus-group-indentation gnus-tmp-summary-live)
  (insert (format "%c%c%d%c %6s %7d %s%c" gnus-tmp-marked-mark gnus-tmp-subscribed gnus-tmp-level gnus-tmp-process-marked (cond ((eq number t) "*") ((numberp number) (int-to-string (+ number (gnus-range-length (cdr ...)) (gnus-range-length (cdr ...))))) (t number)) gnus-tmp-number-total gnus-group-indentation gnus-tmp-summary-live))
  (let (gnus-position) (insert (format "%c%c%d%c %6s %7d %s%c" gnus-tmp-marked-mark gnus-tmp-subscribed gnus-tmp-level gnus-tmp-process-marked (cond ((eq number t) "*") ((numberp number) (int-to-string (+ number (gnus-range-length ...) (gnus-range-length ...)))) (t number)) gnus-tmp-number-total gnus-group-indentation gnus-tmp-summary-live)) (setq gnus-position (point)) (insert (format "%-55s" (let* ((val (eval (if ... ... gnus-tmp-qualified-group))) (need (- 55 (string-width val)))) (if (> need 0) (concat nil val (make-string need 32)) val)))) (insert-char 32 (max (- 75 (current-column)) 0)) (add-text-properties (point) (progn (insert gnus-tmp-news-server) (point)) (cons 'face (cons (list 'italic 'default) '(gnus-face t)))) (insert "\n") (if gnus-position (put-text-property gnus-position 
 (1+ gnus-position) 'gnus-position t)))
  eval((let (gnus-position) (insert (format "%c%c%d%c %6s %7d %s%c" gnus-tmp-marked-mark gnus-tmp-subscribed gnus-tmp-level gnus-tmp-process-marked (cond ((eq number t) "*") ((numberp number) (int-to-string (+ number ... ...))) (t number)) gnus-tmp-number-total gnus-group-indentation gnus-tmp-summary-live)) (setq gnus-position (point)) (insert (format "%-55s" (let* ((val (eval ...)) (need (- 55 ...))) (if (> need 0) (concat nil val (make-string need 32)) val)))) (insert-char 32 (max (- 75 (current-column)) 0)) (add-text-properties (point) (progn (insert gnus-tmp-news-server) (point)) (cons 'face (cons (list 'italic 'default) '(gnus-face t)))) (insert "\n") (if gnus-position (put-text-property gnus-position (1+ gnus-position) 'gnus-position t))) t)
  gnus-group-insert-group-line("nndraft:drafts" 1 nil 0 (nndraft ""))
  gnus-topic-prepare-topic((("misc" visible nil nil)) 1 5 nil nil 1 nil)
  gnus-topic-prepare-topic((("Topics" visible nil nil) (("Cygwin" visible nil nil)) (("Emacs" visible nil nil)) (("Windows" visible nil nil)) (("Linux" visible nil nil)) (("IETF" visible nil nil)) (("Network" visible nil nil)) (("Developer" visible nil nil) (("Build Tools" visible nil nil)) (("GCC" visible nil nil)) (("LLVM" visible nil nil)) (("Libc" visible nil nil))) (("Languages" visible nil nil) (("C++" visible nil nil)) (("Rust" visible nil nil)) (("Python" visible nil nil)) (("Lua" visible nil nil)) (("Javascript" visible nil nil)) (("Scheme" visible nil nil)) (("Common Lisp" visible nil nil)) (("Haskell" visible nil nil))) (("Hardware" visible nil nil)) (("Blogs" visible nil nil)) (("misc" visible nil nil))) 0 5 nil nil 1 nil)
  gnus-group-prepare-topics(5 nil nil)
  gnus-group-list-groups(nil)
  #f(compiled-function () #<bytecode 0x991f1d1e36f151a>)()
  gnus-1(nil nil nil)
  gnus(nil)
  funcall-interactively(gnus nil)
  call-interactively(gnus record nil)
  command-execute(gnus record)
  execute-extended-command(nil "gnus" "gnus")
  funcall-interactively(execute-extended-command nil "gnus" "gnus")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)




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

* Re: Gnus using lexical-binding
  2021-01-30 16:10 ` Andy Moreton
@ 2021-01-30 17:35   ` Stefan Monnier
  2021-01-30 18:00     ` Andy Moreton
  0 siblings, 1 reply; 27+ messages in thread
From: Stefan Monnier @ 2021-01-30 17:35 UTC (permalink / raw)
  To: Andy Moreton; +Cc: emacs-devel

> Fails starting gnus for me. Setting `debug-on-error' gives backtrace:
>
> Debugger entered--Lisp error: (void-variable gnus-tmp-level)

Thanks.  EMACS_DYNVARS_FILE caught this one earlier today as well, indeed.


        Stefan




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

* Re: Gnus using lexical-binding
  2021-01-30 15:07 ` Basil L. Contovounesios
@ 2021-01-30 17:40   ` Stefan Monnier
  2021-02-08 19:10     ` Ted Zlatanov
  0 siblings, 1 reply; 27+ messages in thread
From: Stefan Monnier @ 2021-01-30 17:40 UTC (permalink / raw)
  To: Basil L. Contovounesios; +Cc: emacs-devel

> Bootstrapping emits the following warnings:
>
>   In mail-add-attachment:
>   mail/sendmail.el:1809:25: Warning: ‘mm-default-file-encoding’ is an obsolete
>       function (as of future); use ‘mm-default-file-type’ instead.
>
>   In mh-minibuffer-read-type:
>   mh-e/mh-mime.el:1728:24: Warning: ‘mm-default-file-encoding’ is an obsolete
>       function (as of future); use ‘mm-default-file-type’ instead.

Good catch, thanks.

> and starting Gnus only gets me as far as the splash screen; see the
> attached backtrace, which I'm guessing is related to the following
[...]
> Debugger entered--Lisp error: (void-variable gnus-tmp-marked)
[...]
>   gnus-group-insert-group-line("dummy.group" 0 nil 0 nil)

EMACS_DYNVARS_FILE had also found this one (actually, this one and the
`gnus-tmp-level` in that same `gnus-group.el` file are the only two new
problems that it found, so it was no better at finding problems than
Basil and Andy combined).

I've updated the branch accordingly.


        Stefan




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

* Re: Gnus using lexical-binding
  2021-01-30 17:35   ` Stefan Monnier
@ 2021-01-30 18:00     ` Andy Moreton
  2021-01-30 18:53       ` Stefan Monnier
  0 siblings, 1 reply; 27+ messages in thread
From: Andy Moreton @ 2021-01-30 18:00 UTC (permalink / raw)
  To: emacs-devel

On Sat 30 Jan 2021, Stefan Monnier wrote:

>> Fails starting gnus for me. Setting `debug-on-error' gives backtrace:
>>
>> Debugger entered--Lisp error: (void-variable gnus-tmp-level)
>
> Thanks.  EMACS_DYNVARS_FILE caught this one earlier today as well, indeed.

A little further, but:

Debugger entered--Lisp error: (void-variable number)
  (eq number t)
  (cond ((eq number t) "*") ((numberp number) (int-to-string (+ number (gnus-range-length (cdr (assq 'dormant gnus-tmp-marked))) (gnus-range-length (cdr (assq 'tick gnus-tmp-marked)))))) (t number))
  (format "%c%c%d%c %6s %7d %s%c" gnus-tmp-marked-mark gnus-tmp-subscribed gnus-tmp-level gnus-tmp-process-marked (cond ((eq number t) "*") ((numberp number) (int-to-string (+ number (gnus-range-length (cdr (assq ... gnus-tmp-marked))) (gnus-range-length (cdr (assq ... gnus-tmp-marked)))))) (t number)) gnus-tmp-number-total gnus-group-indentation gnus-tmp-summary-live)
  (insert (format "%c%c%d%c %6s %7d %s%c" gnus-tmp-marked-mark gnus-tmp-subscribed gnus-tmp-level gnus-tmp-process-marked (cond ((eq number t) "*") ((numberp number) (int-to-string (+ number (gnus-range-length (cdr ...)) (gnus-range-length (cdr ...))))) (t number)) gnus-tmp-number-total gnus-group-indentation gnus-tmp-summary-live))
  (let (gnus-position) (insert (format "%c%c%d%c %6s %7d %s%c" gnus-tmp-marked-mark gnus-tmp-subscribed gnus-tmp-level gnus-tmp-process-marked (cond ((eq number t) "*") ((numberp number) (int-to-string (+ number (gnus-range-length ...) (gnus-range-length ...)))) (t number)) gnus-tmp-number-total gnus-group-indentation gnus-tmp-summary-live)) (setq gnus-position (point)) (insert (format "%-55s" (let* ((val (eval (if ... ... gnus-tmp-qualified-group))) (need (- 55 (string-width val)))) (if (> need 0) (concat nil val (make-string need 32)) val)))) (insert-char 32 (max (- 75 (current-column)) 0)) (add-text-properties (point) (progn (insert gnus-tmp-news-server) (point)) (cons 'face (cons (list 'italic 'default) '(gnus-face t)))) (insert "\n") (if gnus-position (put-text-property gnus-position 
 (1+ gnus-position) 'gnus-position t)))
  eval((let (gnus-position) (insert (format "%c%c%d%c %6s %7d %s%c" gnus-tmp-marked-mark gnus-tmp-subscribed gnus-tmp-level gnus-tmp-process-marked (cond ((eq number t) "*") ((numberp number) (int-to-string (+ number ... ...))) (t number)) gnus-tmp-number-total gnus-group-indentation gnus-tmp-summary-live)) (setq gnus-position (point)) (insert (format "%-55s" (let* ((val (eval ...)) (need (- 55 ...))) (if (> need 0) (concat nil val (make-string need 32)) val)))) (insert-char 32 (max (- 75 (current-column)) 0)) (add-text-properties (point) (progn (insert gnus-tmp-news-server) (point)) (cons 'face (cons (list 'italic 'default) '(gnus-face t)))) (insert "\n") (if gnus-position (put-text-property gnus-position (1+ gnus-position) 'gnus-position t))) t)
  gnus-group-insert-group-line("dummy.group" 0 nil 0 nil)
  gnus-update-group-mark-positions()
  gnus-group-mode()
  gnus-group-setup-buffer()
  gnus-group-list-groups(nil)
  #f(compiled-function () #<bytecode 0x991f1d58b065dda>)()
  gnus-1(nil nil nil)
  gnus(nil)
  funcall-interactively(gnus nil)
  call-interactively(gnus record nil)
  command-execute(gnus record)
  execute-extended-command(nil "gnus" nil)
  funcall-interactively(execute-extended-command nil "gnus" nil)
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)




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

* Re: Gnus using lexical-binding
  2021-01-30 18:00     ` Andy Moreton
@ 2021-01-30 18:53       ` Stefan Monnier
  2021-01-30 23:23         ` Andy Moreton
  0 siblings, 1 reply; 27+ messages in thread
From: Stefan Monnier @ 2021-01-30 18:53 UTC (permalink / raw)
  To: Andy Moreton; +Cc: emacs-devel

> Debugger entered--Lisp error: (void-variable number)
>   (eq number t)

Aha!

>   (cond ((eq number t) "*") ((numberp number) (int-to-string (+ number

That seems to be coming from `gnus-group-line-format-alist` where "all"
the vars it refers have names that start with `gnus-tmp-` except for
`number`, apparently.

I added a patch to accommodate for that.
I hope there aren't many more of those: they're hard to find.


        Stefan




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

* Re: Gnus using lexical-binding
  2021-01-30 18:53       ` Stefan Monnier
@ 2021-01-30 23:23         ` Andy Moreton
  2021-01-31  0:06           ` Stefan Monnier
  0 siblings, 1 reply; 27+ messages in thread
From: Andy Moreton @ 2021-01-30 23:23 UTC (permalink / raw)
  To: emacs-devel

On Sat 30 Jan 2021, Stefan Monnier wrote:

>> Debugger entered--Lisp error: (void-variable number)
>>   (eq number t)
>
> Aha!
>
>>   (cond ((eq number t) "*") ((numberp number) (int-to-string (+ number
>
> That seems to be coming from `gnus-group-line-format-alist` where "all"
> the vars it refers have names that start with `gnus-tmp-` except for
> `number`, apparently.
>
> I added a patch to accommodate for that.
> I hope there aren't many more of those: they're hard to find.

Thats gets a little further, but...

Debugger entered--Lisp error: (void-variable gnus-tmp-number-total)
  (format "%c%c%d%c %6s %7d %s%c" gnus-tmp-marked-mark gnus-tmp-subscribed gnus-tmp-level gnus-tmp-process-marked (cond ((eq number t) "*") ((numberp number) (int-to-string (+ number (gnus-range-length (cdr (assq ... gnus-tmp-marked))) (gnus-range-length (cdr (assq ... gnus-tmp-marked)))))) (t number)) gnus-tmp-number-total gnus-group-indentation gnus-tmp-summary-live)
  (insert (format "%c%c%d%c %6s %7d %s%c" gnus-tmp-marked-mark gnus-tmp-subscribed gnus-tmp-level gnus-tmp-process-marked (cond ((eq number t) "*") ((numberp number) (int-to-string (+ number (gnus-range-length (cdr ...)) (gnus-range-length (cdr ...))))) (t number)) gnus-tmp-number-total gnus-group-indentation gnus-tmp-summary-live))
  (let (gnus-position) (insert (format "%c%c%d%c %6s %7d %s%c" gnus-tmp-marked-mark gnus-tmp-subscribed gnus-tmp-level gnus-tmp-process-marked (cond ((eq number t) "*") ((numberp number) (int-to-string (+ number (gnus-range-length ...) (gnus-range-length ...)))) (t number)) gnus-tmp-number-total gnus-group-indentation gnus-tmp-summary-live)) (setq gnus-position (point)) (insert (format "%-55s" (let* ((val (eval (if ... ... gnus-tmp-qualified-group))) (need (- 55 (string-width val)))) (if (> need 0) (concat nil val (make-string need 32)) val)))) (insert-char 32 (max (- 75 (current-column)) 0)) (add-text-properties (point) (progn (insert gnus-tmp-news-server) (point)) (cons 'face (cons (list 'italic 'default) '(gnus-face t)))) (insert "\n") (if gnus-position (put-text-property gnus-position 
 (1+ gnus-position) 'gnus-position t)))
  eval((let (gnus-position) (insert (format "%c%c%d%c %6s %7d %s%c" gnus-tmp-marked-mark gnus-tmp-subscribed gnus-tmp-level gnus-tmp-process-marked (cond ((eq number t) "*") ((numberp number) (int-to-string (+ number ... ...))) (t number)) gnus-tmp-number-total gnus-group-indentation gnus-tmp-summary-live)) (setq gnus-position (point)) (insert (format "%-55s" (let* ((val (eval ...)) (need (- 55 ...))) (if (> need 0) (concat nil val (make-string need 32)) val)))) (insert-char 32 (max (- 75 (current-column)) 0)) (add-text-properties (point) (progn (insert gnus-tmp-news-server) (point)) (cons 'face (cons (list 'italic 'default) '(gnus-face t)))) (insert "\n") (if gnus-position (put-text-property gnus-position (1+ gnus-position) 'gnus-position t))) t)
  gnus-group-insert-group-line("dummy.group" 0 nil 0 nil)
  gnus-update-group-mark-positions()
  gnus-group-mode()
  gnus-group-setup-buffer()
  gnus-group-list-groups(nil)
  #f(compiled-function () #<bytecode 0x991f1d2aaa768d6>)()
  gnus-1(nil nil nil)
  gnus(nil)
  funcall-interactively(gnus nil)
  call-interactively(gnus record nil)
  command-execute(gnus record)
  execute-extended-command(nil "gnus" nil)
  funcall-interactively(execute-extended-command nil "gnus" nil)
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)




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

* Re: Gnus using lexical-binding
  2021-01-30 23:23         ` Andy Moreton
@ 2021-01-31  0:06           ` Stefan Monnier
  2021-01-31  0:46             ` Andy Moreton
                               ` (2 more replies)
  0 siblings, 3 replies; 27+ messages in thread
From: Stefan Monnier @ 2021-01-31  0:06 UTC (permalink / raw)
  To: Andy Moreton; +Cc: emacs-devel

> Thats gets a little further, but...
>
> Debugger entered--Lisp error: (void-variable gnus-tmp-number-total)

OK, I `defvar`d all the gnus-tmp-* I could find now.
Please try again.

Note that the branch has a new name `scratch/lexical-gnus-rc` because
I have now cleaned up the commit messages, so it's basically "ready to
be merged".


        Stefan




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

* Re: Gnus using lexical-binding
  2021-01-31  0:06           ` Stefan Monnier
@ 2021-01-31  0:46             ` Andy Moreton
  2021-01-31 13:34             ` Basil L. Contovounesios
  2021-02-02 18:17             ` Eric Abrahamsen
  2 siblings, 0 replies; 27+ messages in thread
From: Andy Moreton @ 2021-01-31  0:46 UTC (permalink / raw)
  To: emacs-devel

On Sat 30 Jan 2021, Stefan Monnier wrote:

>> Thats gets a little further, but...
>>
>> Debugger entered--Lisp error: (void-variable gnus-tmp-number-total)
>
> OK, I `defvar`d all the gnus-tmp-* I could find now.
> Please try again.
>
> Note that the branch has a new name `scratch/lexical-gnus-rc` because
> I have now cleaned up the commit messages, so it's basically "ready to
> be merged".

After a full bootstrap this branch now seems to have a working gnus, at
least for nntp (I don't use gnus for email).


    AndyM




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

* Re: Gnus using lexical-binding
  2021-01-29 23:11 Gnus using lexical-binding Stefan Monnier
                   ` (3 preceding siblings ...)
  2021-01-30 16:10 ` Andy Moreton
@ 2021-01-31  9:13 ` David Engster
  2021-01-31 22:43   ` Stefan Monnier
  4 siblings, 1 reply; 27+ messages in thread
From: David Engster @ 2021-01-31  9:13 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

> And please, after testing it, tell me how it went, regardless if you
> encountered problems or not.

I've been running this now for a few hours without problems.

-David



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

* Re: Gnus using lexical-binding
  2021-01-31  0:06           ` Stefan Monnier
  2021-01-31  0:46             ` Andy Moreton
@ 2021-01-31 13:34             ` Basil L. Contovounesios
  2021-02-02 18:17             ` Eric Abrahamsen
  2 siblings, 0 replies; 27+ messages in thread
From: Basil L. Contovounesios @ 2021-01-31 13:34 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Andy Moreton, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Thats gets a little further, but...
>>
>> Debugger entered--Lisp error: (void-variable gnus-tmp-number-total)
>
> OK, I `defvar`d all the gnus-tmp-* I could find now.
> Please try again.
>
> Note that the branch has a new name `scratch/lexical-gnus-rc` because
> I have now cleaned up the commit messages, so it's basically "ready to
> be merged".

Seems to be working fine for me, thanks,

-- 
Basil



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

* Re: Gnus using lexical-binding
  2021-01-31  9:13 ` David Engster
@ 2021-01-31 22:43   ` Stefan Monnier
  0 siblings, 0 replies; 27+ messages in thread
From: Stefan Monnier @ 2021-01-31 22:43 UTC (permalink / raw)
  To: emacs-devel

Thanks Lars, David, Andy, and Basil,

It's clearly not enough testing for a release, but I decided it was
enough for now, I pushed the new code to `master`.


        Stefan




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

* Re: Gnus using lexical-binding
  2021-01-31  0:06           ` Stefan Monnier
  2021-01-31  0:46             ` Andy Moreton
  2021-01-31 13:34             ` Basil L. Contovounesios
@ 2021-02-02 18:17             ` Eric Abrahamsen
  2021-02-02 19:40               ` Stefan Monnier
  2 siblings, 1 reply; 27+ messages in thread
From: Eric Abrahamsen @ 2021-02-02 18:17 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Andy Moreton, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Thats gets a little further, but...
>>
>> Debugger entered--Lisp error: (void-variable gnus-tmp-number-total)
>
> OK, I `defvar`d all the gnus-tmp-* I could find now.
> Please try again.
>
> Note that the branch has a new name `scratch/lexical-gnus-rc` because
> I have now cleaned up the commit messages, so it's basically "ready to
> be merged".

I'm now seeing a bug with `gnus-article-browse-html-article' that might
(?) be a result of this, I'm not sure. Below is the definition of
`gnus-visible-headers', which I haven't changed from its default. When
viewing an HTML part, however, and we reach the function
`article-hide-headers', the definition of `gnus-visible-headers' now
looks like this:

((funcall #'#f(compiled-function () #<bytecode 0x134a5ff509cc6ffd>)))

Which `article-hide-headers' isn't set up to handle.

Could this be a result of lexical binding?


(defcustom gnus-visible-headers
  "^From:\\|^Newsgroups:\\|^Subject:\\|^Date:\\|^Followup-To:\\|^Reply-To:\\|^Organization:\\|^Summary:\\|^Keywords:\\|^To:\\|^[BGF]?Cc:\\|^Posted-To:\\|^Mail-Copies-To:\\|^Mail-Followup-To:\\|^Apparently-To:\\|^Gnus-Warning:\\|^Resent-From:"
  "All headers that do not match this regexp will be hidden.
This variable can also be a list of regexp of headers to remain visible.
If this variable is non-nil, `gnus-ignored-headers' will be ignored."
  :type '(choice
	  (repeat :value-to-internal (lambda (widget value)
				       (custom-split-regexp-maybe value))
		  :match (lambda (widget value)
			   (or (stringp value)
			       (widget-editable-list-match widget value)))
		  regexp)
	  (const :tag "Use gnus-ignored-headers" nil)
	  regexp)
  :group 'gnus-article-hiding)



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

* Re: Gnus using lexical-binding
  2021-02-02 18:17             ` Eric Abrahamsen
@ 2021-02-02 19:40               ` Stefan Monnier
  2021-02-02 20:31                 ` Eric Abrahamsen
  0 siblings, 1 reply; 27+ messages in thread
From: Stefan Monnier @ 2021-02-02 19:40 UTC (permalink / raw)
  To: Eric Abrahamsen; +Cc: Andy Moreton, emacs-devel

> I'm now seeing a bug with `gnus-article-browse-html-article' that might
> (?) be a result of this, I'm not sure.

It's triggered by the recent change, indeed.
It's due to a longer standing bug, tho.
The problem is in these two chunks of code in `gnus-art.el`:

		 (let ((gnus-visible-headers
			(or (get 'gnus-visible-headers 'standard-value)
			    gnus-visible-headers)))
		   (article-hide-headers))

and

    (let ((gnus-visible-headers (or (get 'gnus-visible-headers 'standard-value)
				    gnus-visible-headers))
	  (gnus-mime-display-attachment-buttons-in-header nil)
	  ;; As we insert a <hr>, there's no need for the body boundary.
	  (gnus-treat-body-boundary nil))
      (gnus-summary-show-article)))

I'm not completely sure why this code looks up the `standard-value`, but
the `standard-value` property is supposed to contain a cons cell whose
car is an *expression* that needs to be evaluated to get the variable's
intended standard value.

So it will never be nil and using it as a value is just wrong.

I installed a patch into `master` which should hopefully fix
the problem.


        Stefan




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

* Re: Gnus using lexical-binding
  2021-02-02 19:40               ` Stefan Monnier
@ 2021-02-02 20:31                 ` Eric Abrahamsen
  0 siblings, 0 replies; 27+ messages in thread
From: Eric Abrahamsen @ 2021-02-02 20:31 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Andy Moreton, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I'm now seeing a bug with `gnus-article-browse-html-article' that might
>> (?) be a result of this, I'm not sure.
>
> It's triggered by the recent change, indeed.
> It's due to a longer standing bug, tho.

[...]

> I'm not completely sure why this code looks up the `standard-value`, but
> the `standard-value` property is supposed to contain a cons cell whose
> car is an *expression* that needs to be evaluated to get the variable's
> intended standard value.

Ah, hence the lambda. I can't immediately think of why we'd need the
standard value of the option here, either.

> So it will never be nil and using it as a value is just wrong.
>
> I installed a patch into `master` which should hopefully fix
> the problem.

Looks good! Thanks for the quick fix.

Eric



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

* Re: Gnus using lexical-binding
  2021-01-30 17:40   ` Stefan Monnier
@ 2021-02-08 19:10     ` Ted Zlatanov
  2021-02-09  0:10       ` Stefan Monnier
  0 siblings, 1 reply; 27+ messages in thread
From: Ted Zlatanov @ 2021-02-08 19:10 UTC (permalink / raw)
  To: emacs-devel

Hi!

I got a probably related error after restarting Gnus, which had been
running for a while. Sorry for the late catch. I have a custom topic
function `gnus-user-format-function-topic-line' that started
complaining:

Debugger entered--Lisp error: (void-variable total-number-of-articles)
  (= 0 total-number-of-articles)
  (if (= 0 total-number-of-articles) 'font-lock-comment-face 'font-lock-function-name-face)
  (let* ((topic-face (if (= 0 total-number-of-articles) 'font-lock-comment-face 'font-lock-function-name-face)) (h (tzz-frame-font-size))) (propertize (format "%s %s" name (if (and tzz-ungradients (image-type-available-p 'svg)) (tzz-image-from-svg-string (+ 4 h) h total-number-of-articles nil) (tzz-summarize-number total-number-of-articles))) 'face topic-face))
  gnus-user-format-function-topic-line(nil)
  (format "%s[ %s ] %s\n" indentation (gnus-user-format-function-topic-line gnus-tmp-header) visible)
  (insert (format "%s[ %s ] %s\n" indentation (gnus-user-format-function-topic-line gnus-tmp-header) visible))
  eval((insert (format "%s[ %s ] %s\n" indentation (gnus-user-format-function-topic-line gnus-tmp-header) visible)) ((indentation . "    ") (visible . "") (name . "comics") (level . 2) (number-of-groups . 1) (total-number-of-articles . 1) (entries (1 ("nntp+news.gwene.org:gwene.com.xkcd" 3 ((1 . 1664)) ((unexist) (seen (1 . 417) (423 . 445) (449 . 453) (455 . 464) 468 (507 . 511) (513 . 521) (525 . 536) 538 (540 . 544) (546 . 554) (558 . 580) (584 . 589) (605 . 622) (636 . 651) (653 . 655) (659 . 660) (662 . 664) (668 . 684) (686 . 705) (707 . 708) (710 . 711) (714 . 733) 736 (739 . 749) (751 . 752) (757 . 761) (764 . 765) 771 773 (776 . 920) (922 . 929) (931 . 937) (940 . 941) (943 . 961) (963 . 974) 979 (984 . 996) (998 . 1044) (1047 . 1054) (1056 . 1065) (1076 . 1078) (1082 . 1085) (109
 1 . 1093) (1095 . 1104) (1106 . 1120) (1122 . 1139) (1142 . 1144) (1148 . 1149) ...) (forward 164 411) (score (778 . 1000) (63 . 1000))) "news.gwene.org")))))
  gnus-topic-insert-topic-line("comics" t t 2 ((1 ("nntp+news.gwene.org:gwene.com.xkcd" 3 ((1 . 1664)) ((unexist) (seen (1 . 417) (423 . 445) (449 . 453) (455 . 464) 468 (507 . 511) (513 . 521) (525 . 536) 538 (540 . 544) (546 . 554) (558 . 580) (584 . 589) (605 . 622) (636 . 651) (653 . 655) (659 . 660) (662 . 664) (668 . 684) (686 . 705) (707 . 708) (710 . 711) (714 . 733) 736 (739 . 749) (751 . 752) (757 . 761) (764 . 765) 771 773 (776 . 920) (922 . 929) (931 . 937) (940 . 941) (943 . 961) (963 . 974) 979 (984 . 996) (998 . 1044) (1047 . 1054) (1056 . 1065) (1076 . 1078) (1082 . 1085) (1091 . 1093) (1095 . 1104) (1106 . 1120) (1122 . 1139) (1142 . 1144) (1148 . 1149) ...) (forward 164 411) (score (778 . 1000) (63 . 1000))) "news.gwene.org"))) 1)
  gnus-topic-prepare-topic((("comics" visible nil nil)) 2 5 nil nil 1 nil)

The confusing thing here is that the eval lexical environment is
correct. I'm not sure what's happening in the stack. I can reproduce it
with a shorter example:

(defun gnus-user-format-function-topic-line (dummy)
  (message "total %s" total-number-of-articles))

(let ((gnus-topic-line-format "%i[ %u&topic-line; ] %v\n"))
     (gnus-update-format-specifications nil 'topic))

(let ((gnus-tmp-header nil))
     (eval gnus-topic-line-format-spec
           '((indentation . "    ") (visible . "") (name . "comics") (level . 2) (number-of-groups . 1) (total-number-of-articles . 1))))

I hope that helps track it down.

Thank you
Ted




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

* Re: Gnus using lexical-binding
  2021-02-08 19:10     ` Ted Zlatanov
@ 2021-02-09  0:10       ` Stefan Monnier
  2021-02-10 10:24         ` Ted Zlatanov
  0 siblings, 1 reply; 27+ messages in thread
From: Stefan Monnier @ 2021-02-09  0:10 UTC (permalink / raw)
  To: emacs-devel

> Debugger entered--Lisp error: (void-variable total-number-of-articles)
>   (= 0 total-number-of-articles)
>   (if (= 0 total-number-of-articles) 'font-lock-comment-face 'font-lock-function-name-face)
>   (let* ((topic-face (if (= 0 total-number-of-articles) 'font-lock-comment-face 'font-lock-function-name-face)) (h (tzz-frame-font-size))) (propertize (format "%s %s" name (if (and tzz-ungradients (image-type-available-p 'svg)) (tzz-image-from-svg-string (+ 4 h) h total-number-of-articles nil) (tzz-summarize-number total-number-of-articles))) 'face topic-face))
>   gnus-user-format-function-topic-line(nil)
>   (format "%s[ %s ] %s\n" indentation (gnus-user-format-function-topic-line gnus-tmp-header) visible)
>   (insert (format "%s[ %s ] %s\n" indentation (gnus-user-format-function-topic-line gnus-tmp-header) visible))
>   eval((insert (format "%s[ %s ] %s\n" indentation
>   (gnus-user-format-function-topic-line gnus-tmp-header) visible))
>   ((indentation . "    ") (visible . "") (name . "comics") (level . 2)
>   (number-of-groups . 1) (total-number-of-articles . 1) (entries (1

That sucks!

> The confusing thing here is that the eval lexical environment
> is correct.

It's correct but it's lexical, so those vars can't be seen from functions
called from `gnus-topic-line-format-spec`.

I installed the patch below which should sadly fix it,


        Stefan


Summary: * lisp/gnus/gnus-topic.el: Fix a backward incompatibility

(gnus-topic-insert-topic-line): Make the vars used in
`gnus-topic-line-format-spec` dynamically scoped since it seems
that they're sometimes accessed from functions called by
`gnus-topic-line-format-spec` :-(

* lisp/gnus/gnus-util.el (gnus--\,@): Move macro to here...
* lisp/gnus/gnus-art.el (gnus--\,@): .. from here.

* lisp/gnus/gnus.el (gnus-method-to-server): Apply DeMorgan.


diff --git a/lisp/gnus/gnus-art.el b/lisp/gnus/gnus-art.el
index 7ded9e40e9..c9afa3ac94 100644
--- a/lisp/gnus/gnus-art.el
+++ b/lisp/gnus/gnus-art.el
@@ -4325,10 +4325,6 @@ article-verify-cancel-lock
   (if (gnus-buffer-live-p gnus-original-article-buffer)
       (canlock-verify gnus-original-article-buffer)))
 
-(defmacro gnus--\,@ (exp)
-  (declare (debug t))
-  `(progn ,@(eval exp t)))
-
 (gnus--\,@
  (mapcar (lambda (func)
            `(defun ,(intern (format "gnus-%s" func))
diff --git a/lisp/gnus/gnus-topic.el b/lisp/gnus/gnus-topic.el
index e7d1cf8616..3253b7853d 100644
--- a/lisp/gnus/gnus-topic.el
+++ b/lisp/gnus/gnus-topic.el
@@ -627,7 +627,14 @@ gnus-tmp-header
 
 (defun gnus-topic-insert-topic-line (name visiblep shownp level entries
 					  &optional unread)
+  (gnus--\,@
+   (let ((vars '(indentation visible name level number-of-groups
+                 total-number-of-articles entries)))
+     `((with-suppressed-warnings ((lexical ,@vars))
+         ,@(mapcar (lambda (s) `(defvar ,s)) vars)))))
   (let* ((visible (if visiblep "" "..."))
+	 (level level)
+	 (name name)
 	 (indentation (make-string (* gnus-topic-indent-level level) ? ))
 	 (total-number-of-articles unread)
 	 (number-of-groups (length entries))
@@ -640,14 +647,7 @@ gnus-topic-insert-topic-line
 	(add-text-properties
 	 (point)
 	 (prog1 (1+ (point))
-	   (eval gnus-topic-line-format-spec
-                 `((indentation . ,indentation)
-                   (visible . ,visible)
-                   (name . ,name)
-                   (level . ,level)
-                   (number-of-groups . ,number-of-groups)
-                   (total-number-of-articles . ,total-number-of-articles)
-                   (entries . ,entries))))
+	   (eval gnus-topic-line-format-spec t))
 	 (list 'gnus-topic name
 	       'gnus-topic-level level
 	       'gnus-topic-unread unread
diff --git a/lisp/gnus/gnus-util.el b/lisp/gnus/gnus-util.el
index 3c7c948c2b..f80243cfed 100644
--- a/lisp/gnus/gnus-util.el
+++ b/lisp/gnus/gnus-util.el
@@ -1068,6 +1068,11 @@ gnus-run-mode-hooks
 
 ;;; Various
 
+(defmacro gnus--\,@ (exp)
+  "Splice EXP's value (a list of Lisp forms) into the code."
+  (declare (debug t))
+  `(progn ,@(eval exp t)))
+
 (defvar gnus-group-buffer)		; Compiler directive
 (defun gnus-alive-p ()
   "Say whether Gnus is running or not."
diff --git a/lisp/gnus/gnus.el b/lisp/gnus/gnus.el
index 98664ac2b4..7b94c64ae7 100644
--- a/lisp/gnus/gnus.el
+++ b/lisp/gnus/gnus.el
@@ -3212,9 +3212,9 @@ gnus-method-to-server
 		     (format "%s" (car method))
 		   (format "%s:%s" (car method) (cadr method))))
 	   (name-method (cons name method)))
-      (when (and (not no-enter-cache)
-		 (not (member name-method gnus-server-method-cache))
-		 (not (assoc (car name-method) gnus-server-method-cache)))
+      (unless (or no-enter-cache
+		  (member name-method gnus-server-method-cache)
+		  (assoc (car name-method) gnus-server-method-cache))
 	(push name-method gnus-server-method-cache))
       name)))
 




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

* Re: Gnus using lexical-binding
  2021-02-09  0:10       ` Stefan Monnier
@ 2021-02-10 10:24         ` Ted Zlatanov
  2021-02-10 13:53           ` Stefan Monnier
  2021-02-10 19:05           ` Lars Ingebrigtsen
  0 siblings, 2 replies; 27+ messages in thread
From: Ted Zlatanov @ 2021-02-10 10:24 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

On Mon, 08 Feb 2021 19:10:48 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> The confusing thing here is that the eval lexical environment
>> is correct.

SM> It's correct but it's lexical, so those vars can't be seen from functions
SM> called from `gnus-topic-line-format-spec`.

I looked through (info "(elisp) Lexical Binding") and I think I
understand the issue better. Thank you for fixing it. I confirmed it's
all clear.

SM> I installed the patch below which should sadly fix it,

I have some (probably dumb) suggestions.

The fix and the whole pre-existing Gnus "user defines special function"
mechanism feels very magical. Could we instead define a standard way of
calling these custom user-defined functions in Gnus, passing them an
explicit alist or plist of special properties? That would also make it
easier from within the function to check what's passed down, and
probably remove some complex code in the long run.

The code that calls them today could check their arity and if it's 1
(current call signature), warn and do the workaround. If it's 2, pass
the alist or plist with no workarounds.

Another way may be to provide a special macro to define these functions
in a backwards-compatible way. If they have not been defined with the
macro, warn and use the workaround. Otherwise, pass them the special
values.

...and yet another way may be a new escape char in the format spec for
the new style functions with 2 arguments. Users can switch to it when
they are ready, and the old escape char gets deprecated.

I hope that's useful.
Ted



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

* Re: Gnus using lexical-binding
  2021-02-10 10:24         ` Ted Zlatanov
@ 2021-02-10 13:53           ` Stefan Monnier
  2021-02-10 19:05           ` Lars Ingebrigtsen
  1 sibling, 0 replies; 27+ messages in thread
From: Stefan Monnier @ 2021-02-10 13:53 UTC (permalink / raw)
  To: emacs-devel

> The fix and the whole pre-existing Gnus "user defines special function"
> mechanism feels very magical.

Amen.

> Could we instead define a standard way of calling these custom
> user-defined functions in Gnus, passing them an explicit alist or
> plist of special properties?

I'd welcome such a change,


        Stefan




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

* Re: Gnus using lexical-binding
  2021-02-10 10:24         ` Ted Zlatanov
  2021-02-10 13:53           ` Stefan Monnier
@ 2021-02-10 19:05           ` Lars Ingebrigtsen
  1 sibling, 0 replies; 27+ messages in thread
From: Lars Ingebrigtsen @ 2021-02-10 19:05 UTC (permalink / raw)
  To: Stefan Monnier, emacs-devel

Ted Zlatanov <tzz@lifelogs.com> writes:

> The code that calls them today could check their arity and if it's 1
> (current call signature), warn and do the workaround. If it's 2, pass
> the alist or plist with no workarounds.

Sounds good to me.  Perhaps a hash table with properties?

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



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

end of thread, other threads:[~2021-02-10 19:05 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-01-29 23:11 Gnus using lexical-binding Stefan Monnier
2021-01-30  6:34 ` Lars Ingebrigtsen
2021-01-30  8:35 ` Eli Zaretskii
2021-01-30 13:43   ` Stefan Kangas
2021-01-30 13:52     ` Eli Zaretskii
2021-01-30 14:08       ` Eli Zaretskii
2021-01-30 15:24     ` Stefan Monnier
2021-01-30 15:07 ` Basil L. Contovounesios
2021-01-30 17:40   ` Stefan Monnier
2021-02-08 19:10     ` Ted Zlatanov
2021-02-09  0:10       ` Stefan Monnier
2021-02-10 10:24         ` Ted Zlatanov
2021-02-10 13:53           ` Stefan Monnier
2021-02-10 19:05           ` Lars Ingebrigtsen
2021-01-30 16:10 ` Andy Moreton
2021-01-30 17:35   ` Stefan Monnier
2021-01-30 18:00     ` Andy Moreton
2021-01-30 18:53       ` Stefan Monnier
2021-01-30 23:23         ` Andy Moreton
2021-01-31  0:06           ` Stefan Monnier
2021-01-31  0:46             ` Andy Moreton
2021-01-31 13:34             ` Basil L. Contovounesios
2021-02-02 18:17             ` Eric Abrahamsen
2021-02-02 19:40               ` Stefan Monnier
2021-02-02 20:31                 ` Eric Abrahamsen
2021-01-31  9:13 ` David Engster
2021-01-31 22:43   ` Stefan Monnier

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).