bug#81295: 32.0.50; dired-auto-toggle-b-switch problem with subdirectory

> From: Filipp Gunbin <[email protected]>
> Cc: [email protected],  [email protected],  [email protected]
> Date: Wed, 29 Jul 2026 17:49:31 +0300
> 
> On 29/07/2026 17:00 +0300, Eli Zaretskii wrote:
> 
> >> From: Filipp Gunbin <[email protected]>
> >> Cc: Eli Zaretskii <[email protected]>,  [email protected],
> >>   [email protected]
> >> Date: Wed, 29 Jul 2026 16:50:52 +0300
> >> 
> >> On 29/07/2026 15:32 +0200, Stephen Berman wrote:
> >> 
> >> [...]
> >> 
> >> > So that's the current situation, and why I've turned to you and Sean for
> >> > a decision on how to proceed: (i) install my changes to handle file
> >> > names with newlines in Dired subdirs, including the change that "fixes"
> >> > the bug with `C-u i'; (ii) install the changes except for the one that
> >> > "fixes" the `C-u i' bug, thus leaving that unfixed for now; (iii) wait
> >> > for Filipp's alternative implementation, which will hopefully fix that
> >> > bug without circumventing validation of subdir switches.
> >> 
> >> As I wrote already, I do not object to (ii), we agree on that patch.  I
> >> object only to the fix of supposedly rare problem which we found in the
> >> course of discussing this bug, and (i) additionally includes that fix.
> >> We could create another bug report for that and see if anyone (me, or
> >> you, or somebody else) comes up with the patch that we all agree with.
> >> That is, (iii) is not an alternative to (ii) - we could install the
> >> patch in (ii) right now, and that will fix the problem which I created
> >> this bug about.
> >
> > Why not install (i) and _then_ wait for that one aspect to be fixed
> > separately?
> 
> My concerns are that (i):
> 
> - Breaks the current logic, and thus will introduce more subtle bugs.
> Given that the problem it fixes is minor, I don't see this as a good
> trade-off.
> 
> - Makes the code harder to read and change later, as it adds a
> non-obvious special case, and you need to read this discussion to
> understand why it was added.  I always favor cleaner code, that's why
> I'd prefer to create another bug, rather than fix it here "at all
> costs", but that's me.

Fair enough, let's wait for Sean to chime in.