Bug or feature?

Bug or feature?

[Po Lu]

There is an elaborate segment of code in reset_buffer_local_variables
for, among other actions, eliminating outdated value cells from
buffer-local symbols that is not run when the shortcut is taken of
clearing local_var_alist_ in the case where PERMANENT_TOO is set, which
I suspect results in variable watchers being ignored and outdated symbol
values persisting.  Is there a specific reason for this discrepancy, or
is it just an oversight?

Re: Bug or feature?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Sat, 18 May 2024 15:34:00 +0800
> 
> There is an elaborate segment of code in reset_buffer_local_variables
> for, among other actions, eliminating outdated value cells from
> buffer-local symbols that is not run when the shortcut is taken of
> clearing local_var_alist_ in the case where PERMANENT_TOO is set, which
> I suspect results in variable watchers being ignored and outdated symbol
> values persisting.  Is there a specific reason for this discrepancy, or
> is it just an oversight?

Stefan, any comments?

Re: Bug or feature?

[Eli Zaretskii]

Ping!

> Date: Sat, 01 Jun 2024 17:06:05 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Po Lu <luangruo@yahoo.com>
> > Date: Sat, 18 May 2024 15:34:00 +0800
> > 
> > There is an elaborate segment of code in reset_buffer_local_variables
> > for, among other actions, eliminating outdated value cells from
> > buffer-local symbols that is not run when the shortcut is taken of
> > clearing local_var_alist_ in the case where PERMANENT_TOO is set, which
> > I suspect results in variable watchers being ignored and outdated symbol
> > values persisting.  Is there a specific reason for this discrepancy, or
> > is it just an oversight?
> 
> Stefan, any comments?
> 
> 

Re: Bug or feature?

[John ff]

-------- Original Message --------
From: Eli Zaretskii <eliz@gnu.org>
Sent: Sat Jun 15 08:55:04 GMT+01:00 2024
To: monnier@iro.umontreal.ca
Cc: luangruo@yahoo.com, emacs-devel@gnu.org
Subject: Re: Bug or feature?

Ping!

> Date: Sat, 01 Jun 2024 17:06:05 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Po Lu <luangruo@yahoo.com>
> > Date: Sat, 18 May 2024 15:34:00 +0800
> > 
> > There is an elaborate segment of code in reset_buffer_local_variables
> > for, among other actions, eliminating outdated value cells from
> > buffer-local symbols that is not run when the shortcut is taken of
> > clearing local_var_alist_ in the case where PERMANENT_TOO is set, which
> > I suspect results in variable watchers being ignored and outdated symbol
> > values persisting.  Is there a specific reason for this discrepancy, or
> > is it just an oversight?
> 
> Stefan, any comments?
> 
> 

Re: Bug or feature?

[Stefan Monnier]

>> There is an elaborate segment of code in reset_buffer_local_variables
>> for, among other actions, eliminating outdated value cells from
>> buffer-local symbols that is not run when the shortcut is taken of
>> clearing local_var_alist_ in the case where PERMANENT_TOO is set, which
>> I suspect results in variable watchers being ignored and outdated symbol
>> values persisting.  Is there a specific reason for this discrepancy, or
>> is it just an oversight?
> Stefan, any comments?

Yes, it was an oversight in my commit 3ddff0803415.

This code also has another related problem because the var watchers can
change `local_var_alist`.  And I can't see in the code what prevents us
from running the watcher twice for those vars with `Qpermanent_local_hook`.
Oh, and calling `swap_in_global_binding` doesn't sound quite right
if we don't kill the var (because of `Qpermanent_local_hook`).


        Stefan

Bug or feature?

[Colin Baxter]

Suppose you do

1. emacs <RET>
2. M-x gnus <RET>

We will assume this works - it generally does if your ~/.emacs and
~/.gnus.el are good :-). But

1. emacs -q <RET>
2. M-x load-library <RET>
3. ~/.emacs <RET>
4. M-x gnus <RET>

will produce an error. You must do

i.  M-x load-library <RET>
ii. ~/.gnus.el <RET>

before step (4). We assume that the file ~/.emacs does not have the line
(load-library "~/.gnus.el").

Is this simply a feature of the "-q" option or a bug?

Best wishes,


Colin Baxter
URL: http://www.Colin-Baxter.com
---------------------------------------------------------------------
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8
---------------------------------------------------------------------
The sole cause of all human misery is the inability of people to sit
quietly in their rooms.  Blaise Pascal, 1670

Re: Bug or feature?

[Colin Baxter]

>>>>> Colin Baxter <m43cap@yandex.com> writes:

    > Suppose you do

    > 1. emacs <RET> 2. M-x gnus <RET>

    > We will assume this works - it generally does if your ~/.emacs and
    > ~/.gnus.el are good :-). But

    > 1. emacs -q <RET> 2. M-x load-library <RET> 3. ~/.emacs <RET>
    > 4. M-x gnus <RET>

    > will produce an error. You must do

    > i.  M-x load-library <RET> ii. ~/.gnus.el <RET>

    > before step (4). We assume that the file ~/.emacs does not have
    > the line (load-library "~/.gnus.el").

    > Is this simply a feature of the "-q" option or a bug?

Thinking about it more, this is a feature because "emacs -q" will not
have any default settings, such as the location of the gnus init
file. Sorry about the original post.

Best wishes,

Colin Baxter
URL: http://www.Colin-Baxter.com
---------------------------------------------------------------------
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8
---------------------------------------------------------------------
The sole cause of all human misery is the inability of people to sit
quietly in their rooms.  Blaise Pascal, 1670