GNU bug report logs -
#68698
30.0.50; Making xt-mouse emit `wheel-up/down`
Previous Next
Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>
Date: Wed, 24 Jan 2024 20:34:02 UTC
Severity: normal
Found in version 30.0.50
Done: Stefan Monnier <monnier <at> iro.umontreal.ca>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 68698 in the body.
You can then email your comments to 68698 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68698
; Package
emacs
.
(Wed, 24 Jan 2024 20:34:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 24 Jan 2024 20:34:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Package: Emacs
Version: 30.0.50
Currently, wheel-up/down events are generated in most setups instead
of the old mouse-4/5. There are still two exceptions:
- X11 builds not using XInput2.
- text terminals.
The attached patch intends to fix the second bullet.
Text terminals themselves only give us info equivalent to `mouse-4/5`
and don't actually tell us that it's a wheel movement, but we can still
turn those things into `wheel-up/down`.
This is related to bug#49803.
The second step would be to do something similar for the non-XInput2 X11
build: make it generate `wheel-up/down` events according to
`mouse-wheel-down/up-event` settings. Then packages like
`completion-preview` and `mwheel` won't need to pay attention to the
(confusingly named) `mouse-wheel-down/up-event` vars any more.
Stefan
[xtmouse.patch (text/x-diff, inline)]
diff --git a/lisp/mwheel.el b/lisp/mwheel.el
index 53042085bf6..66a1fa1a706 100644
--- a/lisp/mwheel.el
+++ b/lisp/mwheel.el
@@ -59,7 +59,7 @@ mouse-wheel-change-button
(defvar mouse-wheel-obey-old-style-wheel-buttons t
"If non-nil, treat mouse-4/5/6/7 events as mouse wheel events.
These are the event names used historically in X11 before XInput2.
-They are sometimes generated by things like `xterm-mouse-mode' as well.")
+They are sometimes generated by things like text-terminals as well.")
(defcustom mouse-wheel-down-event
(if mouse-wheel-obey-old-style-wheel-buttons 'mouse-4)
diff --git a/lisp/xt-mouse.el b/lisp/xt-mouse.el
index cd00467f14f..fcc0db1d9eb 100644
--- a/lisp/xt-mouse.el
+++ b/lisp/xt-mouse.el
@@ -40,6 +40,8 @@
;;; Code:
+(require 'mwheel)
+
(defvar xterm-mouse-debug-buffer nil)
(defun xterm-mouse-translate (_event)
@@ -193,6 +195,12 @@ xterm-mouse--read-number-from-terminal
(cons n c))
(cons (- (setq c (xterm-mouse--read-coordinate)) 32) c))))
+(defun xterm-mouse--same-button-p (event btn)
+ (and (symbolp event)
+ (string-prefix-p "mouse-" (symbol-name event))
+ (eq btn (car (read-from-string (symbol-name event)
+ (length "mouse-"))))))
+
;; XTerm reports mouse events as
;; <EVENT-CODE> <X> <Y> in default mode, and
;; <EVENT-CODE> ";" <X> ";" <Y> <"M" or "m"> in extended mode.
@@ -231,12 +239,24 @@ xterm-mouse--read-event-sequence
;; event: assume, that the last button was button 1.
(t 1)))
(sym (if move 'mouse-movement
- (intern (concat (if ctrl "C-" "")
- (if meta "M-" "")
- (if shift "S-" "")
- (if down "down-" "")
- "mouse-"
- (number-to-string btn))))))
+ (intern
+ (concat
+ (if ctrl "C-" "")
+ (if meta "M-" "")
+ (if shift "S-" "")
+ (if down "down-" "")
+ (cond
+ ;; BEWARE: `mouse-wheel-UP-event' corresponds to
+ ;; `wheel-DOWN' events and vice versa!!
+ ((xterm-mouse--same-button-p mouse-wheel-down-event btn)
+ "wheel-up")
+ ((xterm-mouse--same-button-p mouse-wheel-up-event btn)
+ "wheel-down")
+ ((xterm-mouse--same-button-p mouse-wheel-left-event btn)
+ "wheel-left")
+ ((xterm-mouse--same-button-p mouse-wheel-right-event btn)
+ "wheel-right")
+ (t (format "mouse-%d" btn))))))))
(list sym (1- x) (1- y))))
(defun xterm-mouse--set-click-count (event click-count)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68698
; Package
emacs
.
(Thu, 25 Jan 2024 02:27:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 68698 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> The second step would be to do something similar for the non-XInput2 X11
> build: make it generate `wheel-up/down` events according to
> `mouse-wheel-down/up-event` settings. Then packages like
> `completion-preview` and `mwheel` won't need to pay attention to the
> (confusingly named) `mouse-wheel-down/up-event` vars any more.
No!
Button4, 5, 6 and 7 are only mouse wheels in one particular group of X
servers. It is impossible to detect whether they are mouse wheels
without the input extension (and this is why XI display connections
produce wheel events), so such an escape hatch as mouse-wheel-*-event
_must_ be provided for X servers where the general assumption that they
are mouse wheels does not hold true.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68698
; Package
emacs
.
(Thu, 25 Jan 2024 07:31:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 68698 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 24 Jan 2024 15:31:32 -0500
> From: Stefan Monnier via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> Package: Emacs
> Version: 30.0.50
>
>
> Currently, wheel-up/down events are generated in most setups instead
> of the old mouse-4/5. There are still two exceptions:
> - X11 builds not using XInput2.
> - text terminals.
> The attached patch intends to fix the second bullet.
> Text terminals themselves only give us info equivalent to `mouse-4/5`
> and don't actually tell us that it's a wheel movement, but we can still
> turn those things into `wheel-up/down`.
>
> This is related to bug#49803.
Jared, any comments on the patch, or related issues?
Thanks.
> The second step would be to do something similar for the non-XInput2 X11
> build: make it generate `wheel-up/down` events according to
> `mouse-wheel-down/up-event` settings. Then packages like
> `completion-preview` and `mwheel` won't need to pay attention to the
> (confusingly named) `mouse-wheel-down/up-event` vars any more.
>
>
> Stefan
>
> diff --git a/lisp/mwheel.el b/lisp/mwheel.el
> index 53042085bf6..66a1fa1a706 100644
> --- a/lisp/mwheel.el
> +++ b/lisp/mwheel.el
> @@ -59,7 +59,7 @@ mouse-wheel-change-button
> (defvar mouse-wheel-obey-old-style-wheel-buttons t
> "If non-nil, treat mouse-4/5/6/7 events as mouse wheel events.
> These are the event names used historically in X11 before XInput2.
> -They are sometimes generated by things like `xterm-mouse-mode' as well.")
> +They are sometimes generated by things like text-terminals as well.")
>
> (defcustom mouse-wheel-down-event
> (if mouse-wheel-obey-old-style-wheel-buttons 'mouse-4)
> diff --git a/lisp/xt-mouse.el b/lisp/xt-mouse.el
> index cd00467f14f..fcc0db1d9eb 100644
> --- a/lisp/xt-mouse.el
> +++ b/lisp/xt-mouse.el
> @@ -40,6 +40,8 @@
>
> ;;; Code:
>
> +(require 'mwheel)
> +
> (defvar xterm-mouse-debug-buffer nil)
>
> (defun xterm-mouse-translate (_event)
> @@ -193,6 +195,12 @@ xterm-mouse--read-number-from-terminal
> (cons n c))
> (cons (- (setq c (xterm-mouse--read-coordinate)) 32) c))))
>
> +(defun xterm-mouse--same-button-p (event btn)
> + (and (symbolp event)
> + (string-prefix-p "mouse-" (symbol-name event))
> + (eq btn (car (read-from-string (symbol-name event)
> + (length "mouse-"))))))
> +
> ;; XTerm reports mouse events as
> ;; <EVENT-CODE> <X> <Y> in default mode, and
> ;; <EVENT-CODE> ";" <X> ";" <Y> <"M" or "m"> in extended mode.
> @@ -231,12 +239,24 @@ xterm-mouse--read-event-sequence
> ;; event: assume, that the last button was button 1.
> (t 1)))
> (sym (if move 'mouse-movement
> - (intern (concat (if ctrl "C-" "")
> - (if meta "M-" "")
> - (if shift "S-" "")
> - (if down "down-" "")
> - "mouse-"
> - (number-to-string btn))))))
> + (intern
> + (concat
> + (if ctrl "C-" "")
> + (if meta "M-" "")
> + (if shift "S-" "")
> + (if down "down-" "")
> + (cond
> + ;; BEWARE: `mouse-wheel-UP-event' corresponds to
> + ;; `wheel-DOWN' events and vice versa!!
> + ((xterm-mouse--same-button-p mouse-wheel-down-event btn)
> + "wheel-up")
> + ((xterm-mouse--same-button-p mouse-wheel-up-event btn)
> + "wheel-down")
> + ((xterm-mouse--same-button-p mouse-wheel-left-event btn)
> + "wheel-left")
> + ((xterm-mouse--same-button-p mouse-wheel-right-event btn)
> + "wheel-right")
> + (t (format "mouse-%d" btn))))))))
> (list sym (1- x) (1- y))))
>
> (defun xterm-mouse--set-click-count (event click-count)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68698
; Package
emacs
.
(Thu, 25 Jan 2024 13:48:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 68698 <at> debbugs.gnu.org (full text, mbox):
Po Lu [2024-01-25 10:25:53] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> The second step would be to do something similar for the non-XInput2 X11
>> build: make it generate `wheel-up/down` events according to
>> `mouse-wheel-down/up-event` settings. Then packages like
>> `completion-preview` and `mwheel` won't need to pay attention to the
>> (confusingly named) `mouse-wheel-down/up-event` vars any more.
>
> No!
>
> Button4, 5, 6 and 7 are only mouse wheels in one particular group of X
> servers. It is impossible to detect whether they are mouse wheels
> without the input extension (and this is why XI display connections
> produce wheel events), so such an escape hatch as mouse-wheel-*-event
> _must_ be provided for X servers where the general assumption that they
> are mouse wheels does not hold true.
I'm not suggesting to get rid of those vars. I'm suggesting to use
those vars in the C code when generating the event.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68698
; Package
emacs
.
(Thu, 25 Jan 2024 14:18:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 68698 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> I'm not suggesting to get rid of those vars. I'm suggesting to use
> those vars in the C code when generating the event.
Why, though? Why not bind them within input-decode-map, if really
necessary?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68698
; Package
emacs
.
(Thu, 25 Jan 2024 15:42:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 68698 <at> debbugs.gnu.org (full text, mbox):
Po Lu [2024-01-25 22:16:54] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> I'm not suggesting to get rid of those vars. I'm suggesting to use
>> those vars in the C code when generating the event.
> Why, though? Why not bind them within input-decode-map, if really
> necessary?
The main reason is that it's painful to do it in `input-decode-map`
because it has to be done not just for `mouse-4/5/6/7` but for all
combinations of possible modifiers (shift, control, alt, meta, super,
hyper, double, triple, down), so that's like a couple thousand entries
we'd need to put in that map.
Stefan "wishing we had more flexible keymaps (e.g. "procedural"
keymaps which can compute the binding for a given key)"
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68698
; Package
emacs
.
(Fri, 26 Jan 2024 01:42:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 68698 <at> debbugs.gnu.org (full text, mbox):
On 2024-01-24 23:30, Eli Zaretskii wrote:
>> Date: Wed, 24 Jan 2024 15:31:32 -0500
>> From: Stefan Monnier via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> Package: Emacs
>> Version: 30.0.50
>>
>>
>> Currently, wheel-up/down events are generated in most setups instead
>> of the old mouse-4/5. There are still two exceptions:
>> - X11 builds not using XInput2.
>> - text terminals.
>> The attached patch intends to fix the second bullet.
>> Text terminals themselves only give us info equivalent to `mouse-4/5`
>> and don't actually tell us that it's a wheel movement, but we can
>> still
>> turn those things into `wheel-up/down`.
>>
>> This is related to bug#49803.
>
> Jared, any comments on the patch, or related issues?
>
> Thanks.
>
>> The second step would be to do something similar for the non-XInput2
>> X11
>> build: make it generate `wheel-up/down` events according to
>> `mouse-wheel-down/up-event` settings. Then packages like
>> `completion-preview` and `mwheel` won't need to pay attention to the
>> (confusingly named) `mouse-wheel-down/up-event` vars any more.
I'll be so happy if everything switches over to mouse-up / mouse-down
events. This would be great. I'd love to ignore mouse-wheel-down-event
and mouse-wheel-down-alternate-event.
>> diff --git a/lisp/mwheel.el b/lisp/mwheel.el
>> @@ -231,12 +239,24 @@ xterm-mouse--read-event-sequence
>> ;; event: assume, that the last button was button 1.
>> (t 1)))
>> (sym (if move 'mouse-movement
>> - (intern (concat (if ctrl "C-" "")
>> - (if meta "M-" "")
>> - (if shift "S-" "")
>> - (if down "down-" "")
>> - "mouse-"
>> - (number-to-string btn))))))
>> + (intern
>> + (concat
>> + (if ctrl "C-" "")
>> + (if meta "M-" "")
>> + (if shift "S-" "")
>> + (if down "down-" "")
>> + (cond
>> + ;; BEWARE: `mouse-wheel-UP-event' corresponds to
>> + ;; `wheel-DOWN' events and vice versa!!
>> + ((xterm-mouse--same-button-p mouse-wheel-down-event
>> btn)
>> + "wheel-up")
>> + ((xterm-mouse--same-button-p mouse-wheel-up-event
>> btn)
>> + "wheel-down")
>> + ((xterm-mouse--same-button-p mouse-wheel-left-event
>> btn)
>> + "wheel-left")
>> + ((xterm-mouse--same-button-p mouse-wheel-right-event
>> btn)
>> + "wheel-right")
I think there is a bug with mouse-wheel-up/down/left/right-event and
alternate event where it doesn't take window-system into account.
Without fixing that bug, this won't work because it is valid for
mouse-wheel-up-event to be wheel-down in a terminal. A local run of
HEAD (as of Jan 17, I'm at daec3e) with "./configure --with-pgtk" has
mouse-wheel-up-event set to wheel-down because (featurep 'pgtk-win) is
t, even with -nw on the command line. Testing on Windows at Emacs 29.1
shows the same behavior.
Also, I do not think xt-mouse knows how to generate mouse-6 or mouse-7
events. I think to generate events beyond mouse-5, you need to test
against the 128 bit as well. I don't have mouse hardware to confirm
this behavior.
-- MJF
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68698
; Package
emacs
.
(Fri, 26 Jan 2024 02:01:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 68698 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> The main reason is that it's painful to do it in `input-decode-map`
> because it has to be done not just for `mouse-4/5/6/7` but for all
> combinations of possible modifiers (shift, control, alt, meta, super,
> hyper, double, triple, down), so that's like a couple thousand entries
> we'd need to put in that map.
I am quite loath to change the set of events generated by the X11 button
event processing code, in view of the convoluted interaction between it,
toolkits, and code further down the line. Any other solution would be
preferable, such as perhaps:
> Stefan "wishing we had more flexible keymaps (e.g. "procedural"
> keymaps which can compute the binding for a given key)"
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68698
; Package
emacs
.
(Fri, 26 Jan 2024 02:28:03 GMT)
Full text and
rfc822 format available.
Message #29 received at 68698 <at> debbugs.gnu.org (full text, mbox):
> A local run of HEAD (as of Jan 17, I'm at daec3e) with
> "./configure --with-pgtk" has mouse-wheel-up-event set to wheel-down
> because (featurep 'pgtk-win) is t, even with -nw on the command line.
> Testing on Windows at Emacs 29.1 shows the same behavior.
This has been changed on `master` around Jan 19. Now `mwheel.el` uses
`wheel-up/down` unconditionally and `mouse-wheel-up/down-event` is only
used for *other* events (defaults to `mouse-4/5`).
> Also, I do not think xt-mouse knows how to generate mouse-6 or mouse-7
> events. I think to generate events beyond mouse-5, you need to test
> against the 128 bit as well. I don't have mouse hardware to confirm
> this behavior.
I didn't both to check the code to see if that can happen (especially
since there are various possible encodings coming from the terminal).
The way wrote the code, it'll do the right thing if/when the rest of
`xt-mouse` manages to generate those events, but indeed it might be the
case that currently this will never happen.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68698
; Package
emacs
.
(Fri, 26 Jan 2024 02:31:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 68698 <at> debbugs.gnu.org (full text, mbox):
Po Lu [2024-01-26 09:59:50] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> The main reason is that it's painful to do it in `input-decode-map`
>> because it has to be done not just for `mouse-4/5/6/7` but for all
>> combinations of possible modifiers (shift, control, alt, meta, super,
>> hyper, double, triple, down), so that's like a couple thousand entries
>> we'd need to put in that map.
>
> I am quite loath to change the set of events generated by the X11 button
> event processing code, in view of the convoluted interaction between it,
> toolkits, and code further down the line. Any other solution would be
> preferable, such as perhaps:
OK, will keep this in mind. The current bug#68698 is only suggesting
changing `xt-mouse.el`, tho, so we can leave the X11 case for later (or
for never, since we may also decide to let it disappear into the past
as XInput2 becomes the norm).
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68698
; Package
emacs
.
(Fri, 26 Jan 2024 05:03:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 68698 <at> debbugs.gnu.org (full text, mbox):
On 2024-01-25 18:26, Stefan Monnier wrote:
>> A local run of HEAD (as of Jan 17, I'm at daec3e) with
>> "./configure --with-pgtk" has mouse-wheel-up-event set to wheel-down
>> because (featurep 'pgtk-win) is t, even with -nw on the command line.
>> Testing on Windows at Emacs 29.1 shows the same behavior.
>
> This has been changed on `master` around Jan 19. Now `mwheel.el` uses
> `wheel-up/down` unconditionally and `mouse-wheel-up/down-event` is only
> used for *other* events (defaults to `mouse-4/5`).
>
>> Also, I do not think xt-mouse knows how to generate mouse-6 or mouse-7
>> events. I think to generate events beyond mouse-5, you need to test
>> against the 128 bit as well. I don't have mouse hardware to confirm
>> this behavior.
>
> I didn't both to check the code to see if that can happen (especially
> since there are various possible encodings coming from the terminal).
> The way wrote the code, it'll do the right thing if/when the rest of
> `xt-mouse` manages to generate those events, but indeed it might be the
> case that currently this will never happen.
Ah great!
Then I have no concerns about this patch.
-- MJF
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68698
; Package
emacs
.
(Fri, 26 Jan 2024 07:57:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 68698 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 68698 <at> debbugs.gnu.org
> Date: Thu, 25 Jan 2024 21:26:49 -0500
>
> > A local run of HEAD (as of Jan 17, I'm at daec3e) with
> > "./configure --with-pgtk" has mouse-wheel-up-event set to wheel-down
> > because (featurep 'pgtk-win) is t, even with -nw on the command line.
> > Testing on Windows at Emacs 29.1 shows the same behavior.
>
> This has been changed on `master` around Jan 19. Now `mwheel.el` uses
> `wheel-up/down` unconditionally and `mouse-wheel-up/down-event` is only
> used for *other* events (defaults to `mouse-4/5`).
Was this reflected in the documentation? The ELisp Reference manual
still says
The ‘wheel-up’ and ‘wheel-down’ events are generated only on some
kinds of systems. On other systems, other events like ‘mouse-4’
and ‘mouse-5’ are used instead. Portable code should handle both
‘wheel-up’ and ‘wheel-down’ events as well as the events specified
in the variables ‘mouse-wheel-up-event’ and
‘mouse-wheel-down-event’, defined in ‘mwheel.el’. Beware that for
historical reasons the ‘mouse-wheel-_up_-event’ is the variable
that holds an event that should be handled similarly to
‘wheel-_down_’ and vice versa.
Is that still correct and accurate? (And what about a similar issue
with wheel-left/right?).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68698
; Package
emacs
.
(Fri, 26 Jan 2024 13:05:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 68698 <at> debbugs.gnu.org (full text, mbox):
>> > A local run of HEAD (as of Jan 17, I'm at daec3e) with
>> > "./configure --with-pgtk" has mouse-wheel-up-event set to wheel-down
>> > because (featurep 'pgtk-win) is t, even with -nw on the command line.
>> > Testing on Windows at Emacs 29.1 shows the same behavior.
>>
>> This has been changed on `master` around Jan 19. Now `mwheel.el` uses
>> `wheel-up/down` unconditionally and `mouse-wheel-up/down-event` is only
>> used for *other* events (defaults to `mouse-4/5`).
>
> Was this reflected in the documentation? The ELisp Reference manual
> still says
>
> The ‘wheel-up’ and ‘wheel-down’ events are generated only on some
> kinds of systems. On other systems, other events like ‘mouse-4’
> and ‘mouse-5’ are used instead. Portable code should handle both
> ‘wheel-up’ and ‘wheel-down’ events as well as the events specified
> in the variables ‘mouse-wheel-up-event’ and
> ‘mouse-wheel-down-event’, defined in ‘mwheel.el’. Beware that for
> historical reasons the ‘mouse-wheel-_up_-event’ is the variable
> that holds an event that should be handled similarly to
> ‘wheel-_down_’ and vice versa.
>
> Is that still correct and accurate? (And what about a similar issue
> with wheel-left/right?).
Yup, before Jan 19 the text was different :-)
Stefan
Reply sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>
:
You have taken responsibility.
(Sun, 28 Jan 2024 23:53:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>
:
bug acknowledged by developer.
(Sun, 28 Jan 2024 23:53:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 68698-done <at> debbugs.gnu.org (full text, mbox):
Pushed to `master`, closing,
Stefan
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 26 Feb 2024 12:24:16 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 115 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.