GNU bug report logs - #32950
27.0.50; Strange display bug in *Help* buffer

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32950 in the body.
You can then email your comments to 32950 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Filipp Gunbin <fgunbin <at> fastmail.fm>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; Strange display bug in *Help* buffer
Date: Fri, 05 Oct 2018 21:52:15 +0300

[Message part 1 (text/plain, inline)]

emacs -Q
C-h f proced-sort RET
C-x o (go to newly created *Help* buffer)
TAB TAB (to move to `proced-sort' link)
RET (to go to that link)

Now the screen looks like in the screenshot attached.  It's Terminal app
on macOS 10.13.6, if that matters.

It looks like a new window is created, with that black line instead of a
usual separator.  But it's still the same window.

Maybe it has to do with the fact that help buffer for `proced-sort'
contains link to the same function (or similarly name variable).

In GNU Emacs 27.0.50 (build 2, x86_64-apple-darwin17.7.0, NS appkit-1561.60 Version 10.13.6 (Build 17G65))
 of 2018-10-04 built on fgunbin.playteam.ru
Repository revision: 44bf4a6b012f65327718b8c8334bfac1aee26370
System Description:  Mac OS X 10.13.6

[Screen Shot 2018-10-05 at 21.41.28.png (image/png, attachment)]

Message #8 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Filipp Gunbin <fgunbin <at> fastmail.fm>
Cc: 32950 <at> debbugs.gnu.org
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Fri, 05 Oct 2018 22:54:44 +0300

tags 32950 notabug
thanks

> From: Filipp Gunbin <fgunbin <at> fastmail.fm>
> Date: Fri, 05 Oct 2018 21:52:15 +0300
> 
> emacs -Q
> C-h f proced-sort RET
> C-x o (go to newly created *Help* buffer)
> TAB TAB (to move to `proced-sort' link)
> RET (to go to that link)
> 
> Now the screen looks like in the screenshot attached.  It's Terminal app
> on macOS 10.13.6, if that matters.
> 
> It looks like a new window is created, with that black line instead of a
> usual separator.  But it's still the same window.
> 
> Maybe it has to do with the fact that help buffer for `proced-sort'
> contains link to the same function (or similarly name variable).

Yes.  This is the intended behavior.  Go to that black line and type
"M-x describe-text-properties RET": you will see what it tries to do.
Also try the same on a GUI frame.

Message #13 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Filipp Gunbin <fgunbin <at> fastmail.fm>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 32950 <at> debbugs.gnu.org
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Mon, 08 Oct 2018 18:28:55 +0300

Thanks Eli,

On 05/10/2018 22:54 +0300, Eli Zaretskii wrote:

>> Maybe it has to do with the fact that help buffer for `proced-sort'
>> contains link to the same function (or similarly name variable).
>
> Yes.  This is the intended behavior.  Go to that black line and type
> "M-x describe-text-properties RET": you will see what it tries to do.
> Also try the same on a GUI frame.

I see these text props there:

  face                 (:height 0.1 :inverse-video t)

Yes, it's inverse-video, but it does not provide an explanation.

Anyway, it looks somewhat scary for an unprepared user.  Why don't we
just show usual help for variable/function separately, and make this
"list"?

If this "list" was displayed right after help for either var/fun was
requested, then it's understandable.  But this scenario of "open help
for one of them, follow the link to another, and see it added" is
non-obvious and confusing.  To me, at least.  I doubt that even
experienced users know about this feature.

Filipp

Message #16 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Filipp Gunbin <fgunbin <at> fastmail.fm>
Cc: 32950 <at> debbugs.gnu.org
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Mon, 08 Oct 2018 23:00:52 +0300

> From: Filipp Gunbin <fgunbin <at> fastmail.fm>
> Cc: 32950 <at> debbugs.gnu.org
> Date: Mon, 08 Oct 2018 18:28:55 +0300
> 
> > Yes.  This is the intended behavior.  Go to that black line and type
> > "M-x describe-text-properties RET": you will see what it tries to do.
> > Also try the same on a GUI frame.
> 
> I see these text props there:
> 
>   face                 (:height 0.1 :inverse-video t)
> 
> Yes, it's inverse-video, but it does not provide an explanation.

I'm not sure I follow: explanation for what?  The ":height 0.1" part
is supposed to explain that the intent is to display a thin horizontal
line, except that TTY frames don't support variable-height lines, so
you see a normal-height line there in inverse video.

> Anyway, it looks somewhat scary for an unprepared user.  Why don't we
> just show usual help for variable/function separately, and make this
> "list"?

I'm sure that whoever coded this thought it to be a very coll feature,
so all I can advise is to get used to it.

> I doubt that even experienced users know about this feature.

Well, I, for one, do.

Not every surprising feature should be an immediate candidate for
removal.

Message #19 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Filipp Gunbin <fgunbin <at> fastmail.fm>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 32950 <at> debbugs.gnu.org
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Tue, 09 Oct 2018 02:11:06 +0300

Hi,

On 08/10/2018 23:00 +0300, Eli Zaretskii wrote:

>> From: Filipp Gunbin <fgunbin <at> fastmail.fm>
>> Cc: 32950 <at> debbugs.gnu.org
>> Date: Mon, 08 Oct 2018 18:28:55 +0300
>>
>> > Yes.  This is the intended behavior.  Go to that black line and type
>> > "M-x describe-text-properties RET": you will see what it tries to do.
>> > Also try the same on a GUI frame.
>>
>> I see these text props there:
>>
>>   face                 (:height 0.1 :inverse-video t)
>>
>> Yes, it's inverse-video, but it does not provide an explanation.
>
> I'm not sure I follow: explanation for what?  The ":height 0.1" part
> is supposed to explain that the intent is to display a thin horizontal
> line, except that TTY frames don't support variable-height lines, so
> you see a normal-height line there in inverse video.

Explanation for why it's there, in the first place.  Ok, it's thin in
GUI, but it's very prominent on TTY.

>> Anyway, it looks somewhat scary for an unprepared user.  Why don't we
>> just show usual help for variable/function separately, and make this
>> "list"?
>
> I'm sure that whoever coded this thought it to be a very coll feature,
> so all I can advise is to get used to it.
>
>> I doubt that even experienced users know about this feature.
>
> Well, I, for one, do.
>
> Not every surprising feature should be an immediate candidate for
> removal.

I'm sure on GUI it serves its purpose well, when it's really thin line.
But on TTY, as I already wrote, nothing except "what happened?" comes to
(my) mind.  When you are accustomed to the usual behavior of Help
buffers to replace contents when following a link, this special-case
adding is really confusing.

Well, now I know about it too, so it's not a problem for me.  I was
thinking of others, who may as well file a bug about it, and maintainers
will spend time responding to it.  Yes, this seems to be a rare case -
for example, the reverse reference (from variable proced-sort to
function) is not there, but still.

Thanks.

Message #22 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Filipp Gunbin <fgunbin <at> fastmail.fm>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 32950 <at> debbugs.gnu.org
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Tue, 09 Oct 2018 09:44:39 +0200

> I'm sure on GUI it serves its purpose well, when it's really thin line.
> But on TTY, as I already wrote, nothing except "what happened?" comes to
> (my) mind.  When you are accustomed to the usual behavior of Help
> buffers to replace contents when following a link, this special-case
> adding is really confusing.

Would it be difficult to replace it with a line of dashes on TTYs?

martin

Message #25 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 32950 <at> debbugs.gnu.org, fgunbin <at> fastmail.fm
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Tue, 09 Oct 2018 17:59:13 +0300

> Date: Tue, 09 Oct 2018 09:44:39 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 32950 <at> debbugs.gnu.org
> 
>  > I'm sure on GUI it serves its purpose well, when it's really thin line.
>  > But on TTY, as I already wrote, nothing except "what happened?" comes to
>  > (my) mind.  When you are accustomed to the usual behavior of Help
>  > buffers to replace contents when following a link, this special-case
>  > adding is really confusing.
> 
> Would it be difficult to replace it with a line of dashes on TTYs?

You mean, apart of adding some code to make that happen?  No, I don't
think so.  But don't be surprised if someone then comes up crying that
their favorite feature was removed.

Message #28 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Filipp Gunbin <fgunbin <at> fastmail.fm>
Cc: 32950 <at> debbugs.gnu.org
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Fri, 5 Nov 2021 17:28:39 -0700

Filipp Gunbin <fgunbin <at> fastmail.fm> writes:

> emacs -Q
> C-h f proced-sort RET
> C-x o (go to newly created *Help* buffer)
> TAB TAB (to move to `proced-sort' link)
> RET (to go to that link)
>
> Now the screen looks like in the screenshot attached.  It's Terminal app
> on macOS 10.13.6, if that matters.
>
> It looks like a new window is created, with that black line instead of a
> usual separator.  But it's still the same window.
>
> Maybe it has to do with the fact that help buffer for `proced-sort'
> contains link to the same function (or similarly name variable).

This is about how a horizontal line is displayed in the terminal.
We now have at least three different ways to display horizontal lines:

    1. The above recipe
    2. M-x customize-group RET emacs RET
    3. C-h b    [which seems buggy?]

I think we should decide which of the three are best, and replace the
others with that.

Aesthetically, I very much prefer the one in customize-group, but point
jumps to the right when you move over it, which is slightly jarring.

Message #31 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 32950 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Sat, 06 Nov 2021 01:34:41 +0100

Stefan Kangas <stefan <at> marxist.se> writes:

> This is about how a horizontal line is displayed in the terminal.
> We now have at least three different ways to display horizontal lines:
>
>     1. The above recipe
>     2. M-x customize-group RET emacs RET
>     3. C-h b    [which seems buggy?]

Buggy in what way?  Seems to be working for me both in GUI and TUI Emacs
in `C-h b'?

> I think we should decide which of the three are best, and replace the
> others with that.
>
> Aesthetically, I very much prefer the one in customize-group, but point
> jumps to the right when you move over it, which is slightly jarring.

Yes, it looks better in TUI Emacs (but I prefer the 'C-h b' one in GUI
Emacs).  But the point movement is really jarring (in both GUI and TUI),
so overall I think the 'C-h b' one wins.  😀

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #34 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 32950 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Sat, 06 Nov 2021 01:37:10 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

>> This is about how a horizontal line is displayed in the terminal.
>> We now have at least three different ways to display horizontal lines:
>>
>>     1. The above recipe
>>     2. M-x customize-group RET emacs RET
>>     3. C-h b    [which seems buggy?]
>
> Buggy in what way?  Seems to be working for me both in GUI and TUI Emacs
> in `C-h b'?

1. and 3. are the same, I think?  (At least now.)  It's a newline with
`separator-face' on it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #37 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 32950 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Fri, 5 Nov 2021 18:05:37 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

>>> We now have at least three different ways to display horizontal lines:
>>>
>>>     1. The above recipe
>>>     2. M-x customize-group RET emacs RET
>>>     3. C-h b    [which seems buggy?]
[snip]
> 1. and 3. are the same, I think?  (At least now.)  It's a newline with
> `separator-face' on it.

I thought it was different as I didn't see this behavior in `C-h f
proced-sort RET' for some reason.

I guess the call happens later in `C-h f', or something.

Message #40 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 32950 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Fri, 5 Nov 2021 18:05:43 -0700

[Message part 1 (text/plain, inline)]

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Stefan Kangas <stefan <at> marxist.se> writes:
>
>> This is about how a horizontal line is displayed in the terminal.
>> We now have at least three different ways to display horizontal lines:
>>
>>     1. The above recipe
>>     2. M-x customize-group RET emacs RET
>>     3. C-h b    [which seems buggy?]
>
> Buggy in what way?  Seems to be working for me both in GUI and TUI Emacs
> in `C-h b'?

See the attached screenshot.

[Message part 2 (text/plain, attachment)]

[buggy-line.png (image/png, attachment)]

Message #43 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 32950 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Sat, 06 Nov 2021 02:13:27 +0100

Stefan Kangas <stefan <at> marxist.se> writes:

> I thought it was different as I didn't see this behavior in `C-h f
> proced-sort RET' for some reason.
>
> I guess the call happens later in `C-h f', or something.

It happens when the buffer displays both the function and the variable,
which happens when hitting RET on the variable in the function *Help*
buffer.  :-)

But I think this means that the reported display bug is gone, so I'm
closing this bug report.  There's a question of whether we should use
`make-separator-line' more throughout Emacs (like in Customize), and I
think we should, probably?  But gingerly.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #48 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 32950 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Sat, 06 Nov 2021 02:16:12 +0100

Stefan Kangas <stefan <at> marxist.se> writes:

> See the attached screenshot.

Hm, very odd.  It's supposed to use a `window-width's worth of dashes on
TUI, and it seems to be overshooting that significantly?  Do you have a
recipe to reproduce the bug (starting from emacs -Q)?

>> Yes, it looks better in TUI Emacs (but I prefer the 'C-h b' one in GUI
>> Emacs).  But the point movement is really jarring (in both GUI and TUI),
>> so overall I think the 'C-h b' one wins.  😀
>
> Hmm, the `C-h b' one looks better here in both GUI and terminal.
> Are you sure you used the same set of eyes as I did?

It's possible not.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #51 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 32950 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Fri, 5 Nov 2021 18:36:12 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Hm, very odd.  It's supposed to use a `window-width's worth of dashes on
> TUI, and it seems to be overshooting that significantly?  Do you have a
> recipe to reproduce the bug (starting from emacs -Q)?

Sure, it's a short one: "emacs -Q -nw" and then `C-h b'.

Message #54 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 32950 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Sat, 06 Nov 2021 02:48:31 +0100

[Message part 1 (text/plain, inline)]

Stefan Kangas <stefan <at> marxist.se> writes:

> Sure, it's a short one: "emacs -Q -nw" and then `C-h b'.

Huh.  That gives me:

[Message part 2 (image/png, inline)]

[Message part 3 (text/plain, inline)]

What does (window-width) evaluate to for you here?  (It's 80 for me.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #57 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 32950 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Fri, 5 Nov 2021 19:24:30 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Stefan Kangas <stefan <at> marxist.se> writes:
>
>> Sure, it's a short one: "emacs -Q -nw" and then `C-h b'.
>
> Huh.  That gives me:

Try with a very wide terminal window.

> What does (window-width) evaluate to for you here?  (It's 80 for me.)

255 before running `C-h b', 128 after.

Message #60 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 32950 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Sat, 06 Nov 2021 03:31:15 +0100

Stefan Kangas <stefan <at> marxist.se> writes:

>> What does (window-width) evaluate to for you here?  (It's 80 for me.)
>
> 255 before running `C-h b', 128 after.

Oh, you resized the terminal?  Well, then that's expected.

Hm...  hang on a minute.  Can't we just use an underline on TUI?  Or was
that what Customize did?  Hm...  OK, tried it now, and it seems to work
without the odd point motion?  So I've now pushed it to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #63 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 32950 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Fri, 5 Nov 2021 20:11:54 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Stefan Kangas <stefan <at> marxist.se> writes:
>
>>> What does (window-width) evaluate to for you here?  (It's 80 for me.)
>>
>> 255 before running `C-h b', 128 after.
>
> Oh, you resized the terminal?  Well, then that's expected.

No, I didn't resize it.  (I wrote up a detailed explanation, but the bug
was fixed by your below commit, so it's not relevant now I think.)

> Hm...  hang on a minute.  Can't we just use an underline on TUI?  Or was
> that what Customize did?  Hm...  OK, tried it now, and it seems to work
> without the odd point motion?  So I've now pushed it to Emacs 29.

With that change, the above bug is gone.  And it looks much better!
I think we should change customize to use that, too.

However, especially on a graphical display, it would be nice if you
couldn't place point on the actual divider.  It looks almost as jarring
as the weird point movement to me.

Message #66 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 32950 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Sat, 06 Nov 2021 05:01:32 +0100

Stefan Kangas <stefan <at> marxist.se> writes:

> With that change, the above bug is gone.  And it looks much better!
> I think we should change customize to use that, too.

Yes, probably.

> However, especially on a graphical display, it would be nice if you
> couldn't place point on the actual divider.  It looks almost as jarring
> as the weird point movement to me.

You mean the teensy tiny cursor?  Yes, that's odd, but...  Perhaps we
should experiment with making it intangible?  I've had really bad
experiences with that before, but perhaps it could work here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #69 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 32950 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Fri, 5 Nov 2021 23:12:12 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> You mean the teensy tiny cursor?  Yes, that's odd, but...  Perhaps we
> should experiment with making it intangible?  I've had really bad
> experiences with that before, but perhaps it could work here.

Yes, I'm thinking of the small cursor there.

I'm aware of the existence of intangible, but I've never actually tried
to use it.  From its description in the manual, it does sound like it
could be a good solution here.

Message #72 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 32950 <at> debbugs.gnu.org, fgunbin <at> fastmail.fm, stefan <at> marxist.se
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Sat, 06 Nov 2021 10:00:28 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sat, 06 Nov 2021 03:31:15 +0100
> Cc: 32950 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
> 
> Hm...  hang on a minute.  Can't we just use an underline on TUI?  Or was
> that what Customize did?  Hm...  OK, tried it now, and it seems to work
> without the odd point motion?  So I've now pushed it to Emacs 29.

Not all terminals support underline.

Message #75 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: larsi <at> gnus.org
Cc: 32950 <at> debbugs.gnu.org, fgunbin <at> fastmail.fm, stefan <at> marxist.se
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Sat, 06 Nov 2021 11:34:46 +0200

> Date: Sat, 06 Nov 2021 10:00:28 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 32950 <at> debbugs.gnu.org, stefan <at> marxist.se, fgunbin <at> fastmail.fm
> 
> > From: Lars Ingebrigtsen <larsi <at> gnus.org>
> > Date: Sat, 06 Nov 2021 03:31:15 +0100
> > Cc: 32950 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
> > 
> > Hm...  hang on a minute.  Can't we just use an underline on TUI?  Or was
> > that what Customize did?  Hm...  OK, tried it now, and it seems to work
> > without the odd point motion?  So I've now pushed it to Emacs 29.
> 
> Not all terminals support underline.

And, as I suspected, we now show no separator at all on those text
terminals which don't support the underline attribute.  This is a
regression, I think.

Message #78 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>, larsi <at> gnus.org
Cc: 32950 <at> debbugs.gnu.org, fgunbin <at> fastmail.fm
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Sat, 6 Nov 2021 04:09:01 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

> And, as I suspected, we now show no separator at all on those text
> terminals which don't support the underline attribute.  This is a
> regression, I think.

Can we detect those terminals that doesn't support underline and fall
back to the old method for them?

Message #81 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 32950 <at> debbugs.gnu.org, larsi <at> gnus.org, fgunbin <at> fastmail.fm
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Sat, 06 Nov 2021 13:39:58 +0200

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Sat, 6 Nov 2021 04:09:01 -0700
> Cc: 32950 <at> debbugs.gnu.org, fgunbin <at> fastmail.fm
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > And, as I suspected, we now show no separator at all on those text
> > terminals which don't support the underline attribute.  This is a
> > regression, I think.
> 
> Can we detect those terminals that doesn't support underline and fall
> back to the old method for them?

Yes, of course.  See display-supports-face-attributes-p.

Message #84 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 32950 <at> debbugs.gnu.org, fgunbin <at> fastmail.fm,
 Stefan Kangas <stefan <at> marxist.se>
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Sat, 06 Nov 2021 18:57:00 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Yes, of course.  See display-supports-face-attributes-p.

Thanks; this should now be fixed on the trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #87 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 32950 <at> debbugs.gnu.org, Filipp Gunbin <fgunbin <at> fastmail.fm>
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Sat, 06 Nov 2021 19:00:54 +0100

Stefan Kangas <stefan <at> marxist.se> writes:

> I'm aware of the existence of intangible, but I've never actually tried
> to use it.  From its description in the manual, it does sound like it
> could be a good solution here.

Hm...  It doesn't seem like that does what we want here, because it's
really just a newline character with a face with :extend there.
`intangible' is:

---
If a group of consecutive characters have equal and non-@code{nil}
@code{intangible} properties, then you cannot place point between them.
---

Which I'd forgotten.  So we'd have to put intangible on the
... preceding newline, too?  And that just sounds too hacky.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #90 received at 32950 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 32950 <at> debbugs.gnu.org, fgunbin <at> fastmail.fm, stefan <at> marxist.se
Subject: Re: bug#32950: 27.0.50; Strange display bug in *Help* buffer
Date: Sat, 06 Nov 2021 20:27:55 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Stefan Kangas <stefan <at> marxist.se>,  32950 <at> debbugs.gnu.org,
>   fgunbin <at> fastmail.fm
> Date: Sat, 06 Nov 2021 18:57:00 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Yes, of course.  See display-supports-face-attributes-p.
> 
> Thanks; this should now be fixed on the trunk.

It is indeed.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.