GNU bug report logs -
#57876
[PATCH] pulse-momentary-highlight-one-line: Act on visual line
Previous Next
Reported by: Augusto Stoffel <arstoffel <at> gmail.com>
Date: Sat, 17 Sep 2022 08:24:01 UTC
Severity: normal
Tags: patch
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
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 57876 in the body.
You can then email your comments to 57876 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
public <at> protesilaos.com, bug-gnu-emacs <at> gnu.org
:
bug#57876
; Package
emacs
.
(Sat, 17 Sep 2022 08:24:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Augusto Stoffel <arstoffel <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
public <at> protesilaos.com, bug-gnu-emacs <at> gnu.org
.
(Sat, 17 Sep 2022 08:24:01 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)]
Tags: patch
Currently, if point is say at the prompt of a comint buffer,
pulse-momentary-highlight-one-line doesn't show do anything – or, more
precisely, it pulses the zero-length region from prompt end to EOB.
Prot: I think you want to apply a similar change in pulsar.el.
[0001-pulse-momentary-highlight-one-line-Act-on-visual-lin.patch (text/patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57876
; Package
emacs
.
(Sat, 17 Sep 2022 09:39:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 57876 <at> debbugs.gnu.org (full text, mbox):
> Cc: Protesilaos Stavrou <public <at> protesilaos.com>
> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Date: Sat, 17 Sep 2022 10:23:01 +0200
>
> Tags: patch
>
> Currently, if point is say at the prompt of a comint buffer,
> pulse-momentary-highlight-one-line doesn't show do anything – or, more
> precisely, it pulses the zero-length region from prompt end to EOB.
>
> Prot: I think you want to apply a similar change in pulsar.el.
>
>
> >From e1241510fc9e0deddc5adb416aec5de4ca0300c8 Mon Sep 17 00:00:00 2001
> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Date: Sat, 17 Sep 2022 10:17:34 +0200
> Subject: [PATCH] pulse-momentary-highlight-one-line: Act on visual line
>
> * lisp/cedet/pulse.el (pulse-momentary-highlight-one-line): Act on
> entire visual line, ignoring fields etc.
Why don't you use beginning/end-of-visual-line?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57876
; Package
emacs
.
(Sat, 17 Sep 2022 10:57:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 57876 <at> debbugs.gnu.org (full text, mbox):
On Sat, 17 Sep 2022 at 12:38, Eli Zaretskii wrote:
>> Cc: Protesilaos Stavrou <public <at> protesilaos.com>
>> From: Augusto Stoffel <arstoffel <at> gmail.com>
>> Date: Sat, 17 Sep 2022 10:23:01 +0200
>>
>> Tags: patch
>>
>> Currently, if point is say at the prompt of a comint buffer,
>> pulse-momentary-highlight-one-line doesn't show do anything – or, more
>> precisely, it pulses the zero-length region from prompt end to EOB.
>>
>> Prot: I think you want to apply a similar change in pulsar.el.
>>
>>
>> >From e1241510fc9e0deddc5adb416aec5de4ca0300c8 Mon Sep 17 00:00:00 2001
>> From: Augusto Stoffel <arstoffel <at> gmail.com>
>> Date: Sat, 17 Sep 2022 10:17:34 +0200
>> Subject: [PATCH] pulse-momentary-highlight-one-line: Act on visual line
>>
>> * lisp/cedet/pulse.el (pulse-momentary-highlight-one-line): Act on
>> entire visual line, ignoring fields etc.
>
> Why don't you use beginning/end-of-visual-line?
Because it obeys fields, so if you try to highlight a prompt line in a
comint buffer, only part of the line would be highlighted.
The (only, AFAICT) purpose of pulse-momentary-highlight-one-line is to
locate the cursor, so you want to pulse a little rectangle spanning the
entire width of the window.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57876
; Package
emacs
.
(Sat, 17 Sep 2022 11:21:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 57876 <at> debbugs.gnu.org (full text, mbox):
> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: 57876 <at> debbugs.gnu.org, public <at> protesilaos.com
> Date: Sat, 17 Sep 2022 12:56:44 +0200
>
> > Why don't you use beginning/end-of-visual-line?
>
> Because it obeys fields, so if you try to highlight a prompt line in a
> comint buffer, only part of the line would be highlighted.
It should be possible to disable fields temporarily by binding
inhibit-point-motion-hooks, right? I prefer doing that to reinventing
the wheel of moving to the edges of the visible line.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57876
; Package
emacs
.
(Sat, 17 Sep 2022 11:33:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 57876 <at> debbugs.gnu.org (full text, mbox):
On Sat, 17 Sep 2022 at 14:20, Eli Zaretskii wrote:
>> From: Augusto Stoffel <arstoffel <at> gmail.com>
>> Cc: 57876 <at> debbugs.gnu.org, public <at> protesilaos.com
>> Date: Sat, 17 Sep 2022 12:56:44 +0200
>>
>> > Why don't you use beginning/end-of-visual-line?
>>
>> Because it obeys fields, so if you try to highlight a prompt line in a
>> comint buffer, only part of the line would be highlighted.
>
> It should be possible to disable fields temporarily by binding
> inhibit-point-motion-hooks, right? I prefer doing that to reinventing
> the wheel of moving to the edges of the visible line.
This variable is allegedly obsolete since Emacs 25. In any case, the
patch is really trivial, so how would this be making the code simpler or
more robust?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57876
; Package
emacs
.
(Sat, 17 Sep 2022 11:50:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 57876 <at> debbugs.gnu.org (full text, mbox):
> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: 57876 <at> debbugs.gnu.org, public <at> protesilaos.com
> Date: Sat, 17 Sep 2022 13:31:55 +0200
>
> > It should be possible to disable fields temporarily by binding
> > inhibit-point-motion-hooks, right? I prefer doing that to reinventing
> > the wheel of moving to the edges of the visible line.
>
> This variable is allegedly obsolete since Emacs 25.
Sorry, I meant inhibit-field-text-motion.
> In any case, the patch is really trivial, so how would this be
> making the code simpler or more robust?
I just explained the reasons above: we have these utility functions
for a reason: so that Lisp programs won't need to reinvent how to do
what these utilities do every time.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57876
; Package
emacs
.
(Sun, 18 Sep 2022 07:25:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 57876 <at> debbugs.gnu.org (full text, mbox):
> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Date: Sat, 17 Sep 2022 10:23:01 +0200
>
> Tags: patch
>
> Currently, if point is say at the prompt of a comint buffer,
> pulse-momentary-highlight-one-line doesn't show do anything – or, more
> precisely, it pulses the zero-length region from prompt end to EOB.
>
> Prot: I think you want to apply a similar change in pulsar.el.
Hello Augusto,
Just to note that I am monitoring this thread and will act accordingly.
Thank you!
Prot
--
Protesilaos Stavrou
https://protesilaos.com
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57876
; Package
emacs
.
(Sun, 18 Sep 2022 11:03:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 57876 <at> debbugs.gnu.org (full text, mbox):
Augusto Stoffel <arstoffel <at> gmail.com> writes:
> Currently, if point is say at the prompt of a comint buffer,
> pulse-momentary-highlight-one-line doesn't show do anything – or, more
> precisely, it pulses the zero-length region from prompt end to EOB.
Thanks; pushed to Emacs 29.
Eli Zaretskii <eliz <at> gnu.org> writes:
>> This variable is allegedly obsolete since Emacs 25.
>
> Sorry, I meant inhibit-field-text-motion.
That variable does not affect what beginning-of-visual-line does
w.r.t. fields, only invisible text.
bug marked as fixed in version 29.1, send any further explanations to
57876 <at> debbugs.gnu.org and Augusto Stoffel <arstoffel <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 18 Sep 2022 11:03:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57876
; Package
emacs
.
(Sun, 18 Sep 2022 12:41:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 57876 <at> debbugs.gnu.org (full text, mbox):
> Cc: Protesilaos Stavrou <public <at> protesilaos.com>, 57876 <at> debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sun, 18 Sep 2022 13:02:11 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> This variable is allegedly obsolete since Emacs 25.
> >
> > Sorry, I meant inhibit-field-text-motion.
>
> That variable does not affect what beginning-of-visual-line does
> w.r.t. fields, only invisible text.
That's not what the doc string of inhibit-field-text-motion does, so
it might be a bug in itself. line-beginning-position, for example,
does ignore fields when that variable is non-nil.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57876
; Package
emacs
.
(Sun, 18 Sep 2022 12:46:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 57876 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> >> This variable is allegedly obsolete since Emacs 25.
>> >
>> > Sorry, I meant inhibit-field-text-motion.
>>
>> That variable does not affect what beginning-of-visual-line does
>> w.r.t. fields, only invisible text.
>
> That's not what the doc string of inhibit-field-text-motion does, so
> it might be a bug in itself. line-beginning-position, for example,
> does ignore fields when that variable is non-nil.
Oh, sorry! I was confusing myself by testing with
(let ((inhibit-point-motion-hooks t)) (beginning-of-visual-line))
which is the wrong thing, of course -- with inhibit-field-text-motion it
works fine.
So adjusting the patch to use that instead might be appropriate (but
doesn't make much difference).
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#57876
; Package
emacs
.
(Sun, 18 Sep 2022 12:56:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 57876 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: arstoffel <at> gmail.com, public <at> protesilaos.com, 57876 <at> debbugs.gnu.org
> Date: Sun, 18 Sep 2022 14:45:33 +0200
>
> Oh, sorry! I was confusing myself by testing with
>
> (let ((inhibit-point-motion-hooks t)) (beginning-of-visual-line))
>
> which is the wrong thing, of course -- with inhibit-field-text-motion it
> works fine.
>
> So adjusting the patch to use that instead might be appropriate (but
> doesn't make much difference).
My point in suggesting that was that it is better to use utility
functions we have rather than the equivalent code, because the utility
functions presumably serve as a locus of all our wisdom related to
what they do. For example, what does "beginning of visual line" mean
with bidirectional text? Instead of having to decide this in each
case, we have a function that already does TRT.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 17 Oct 2022 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 242 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.