GNU bug report logs -
#71646
29.3; pixel-scroll-precision-mode overrides paging behaviour even when pixel-scroll-precision-interpolate-page is off
Previous Next
To reply to this bug, email your comments to 71646 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Wed, 19 Jun 2024 10:48:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Mike Woolley <mike <at> bulsara.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 19 Jun 2024 10:48: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)]
Hi,
Playing with `pixel-scroll-precision-mode’ I noticed a small issue:
Setting `pixel-scroll-precision-interpolate-page’ is supposed to turn off the paging animation (which it does) however even when it’s off, <prior> and <next> invoke `cua-scroll-up’ & `cua-scroll-down’ rather than allowing another keymap to handle it.
Unfortunately this means any other mapping for these keys you might have has now been silently overridden (even after you’ve said you don’t want the new behaviour).
(defun pixel-scroll-interpolate-up ()
"Interpolate a scroll upwards by one page."
(interactive)
(if pixel-scroll-precision-interpolate-page
(pixel-scroll-precision-interpolate (window-text-height nil t) nil 1)
(cua-scroll-down)))
I think it would be better if `pixel-scroll-precision-mode’ did nothing if `pixel-scroll-precision-interpolate-page’ is off and allowed another keycap to handle <prior> & <next>.
I also noticed that it only maps <prior> & <next> and not C-v / M-v, so in other words behaviour could be different depending on exactly which Page Up & Down key sequence you invoke.
Thanks,
Mike
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Sat, 22 Jun 2024 08:58:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 71646 <at> debbugs.gnu.org (full text, mbox):
> From: Mike Woolley <mike <at> bulsara.com>
> Date: Wed, 19 Jun 2024 11:44:52 +0100
>
> Playing with `pixel-scroll-precision-mode’ I noticed a small issue:
>
> Setting `pixel-scroll-precision-interpolate-page’ is supposed to turn off the paging animation (which it does)
> however even when it’s off, <prior> and <next> invoke `cua-scroll-up’ & `cua-scroll-down’ rather than allowing
> another keymap to handle it.
>
> Unfortunately this means any other mapping for these keys you might have has now been silently overridden
> (even after you’ve said you don’t want the new behaviour).
>
> (defun pixel-scroll-interpolate-up ()
> "Interpolate a scroll upwards by one page."
> (interactive)
> (if pixel-scroll-precision-interpolate-page
> (pixel-scroll-precision-interpolate (window-text-height nil t) nil 1)
> (cua-scroll-down)))
>
> I think it would be better if `pixel-scroll-precision-mode’ did nothing if `pixel-scroll-precision-interpolate-page’ is
> off and allowed another keycap to handle <prior> & <next>.
>
> I also noticed that it only maps <prior> & <next> and not C-v / M-v, so in other words behaviour could be
> different depending on exactly which Page Up & Down key sequence you invoke.
Po Lu, any comments or suggestions?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Sat, 06 Jul 2024 07:40:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 71646 <at> debbugs.gnu.org (full text, mbox):
Ping!
> Cc: 71646 <at> debbugs.gnu.org
> Date: Sat, 22 Jun 2024 11:57:43 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > From: Mike Woolley <mike <at> bulsara.com>
> > Date: Wed, 19 Jun 2024 11:44:52 +0100
> >
> > Playing with `pixel-scroll-precision-mode’ I noticed a small issue:
> >
> > Setting `pixel-scroll-precision-interpolate-page’ is supposed to turn off the paging animation (which it does)
> > however even when it’s off, <prior> and <next> invoke `cua-scroll-up’ & `cua-scroll-down’ rather than allowing
> > another keymap to handle it.
> >
> > Unfortunately this means any other mapping for these keys you might have has now been silently overridden
> > (even after you’ve said you don’t want the new behaviour).
> >
> > (defun pixel-scroll-interpolate-up ()
> > "Interpolate a scroll upwards by one page."
> > (interactive)
> > (if pixel-scroll-precision-interpolate-page
> > (pixel-scroll-precision-interpolate (window-text-height nil t) nil 1)
> > (cua-scroll-down)))
> >
> > I think it would be better if `pixel-scroll-precision-mode’ did nothing if `pixel-scroll-precision-interpolate-page’ is
> > off and allowed another keycap to handle <prior> & <next>.
> >
> > I also noticed that it only maps <prior> & <next> and not C-v / M-v, so in other words behaviour could be
> > different depending on exactly which Page Up & Down key sequence you invoke.
>
> Po Lu, any comments or suggestions?
>
>
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Sat, 06 Jul 2024 08:41:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 71646 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Ping!
>
>> Cc: 71646 <at> debbugs.gnu.org
>> Date: Sat, 22 Jun 2024 11:57:43 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>>
>> > From: Mike Woolley <mike <at> bulsara.com>
>> > Date: Wed, 19 Jun 2024 11:44:52 +0100
>> >
>> > Playing with `pixel-scroll-precision-mode’ I noticed a small issue:
>> >
>> > Setting `pixel-scroll-precision-interpolate-page’ is supposed to turn off the paging animation (which it does)
>> > however even when it’s off, <prior> and <next> invoke `cua-scroll-up’ & `cua-scroll-down’ rather than allowing
>> > another keymap to handle it.
>> >
>> > Unfortunately this means any other mapping for these keys you might have has now been silently overridden
>> > (even after you’ve said you don’t want the new behaviour).
>> >
>> > (defun pixel-scroll-interpolate-up ()
>> > "Interpolate a scroll upwards by one page."
>> > (interactive)
>> > (if pixel-scroll-precision-interpolate-page
>> > (pixel-scroll-precision-interpolate (window-text-height nil t) nil 1)
>> > (cua-scroll-down)))
>> >
>> > I think it would be better if `pixel-scroll-precision-mode’ did nothing if `pixel-scroll-precision-interpolate-page’ is
>> > off and allowed another keycap to handle <prior> & <next>.
>> >
>> > I also noticed that it only maps <prior> & <next> and not C-v / M-v, so in other words behaviour could be
>> > different depending on exactly which Page Up & Down key sequence you invoke.
>>
>> Po Lu, any comments or suggestions?
Mike, is there any reason in particular you cannot remove the bindings
of `prior' and `next' from `pixel-scroll-precision-mode-map'?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Sat, 20 Jul 2024 09:42:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 71646 <at> debbugs.gnu.org (full text, mbox):
Ping! Mike, can you answer Po Lu's question, please?
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: mike <at> bulsara.com, 71646 <at> debbugs.gnu.org
> Date: Sat, 06 Jul 2024 16:40:01 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Ping!
> >
> >> Cc: 71646 <at> debbugs.gnu.org
> >> Date: Sat, 22 Jun 2024 11:57:43 +0300
> >> From: Eli Zaretskii <eliz <at> gnu.org>
> >>
> >> > From: Mike Woolley <mike <at> bulsara.com>
> >> > Date: Wed, 19 Jun 2024 11:44:52 +0100
> >> >
> >> > Playing with `pixel-scroll-precision-mode’ I noticed a small issue:
> >> >
> >> > Setting `pixel-scroll-precision-interpolate-page’ is supposed to turn off the paging animation (which it does)
> >> > however even when it’s off, <prior> and <next> invoke `cua-scroll-up’ & `cua-scroll-down’ rather than allowing
> >> > another keymap to handle it.
> >> >
> >> > Unfortunately this means any other mapping for these keys you might have has now been silently overridden
> >> > (even after you’ve said you don’t want the new behaviour).
> >> >
> >> > (defun pixel-scroll-interpolate-up ()
> >> > "Interpolate a scroll upwards by one page."
> >> > (interactive)
> >> > (if pixel-scroll-precision-interpolate-page
> >> > (pixel-scroll-precision-interpolate (window-text-height nil t) nil 1)
> >> > (cua-scroll-down)))
> >> >
> >> > I think it would be better if `pixel-scroll-precision-mode’ did nothing if `pixel-scroll-precision-interpolate-page’ is
> >> > off and allowed another keycap to handle <prior> & <next>.
> >> >
> >> > I also noticed that it only maps <prior> & <next> and not C-v / M-v, so in other words behaviour could be
> >> > different depending on exactly which Page Up & Down key sequence you invoke.
> >>
> >> Po Lu, any comments or suggestions?
>
> Mike, is there any reason in particular you cannot remove the bindings
> of `prior' and `next' from `pixel-scroll-precision-mode-map'?
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Sat, 20 Jul 2024 10:11:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 71646 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Sorry Eli,
I had replied, but forgot to CC the list :-)
What I was saying was: of course I can remove the bindings from the map myself (& indeed that’s what I've done), but my point is why should I have to?
Why is a feature that’s turned off still having an effect? I think this is unnecessary and surprising to users (at least it was to me)!
I was thinking this paging animation feature might be better as it’s own minor mode, which would do the right thing with keymaps and is how the other features in the same file are implemented?
Thanks,
Mike
> On 20 Jul 2024, at 10:40, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> Ping! Mike, can you answer Po Lu's question, please?
>
>> From: Po Lu <luangruo <at> yahoo.com>
>> Cc: mike <at> bulsara.com, 71646 <at> debbugs.gnu.org
>> Date: Sat, 06 Jul 2024 16:40:01 +0800
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>> Ping!
>>>
>>>> Cc: 71646 <at> debbugs.gnu.org
>>>> Date: Sat, 22 Jun 2024 11:57:43 +0300
>>>> From: Eli Zaretskii <eliz <at> gnu.org>
>>>>
>>>>> From: Mike Woolley <mike <at> bulsara.com>
>>>>> Date: Wed, 19 Jun 2024 11:44:52 +0100
>>>>>
>>>>> Playing with `pixel-scroll-precision-mode’ I noticed a small issue:
>>>>>
>>>>> Setting `pixel-scroll-precision-interpolate-page’ is supposed to turn off the paging animation (which it does)
>>>>> however even when it’s off, <prior> and <next> invoke `cua-scroll-up’ & `cua-scroll-down’ rather than allowing
>>>>> another keymap to handle it.
>>>>>
>>>>> Unfortunately this means any other mapping for these keys you might have has now been silently overridden
>>>>> (even after you’ve said you don’t want the new behaviour).
>>>>>
>>>>> (defun pixel-scroll-interpolate-up ()
>>>>> "Interpolate a scroll upwards by one page."
>>>>> (interactive)
>>>>> (if pixel-scroll-precision-interpolate-page
>>>>> (pixel-scroll-precision-interpolate (window-text-height nil t) nil 1)
>>>>> (cua-scroll-down)))
>>>>>
>>>>> I think it would be better if `pixel-scroll-precision-mode’ did nothing if `pixel-scroll-precision-interpolate-page’ is
>>>>> off and allowed another keycap to handle <prior> & <next>.
>>>>>
>>>>> I also noticed that it only maps <prior> & <next> and not C-v / M-v, so in other words behaviour could be
>>>>> different depending on exactly which Page Up & Down key sequence you invoke.
>>>>
>>>> Po Lu, any comments or suggestions?
>>
>> Mike, is there any reason in particular you cannot remove the bindings
>> of `prior' and `next' from `pixel-scroll-precision-mode-map'?
>>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Sun, 04 Aug 2024 07:56:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 71646 <at> debbugs.gnu.org (full text, mbox):
Po Lu, how can we make some progress here?
> From: Mike Woolley <mike <at> bulsara.com>
> Date: Sat, 20 Jul 2024 11:10:15 +0100
> Cc: Po Lu <luangruo <at> yahoo.com>,
> 71646 <at> debbugs.gnu.org
>
> Sorry Eli,
>
> I had replied, but forgot to CC the list :-)
>
> What I was saying was: of course I can remove the bindings from the map myself (& indeed that’s what I've
> done), but my point is why should I have to?
> Why is a feature that’s turned off still having an effect? I think this is unnecessary and surprising to users (at
> least it was to me)!
>
> I was thinking this paging animation feature might be better as it’s own minor mode, which would do the right
> thing with keymaps and is how the other features in the same file are implemented?
>
> Thanks,
> Mike
>
> On 20 Jul 2024, at 10:40, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> Ping! Mike, can you answer Po Lu's question, please?
>
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: mike <at> bulsara.com, 71646 <at> debbugs.gnu.org
> Date: Sat, 06 Jul 2024 16:40:01 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Ping!
>
> Cc: 71646 <at> debbugs.gnu.org
> Date: Sat, 22 Jun 2024 11:57:43 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> From: Mike Woolley <mike <at> bulsara.com>
> Date: Wed, 19 Jun 2024 11:44:52 +0100
>
> Playing with `pixel-scroll-precision-mode’ I noticed a small issue:
>
> Setting `pixel-scroll-precision-interpolate-page’ is supposed to turn off the paging
> animation (which it does)
> however even when it’s off, <prior> and <next> invoke `cua-scroll-up’ &
> `cua-scroll-down’ rather than allowing
> another keymap to handle it.
>
> Unfortunately this means any other mapping for these keys you might have has
> now been silently overridden
> (even after you’ve said you don’t want the new behaviour).
>
> (defun pixel-scroll-interpolate-up ()
> "Interpolate a scroll upwards by one page."
> (interactive)
> (if pixel-scroll-precision-interpolate-page
> (pixel-scroll-precision-interpolate (window-text-height nil t) nil 1)
> (cua-scroll-down)))
>
> I think it would be better if `pixel-scroll-precision-mode’ did nothing if
> `pixel-scroll-precision-interpolate-page’ is
> off and allowed another keycap to handle <prior> & <next>.
>
> I also noticed that it only maps <prior> & <next> and not C-v / M-v, so in other
> words behaviour could be
> different depending on exactly which Page Up & Down key sequence you invoke.
>
> Po Lu, any comments or suggestions?
>
> Mike, is there any reason in particular you cannot remove the bindings
> of `prior' and `next' from `pixel-scroll-precision-mode-map'?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Sat, 17 Aug 2024 08:23:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 71646 <at> debbugs.gnu.org (full text, mbox):
Ping!
> Cc: 71646 <at> debbugs.gnu.org
> Date: Sun, 04 Aug 2024 10:54:54 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> Po Lu, how can we make some progress here?
>
> > From: Mike Woolley <mike <at> bulsara.com>
> > Date: Sat, 20 Jul 2024 11:10:15 +0100
> > Cc: Po Lu <luangruo <at> yahoo.com>,
> > 71646 <at> debbugs.gnu.org
> >
> > Sorry Eli,
> >
> > I had replied, but forgot to CC the list :-)
> >
> > What I was saying was: of course I can remove the bindings from the map myself (& indeed that’s what I've
> > done), but my point is why should I have to?
> > Why is a feature that’s turned off still having an effect? I think this is unnecessary and surprising to users (at
> > least it was to me)!
> >
> > I was thinking this paging animation feature might be better as it’s own minor mode, which would do the right
> > thing with keymaps and is how the other features in the same file are implemented?
> >
> > Thanks,
> > Mike
> >
> > On 20 Jul 2024, at 10:40, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > Ping! Mike, can you answer Po Lu's question, please?
> >
> > From: Po Lu <luangruo <at> yahoo.com>
> > Cc: mike <at> bulsara.com, 71646 <at> debbugs.gnu.org
> > Date: Sat, 06 Jul 2024 16:40:01 +0800
> >
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > Ping!
> >
> > Cc: 71646 <at> debbugs.gnu.org
> > Date: Sat, 22 Jun 2024 11:57:43 +0300
> > From: Eli Zaretskii <eliz <at> gnu.org>
> >
> > From: Mike Woolley <mike <at> bulsara.com>
> > Date: Wed, 19 Jun 2024 11:44:52 +0100
> >
> > Playing with `pixel-scroll-precision-mode’ I noticed a small issue:
> >
> > Setting `pixel-scroll-precision-interpolate-page’ is supposed to turn off the paging
> > animation (which it does)
> > however even when it’s off, <prior> and <next> invoke `cua-scroll-up’ &
> > `cua-scroll-down’ rather than allowing
> > another keymap to handle it.
> >
> > Unfortunately this means any other mapping for these keys you might have has
> > now been silently overridden
> > (even after you’ve said you don’t want the new behaviour).
> >
> > (defun pixel-scroll-interpolate-up ()
> > "Interpolate a scroll upwards by one page."
> > (interactive)
> > (if pixel-scroll-precision-interpolate-page
> > (pixel-scroll-precision-interpolate (window-text-height nil t) nil 1)
> > (cua-scroll-down)))
> >
> > I think it would be better if `pixel-scroll-precision-mode’ did nothing if
> > `pixel-scroll-precision-interpolate-page’ is
> > off and allowed another keycap to handle <prior> & <next>.
> >
> > I also noticed that it only maps <prior> & <next> and not C-v / M-v, so in other
> > words behaviour could be
> > different depending on exactly which Page Up & Down key sequence you invoke.
> >
> > Po Lu, any comments or suggestions?
> >
> > Mike, is there any reason in particular you cannot remove the bindings
> > of `prior' and `next' from `pixel-scroll-precision-mode-map'?
>
>
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Sat, 17 Aug 2024 08:26:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 71646 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Ping!
>
>> Cc: 71646 <at> debbugs.gnu.org
>> Date: Sun, 04 Aug 2024 10:54:54 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>>
>> Po Lu, how can we make some progress here?
>>
>> > From: Mike Woolley <mike <at> bulsara.com>
>> > Date: Sat, 20 Jul 2024 11:10:15 +0100
>> > Cc: Po Lu <luangruo <at> yahoo.com>,
>> > 71646 <at> debbugs.gnu.org
>> >
>> > Sorry Eli,
>> >
>> > I had replied, but forgot to CC the list :-)
I suspect that if you make this mistake and correct it afterwards the
entire thread will be classified as spam...
>> > What I was saying was: of course I can remove the bindings from the map myself (& indeed that’s what I've
>> > done), but my point is why should I have to?
>> > Why is a feature that’s turned off still having an effect? I think this is unnecessary and surprising to users (at
>> > least it was to me)!
>> >
>> > I was thinking this paging animation feature might be better as it’s own minor mode, which would do the right
>> > thing with keymaps and is how the other features in the same file are implemented?
Yes, but that ship sailed with the release of Emacs 29. It's too late
to change any of these mechanics.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Sat, 24 Aug 2024 08:45:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 71646 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: mike <at> bulsara.com, 71646 <at> debbugs.gnu.org
> Date: Sat, 17 Aug 2024 16:24:28 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Ping!
> >
> >> Cc: 71646 <at> debbugs.gnu.org
> >> Date: Sun, 04 Aug 2024 10:54:54 +0300
> >> From: Eli Zaretskii <eliz <at> gnu.org>
> >>
> >> Po Lu, how can we make some progress here?
> >>
> >> > From: Mike Woolley <mike <at> bulsara.com>
> >> > Date: Sat, 20 Jul 2024 11:10:15 +0100
> >> > Cc: Po Lu <luangruo <at> yahoo.com>,
> >> > 71646 <at> debbugs.gnu.org
> >> >
> >> > Sorry Eli,
> >> >
> >> > I had replied, but forgot to CC the list :-)
>
> I suspect that if you make this mistake and correct it afterwards the
> entire thread will be classified as spam...
>
> >> > What I was saying was: of course I can remove the bindings from the map myself (& indeed that’s what I've
> >> > done), but my point is why should I have to?
> >> > Why is a feature that’s turned off still having an effect? I think this is unnecessary and surprising to users (at
> >> > least it was to me)!
> >> >
> >> > I was thinking this paging animation feature might be better as it’s own minor mode, which would do the right
> >> > thing with keymaps and is how the other features in the same file are implemented?
>
> Yes, but that ship sailed with the release of Emacs 29. It's too late
> to change any of these mechanics.
So should we close this bug as wontfix, then?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Sat, 31 Aug 2024 09:26:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 71646 <at> debbugs.gnu.org (full text, mbox):
Ping! Should I close this?
> Cc: mike <at> bulsara.com, 71646 <at> debbugs.gnu.org
> Date: Sat, 24 Aug 2024 11:43:51 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > From: Po Lu <luangruo <at> yahoo.com>
> > Cc: mike <at> bulsara.com, 71646 <at> debbugs.gnu.org
> > Date: Sat, 17 Aug 2024 16:24:28 +0800
> >
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > > Ping!
> > >
> > >> Cc: 71646 <at> debbugs.gnu.org
> > >> Date: Sun, 04 Aug 2024 10:54:54 +0300
> > >> From: Eli Zaretskii <eliz <at> gnu.org>
> > >>
> > >> Po Lu, how can we make some progress here?
> > >>
> > >> > From: Mike Woolley <mike <at> bulsara.com>
> > >> > Date: Sat, 20 Jul 2024 11:10:15 +0100
> > >> > Cc: Po Lu <luangruo <at> yahoo.com>,
> > >> > 71646 <at> debbugs.gnu.org
> > >> >
> > >> > Sorry Eli,
> > >> >
> > >> > I had replied, but forgot to CC the list :-)
> >
> > I suspect that if you make this mistake and correct it afterwards the
> > entire thread will be classified as spam...
> >
> > >> > What I was saying was: of course I can remove the bindings from the map myself (& indeed that’s what I've
> > >> > done), but my point is why should I have to?
> > >> > Why is a feature that’s turned off still having an effect? I think this is unnecessary and surprising to users (at
> > >> > least it was to me)!
> > >> >
> > >> > I was thinking this paging animation feature might be better as it’s own minor mode, which would do the right
> > >> > thing with keymaps and is how the other features in the same file are implemented?
> >
> > Yes, but that ship sailed with the release of Emacs 29. It's too late
> > to change any of these mechanics.
>
> So should we close this bug as wontfix, then?
>
>
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Sat, 31 Aug 2024 09:56:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 71646 <at> debbugs.gnu.org (full text, mbox):
I’m quite happy to fix it along the lines I suggested, it’s only a small, low impact change?
Thanks,
Mike
> On 31 Aug 2024, at 10:24, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> Ping! Should I close this?
>
>> Cc: mike <at> bulsara.com, 71646 <at> debbugs.gnu.org
>> Date: Sat, 24 Aug 2024 11:43:51 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>>
>>> From: Po Lu <luangruo <at> yahoo.com>
>>> Cc: mike <at> bulsara.com, 71646 <at> debbugs.gnu.org
>>> Date: Sat, 17 Aug 2024 16:24:28 +0800
>>>
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>
>>>> Ping!
>>>>
>>>>> Cc: 71646 <at> debbugs.gnu.org
>>>>> Date: Sun, 04 Aug 2024 10:54:54 +0300
>>>>> From: Eli Zaretskii <eliz <at> gnu.org>
>>>>>
>>>>> Po Lu, how can we make some progress here?
>>>>>
>>>>>> From: Mike Woolley <mike <at> bulsara.com>
>>>>>> Date: Sat, 20 Jul 2024 11:10:15 +0100
>>>>>> Cc: Po Lu <luangruo <at> yahoo.com>,
>>>>>> 71646 <at> debbugs.gnu.org
>>>>>>
>>>>>> Sorry Eli,
>>>>>>
>>>>>> I had replied, but forgot to CC the list :-)
>>>
>>> I suspect that if you make this mistake and correct it afterwards the
>>> entire thread will be classified as spam...
>>>
>>>>>> What I was saying was: of course I can remove the bindings from the map myself (& indeed that’s what I've
>>>>>> done), but my point is why should I have to?
>>>>>> Why is a feature that’s turned off still having an effect? I think this is unnecessary and surprising to users (at
>>>>>> least it was to me)!
>>>>>>
>>>>>> I was thinking this paging animation feature might be better as it’s own minor mode, which would do the right
>>>>>> thing with keymaps and is how the other features in the same file are implemented?
>>>
>>> Yes, but that ship sailed with the release of Emacs 29. It's too late
>>> to change any of these mechanics.
>>
>> So should we close this bug as wontfix, then?
>>
>>
>>
>>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Sun, 01 Sep 2024 09:52:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 71646 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Ping! Should I close this?
Shouldn't we rather fix the bug described by Mike? I.e. this:
> Setting `pixel-scroll-precision-interpolate-page’ is supposed to
> turn off the paging animation (which it does) however even when it’s
> off, <prior> and <next> invoke `cua-scroll-up’ & `cua-scroll-down’
> rather than allowing another keymap to handle it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Sun, 01 Sep 2024 10:36:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 71646 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sun, 1 Sep 2024 02:48:57 -0700
> Cc: mike <at> bulsara.com, 71646 <at> debbugs.gnu.org
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Ping! Should I close this?
>
> Shouldn't we rather fix the bug described by Mike? I.e. this:
>
> > Setting `pixel-scroll-precision-interpolate-page’ is supposed to
> > turn off the paging animation (which it does) however even when it’s
> > off, <prior> and <next> invoke `cua-scroll-up’ & `cua-scroll-down’
> > rather than allowing another keymap to handle it.
I don't mind to fixing this, if possible, but (a) I don't think I
understand what is being suggested by the text you quote above, and
(b) given Po Lu's response, it doesn't seem like the proposed changes
will be accepted, or did I miss something?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Sun, 01 Sep 2024 11:37:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 71646 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> Ping! Should I close this?
>
> Shouldn't we rather fix the bug described by Mike? I.e. this:
>
>> Setting `pixel-scroll-precision-interpolate-page’ is supposed to
>> turn off the paging animation (which it does) however even when it’s
>> off, <prior> and <next> invoke `cua-scroll-up’ & `cua-scroll-down’
>> rather than allowing another keymap to handle it.
This isn't a bug. If ever there was a time to object to these
semantics, it was two years ago, at which time all I heard was
enthusiastic support.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Sun, 01 Sep 2024 11:55:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 71646 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Sun, 1 Sep 2024 02:48:57 -0700
>> Cc: mike <at> bulsara.com, 71646 <at> debbugs.gnu.org
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > Ping! Should I close this?
>>
>> Shouldn't we rather fix the bug described by Mike? I.e. this:
>>
>> > Setting `pixel-scroll-precision-interpolate-page’ is supposed to
>> > turn off the paging animation (which it does) however even when it’s
>> > off, <prior> and <next> invoke `cua-scroll-up’ & `cua-scroll-down’
>> > rather than allowing another keymap to handle it.
>
> I don't mind to fixing this, if possible, but (a) I don't think I
> understand what is being suggested by the text you quote above, and
> (b) given Po Lu's response, it doesn't seem like the proposed changes
> will be accepted, or did I miss something?
My problem is that two years ago I stated quite clearly why it was
inappropriate to engineer paging interpolation into p-s-p-m (in a
Telegram group), to the deaf ears of the mob requesting it, but since it
is only now that we have received a lone complaint, it's safe to
conclude that most users are satisfied with its established behavior,
which should at least give us pause before any decision to tamper with
it some more, and which behavior, mind you, had already been revised
once in response to user feedback before 29.1. The optimal solution is
simply not to bind p-s-p-i-p in pixel-scroll-precision-mode, but users
disagreed then, and now it's far too late to tamper with these bindings.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Sat, 07 Sep 2024 08:09:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 71646 <at> debbugs.gnu.org (full text, mbox):
> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Stefan Kangas <stefankangas <at> gmail.com>, mike <at> bulsara.com,
> 71646 <at> debbugs.gnu.org
> Date: Sun, 01 Sep 2024 19:52:19 +0800
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Stefan Kangas <stefankangas <at> gmail.com>
> >> Date: Sun, 1 Sep 2024 02:48:57 -0700
> >> Cc: mike <at> bulsara.com, 71646 <at> debbugs.gnu.org
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> > Ping! Should I close this?
> >>
> >> Shouldn't we rather fix the bug described by Mike? I.e. this:
> >>
> >> > Setting `pixel-scroll-precision-interpolate-page’ is supposed to
> >> > turn off the paging animation (which it does) however even when it’s
> >> > off, <prior> and <next> invoke `cua-scroll-up’ & `cua-scroll-down’
> >> > rather than allowing another keymap to handle it.
> >
> > I don't mind to fixing this, if possible, but (a) I don't think I
> > understand what is being suggested by the text you quote above, and
> > (b) given Po Lu's response, it doesn't seem like the proposed changes
> > will be accepted, or did I miss something?
>
> My problem is that two years ago I stated quite clearly why it was
> inappropriate to engineer paging interpolation into p-s-p-m (in a
> Telegram group), to the deaf ears of the mob requesting it, but since it
> is only now that we have received a lone complaint, it's safe to
> conclude that most users are satisfied with its established behavior,
> which should at least give us pause before any decision to tamper with
> it some more, and which behavior, mind you, had already been revised
> once in response to user feedback before 29.1. The optimal solution is
> simply not to bind p-s-p-i-p in pixel-scroll-precision-mode, but users
> disagreed then, and now it's far too late to tamper with these bindings.
So what to do with this bug? close as wontfix? leave open and hope
someone will find a solution? something else?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#71646
; Package
emacs
.
(Sat, 07 Sep 2024 09:35:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 71646 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Po Lu <luangruo <at> yahoo.com>
>> Cc: Stefan Kangas <stefankangas <at> gmail.com>, mike <at> bulsara.com,
>> 71646 <at> debbugs.gnu.org
>> Date: Sun, 01 Sep 2024 19:52:19 +0800
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> From: Stefan Kangas <stefankangas <at> gmail.com>
>> >> Date: Sun, 1 Sep 2024 02:48:57 -0700
>> >> Cc: mike <at> bulsara.com, 71646 <at> debbugs.gnu.org
>> >>
>> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >>
>> >> > Ping! Should I close this?
>> >>
>> >> Shouldn't we rather fix the bug described by Mike? I.e. this:
>> >>
>> >> > Setting `pixel-scroll-precision-interpolate-page’ is supposed to
>> >> > turn off the paging animation (which it does) however even when it’s
>> >> > off, <prior> and <next> invoke `cua-scroll-up’ & `cua-scroll-down’
>> >> > rather than allowing another keymap to handle it.
>> >
>> > I don't mind to fixing this, if possible, but (a) I don't think I
>> > understand what is being suggested by the text you quote above, and
>> > (b) given Po Lu's response, it doesn't seem like the proposed changes
>> > will be accepted, or did I miss something?
>>
>> My problem is that two years ago I stated quite clearly why it was
>> inappropriate to engineer paging interpolation into p-s-p-m (in a
>> Telegram group), to the deaf ears of the mob requesting it, but since it
>> is only now that we have received a lone complaint, it's safe to
>> conclude that most users are satisfied with its established behavior,
>> which should at least give us pause before any decision to tamper with
>> it some more, and which behavior, mind you, had already been revised
>> once in response to user feedback before 29.1. The optimal solution is
>> simply not to bind p-s-p-i-p in pixel-scroll-precision-mode, but users
>> disagreed then, and now it's far too late to tamper with these bindings.
>
> So what to do with this bug? close as wontfix? leave open and hope
> someone will find a solution? something else?
I'd prefer to decide this question after Emacs 30 is released when
I will enjoy more time to devote to Emacs.
This bug report was last modified today.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.