GNU bug report logs - #71163
Cursor can disappear off the window if no-special-glyphs is enabled

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 71163 in the body.
You can then email your comments to 71163 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: Emre Yolcu <mail <at> emreyolcu.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Cursor can disappear off the window if no-special-glyphs is enabled
Date: Fri, 24 May 2024 00:42:29 -0400

If the layout parameter no-special-glyphs is enabled and a line is 
exactly as wide as a window, then the cursor placed at the end of the 
line disappears off the window. Steps to confirm after "emacs -Q":

1. Evaluate the following:

(set-frame-parameter nil 'no-special-glyphs nil)
  (fringe-mode 0)
  (scroll-bar-mode -1)

2. Insert some line that is exactly as wide as the window, leaving the 
cursor at the end of the line.

After those steps, the cursor is not visible. I'm not sure if this is 
the intended behavior. I would expect the cursor to appear at the 
beginning of the next screen line instead. If no-special-glyphs is not 
enabled, then, as expected, the final character of the first screen line 
is displayed as the continuation indicator "\", and the actual final 
character of the line appears on the next screen line, with the cursor 
after it.

I have confirmed this behavior with Emacs 29.3 on macOS and Windows.

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

From: Emre Yolcu <mail <at> emreyolcu.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#71163: Cursor can disappear off the window if
 no-special-glyphs is enabled
Date: Fri, 24 May 2024 02:46:45 -0400

Emre Yolcu wrote:
> (set-frame-parameter nil 'no-special-glyphs nil)

This is a typo. It should have been:

  (set-frame-parameter nil 'no-special-glyphs t)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Emre Yolcu <mail <at> emreyolcu.com>, martin rudalics <rudalics <at> gmx.at>
Cc: 71163 <at> debbugs.gnu.org
Subject: Re: bug#71163: Cursor can disappear off the window if
 no-special-glyphs is enabled
Date: Fri, 24 May 2024 10:20:19 +0300

> Date: Fri, 24 May 2024 00:42:29 -0400
> From: Emre Yolcu <mail <at> emreyolcu.com>
> 
> If the layout parameter no-special-glyphs is enabled and a line is 
> exactly as wide as a window, then the cursor placed at the end of the 
> line disappears off the window. Steps to confirm after "emacs -Q":
> 
> 1. Evaluate the following:
> 
> (set-frame-parameter nil 'no-special-glyphs nil)

You must have meant

  (set-frame-parameter nil 'no-special-glyphs t)

Because nil is the default value of this frame parameter.

>  (fringe-mode 0)
>  (scroll-bar-mode -1)

The last part of disabling scroll-bars is not necessary, AFAICT.

> 2. Insert some line that is exactly as wide as the window, leaving the 
> cursor at the end of the line.
> 
> After those steps, the cursor is not visible. I'm not sure if this is 
> the intended behavior. I would expect the cursor to appear at the 
> beginning of the next screen line instead. If no-special-glyphs is not 
> enabled, then, as expected, the final character of the first screen line 
> is displayed as the continuation indicator "\", and the actual final 
> character of the line appears on the next screen line, with the cursor 
> after it.

I don't really understand how this was intended to behave, so I added
Martin who introduced this feature, in the hope that he could provide
the explanation of the intent.  This was added as part of support for
child frames, so I presume it has something to do with child frames,
but I don't really understand what exactly and why child frames would
need that.

AFAICT, this is currently broken in several ways:

  . it only has effect on GUI frames (basically, the code ignores this
    parameter on TTY frames), although the documentation doesn't say
    that, and I see no immediate reason why it wouldn't make sense on
    TTY frames;
  . it doesn't affect the display of fringe truncation and
    continuation bitmaps, although the documentation doesn't say that,
    either, and it is not clear to me that those bitmaps should be
    displayed in that case;
  . not only display of cursor in full-window lines is broken, but
    also the automatic horizontal scrolling (auto-hscroll-mode) in
    that case: the line is not hscrolled until you type one more
    character beyond those visible;
  . if you insert a TAB near the end of a screen line such that the
    next tab stop is on the next screen line, the TAB is shown with
    wrong number of columns, as if the next tab stop is at column zero
    of the next screen line.

The last 2 points, and the report that started this bug discussion,
are because the logic of line-continuation and truncation is basically
broken in this case: the layout code thinks the continuation and
truncation glyphs are inserted when needed, whereas they are not.
That's because the layout code was not adapted to this frame
parameter, only the geometry of the screen line was adjusted.

Fixing this will take a while.  But first we need to understand and
agree on the scope of support for this frame parameter, and what Emacs
should do in each supported case.

Thanks.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Emre Yolcu <mail <at> emreyolcu.com>
Cc: 71163 <at> debbugs.gnu.org
Subject: Re: bug#71163: Cursor can disappear off the window if
 no-special-glyphs is enabled
Date: Fri, 24 May 2024 11:16:36 +0200

> I don't really understand how this was intended to behave, so I added
> Martin who introduced this feature, in the hope that he could provide
> the explanation of the intent.  This was added as part of support for
> child frames, so I presume it has something to do with child frames,
> but I don't really understand what exactly and why child frames would
> need that.

IIRC this feature is used to make 'fit-frame-to-buffer' work reasonably
for tooltip frames and child frames that display information in a
similar way.  Bug#25408, Bug#52929 are two examples of why it is useful.

> AFAICT, this is currently broken in several ways:
>
>    . it only has effect on GUI frames (basically, the code ignores this
>      parameter on TTY frames), although the documentation doesn't say
>      that, and I see no immediate reason why it wouldn't make sense on
>      TTY frames;

We neither had child frames nor tooltip frames on TTYs when this feature
was introduced.  Did this change in the meantime?

>    . it doesn't affect the display of fringe truncation and
>      continuation bitmaps, although the documentation doesn't say that,
>      either, and it is not clear to me that those bitmaps should be
>      displayed in that case;

Fringes should not be shown on such frames.

>    . not only display of cursor in full-window lines is broken, but
>      also the automatic horizontal scrolling (auto-hscroll-mode) in
>      that case: the line is not hscrolled until you type one more
>      character beyond those visible;

Neither of these are supported by this feature.

>    . if you insert a TAB near the end of a screen line such that the
>      next tab stop is on the next screen line, the TAB is shown with
>      wrong number of columns, as if the next tab stop is at column zero
>      of the next screen line.

Interactive insertion is not supported either.

> The last 2 points, and the report that started this bug discussion,
> are because the logic of line-continuation and truncation is basically
> broken in this case: the layout code thinks the continuation and
> truncation glyphs are inserted when needed, whereas they are not.
> That's because the layout code was not adapted to this frame
> parameter, only the geometry of the screen line was adjusted.
>
> Fixing this will take a while.  But first we need to understand and
> agree on the scope of support for this frame parameter, and what Emacs
> should do in each supported case.

Turning off special glyphs is a pure presentation feature.  The variable
'show-paren--context-child-frame-parameters' tells best what should be
turned off too on any frames where it is used - such frames should never
be switched to, should not show a cursor, decorations and the like.

Feel free to add an appropriate explanation to the manual.

Thanks, martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 71163-done <at> debbugs.gnu.org, mail <at> emreyolcu.com
Subject: Re: bug#71163: Cursor can disappear off the window if
 no-special-glyphs is enabled
Date: Sat, 25 May 2024 13:26:09 +0300

> Date: Fri, 24 May 2024 11:16:36 +0200
> Cc: 71163 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> 
>  >    . it only has effect on GUI frames (basically, the code ignores this
>  >      parameter on TTY frames), although the documentation doesn't say
>  >      that, and I see no immediate reason why it wouldn't make sense on
>  >      TTY frames;
> 
> We neither had child frames nor tooltip frames on TTYs when this feature
> was introduced.  Did this change in the meantime?

No.  But the manual doesn't mention child frames at all, in
conjunction with this parameter.

>  >    . it doesn't affect the display of fringe truncation and
>  >      continuation bitmaps, although the documentation doesn't say that,
>  >      either, and it is not clear to me that those bitmaps should be
>  >      displayed in that case;
> 
> Fringes should not be shown on such frames.
> 
>  >    . not only display of cursor in full-window lines is broken, but
>  >      also the automatic horizontal scrolling (auto-hscroll-mode) in
>  >      that case: the line is not hscrolled until you type one more
>  >      character beyond those visible;
> 
> Neither of these are supported by this feature.
> 
>  >    . if you insert a TAB near the end of a screen line such that the
>  >      next tab stop is on the next screen line, the TAB is shown with
>  >      wrong number of columns, as if the next tab stop is at column zero
>  >      of the next screen line.
> 
> Interactive insertion is not supported either.
> 
>  > The last 2 points, and the report that started this bug discussion,
>  > are because the logic of line-continuation and truncation is basically
>  > broken in this case: the layout code thinks the continuation and
>  > truncation glyphs are inserted when needed, whereas they are not.
>  > That's because the layout code was not adapted to this frame
>  > parameter, only the geometry of the screen line was adjusted.
>  >
>  > Fixing this will take a while.  But first we need to understand and
>  > agree on the scope of support for this frame parameter, and what Emacs
>  > should do in each supported case.
> 
> Turning off special glyphs is a pure presentation feature.  The variable
> 'show-paren--context-child-frame-parameters' tells best what should be
> turned off too on any frames where it is used - such frames should never
> be switched to, should not show a cursor, decorations and the like.

So basically you are saying that this parameter is an internal feature
meant to allow better implementation of certain types of frames on GUI
displays?

> Feel free to add an appropriate explanation to the manual.

Thanks, now done, and closing the bug.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 71163-done <at> debbugs.gnu.org, mail <at> emreyolcu.com
Subject: Re: bug#71163: Cursor can disappear off the window if
 no-special-glyphs is enabled
Date: Sun, 26 May 2024 10:54:40 +0200

> So basically you are saying that this parameter is an internal feature
> meant to allow better implementation of certain types of frames on GUI
> displays?

It's a feature for frames displaying buffers whose lines never extend
past the right frame border.  I'm not sure whether "internal" is the
right term for this.  If so, most 'tooltip-frame-parameters' are
internal too.  For me the "-internal" postfix stands for "do not call
that from your code."

>> Feel free to add an appropriate explanation to the manual.
>
> Thanks, now done, and closing the bug.

Looks good to me.

Many thanks, martin

Previous Next

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