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

Previous Next

Package: emacs;

Reported by: Emre Yolcu <mail <at> emreyolcu.com>

Date: Fri, 24 May 2024 04:43:01 UTC

Severity: normal

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

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




This bug report was last modified 361 days ago.

Previous Next


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