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

[Eli Zaretskii <eliz@gnu.org>]

> From: Vladimir Sedach <vas@oneofus.la>
> Cc: 64311@debbugs.gnu.org
> Date: Thu, 29 Jun 2023 13:24:58 -0600
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Am I?  Asking about the root cause of the problem is not wrong,
> > because it indicates how best to fix it.
> 
> The root cause of the problem is the redundant variable
> shell-dirtrackp, not its value. It is the variable aliasing in the
> 2018 commit 9c3eeba4db26ddaeead100beea7a96f9fa640918 that introduced
> the bug.
> 
> This is why my patch addresses the root cause of the problem, instead
> of setting the value of the variable (which commit
> 9c3eeba4db26ddaeead100beea7a96f9fa640918 did not touch).

The variable's existence is only the cause of the problem because of
its value.

> > Why would we bother about that?  With the exception of the default
> > value, what harm does that variable cause by existing?
> 
> It is misleading for someone trying to customize shell-mode, or work
> on shell.el. I found it confusing on both counts.

Such confusion can be prevented by adding appropriate comments.

By contrast, removing the variable, or declaring it obsolete, is
backward-incompatible change in behavior, which we try to avoid at all
costs.  In this case, I see absolutely no justification for such
backward incompatibility.  We wouldn't be able to defend such a change
if it caused someone annoyance or, worse, breakage of their Emacs
setup and usage.

> If it were not confusing for you too, we obviously would not be
> having such a long back-and-forth conversation about this bug.

The discussion was long because I couldn't connect between the problem
and the changes you proposed.  The solution I thought about
immediately was just to change the value of the variable.  The rest
was getting you to agree that such a change would indeed solve the
problem (although you disagree it's the right solution).