Re: master af4791b5706: Fix apparently wrong `delete` and `delq` value discards (bug#61730)

Re: master af4791b5706: Fix apparently wrong `delete` and `delq` value discards (bug#61730)

[Eli Zaretskii]

This part of the changeset looks strange to me:

  diff --git a/lisp/allout.el b/lisp/allout.el
  index be2fd632c69..d3203800168 100644
  --- a/lisp/allout.el
  +++ b/lisp/allout.el
  @@ -6307,7 +6307,7 @@ not its value."
	     (if (yes-or-no-p (format-message
			      "%s entry `%s' is unbound -- remove it? "
			      configvar-name sym))
  -              (delq sym (symbol-value configvar-name)))
  +              (set configvar-name (delq sym (symbol-value configvar-name))))
	   (push (symbol-value sym) got)))

configvar-name is evidently a string, whereas the value returned by
delq is not a string at all.  Do you understand why this code even
calls delq?  If it wants to change the value of configvar-name, it
should assign to (symbol-value configvar-name), no?  And if all it
wants is to skip 'sym' and not add it to 'got', then there's no need
to call delq, right?

Re: master af4791b5706: Fix apparently wrong `delete` and `delq` value discards (bug#61730)

[Mattias Engdegård]

25 maj 2023 kl. 09.09 skrev Eli Zaretskii <eliz@gnu.org>:

> configvar-name is evidently a string, whereas the value returned by
> delq is not a string at all.  Do you understand why this code even
> calls delq?

I thought I did but may have been mistaken. Let's look at this again:

From the text of this function we can infer that `configvar-name` is the name (symbol) of a dynamic variable whose value is a list of symbols naming other variables. If we strip all the `boundp` and `delq` gunk, this function essentially becomes

  (mapcar #'symbol-value (symbol-value configvar-name))

I don't fancy mutation of a list while it's being looped over any more than you do, but I didn't want to touch it more than strictly necessary.

>  If it wants to change the value of configvar-name, it
> should assign to (symbol-value configvar-name), no?

It does.

>  And if all it
> wants is to skip 'sym' and not add it to 'got', then there's no need
> to call delq, right?

As the yes-or-no-p call suggests, the intent is likely to remove unbound entries permanently so there is no need to ask again in future calls, or ask more than once for the same variable appearing in duplicate during the same call.