bug#74700: [PATCH] Revert Dired buffer when clicking on last segment of directory name

[Eli Zaretskii]

> From: Visuwesh <visuweshm@gmail.com>
> Cc: 74700@debbugs.gnu.org,  eliz@gnu.org
> Date: Wed, 25 Dec 2024 10:17:59 +0530
> 
> [புதன் டிசம்பர் 25, 2024] Michael Heerdegen wrote:
> 
> >> However, using mouse-1 still moves the point to bob.  I believe we
> >> could fix it by directly binding mouse-1 but I would like to respect
> >> mouse-1-click-follows-link like the rest of the code in the function.
> >> I cannot tell how to prevent mouse-1 from moving point reading the
> >> Info nodes (info "(elisp) Clickable Text") and (info "(emacs) Mouse
> >> References").  I tried
> >>
> >>     (with-selected-window (posn-window (event-start e)) ...)
> >>
> >> to no avail.
> >
> > Was that code line the attempt to fix the problem that the buffer in the
> > wrong window was being reverted, or the attempt to fix the mouse-1
> > problem?
> 
> It was an attempt to fix the mouse-1 problem.  The former issue is fixed
> with the following patch.
> 
> >> This goes beyond my level of knowledge so someone else will have to
> >> take care of this.  But please install the following patch because
> >> without it using mouse-2 on the base name tries to revert the
> >> current-buffer instead of the dired buffer when the dired buffer is
> >> not shown in the selected window.
> >
> >> +++ #<buffer dired.el>
> >> @@ -2089,8 +2089,10 @@
> >>             `( mouse-face highlight
> >>                help-echo "mouse-1: revert this buffer"
> >>                keymap ,(define-keymap
> >> -                        "<mouse-2>" #'revert-buffer
> >> -                        "<follow-link>" 'follow-link
> >> +                        "<mouse-2>" (lambda (_)
> >> +                                      (interactive "@e")
> >> +                                      (revert-buffer))
> >> +                        "<follow-link>" 'mouse-face
> >
> > I don't know how to fix the mouse-1 problem in a sensible way either.
> > Does anyone?
> >
> > (And I think in this version the "e" code in `interactive' isn't
> > significant - but let's first see if we can improve the behavior even
> > more.)
> 
> Indeed, I thought @ had to go with e _always_.

Thanks, so please post a proper patch with a commit log message, so I
could install it.