bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Visuwesh
Subject: bug#74700: [PATCH] Revert Dired buffer when clicking on last segment of directory name
Date: Wed, 25 Dec 2024 10:17:59 +0530
User-agent: Gnus/5.13 (Gnus v5.13)

[புதன் டிசம்பர் 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_.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]