bug#32950: 27.0.50; Strange display bug in *Help* buffer

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Filipp Gunbin]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

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


[-- Attachment #2: Screen Shot 2018-10-05 at 21.41.28.png --]
[-- Type: image/png, Size: 160171 bytes --]

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Eli Zaretskii]

tags 32950 notabug
thanks

> From: Filipp Gunbin <fgunbin@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.

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Filipp Gunbin]

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

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Eli Zaretskii]

> From: Filipp Gunbin <fgunbin@fastmail.fm>
> Cc: 32950@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.

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Filipp Gunbin]

Hi,

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

>> From: Filipp Gunbin <fgunbin@fastmail.fm>
>> Cc: 32950@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.

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[martin rudalics]

 > 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

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Eli Zaretskii]

> Date: Tue, 09 Oct 2018 09:44:39 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 32950@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.

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Stefan Kangas]

Filipp Gunbin <fgunbin@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.

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Lars Ingebrigtsen]

Stefan Kangas <stefan@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

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Stefan Kangas]

Lars Ingebrigtsen <larsi@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.

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Lars Ingebrigtsen]

Stefan Kangas <stefan@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

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefan@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.

[-- Attachment #2: Type: text/plain, Size: 317 bytes --]


> 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?

[-- Attachment #3: buggy-line.png --]
[-- Type: image/png, Size: 4310 bytes --]

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Lars Ingebrigtsen]

Stefan Kangas <stefan@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

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Stefan Kangas]

Lars Ingebrigtsen <larsi@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'.

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 125 bytes --]

Stefan Kangas <stefan@marxist.se> writes:

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

Huh.  That gives me:


[-- Attachment #2: Type: image/png, Size: 60163 bytes --]

[-- Attachment #3: Type: text/plain, Size: 176 bytes --]



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

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefan@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.

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Lars Ingebrigtsen]

Stefan Kangas <stefan@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

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefan@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.

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Lars Ingebrigtsen]

Stefan Kangas <stefan@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

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Stefan Kangas]

Lars Ingebrigtsen <larsi@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.

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Lars Ingebrigtsen]

Stefan Kangas <stefan@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

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 06 Nov 2021 03:31:15 +0100
> Cc: 32950@debbugs.gnu.org, Filipp Gunbin <fgunbin@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.

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Eli Zaretskii]

> Date: Sat, 06 Nov 2021 10:00:28 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 32950@debbugs.gnu.org, stefan@marxist.se, fgunbin@fastmail.fm
> 
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Date: Sat, 06 Nov 2021 03:31:15 +0100
> > Cc: 32950@debbugs.gnu.org, Filipp Gunbin <fgunbin@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.

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Stefan Kangas]

Eli Zaretskii <eliz@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?

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Sat, 6 Nov 2021 04:09:01 -0700
> Cc: 32950@debbugs.gnu.org, fgunbin@fastmail.fm
> 
> Eli Zaretskii <eliz@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.

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#32950: 27.0.50; Strange display bug in *Help* buffer

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Kangas <stefan@marxist.se>,  32950@debbugs.gnu.org,
>   fgunbin@fastmail.fm
> Date: Sat, 06 Nov 2021 18:57:00 +0100
> 
> Eli Zaretskii <eliz@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.