GNU bug report logs - #16856
24.3.50; Cursor leaves garbage in fringe (and a request: width of fringes + scroll bar should be full characters)

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 16856 in the body.
You can then email your comments to 16856 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: Anders Lindgren <andlind <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Cursor leaves garbage in fringe (and a request: width of
 fringes + scroll bar should be full characters)
Date: Sun, 23 Feb 2014 22:39:55 +0100

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

Hi!

The cursor leaves garbage in the fringe column.

Steps to repeat:

    Emacs -Q
    (setq truncate-partial-width-windows nil) C-j
    C-x 3
    C-x 3
    C-x o
    C-u 15 x
    C-p

Here, the cursor have left a one-pixel bar in the fringe area.

In other scenarios I have seen the cursor leave two or three pixels wide
garbage. (I use six columns and a 6x8 font.)

I use OS X 10.9.

I have noticed that when splitting two windows horizontally, the width of
the fringes + scroll bar between the two windows don't add up to full
characters. Instead, they are five characters and one pixel. My theory is
that this extra pixel pushes the cursor into the fringe to the right.

If possible, I would like to see the pixel width of fringes + scroll bar to
be a multiple of the width of the font used in the frame, since it is much
more convenient for elisp packages that make layout decisions. (As I
mentioned above, now they are 5 characters and one pixel. In 24.3 they were
exactly six characters wide.)

Sincerely,
    Anders Lindgren

In GNU Emacs 24.3.50.2 (x86_64-apple-darwin13.0.0, NS apple-appkit-1265.00)
 of 2014-02-16 on macpro.lan
Repository revision: 116451
jan.h.d <at> swipnet.se-20140216095141-cop794qd0bf30tmt
Windowing system distributor `Apple', version 10.3.1265
Configured using:
 `configure --with-ns'

Important settings:
  value of $LC_CTYPE: UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-y C-j C-x 3 C-x 3 C-x o C-u 1 5 x C-p <up> <down>
C-g C-x 1 <escape> x r e p o r t <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set
Quit

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils time-date tooltip electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
cocoa ns multi-tty emacs)

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 16856 <at> debbugs.gnu.org
Subject: Re: bug#16856: 24.3.50;
 Cursor leaves garbage in fringe (and a request: width of fringes
 +	scroll bar should be full characters)
Date: Mon, 24 Feb 2014 05:44:40 +0200

> Date: Sun, 23 Feb 2014 22:39:55 +0100
> From: Anders Lindgren <andlind <at> gmail.com>
> 
> The cursor leaves garbage in the fringe column.
> 
> Steps to repeat:
> 
>     Emacs -Q
>     (setq truncate-partial-width-windows nil) C-j
>     C-x 3
>     C-x 3
>     C-x o
>     C-u 15 x
>     C-p
> 
> Here, the cursor have left a one-pixel bar in the fringe area.

Not reproducible here (not on OS X).  Might be OS X specific.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 16856 <at> debbugs.gnu.org
Subject: Re: bug#16856: 24.3.50;
 Cursor leaves garbage in fringe (and a request:
 width of fringes +	scroll bar should be full characters)
Date: Mon, 24 Feb 2014 08:41:03 +0100

> If possible, I would like to see the pixel width of fringes + scroll bar to
> be a multiple of the width of the font used in the frame, since it is much
> more convenient for elisp packages that make layout decisions. (As I
> mentioned above, now they are 5 characters and one pixel. In 24.3 they were
> exactly six characters wide.)

The pixel widths of fringes and scrollbars are customizable on a per
frame/window basis so you should be able to set them up on you system
as you need.  Does that fail?

martin

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

From: Anders Lindgren <andlind <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 16856 <at> debbugs.gnu.org
Subject: Re: bug#16856: 24.3.50; Cursor leaves garbage in fringe (and a
 request: width of fringes + scroll bar should be full characters)
Date: Mon, 24 Feb 2014 11:12:31 +0100

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

On Mon, Feb 24, 2014 at 8:41 AM, martin rudalics <rudalics <at> gmx.at> wrote:

> > If possible, I would like to see the pixel width of fringes + scroll bar
> to
> > be a multiple of the width of the font used in the frame, since it is
> much
> > more convenient for elisp packages that make layout decisions. (As I
> > mentioned above, now they are 5 characters and one pixel. In 24.3 they
> were
> > exactly six characters wide.)
>
> The pixel widths of fringes and scrollbars are customizable on a per
> frame/window basis so you should be able to set them up on you system
> as you need.  Does that fail?


Well, it's much more work to handle things on the pixel level than working
with characters as the base unit.

For example, I'm currently writing a package to set up multiple
side-by-size windows. When figuring out a suitable frame width, I used to
multiply the number of side-by-side windows with the sum of the column
width and the width (in characters) of the fringe and scroll bars, to get
the number of characters to set the width to. Now, I would have to work on
the pixel level to do this properly -- this is much more error prone and I
can't use the code on old Emacs versions.

It doesn't help that functions doesn't seem to be designed to work
together, for example I would expect:
    (set-frame-size (selected-frame) (frame-pixel-width)
(frame-pixel-height) t)'
to be a no-op, but instead the frame increases its size both on the width
and on the height.

Another argument of not having a "odd" width is that when splitting windows
side-by-side, you will end up with an unused gap to the right of almost a
full character. Steps to repeat:

    emacs -Q
    (setq truncate-partial-width-windows nil) C-j
    C-x 3

        Here, the right window have an unused space between the rightmost
character and the fringe, the space is almost a character wide. It's not
possible to resize the frame manually to correct this, as the frame can
only be resized full characters (as it should be). (When
`truncate-partial-width-windows' is t, the gap is used to display a partial
character.)

To conclude, I would be much happier if the sum of the fringes and the
scroll bar would be an even five characters rather than five characters and
one pixel, as it is today.

The question is if this is due to some display bug (maybe OS X specific) or
if this is the way it is supposed to work now?

    -- Anders

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 16856 <at> debbugs.gnu.org
Subject: Re: bug#16856: 24.3.50;
 Cursor leaves garbage in fringe (and a request:
 width of fringes + scroll bar should be full characters)
Date: Mon, 24 Feb 2014 11:53:49 +0100

>> The pixel widths of fringes and scrollbars are customizable on a per
>> frame/window basis so you should be able to set them up on you system
>> as you need.  Does that fail?
>
>
> Well, it's much more work to handle things on the pixel level than working
> with characters as the base unit.
>
> For example, I'm currently writing a package to set up multiple
> side-by-size windows. When figuring out a suitable frame width, I used to
> multiply the number of side-by-side windows with the sum of the column
> width and the width (in characters) of the fringe and scroll bars, to get
> the number of characters to set the width to. Now, I would have to work on
> the pixel level to do this properly -- this is much more error prone and I
> can't use the code on old Emacs versions.

If you do that, you already preclude your code from working correctly on
maximized or fullscreen frames.  These might have widths that are not an
integral multiple of your character widths.  And toolkit scrollbars may
have a width that is not an integral multiple either - so you would have
to adjust the combined size anyway.

> It doesn't help that functions doesn't seem to be designed to work
> together, for example I would expect:
>     (set-frame-size (selected-frame) (frame-pixel-width)
> (frame-pixel-height) t)'
> to be a no-op, but instead the frame increases its size both on the width
> and on the height.

`set-frame-size' expects as argument the new _text_ width of the frame
and adds the width of fringes, a scrollbar and internal borders to that.

> Another argument of not having a "odd" width is that when splitting windows
> side-by-side, you will end up with an unused gap to the right of almost a
> full character. Steps to repeat:
>
>     emacs -Q
>     (setq truncate-partial-width-windows nil) C-j
>     C-x 3
>
>         Here, the right window have an unused space between the rightmost
> character and the fringe, the space is almost a character wide. It's not
> possible to resize the frame manually to correct this, as the frame can
> only be resized full characters (as it should be). (When
> `truncate-partial-width-windows' is t, the gap is used to display a partial
> character.)
>
> To conclude, I would be much happier if the sum of the fringes and the
> scroll bar would be an even five characters rather than five characters and
> one pixel, as it is today.
>
> The question is if this is due to some display bug (maybe OS X specific) or
> if this is the way it is supposed to work now?

This used to happen with Emacs 24.3 here and should be gone now.  But OS
X still has the old extended fringes code in place - maybe that
interferes.  Could you try to remove it - I can't compile for OS X so I
won't do that.  If you want to know how, have a look at these changes:

2013-12-02  YAMAMOTO Mitsuharu  <mituharu <at> math.s.chiba-u.ac.jp>

	* xterm.h (struct scroll_bar): Remove member `fringe_extended_p'.

	* xterm.c (x_draw_fringe_bitmap, x_scroll_run): Remove code for
	fringe background extension.
	(x_scroll_bar_create): Remove variables `sb_left' and `sb_width',
	because they are now always the same as `left' and `width',
	respectively.  Remove code for the case that `width' and
	`sb_width' are different.

2013-12-21  YAMAMOTO Mitsuharu  <mituharu <at> math.s.chiba-u.ac.jp>

	* w32term.h (struct scroll_bar): Remove member `fringe_extended_p'.

	* w32term.c (w32_draw_fringe_bitmap, x_scroll_run): Remove code for
	fringe background extension.
	(x_scroll_bar_create): Remove variables `sb_left' and `sb_width',
	because they are now always the same as `left' and `width',
	respectively.  Remove code for the case that `width' and
	`sb_width' are different.

martin

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

From: Anders Lindgren <andlind <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 16856 <at> debbugs.gnu.org
Subject: Re: bug#16856: 24.3.50; Cursor leaves garbage in fringe (and a
 request: width of fringes + scroll bar should be full characters)
Date: Mon, 24 Feb 2014 16:12:38 +0100

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

Ok, I think that I understand more of how the new layout works, and that I
need to work on the pixel level. Hence, I drop my request to make the width
of the fringes + scroll bars a multiple of the frame character width.

The problem with the cursor leaving garbage in the right fringe still
remains, though.

    -- Anders


On Mon, Feb 24, 2014 at 11:53 AM, martin rudalics <rudalics <at> gmx.at> wrote:

> >> The pixel widths of fringes and scrollbars are customizable on a per
> >> frame/window basis so you should be able to set them up on you system
> >> as you need.  Does that fail?
> >
> >
> > Well, it's much more work to handle things on the pixel level than
> working
> > with characters as the base unit.
> >
> > For example, I'm currently writing a package to set up multiple
> > side-by-size windows. When figuring out a suitable frame width, I used to
> > multiply the number of side-by-side windows with the sum of the column
> > width and the width (in characters) of the fringe and scroll bars, to get
> > the number of characters to set the width to. Now, I would have to work
> on
> > the pixel level to do this properly -- this is much more error prone and
> I
> > can't use the code on old Emacs versions.
>
> If you do that, you already preclude your code from working correctly on
> maximized or fullscreen frames.  These might have widths that are not an
> integral multiple of your character widths.  And toolkit scrollbars may
> have a width that is not an integral multiple either - so you would have
> to adjust the combined size anyway.
>
>
> > It doesn't help that functions doesn't seem to be designed to work
> > together, for example I would expect:
> >     (set-frame-size (selected-frame) (frame-pixel-width)
> > (frame-pixel-height) t)'
> > to be a no-op, but instead the frame increases its size both on the width
> > and on the height.
>
> `set-frame-size' expects as argument the new _text_ width of the frame
> and adds the width of fringes, a scrollbar and internal borders to that.
>
>
> > Another argument of not having a "odd" width is that when splitting
> windows
> > side-by-side, you will end up with an unused gap to the right of almost a
> > full character. Steps to repeat:
> >
> >     emacs -Q
> >     (setq truncate-partial-width-windows nil) C-j
> >     C-x 3
> >
> >         Here, the right window have an unused space between the rightmost
> > character and the fringe, the space is almost a character wide. It's not
> > possible to resize the frame manually to correct this, as the frame can
> > only be resized full characters (as it should be). (When
> > `truncate-partial-width-windows' is t, the gap is used to display a
> partial
> > character.)
> >
> > To conclude, I would be much happier if the sum of the fringes and the
> > scroll bar would be an even five characters rather than five characters
> and
> > one pixel, as it is today.
> >
> > The question is if this is due to some display bug (maybe OS X specific)
> or
> > if this is the way it is supposed to work now?
>
> This used to happen with Emacs 24.3 here and should be gone now.  But OS
> X still has the old extended fringes code in place - maybe that
> interferes.  Could you try to remove it - I can't compile for OS X so I
> won't do that.  If you want to know how, have a look at these changes:
>
> 2013-12-02  YAMAMOTO Mitsuharu  <mituharu <at> math.s.chiba-u.ac.jp>
>
>         * xterm.h (struct scroll_bar): Remove member `fringe_extended_p'.
>
>         * xterm.c (x_draw_fringe_bitmap, x_scroll_run): Remove code for
>         fringe background extension.
>         (x_scroll_bar_create): Remove variables `sb_left' and `sb_width',
>         because they are now always the same as `left' and `width',
>         respectively.  Remove code for the case that `width' and
>         `sb_width' are different.
>
> 2013-12-21  YAMAMOTO Mitsuharu  <mituharu <at> math.s.chiba-u.ac.jp>
>
>         * w32term.h (struct scroll_bar): Remove member `fringe_extended_p'.
>
>         * w32term.c (w32_draw_fringe_bitmap, x_scroll_run): Remove code for
>         fringe background extension.
>         (x_scroll_bar_create): Remove variables `sb_left' and `sb_width',
>         because they are now always the same as `left' and `width',
>         respectively.  Remove code for the case that `width' and
>         `sb_width' are different.
>
> martin
>

[Message part 2 (text/html, inline)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 16856 <at> debbugs.gnu.org
Subject: Re: bug#16856: 24.3.50;
 Cursor leaves garbage in fringe (and a request:
 width of fringes + scroll bar should be full characters)
Date: Wed, 26 Feb 2014 11:15:58 +0100

> The problem with the cursor leaving garbage in the right fringe still
> remains, though.

So you didn't try to remove the extended fringe code?  Is it too
difficult?  The problem might be located there.

martin

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

From: Anders Lindgren <andlind <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 16856 <at> debbugs.gnu.org
Subject: Re: bug#16856: 24.3.50; Cursor leaves garbage in fringe (and a
 request: width of fringes + scroll bar should be full characters)
Date: Wed, 26 Feb 2014 13:51:45 +0100

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

On Wed, Feb 26, 2014 at 11:15 AM, martin rudalics <rudalics <at> gmx.at> wrote:

> So you didn't try to remove the extended fringe code?  Is it too
> difficult?  The problem might be located there.


No, I haven't tried it yet. I don't think it's too difficult, I just
haven't found the time to do it yet.

/ Anders

[Message part 2 (text/html, inline)]

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

From: Alan Third <alan <at> idiocy.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 16856 <at> debbugs.gnu.org, Anders Lindgren <andlind <at> gmail.com>
Subject: Re: bug#16856: 24.3.50;
 Cursor leaves garbage in fringe (and a request: width of fringes +
 scroll bar should be full characters)
Date: Tue, 17 May 2016 19:30:31 +0100

martin rudalics <rudalics <at> gmx.at> writes:

>> Another argument of not having a "odd" width is that when splitting windows
>> side-by-side, you will end up with an unused gap to the right of almost a
>> full character. Steps to repeat:
>>
>>     emacs -Q
>>     (setq truncate-partial-width-windows nil) C-j
>>     C-x 3
>>
>>         Here, the right window have an unused space between the rightmost
>> character and the fringe, the space is almost a character wide. It's not
>> possible to resize the frame manually to correct this, as the frame can
>> only be resized full characters (as it should be). (When
>> `truncate-partial-width-windows' is t, the gap is used to display a partial
>> character.)
>>
>> To conclude, I would be much happier if the sum of the fringes and the
>> scroll bar would be an even five characters rather than five characters and
>> one pixel, as it is today.
>>
>> The question is if this is due to some display bug (maybe OS X specific) or
>> if this is the way it is supposed to work now?
>
> This used to happen with Emacs 24.3 here and should be gone now.  But OS
> X still has the old extended fringes code in place - maybe that
> interferes.  Could you try to remove it - I can't compile for OS X so I
> won't do that.  If you want to know how, have a look at these changes:

I believe this behaviour is no longer present in Emacs 25.

I don't think there's anything else in this bug report that needs
addressed, and as such, I'll close it in a couple of weeks if nobody
objects.
-- 
Alan Third

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

From: Anders Lindgren <andlind <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 16856 <at> debbugs.gnu.org
Subject: Re: bug#16856: 24.3.50; Cursor leaves garbage in fringe (and a
 request: width of fringes + scroll bar should be full characters)
Date: Tue, 17 May 2016 21:06:01 +0200

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

Hi!

I can repeat this using a slightly different recipe:

    emacs -Q
    (setq truncate-partial-width-windows nil)
    C-x 3
    C-x o
    C-u 37 x
       Here, the cursor which is in text area blinks, while the part in the
fringe doesn't.

       Wait until the the cursor stop blinking
    C-a
        Now, the right fringe contains half a cursor.

    -- Anders


On Tue, May 17, 2016 at 8:30 PM, Alan Third <alan <at> idiocy.org> wrote:

> martin rudalics <rudalics <at> gmx.at> writes:
>
> >> Another argument of not having a "odd" width is that when splitting
> windows
> >> side-by-side, you will end up with an unused gap to the right of almost
> a
> >> full character. Steps to repeat:
> >>
> >>     emacs -Q
> >>     (setq truncate-partial-width-windows nil) C-j
> >>     C-x 3
> >>
> >>         Here, the right window have an unused space between the
> rightmost
> >> character and the fringe, the space is almost a character wide. It's not
> >> possible to resize the frame manually to correct this, as the frame can
> >> only be resized full characters (as it should be). (When
> >> `truncate-partial-width-windows' is t, the gap is used to display a
> partial
> >> character.)
> >>
> >> To conclude, I would be much happier if the sum of the fringes and the
> >> scroll bar would be an even five characters rather than five characters
> and
> >> one pixel, as it is today.
> >>
> >> The question is if this is due to some display bug (maybe OS X
> specific) or
> >> if this is the way it is supposed to work now?
> >
> > This used to happen with Emacs 24.3 here and should be gone now.  But OS
> > X still has the old extended fringes code in place - maybe that
> > interferes.  Could you try to remove it - I can't compile for OS X so I
> > won't do that.  If you want to know how, have a look at these changes:
>
> I believe this behaviour is no longer present in Emacs 25.
>
> I don't think there's anything else in this bug report that needs
> addressed, and as such, I'll close it in a couple of weeks if nobody
> objects.
> --
> Alan Third
>

[Message part 2 (text/html, inline)]

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

From: Alan Third <alan <at> idiocy.org>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: martin rudalics <rudalics <at> gmx.at>, 16856 <at> debbugs.gnu.org
Subject: [PATCH] Prevent cursor from over-drawing the fringe
Date: Tue, 17 May 2016 22:14:15 +0100

src/nsterm.m (ns_draw_window_cursor): Reduce clip area from ANY_AREA to
TEXT_AREA. (bug#16856)
---
 src/nsterm.m | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index 1d48c04..5eb4c8f 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -2873,9 +2873,8 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
   r.size.height = h;
   r.size.width = w->phys_cursor_width;
 
-  /* TODO: only needed in rare cases with last-resort font in HELLO..
-     should we do this more efficiently? */
-  ns_clip_to_row (w, glyph_row, ANY_AREA, NO); /* do ns_focus(f, &r, 1); if remove */
+  /* Prevent the cursor from being drawn outside the text area. */
+  ns_clip_to_row (w, glyph_row, TEXT_AREA, NO); /* do ns_focus(f, &r, 1); if remove */
 
 
   face = FACE_FROM_ID (f, phys_cursor_glyph->face_id);
-- 

I believe this fixes it.

-- 
Alan Third

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

From: Anders Lindgren <andlind <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 16856 <at> debbugs.gnu.org
Subject: Re: [PATCH] Prevent cursor from over-drawing the fringe
Date: Fri, 20 May 2016 21:33:52 +0200

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

Hi!

I gave this patch a try.

It works well, the ns port now behaves like the win32 and gtk+ parts of
Emacs.

Do you want me to push it to master?

    -- Anders

Ps. When the text area doesn't partially overlap a column, the cursor can
be drawn in the fringe. It's a bit unfortunate that when it do overlap,
only the part of the cursor in the text area is drawn. A worst case
scenario is that only a single pixel of the cursor is visible. An ideal
solution would be to draw the cursor partially in the text area and
partially in the fringe, but without leaving garbage behind when moved.
However, this is nothing that we can solve here and now as it would require
change to all emacs ports and possibly the core system.


On Tue, May 17, 2016 at 11:14 PM, Alan Third <alan <at> idiocy.org> wrote:

> src/nsterm.m (ns_draw_window_cursor): Reduce clip area from ANY_AREA to
> TEXT_AREA. (bug#16856)
> ---
>  src/nsterm.m | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/src/nsterm.m b/src/nsterm.m
> index 1d48c04..5eb4c8f 100644
> --- a/src/nsterm.m
> +++ b/src/nsterm.m
> @@ -2873,9 +2873,8 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar
> cursors.
>    r.size.height = h;
>    r.size.width = w->phys_cursor_width;
>
> -  /* TODO: only needed in rare cases with last-resort font in HELLO..
> -     should we do this more efficiently? */
> -  ns_clip_to_row (w, glyph_row, ANY_AREA, NO); /* do ns_focus(f, &r, 1);
> if remove */
> +  /* Prevent the cursor from being drawn outside the text area. */
> +  ns_clip_to_row (w, glyph_row, TEXT_AREA, NO); /* do ns_focus(f, &r, 1);
> if remove */
>
>
>    face = FACE_FROM_ID (f, phys_cursor_glyph->face_id);
> --
>
> I believe this fixes it.
>
> --
> Alan Third
>

[Message part 2 (text/html, inline)]

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

From: Alan Third <alan <at> idiocy.org>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: martin rudalics <rudalics <at> gmx.at>, 16856 <at> debbugs.gnu.org
Subject: Re: [PATCH] Prevent cursor from over-drawing the fringe
Date: Sat, 21 May 2016 08:35:36 +0100

On Fri, May 20, 2016 at 09:33:52PM +0200, Anders Lindgren wrote:
> Hi!
> 
> I gave this patch a try.
> 
> It works well, the ns port now behaves like the win32 and gtk+ parts of
> Emacs.
> 
> Do you want me to push it to master?

If you could, thanks.

> Ps. When the text area doesn't partially overlap a column, the cursor can
> be drawn in the fringe. It's a bit unfortunate that when it do overlap,
> only the part of the cursor in the text area is drawn. A worst case
> scenario is that only a single pixel of the cursor is visible. An ideal
> solution would be to draw the cursor partially in the text area and
> partially in the fringe, but without leaving garbage behind when moved.
> However, this is nothing that we can solve here and now as it would require
> change to all emacs ports and possibly the core system.

Yeah, I was thinking about this but couldn't really see much of a way
around it. I checked the gtk+ and windows ports operated this way just
to be sure I wasn't introducing another bug as it does seem wrong. :)
-- 
Alan Third

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

From: Anders Lindgren <andlind <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 16856-done <at> debbugs.gnu.org
Subject: Re: [PATCH] Prevent cursor from over-drawing the fringe
Date: Sat, 21 May 2016 21:07:53 +0200

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

Closed.

Fixed by Alan Third, see the following for details:

http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e5015c5d9632a0bf685c093249ae4a7d3e825b13

    -- Anders

On Sat, May 21, 2016 at 9:35 AM, Alan Third <alan <at> idiocy.org> wrote:

> On Fri, May 20, 2016 at 09:33:52PM +0200, Anders Lindgren wrote:
> > Hi!
> >
> > I gave this patch a try.
> >
> > It works well, the ns port now behaves like the win32 and gtk+ parts of
> > Emacs.
> >
> > Do you want me to push it to master?
>
> If you could, thanks.
>
> > Ps. When the text area doesn't partially overlap a column, the cursor can
> > be drawn in the fringe. It's a bit unfortunate that when it do overlap,
> > only the part of the cursor in the text area is drawn. A worst case
> > scenario is that only a single pixel of the cursor is visible. An ideal
> > solution would be to draw the cursor partially in the text area and
> > partially in the fringe, but without leaving garbage behind when moved.
> > However, this is nothing that we can solve here and now as it would
> require
> > change to all emacs ports and possibly the core system.
>
> Yeah, I was thinking about this but couldn't really see much of a way
> around it. I checked the gtk+ and windows ports operated this way just
> to be sure I wasn't introducing another bug as it does seem wrong. :)
> --
> Alan Third
>

[Message part 2 (text/html, inline)]

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

From: David Reitter <david.reitter <at> gmail.com>
To: 16856 <at> debbugs.gnu.org
Subject: bug#16856: 24.3.50;	Cursor leaves garbage in fringe
Date: Sun, 17 Jul 2016 15:57:39 +0900

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

I don’t think that bea0f95 (May 21, nsterm.m) fully fixed this problem.  I’ve had several “appearances” of the ominous garbage in the right fringe yesterday.

This was after applying your patch (and removing my workaround).

The workaround is shown below, but at the time it only worked with cursor-type (bar . 2), not (bar . 3).  I haven’t checked with your change.








diff --git a/src/xdisp.c b/src/xdisp.c
index b43ce61..389fea7 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -2018,6 +2018,13 @@ get_glyph_string_clip_rects (struct glyph_string *s, NativeRectangle *rects, int
       /* This is a text line that may be partially visible.  */
       r.x = window_box_left (s->w, s->area);
       r.width = window_box_width (s->w, s->area);
+
+      /* Aquamacs workaround - Because the cursor is drawn without limiting focus to the
+        window box, but it is removed by writing glyph and nothing into the right margin,
+        while focus is applied to the window box, parts of the cursor may remain visible.
+        This is a stop-gap measure that fails if the cursor is (bar . 3) or wider. */
+      r.width += 1;
+
       r.height = s->row->visible_height;
     }

[Message part 2 (text/html, inline)]

[Screen Shot 2016-07-16 at 6.35.30 PM.png (image/png, inline)]

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

From: Alan Third <alan <at> idiocy.org>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 16856 <at> debbugs.gnu.org
Subject: Re: bug#16856: 24.3.50;	Cursor leaves garbage in fringe
Date: Sun, 17 Jul 2016 09:42:32 +0100

On Sun, Jul 17, 2016 at 03:33:03PM +0900, David Reitter wrote:
> I don’t think that bea0f95 (May 21, nsterm.m) fully fixed this
> problem. I’ve had several “appearances” of the ominous garbage in
> the right fringe yesterday.
> 
> This was after applying your patch (and removing my workaround).

Hi David, I'm not entirely sure what's going on in your screenshot. Is
the garbage definitely appearing in the fringe rather than in the main
text area? If so, is it on the left or the right (or the middle, I
guess) of the fringe?
-- 
Alan Third

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

From: David Reitter <david.reitter <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: "16856 <at> debbugs.gnu.org" <16856 <at> debbugs.gnu.org>
Subject: Re: bug#16856: 24.3.50; Cursor leaves garbage in fringe
Date: Sun, 17 Jul 2016 19:41:42 +0900

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

Good point, I can't tell.  It happens only in some situations (font size, text extent, window size)

---Sent from my phone

On Sun, Jul 17, 2016 at 03:33:03PM +0900, David Reitter wrote:

> I don’t think that bea0f95 (May 21, nsterm.m) fully fixed this

> problem. I’ve had several “appearances” of the ominous garbage in

> the right fringe yesterday.

>  
> This was after applying your patch (and removing my workaround).



Hi David, I'm not entirely sure what's going on in your screenshot. Is

the garbage definitely appearing in the fringe rather than in the main

text area? If so, is it on the left or the right (or the middle, I

guess) of the fringe?

--  
Alan Third

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: david.reitter <at> gmail.com, 16856 <at> debbugs.gnu.org
Subject: Re: bug#16856: 24.3.50;	Cursor leaves garbage in fringe
Date: Sun, 17 Jul 2016 15:09:34 +0300

> Date: Sun, 17 Jul 2016 09:42:32 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: 16856 <at> debbugs.gnu.org
> 
> On Sun, Jul 17, 2016 at 03:33:03PM +0900, David Reitter wrote:
> > I don’t think that bea0f95 (May 21, nsterm.m) fully fixed this
> > problem. I’ve had several “appearances” of the ominous garbage in
> > the right fringe yesterday.
> > 
> > This was after applying your patch (and removing my workaround).
> 
> Hi David, I'm not entirely sure what's going on in your screenshot. Is
> the garbage definitely appearing in the fringe rather than in the main
> text area? If so, is it on the left or the right (or the middle, I
> guess) of the fringe?

I actually am puzzled by more than that: it looks like the "garbage"
is some text drawn on the fringe, which seems to point to incorrect
coordinates of some screen write.  If that screen write is the one
that draws or erases the cursor, then I don't understand this comment:

  "Because the cursor is drawn without limiting focus to the window
   box, but it is removed by writing glyph and nothing into the right
   margin, while focus is applied to the window box, parts of the
   cursor may remain visible."

It seems to imply that drawing cursor and erasing it are implemented
in Aquamacs by two very different code fragments?  (That's not what
happens on other platforms, AFAIR.)  And if that's true, I understand
the workaround even less: it limits the _width_ of the cursor, whereas
the problem is clearly with its coordinates.

What am I missing?

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

From: David Reitter <david.reitter <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16856 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>
Subject: Re: bug#16856: 24.3.50;	Cursor leaves garbage in fringe
Date: Sun, 17 Jul 2016 21:41:07 +0900

On Jul 17, 2016, at 9:09 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>  "Because the cursor is drawn without limiting focus to the window
>   box, but it is removed by writing glyph and nothing into the right
>   margin, while focus is applied to the window box, parts of the
>   cursor may remain visible."
> 
> It seems to imply that drawing cursor and erasing it are implemented
> in Aquamacs by two very different code fragments?

I don’t think they’re that different.
I do not know the code there very well, otherwise I would have just fixed the problem.

Is it possible that when drawing the glyph, we call ns_focus with the rectangle returned by ns_get_glyph_string_clip_rect()?
ns_draw_window_cursor() on the other hand focuses via ns_clip_to_row().  It might do so before deleting the cursor (if that’s where the cursor is erased), but that doesn’t matter, because clipping in ns_focus probably isn’t incremental from what it looks like.

>   And if that's true, I understand
> the workaround even less: it limits the _width_ of the cursor, whereas
> the problem is clearly with its coordinates.

No, it increases the width of the clipped rectangle so that the cursor can be erased from wherever it was drawn.
But again, if the cursor type is wider than 2px (on the right hand side of the underlying glyph), we would have to widen the clip box even further.

I’m not sure what the correct solution is here.  If the bar cursor is drawn to the right of the glyph, it’s going to go into the margin or fringe.  If you prevent that even at reasonable cursors like (bar . 2), the cursor is going to look funny on the right hand side.  So, I think we have to  (A)  widen the clipping rectangle to something like max(row_width, glyph_x+glyph_w+min(2, cursor_width)), and (B)  also clip when drawing the cursor so that wide cursors don’t go into the fringe.  I think Alan’s change may have done B already.  Haven’t tested that.  (As for A, I can’t work on it right now and probably don’t know the code well enough to do this right anyway.)

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

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: david.reitter <at> gmail.com, 16856 <at> debbugs.gnu.org
Subject: Re: bug#16856: 24.3.50;	Cursor leaves garbage in fringe
Date: Sun, 17 Jul 2016 14:26:31 +0100

On Sun, Jul 17, 2016 at 03:09:34PM +0300, Eli Zaretskii wrote:
> I actually am puzzled by more than that: it looks like the "garbage"
> is some text drawn on the fringe, which seems to point to incorrect
> coordinates of some screen write.  If that screen write is the one
> that draws or erases the cursor, then I don't understand this comment:

I think the screenshot shows Emacs running in front of some other (OS)
window and we can see a little bit of that window on either side of
the Emacs frame.

-- 
Alan Third

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

From: Alan Third <alan <at> idiocy.org>
To: David Reitter <david.reitter <at> gmail.com>
Cc: "16856 <at> debbugs.gnu.org" <16856 <at> debbugs.gnu.org>
Subject: Re: bug#16856: 24.3.50; Cursor leaves garbage in fringe
Date: Sun, 17 Jul 2016 14:35:13 +0100

On Sun, Jul 17, 2016 at 07:41:42PM +0900, David Reitter wrote:
> Good point, I can't tell.  It happens only in some situations (font
> size, text extent, window size)

I think I’ve got a reproducible case:

Emacs -Q

(visual-line-mode 1)
(variable-pitch-mode 1)
(setq-default cursor-type '(bar . 4))

SPC SPC SPC C-b C-b C-b

It doesn’t even have to be spaces, it looks like it's any case where
the bar cursor is wider than the underlying glyph.

Interestingly the Mac port doesn’t seem to ever draw the bar cursor
wider than the glyph whereas the NS port always draws it at the
configured width. Perhaps that’s where the fault is.
-- 
Alan Third

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

From: Alan Third <alan <at> idiocy.org>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 16856 <at> debbugs.gnu.org
Subject: [PATCH] Prevent bar cursor overwriting next glyph (bug#16856)
Date: Sun, 17 Jul 2016 14:51:31 +0100

* src/nsterm.m (ns_draw_window_cursor): Test glyph width vs cursor width
before setting final size.
---
 src/nsterm.m | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index a6160ed..8da2ffe 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -2861,7 +2861,10 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
     {
       if (cursor_width < 1)
 	cursor_width = max (FRAME_CURSOR_WIDTH (f), 1);
-      w->phys_cursor_width = cursor_width;
+
+      /* The bar cursor should never be wider than the glyph. */
+      if (cursor_width < w->phys_cursor_width)
+        w->phys_cursor_width = cursor_width;
     }
   /* If we have an HBAR, "cursor_width" MAY specify height. */
   else if (cursor_type == HBAR_CURSOR)
-- 

And here's a patch to prevent the bar cursor straying into the next glyph.
-- 
Alan Third

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

From: David Reitter <david.reitter <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 16856 <at> debbugs.gnu.org
Subject: Re: [PATCH] Prevent bar cursor overwriting next glyph (bug#16856)
Date: Mon, 18 Jul 2016 07:54:03 +0900

No ill effects with that.  What is the glyph at the end of the line?
Also, about your patch, it seems like w->phys_cursor_width will then just be whatever it was before.


> On Jul 17, 2016, at 10:51 PM, Alan Third <alan <at> idiocy.org> wrote:
> 
> * src/nsterm.m (ns_draw_window_cursor): Test glyph width vs cursor width
> before setting final size.
> ---
> src/nsterm.m | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/src/nsterm.m b/src/nsterm.m
> index a6160ed..8da2ffe 100644
> --- a/src/nsterm.m
> +++ b/src/nsterm.m
> @@ -2861,7 +2861,10 @@ Note that CURSOR_WIDTH is meaningful only for (h)bar cursors.
>     {
>       if (cursor_width < 1)
> 	cursor_width = max (FRAME_CURSOR_WIDTH (f), 1);
> -      w->phys_cursor_width = cursor_width;
> +
> +      /* The bar cursor should never be wider than the glyph. */
> +      if (cursor_width < w->phys_cursor_width)
> +        w->phys_cursor_width = cursor_width;
>     }
>   /* If we have an HBAR, "cursor_width" MAY specify height. */
>   else if (cursor_type == HBAR_CURSOR)
> -- 
> 
> And here's a patch to prevent the bar cursor straying into the next glyph.
> -- 
> Alan Third

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

From: Alan Third <alan <at> idiocy.org>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 16856 <at> debbugs.gnu.org
Subject: Re: bug#16856: [PATCH] Prevent bar cursor overwriting next glyph
 (bug#16856)
Date: Mon, 18 Jul 2016 15:26:57 +0100

On 17 July 2016 at 23:54, David Reitter <david.reitter <at> gmail.com> wrote:
> No ill effects with that.  What is the glyph at the end of the line?

I don't know how the end-of-line is displayed. On the Windows Emacs
I've got here it's a narrow glyph (same as space, I think), so the bar
isn't displayed at it's full width if it's set to be wide. I expect
it'll be the same on the Mac, I can check later if you want.

> Also, about your patch, it seems like w->phys_cursor_width will then just be whatever it was before.

No, w->phys_cursor_width appears to hold the glyph width by default,
so we should end up with the smaller of cursor_width or the glyph
width.

I realise it might be more desirable to have the bar cursor be a
consistent width, but that would make the NS port different from all
the others, afaics.

-- 
Alan Third

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

From: Keith David Bershatsky <esq <at> lawlist.com>
To: Emacs Bug Reports <bug-gnu-emacs <at> gnu.org>
Cc: Alan Third <alan <at> idiocy.org>, 16856 <at> debbugs.gnu.org,
 Martin Rudalics <rudalics <at> gmx.at>, David Reitter <david.reitter <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, Anders Lindgren <andlind <at> gmail.com>
Subject: Enable fringe cursor when *almost* exact_window_width_line_p
Date: Thu, 09 Nov 2017 10:50:41 -0800

For those users who wish to customize the frame width pixelwise to a size such that exact_window_width_line_p will _never_ be true, those users miss out on the joy of seeing the fringe cursor bitmap.  While the patch that was applied pursuant to Bug#16856 fixed the problem with the cursor being drawn on top of the fringe (e5015c5d9632a0bf685c093249ae4a7d3e825b13), it does not permit a fringe bitmap to be placed there instead.

If I had it to do all over again, I would have made the following two modifications.  [I have not yet experimented with xterm.c and w32term.c to see if the new condition should be added there as well for Emacs platform builds on Windows and X11.]

In window.c, add the following condition to get_phys_cursor_glyph:

/* This modification enables placement of the cursor-in-fringe bitmap when
the window-width is slightly less than `glyph_row->exact_window_width_line_p`.
This modification also prevents drawing the real cursor on the fringe (instead
of using the cursor-in-fringe bitmap) in the above-mentioned circumstance. */

  struct frame *f = XFRAME (w->frame);
  int frame_char_width = FRAME_COLUMN_WIDTH (f);
  int text_area_width = window_box_width (w, TEXT_AREA);
  bool cursor_in_fringe_p = w->phys_cursor.x + frame_char_width >= text_area_width;
  if (cursor_in_fringe_p)
    return NULL;


And, in nsterm.m, modify a section of ns_draw_window_cursor to include the new condition:

  if ((phys_cursor_glyph = get_phys_cursor_glyph (w)) == NULL)
    {
      /* This modification enables placement of the cursor-in-fringe bitmap when
      the window-width is slightly less than `glyph_row->exact_window_width_line_p`.
      This modification also prevents drawing the real cursor on the fringe (instead
      of using the cursor-in-fringe bitmap) in the above-mentioned circumstance. */
      int frame_char_width = FRAME_COLUMN_WIDTH (f);
      int text_area_width = window_box_width (w, TEXT_AREA);
      bool cursor_in_fringe_p = w->phys_cursor.x + frame_char_width >= text_area_width;
      if ((glyph_row->exact_window_width_line_p
            && w->phys_cursor.hpos >= glyph_row->used[TEXT_AREA])
          || cursor_in_fringe_p)
        {
          glyph_row->cursor_in_fringe_p = 1;
          draw_fringe_bitmap (w, glyph_row, 0);
        }
      return;
    }

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

From: Keith David Bershatsky <esq <at> lawlist.com>
To: 16856 <at> debbugs.gnu.org
Subject: bug#16856: Cursor leaves garbage in fringe.
Date: Thu, 09 Nov 2017 11:00:04 -0800

See also the related patch that was applied on July 19, 2016:  bf5ddded70c11edaf3514b25da27fc71cfb8e965

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

From: Alan Third <alan <at> idiocy.org>
To: Keith David Bershatsky <esq <at> lawlist.com>
Cc: 16856 <at> debbugs.gnu.org, Emacs Bug Reports <bug-gnu-emacs <at> gnu.org>,
 Martin Rudalics <rudalics <at> gmx.at>, David Reitter <david.reitter <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, Anders Lindgren <andlind <at> gmail.com>
Subject: Re: Enable fringe cursor when *almost* exact_window_width_line_p
Date: Thu, 9 Nov 2017 22:11:42 +0000

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

On Thu, Nov 09, 2017 at 10:50:41AM -0800, Keith David Bershatsky wrote:
> For those users who wish to customize the frame width pixelwise to a
> size such that exact_window_width_line_p will _never_ be true, those
> users miss out on the joy of seeing the fringe cursor bitmap. While
> the patch that was applied pursuant to Bug#16856 fixed the problem
> with the cursor being drawn on top of the fringe
> (e5015c5d9632a0bf685c093249ae4a7d3e825b13), it does not permit a
> fringe bitmap to be placed there instead.
> 
> If I had it to do all over again, I would have made the following
> two modifications. [I have not yet experimented with xterm.c and
> w32term.c to see if the new condition should be added there as well
> for Emacs platform builds on Windows and X11.]

This needs a bit more work I’m afraid. If you’re using a bar cursor it
can seem like it’s putting the cursor into the fringe somewhat
prematurely. I think it should be using the width of the cursor rather
than the glyph width.

Additionally I’ve attached a screenshot of the cursor in the fringe
when it shouldn’t be. It should appear over the last x on the line
(point is before the last x on the line).

David, I can’t replicate junk in the fringe. Do you have a recipe?
-- 
Alan Third

[fringe-cursor.png (image/png, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: david.reitter <at> gmail.com, 16856 <at> debbugs.gnu.org, esq <at> lawlist.com,
 andlind <at> gmail.com, rudalics <at> gmx.at
Subject: Re: Enable fringe cursor when *almost* exact_window_width_line_p
Date: Fri, 10 Nov 2017 09:53:56 +0200

> Date: Thu, 9 Nov 2017 22:11:42 +0000
> From: Alan Third <alan <at> idiocy.org>
> Cc: Emacs Bug Reports <bug-gnu-emacs <at> gnu.org>, 16856 <at> debbugs.gnu.org,
> 	Eli Zaretskii <eliz <at> gnu.org>, Anders Lindgren <andlind <at> gmail.com>,
> 	Martin Rudalics <rudalics <at> gmx.at>,
> 	David Reitter <david.reitter <at> gmail.com>
> 
> Additionally I’ve attached a screenshot of the cursor in the fringe
> when it shouldn’t be. It should appear over the last x on the line
> (point is before the last x on the line).

What you show is not cursor on the fringe, because you have the
continuation arrow on the fringe.  When the continuation arrow is
shown, the cursor cannot be shown on the fringe, because that slot is
already taken.  And anyway, the cursor is only shown on the fringe
when the line is not continued.

What you see there is Emacs displaying the small part of the cursor
that it still has available on the first screen line, probably because
your window-width is not an integral multiple of frame's
character-width.

IOW, I don't think I see anything abnormal in that image.

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

From: Anders Lindgren <andlind <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16856 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>,
 Keith David Bershatsky <esq <at> lawlist.com>,
 David Reitter <david.reitter <at> gmail.com>, martin rudalics <rudalics <at> gmx.at>
Subject: Re: Enable fringe cursor when *almost* exact_window_width_line_p
Date: Sat, 11 Nov 2017 17:34:38 +0100

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

On Fri, Nov 10, 2017 at 8:53 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> What you show is not cursor on the fringe, because you have the
> continuation arrow on the fringe.  When the continuation arrow is
> shown, the cursor cannot be shown on the fringe, because that slot is
> already taken.  And anyway, the cursor is only shown on the fringe
> when the line is not continued.
>
> What you see there is Emacs displaying the small part of the cursor
> that it still has available on the first screen line, probably because
> your window-width is not an integral multiple of frame's
> character-width.
>
> IOW, I don't think I see anything abnormal in that image.
>

Hi!

The problem is that when the normal cursor is drawn, it spills into the
fringe. When the cursor is moved, the fringe isn't updated, so artefacts
are left behind.

This only happens when the last character on the line only is partial
visible, as you correctly suggested.

    -- Anders (Original reporter)

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 16856 <at> debbugs.gnu.org, alan <at> idiocy.org, esq <at> lawlist.com,
 david.reitter <at> gmail.com, rudalics <at> gmx.at
Subject: Re: Enable fringe cursor when *almost* exact_window_width_line_p
Date: Sat, 11 Nov 2017 19:25:44 +0200

> From: Anders Lindgren <andlind <at> gmail.com>
> Date: Sat, 11 Nov 2017 17:34:38 +0100
> Cc: Alan Third <alan <at> idiocy.org>, Keith David Bershatsky <esq <at> lawlist.com>, 16856 <at> debbugs.gnu.org, 
> 	martin rudalics <rudalics <at> gmx.at>, David Reitter <david.reitter <at> gmail.com>
> 
> The problem is that when the normal cursor is drawn, it spills into the fringe.

??? Are you saying that drawing on macOS is not clipped by the
window's edge?

> When the cursor is moved, the
> fringe isn't updated, so artefacts are left behind.

I saw no artifacts on the image that was posted.

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

From: Anders Lindgren <andlind <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16856 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>,
 Keith David Bershatsky <esq <at> lawlist.com>,
 David Reitter <david.reitter <at> gmail.com>, martin rudalics <rudalics <at> gmx.at>
Subject: Re: Enable fringe cursor when *almost* exact_window_width_line_p
Date: Sat, 11 Nov 2017 18:49:03 +0100

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

Hi!

On Sat, Nov 11, 2017 at 6:25 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> ??? Are you saying that drawing on macOS is not clipped by the
> window's edge?

Yes, when it comes to the cursor, that is correct.


> > When the cursor is moved, the
> > fringe isn't updated, so artefacts are left behind.
>
> I saw no artifacts on the image that was posted.


I just verified that the following recipe (posted in 2016) demonstrates the
problem, on NS. (The original recipe from 2014 no longer works, though).

   emacs -Q
    (setq truncate-partial-width-windows nil)
    C-x 3
    C-x o
    C-u 37 x
       Here, the cursor which is in text area blinks, while the part in the
fringe doesn't.

       Wait until the the cursor stop blinking
    C-a
        Now, the right fringe contains half a cursor.

    -- Anders

[Message part 2 (text/html, inline)]

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

From: Alan Third <alan <at> idiocy.org>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: 16856 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Keith David Bershatsky <esq <at> lawlist.com>,
 David Reitter <david.reitter <at> gmail.com>, martin rudalics <rudalics <at> gmx.at>
Subject: Re: Enable fringe cursor when *almost* exact_window_width_line_p
Date: Sat, 11 Nov 2017 18:46:27 +0000

On Sat, Nov 11, 2017 at 06:49:03PM +0100, Anders Lindgren wrote:
> I just verified that the following recipe (posted in 2016) demonstrates the
> problem, on NS. (The original recipe from 2014 no longer works, though).
> 
>    emacs -Q
>     (setq truncate-partial-width-windows nil)
>     C-x 3
>     C-x o
>     C-u 37 x
>        Here, the cursor which is in text area blinks, while the part in the
> fringe doesn't.
> 
>        Wait until the the cursor stop blinking
>     C-a
>         Now, the right fringe contains half a cursor.

I can’t replicate this. It *should* be fixed. Can you confirm whether
it’s still an issue in Emacs 26?

The screenshot was trying to indicate an issue with Keith’s
modifications where it was putting the cursor into the fringe one
character too early. I was using a 2 pixel wide bar cursor, which
probably didn’t help. You can see the cursor is placed underneath the
fringe arrow; it should be on the left of the last x on the line.

Keith has raised a new bug report for his patch (29233) so further
discussion of it should probably continue there.
-- 
Alan Third

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

From: Anders Lindgren <andlind <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>
Cc: 16856 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Keith David Bershatsky <esq <at> lawlist.com>,
 David Reitter <david.reitter <at> gmail.com>, martin rudalics <rudalics <at> gmx.at>
Subject: Re: Enable fringe cursor when *almost* exact_window_width_line_p
Date: Sat, 11 Nov 2017 21:36:40 +0100

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

On Sat, Nov 11, 2017 at 7:46 PM, Alan Third <alan <at> idiocy.org> wrote:

> I can’t replicate this. It *should* be fixed. Can you confirm whether
> it’s still an issue in Emacs 26?
>

I can confirm that it has been fixed in Emacs 26. Thanks for fixing it, and
sorry about the noice.

    -- Anders

[Message part 2 (text/html, inline)]

Previous Next

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