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


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




This bug report was last modified 1 year and 20 days ago.

Previous Next


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