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

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

[Anders Lindgren]

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

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@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)

[-- Attachment #2: Type: text/html, Size: 4444 bytes --]

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

[Eli Zaretskii]

> Date: Sun, 23 Feb 2014 22:39:55 +0100
> From: Anders Lindgren <andlind@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.

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

[martin rudalics]

 > 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

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

[Anders Lindgren]

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

On Mon, Feb 24, 2014 at 8:41 AM, martin rudalics <rudalics@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

[-- Attachment #2: Type: text/html, Size: 3234 bytes --]

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

[martin rudalics]

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

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

[Anders Lindgren]

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

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

[-- Attachment #2: Type: text/html, Size: 5475 bytes --]

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

[martin rudalics]

 > 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

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

[Anders Lindgren]

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

On Wed, Feb 26, 2014 at 11:15 AM, martin rudalics <rudalics@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

[-- Attachment #2: Type: text/html, Size: 731 bytes --]

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

[Alan Third]

martin rudalics <rudalics@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

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

[Anders Lindgren]

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

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@idiocy.org> wrote:

> martin rudalics <rudalics@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
>

[-- Attachment #2: Type: text/html, Size: 3602 bytes --]

bug#16856: [PATCH] Prevent cursor from over-drawing the fringe

[Alan Third]

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

bug#16856: [PATCH] Prevent cursor from over-drawing the fringe

[Anders Lindgren]

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

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

[-- Attachment #2: Type: text/html, Size: 2367 bytes --]

bug#16856: [PATCH] Prevent cursor from over-drawing the fringe

[Alan Third]

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

bug#16856: [PATCH] Prevent cursor from over-drawing the fringe

[Anders Lindgren]

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

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

[-- Attachment #2: Type: text/html, Size: 2065 bytes --]

bug#16856: 24.3.50; Cursor leaves garbage in fringe

[David Reitter]

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

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;
     }


[-- Attachment #2.1: Type: text/html, Size: 2445 bytes --]

[-- Attachment #2.2: Screen Shot 2016-07-16 at 6.35.30 PM.png --]
[-- Type: image/png, Size: 67955 bytes --]

bug#16856: Enable fringe cursor when *almost* exact_window_width_line_p

[Keith David Bershatsky]

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;
    }

bug#29233: Enable fringe cursor when *almost* exact_window_width_line_p

[Keith David Bershatsky]

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

bug#29233: Enable fringe cursor when *almost* exact_window_width_line_p

[Alan Third]

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

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

[-- Attachment #2: fringe-cursor.png --]
[-- Type: image/png, Size: 5035 bytes --]

bug#16856: Enable fringe cursor when *almost* exact_window_width_line_p

[Eli Zaretskii]

> Date: Thu, 9 Nov 2017 22:11:42 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: Emacs Bug Reports <bug-gnu-emacs@gnu.org>, 16856@debbugs.gnu.org,
> 	Eli Zaretskii <eliz@gnu.org>, Anders Lindgren <andlind@gmail.com>,
> 	Martin Rudalics <rudalics@gmx.at>,
> 	David Reitter <david.reitter@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.

bug#16856: Enable fringe cursor when *almost* exact_window_width_line_p

[Anders Lindgren]

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

On Fri, Nov 10, 2017 at 8:53 AM, Eli Zaretskii <eliz@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)

[-- Attachment #2: Type: text/html, Size: 1574 bytes --]

bug#16856: Enable fringe cursor when *almost* exact_window_width_line_p

[Eli Zaretskii]

> From: Anders Lindgren <andlind@gmail.com>
> Date: Sat, 11 Nov 2017 17:34:38 +0100
> Cc: Alan Third <alan@idiocy.org>, Keith David Bershatsky <esq@lawlist.com>, 16856@debbugs.gnu.org, 
> 	martin rudalics <rudalics@gmx.at>, David Reitter <david.reitter@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.

bug#16856: Enable fringe cursor when *almost* exact_window_width_line_p

[Anders Lindgren]

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

Hi!

On Sat, Nov 11, 2017 at 6:25 PM, Eli Zaretskii <eliz@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

[-- Attachment #2: Type: text/html, Size: 1033 bytes --]

bug#16856: Enable fringe cursor when *almost* exact_window_width_line_p

[Alan Third]

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

bug#16856: Enable fringe cursor when *almost* exact_window_width_line_p

[Anders Lindgren]

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

On Sat, Nov 11, 2017 at 7:46 PM, Alan Third <alan@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

[-- Attachment #2: Type: text/html, Size: 649 bytes --]

bug#29233: Enable fringe cursor when *almost* exact_window_width_line_p

[Keith David Bershatsky]

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

I neglected to set up a bug tracking number at the outset before copying everyone, so I am forwarding a copy of Alan's recent message to #29233 (which has been assigned to this particular issue).

;;;;;;;;;;;;;;;;;;;;;; FORWARDED MESSAGE ;;;;;;;;;;;;;;;;;;;;;;


[-- Attachment #2: Type: message/rfc822, Size: 11192 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 1273 bytes --]

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

[-- Attachment #2.1.2: fringe-cursor.png --]
[-- Type: image/png, Size: 5035 bytes --]

bug#29233: Enable fringe cursor when *almost* exact_window_width_line_p

[Keith David Bershatsky]

The crux of the issue raised with #29233 is whether users might wish to see a fringe bitmap instead of a partial width cursor when point is slightly less than the exact window width.  Whereas the patches relating to #16856 reduce the width of the cursor so that it does not overflow into the fringe (creating unwanted artifacts), there was nothing done to permit a fringe bitmap to be placed there instead.

I had not given any consideration to the possibility that a partial width cursor is "a feature".  I.e., I erroneously assumed that a partial width cursor was merely an attempt to avoid unwanted artifacts being drawn on the fringe.

I personally like to see fringe bitmaps when points is slightly less than the exact widow width; however, I am uncertain how to reconcile that proposed feature with the desire by others to see a partial width cursor without a fringe bitmap.

If the consensus is that a user who has a window-width that is not an integral multiple of frame's character width must give up the ability to see a fringe bitmap, then that resolves #29233.

If the consensus is that a user does not have to give up seeing a fringe bitmap in the above-mentioned circumstance, the question is when will the fringe bitmap be seen and what modification would be appropriate in that circumstance.

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

DATE:  [11-09-2017 23:53:56] <10 Nov 2017 09:53:56 +0200>
FROM:  Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Thu, 9 Nov 2017 22:11:42 +0000
> > From: Alan Third <alan@idiocy.org>
> > * * *
> > 
> > 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.

bug#29233: Enable fringe cursor when *almost* exact_window_width_line_p

[Eli Zaretskii]

> Date:  Sat, 11 Nov 2017 14:33:22 -0800
> From:  Keith David Bershatsky <esq@lawlist.com>
> Cc:  Alan Third <alan@idiocy.org>,Anders Lindgren <andlind@gmail.com>,David Reitter <david.reitter@gmail.com>,Martin Rudalics <rudalics@gmx.at>,29233@debbugs.gnu.org
> 
> The crux of the issue raised with #29233 is whether users might wish to see a fringe bitmap instead of a partial width cursor when point is slightly less than the exact window width.  Whereas the patches relating to #16856 reduce the width of the cursor so that it does not overflow into the fringe (creating unwanted artifacts), there was nothing done to permit a fringe bitmap to be placed there instead.
> 
> I had not given any consideration to the possibility that a partial width cursor is "a feature".  I.e., I erroneously assumed that a partial width cursor was merely an attempt to avoid unwanted artifacts being drawn on the fringe.
> 
> I personally like to see fringe bitmaps when points is slightly less than the exact widow width; however, I am uncertain how to reconcile that proposed feature with the desire by others to see a partial width cursor without a fringe bitmap.

The part of the display code that deals with the cursor on the fringes
is insanely complicated.  It's part of the code which deals with the
following features:

 . "normal" display of the cursor at the end of a line
 . showing the cursor on the right (or left, for RTL lines) fringe
   when a line fits in the window exactly
 . showing the continuation/truncation bitmaps on the fringes
 . showing the continuation/truncation glyphs in the text area when
   the fringes are disabled
 . displaying a TAB or any other stretch of white space that extends
   beyond the window edge
 . all of the above, when lines are wrapped (word-wrap is non-nil)
 . most of the above on TTY frames

(I could be forgetting some use cases.)  Each one of these needs
special considerations in the move_it_* functions, because those
functions need to support all of those correctly.

Adding any more complexity to what we already have on our hands is IMO
only justified for some significant features.  The proposed one seems
to be only of aesthetic value, so I don't think we should complicate
the display code more than it already is on this behalf.

> If the consensus is that a user who has a window-width that is not an integral multiple of frame's character width must give up the ability to see a fringe bitmap, then that resolves #29233.

It's not just the window being the integral multiple, it's _any_
situation where some space is available between the right edge of the
last glyph and the window edge.  Don't forget that Emacs supports
variable-pitch fonts and can display glyphs from different fonts on
the same line, which will almost always leave some fractional space at
the end of the line.

I don't know if this is the consensus, but I just don't think we
should go there.

bug#29233: Enable fringe cursor when *almost* exact_window_width_line_p

[Noam Postavsky]

tags 29233 wontfix
close 29233
quit

Eli Zaretskii <eliz@gnu.org> writes:

>> If the consensus is that a user who has a window-width that is not
>> an integral multiple of frame's character width must give up the
>> ability to see a fringe bitmap, then that resolves #29233.

> I don't know if this is the consensus, but I just don't think we
> should go there.

I don't see any counterpoints, so I'm closing as wontfix.

bug#16856: Cursor leaves garbage in fringe.

[Keith David Bershatsky]

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