bug#64311: [PATCH] Fix shell-dirtrack-mode showing up as enabled in unrelated buffers

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Vladimir Sedach <vas@oneofus.la>,  64311@debbugs.gnu.org
> Date: Tue, 04 Jul 2023 10:28:55 -0400
> 
> FWIW, my take on the root cause is that I made a mistake in commit
> 05327ca9724287cc3da4c625f180da5ab11be998 where I forgot to remove the
> `defvar` of `shell-dirtrackp` (and I swapped the args to `defvaralias`).

The problem here for me is that this mistake was made long ago, and by
now there could be people out there who actually rely on this
problematic alias.

> > diff --git a/lisp/shell.el b/lisp/shell.el
> > index 5cf108b..4bbd295 100644
> > --- a/lisp/shell.el
> > +++ b/lisp/shell.el
> > @@ -348,8 +348,10 @@ shell-dirstack
> >  
> >  (defvaralias 'shell-dirtrack-mode 'shell-dirtrackp)
> >  
> > -(defvar shell-dirtrackp t
> > -  "Non-nil in a shell buffer means directory tracking is enabled.")
> > +(defvar-local shell-dirtrackp nil
> > +  "Non-nil in a shell buffer means directory tracking is enabled.
> > +Directory tracking (`shell-dirtrack-mode') is automatically enabled
> > +when `shell-mode' is activated.")
> >  
> >  (defvar shell-last-dir nil
> >    "Keep track of last directory for ksh `cd -' command.")
> > @@ -1129,6 +1131,7 @@ shell-extract-num
> >  
> >  (define-minor-mode shell-dirtrack-mode
> >    "Toggle directory tracking in this shell buffer (Shell Dirtrack mode).
> > +This assigns a buffer-local non-nil value to `shell-dirtrackp'.
> >  
> >  The `dirtrack' package provides an alternative implementation of
> >  this feature; see the function `dirtrack-mode'.  Also see
> 
> This aligns the `defvar` of `shell-dirtrackp` with that of
> `shell-dirtrack-mode`, which reduces the harm of the duplication, so
> it fixes the worst part of my mess, thanks.
> 
> I'd prefer the original patch, tho, which should give basically the same
> end result but without this weird duplicate definition.

The original patch makes a backward-incompatible change, which for me
is a significant disadvantage.

> I assume we're discussing this patch for `master`, not `emacs-29`, right?

Yes.