bug#13011: 24.2; Text flickering moving cursor with box around text enabled

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[mario giovinazzo]

*** E-Mail body has been placed on clipboard, please paste it here! ***

The problem occurs when I customize hl-line enabling box around text
to make evident the current line.
The box around text (also 1 pixel) changes the inside text position
thus producing a vertical and horizontal flickering when I move the cursor.
Setting a box of width -1 (a negative number) stops the vertical
flickering but still remains the horizontal one.





In GNU Emacs 24.2.1 (i386-mingw-nt5.1.2600)
 of 2012-08-29 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENG
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  show-paren-mode: t
  global-hl-line-mode: t
  global-hi-lock-mode: t
  hi-lock-mode: t
  cua-mode: t
  tooltip-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
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <tool-bar> <kill-buffer> <help-echo> <help-echo> 
M-x C-y <return>

Recent messages:
Loading cua-base...done
Loading delsel...done
Loading hi-lock...done
Loading hl-line...done
Loading paren...done
For information about GNU Emacs and the GNU system, type C-h C-a.
.emacs has auto save data; consider M-x recover-this-file

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 mail-prsvr mail-utils time windmove cc-styles cc-align cc-engine
cc-vars cc-defs regexp-opt tempo-c-cpp tempo edmacro kmacro uniquify
advice help-fns advice-preload paren hl-line hi-lock delsel cua-base
cus-start cus-load time-date tooltip ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset
image fringe lisp-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 loaddefs button faces cus-face files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty emacs)

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Eli Zaretskii]

> Date: Tue, 27 Nov 2012 11:42:24 +0100
> From: mario giovinazzo <mario.giovinazzo@virgilio.it>
> 
> The problem occurs when I customize hl-line enabling box around text
> to make evident the current line.
> The box around text (also 1 pixel) changes the inside text position
> thus producing a vertical and horizontal flickering when I move the cursor.
> Setting a box of width -1 (a negative number) stops the vertical
> flickering but still remains the horizontal one.

Can you please show a minimal recipe to reproduce this starting with
"emacs -Q"?  That will make the job of looking into this much easier.

Thanks.

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Eli Zaretskii]

[Please keep the bug address on the CC list.]

> Date: Wed, 28 Nov 2012 16:14:53 +0100
> From: mario giovinazzo <mario.giovinazzo@virgilio.it>
> 
> To reproduce the behavior is very easy.
> My .emacs file contains only this 2  lines:
> 
> 
> (custom-set-variables '(global-hl-line-mode t))
> (custom-set-faces '(hl-line ((t (:box (:line-width 1 :color "gray50"))))))

Thanks.

> If you open any text file and move the cursor inside text with arrow key
> (up, down, right, left), the" box around text" follow the cursor,
> and the text flickers (I suppose +- 2 pixels). It is evident.

I see no flickering when moving cursor horizontally within the same
screen line.  None at all.

When moving cursor vertically, I see this:

  . The text of the current line moves slightly up when the current
    line moves up or down.

  . When the current line is empty, the text in all the lines below it
    moves up slightly, then moves back down when the current lines
    becomes a line with some text.

Is this what you call "flicker"?  Or do you see something else?

If the above is what you see, then please tell what you expect Emacs
to do instead.  You've changed the face of the current line such that
it takes slightly more pixels on the screen.  Emacs just obeys your
specifications, it cannot display a line in less pixels than it needs
to draw all of the characters on it in the face you requested.  The
same would happen if you set the hl-line face to use a larger font,
for example.

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Stefan Monnier]

>> (custom-set-variables '(global-hl-line-mode t))
>> (custom-set-faces '(hl-line ((t (:box (:line-width 1 :color "gray50"))))))
> Thanks.

Actually the interesting case is when the box is of width -1.

> I see no flickering when moving cursor horizontally within the same
> screen line.  None at all.

The problem is when moving vertically.

> If the above is what you see, then please tell what you expect Emacs
> to do instead.

When the box width is 1, indeed, there's no much Emacs could do, but
when the width is -1 (i.e. drawn "inside" the normal text box),
characters shouldn't move, whereas they do (they get shifted
horizontally by a few pixels, and if you try it in the *Help* buffer
you may see that the number of pixel shifts seems to increase at
transition points between different fonts, such as italics for function
arguments).


        Stefan

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: mario giovinazzo <mario.giovinazzo@virgilio.it>,  13011@debbugs.gnu.org
> Date: Wed, 28 Nov 2012 23:39:04 -0500
> 
> When the box width is 1, indeed, there's no much Emacs could do, but
> when the width is -1 (i.e. drawn "inside" the normal text box),
> characters shouldn't move, whereas they do (they get shifted
> horizontally by a few pixels, and if you try it in the *Help* buffer
> you may see that the number of pixel shifts seems to increase at
> transition points between different fonts, such as italics for function
> arguments).

Looks like this was done on (some) purpose:

In xdisp.c:

	  /* If face has a box, add the box thickness to the character
	     height.  If character has a box line to the left and/or
	     right, add the box line width to the character's width.  */
	  if (face->box != FACE_NO_BOX)
	    {
	      int thick = face->box_line_width;

	      if (thick > 0)
		{
		  it->ascent += thick;
		  it->descent += thick;
		}
	      else
		thick = -thick;   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

	      if (it->start_of_box_run_p)
		it->pixel_width += thick;  <<<<<<<<<<<<<<<<<<<<<<<<<
	      if (it->end_of_box_run_p)
		it->pixel_width += thick;
	    }

Note that the ascent and descent are only enlarged when the value is
positive, but pixel_width is also enlarged when the value is negative.

And then in xterm.c:

  /* If first glyph of S has a left box line, start drawing the text
     of S to the right of that box line.  */
  if (s->face->box != FACE_NO_BOX
      && s->first_glyph->left_box_line_p)
    x = s->x + eabs (s->face->box_line_width);  <<<<<<<<<<<<<<<<<<<<
  else         ^^^^
    x = s->x;

Moreover, the commentary in dispextern.h explicitly says that the
left/right borders are not affected by the sign of the box width (note
the last sentence):

  /* Non-zero means characters in this face have a box of that
     thickness around them.  If this value is negative, its absolute
     value indicates the thickness, and the horizontal (top and
     bottom) borders of box are drawn inside of the character glyphs'
     area.  The vertical (left and right) borders of the box are drawn
     in the same way as when this value is positive.  */
  int box_line_width;

and the doc string in faces.el only mentions the top and bottom borders
of the box as being affected by negative values:

  `:box'

  VALUE specifies whether characters in FACE should have a box drawn
  around them.  If VALUE is nil, explicitly don't draw boxes.  If
  VALUE is t, draw a box with lines of width 1 in the foreground color
  of the face.  If VALUE is a string, the string must be a color name,
  and the box is drawn in that color with a line width of 1.  Otherwise,
  VALUE must be a property list of the form `(:line-width WIDTH
  :color COLOR :style STYLE)'.  If a keyword/value pair is missing from
  the property list, a default value will be used for the value, as
  specified below.  WIDTH specifies the width of the lines to draw; it
  defaults to 1.  If WIDTH is negative, the absolute value is the width
  of the lines, and draw top/bottom lines inside the characters area,
  not around it.

Only the ELisp manual makes it sound like both horizontal and vertical
borders are drawn inside the character cell:

    `(:line-width WIDTH :color COLOR :style STYLE)'
          This way you can explicitly specify all aspects of the box.
          The value WIDTH specifies the width of the lines to draw; it
          defaults to 1.  A negative width -N means to draw a line of
          width N that occupies the space of the underlying text, thus
          avoiding any increase in the character height or width.

I made a provisional change that behaves with left and right borders
like it does with horizontal ones, and it seems to work, at least with
character display (didn't text with images, image slices, composite
characters, etc.).  But I'd like to ask Handa-san (CC'ed), who wrote
the code for this feature (almost 12 years ago!), whether he might
remember why the code deliberately makes the left and right borders
behave differently from top and bottom ones.

To see the original changeset that introduced this feature, type

   bzr diff -r 36005..36010

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Stefan Monnier]

>      area.  The vertical (left and right) borders of the box are drawn
>      in the same way as when this value is positive.  */
>   int box_line_width;
[...]
> I made a provisional change that behaves with left and right borders
> like it does with horizontal ones, and it seems to work, at least with
> character display (didn't text with images, image slices, composite
> characters, etc.).  But I'd like to ask Handa-san (CC'ed), who wrote
> the code for this feature (almost 12 years ago!), whether he might
> remember why the code deliberately makes the left and right borders
> behave differently from top and bottom ones.

I'm curious as well.  The only think that comes to mind is that in most
fonts, there's usually some empty pixel-line(s) at the top and the
bottom, whereas there often't isn't any empty pixel-lines at all on the
left (and/or on the right) side.  So there's more risk of overwriting
useful pixels on the left&right than at top&bottom.


        Stefan

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Eli Zaretskii]

[Please don't remove the bug address from the CC list, we want all
this discussion to be archived in the bug tracker.]

> Date: Fri, 30 Nov 2012 01:45:30 +0100 (CET)
> From: "mario.giovinazzo@virgilio.it" <mario.giovinazzo@virgilio.it>
> Cc:  <monnier@iro.umontreal.ca>
> 
> The horizontal flickering has 2 cases:
> 
> 1) font-lock mode disabled.
> Current line has a single global box around current line 
> Moving cursor vertically produce 1 pixel flickering due to the left border 
> that adds 1 pixel.
> Moving cursor horizontal (along the same line) produce flickering crossing 
> parenthesis when paren-mode is enabled. 2 more pixels if the matching 
> one is in another line, 4 more pixels if on the same. This because it draw 
> a box on highlight parenthesis adding  2 pixels for box.

This is the same problem as with stretches of white space.  Its reason
is separate from the one that causes the entire line to shift one
pixel to the right when the line thickness is -1.

> 2) Font-lock-mode enabled.
> Current line seems to have a single global box but looking careful it has 
> many consecutive boxes, one for every font-lock-face.

Same as above: a different reason.

> Moving cursor vertical increase current line length of one pixel for box 
> (cab be very big) producing flickering.

This is done deliberately, as I show in the code snippets I posted.
We are discussing why was this done, and will see whether and how to
fix that after we understand the reason(s).

> This happens also in line without space and tab like this no sense line:
> void{(if(a<b)while(c=d)do)switch(e)

Same as above: a different reason.

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Kenichi Handa]

In article <jwvhao8z0y8.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > I made a provisional change that behaves with left and right borders
> > like it does with horizontal ones, and it seems to work, at least with
> > character display (didn't text with images, image slices, composite
> > characters, etc.).  But I'd like to ask Handa-san (CC'ed), who wrote
> > the code for this feature (almost 12 years ago!), whether he might
> > remember why the code deliberately makes the left and right borders
> > behave differently from top and bottom ones.

> I'm curious as well.  The only think that comes to mind is that in most
> fonts, there's usually some empty pixel-line(s) at the top and the
> bottom, whereas there often't isn't any empty pixel-lines at all on the
> left (and/or on the right) side.  So there's more risk of overwriting
> useful pixels on the left&right than at top&bottom.

Yes.  That's the reason of this asymmetry.  The original
intention of this feature was to make modeline occupy only
canonical line height even with the current style.

---
Kenichi Handa
handa@gnu.org

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Eli Zaretskii]

> From: Kenichi Handa <handa@gnu.org>
> Cc: eliz@gnu.org,  mario.giovinazzo@virgilio.it,  13011@debbugs.gnu.org
> Date: Mon, 03 Dec 2012 18:29:18 +0900
> 
> In article <jwvhao8z0y8.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > > I made a provisional change that behaves with left and right borders
> > > like it does with horizontal ones, and it seems to work, at least with
> > > character display (didn't text with images, image slices, composite
> > > characters, etc.).  But I'd like to ask Handa-san (CC'ed), who wrote
> > > the code for this feature (almost 12 years ago!), whether he might
> > > remember why the code deliberately makes the left and right borders
> > > behave differently from top and bottom ones.
> 
> > I'm curious as well.  The only think that comes to mind is that in most
> > fonts, there's usually some empty pixel-line(s) at the top and the
> > bottom, whereas there often't isn't any empty pixel-lines at all on the
> > left (and/or on the right) side.  So there's more risk of overwriting
> > useful pixels on the left&right than at top&bottom.
> 
> Yes.  That's the reason of this asymmetry.  The original
> intention of this feature was to make modeline occupy only
> canonical line height even with the current style.

So does anyone object to lifting this limitation, even though it might
degrade the quality of displaying the first and the last characters in
the run of characters that have the box face?

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Drew Adams]

> So does anyone object to lifting this limitation, even though it might
> degrade the quality of displaying the first and the last characters in
> the run of characters that have the box face?

It's not obvious to me what that means for users.  Why don't you post before and
after images so we can judge?

Or if this affects something other than the visual appearance, so images won't
show the difference, please explain what this will change for users.

And what is the tradeoff for this "degrading"?  What are users gaining by this
sacrifice?

Thx.

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <mario.giovinazzo@virgilio.it>, <13011@debbugs.gnu.org>
> Date: Mon, 3 Dec 2012 08:44:39 -0800
> 
> > So does anyone object to lifting this limitation, even though it might
> > degrade the quality of displaying the first and the last characters in
> > the run of characters that have the box face?
> 
> It's not obvious to me what that means for users.  Why don't you post before and
> after images so we can judge?

The examples I have don't show any significant effect.  But I can
explain how you can experiment and see yourself.

Evaluate this:

  (custom-set-variables '(global-hl-line-mode t))
  (custom-set-faces '(hl-line ((t (:box (:line-width -1 :color "gray50"))))))

Then visit any files you like, and move cursor vertically.  You will
see that the text of the current line moves 1 pixel to the right when
you move cursor into that line.  This 1-pixel move is to leave enough
space for the 1-pixel border of the box on the left side of the line,
so that the first character is displayed with all its pixels visible.

The change that is being requested here is to prevent that 1-pixel
shift, which means the box border will be drawn ON the left-most
character, obscuring some of its pixels on the left.

For a more prominent effect, replace -1 above with -4.

> And what is the tradeoff for this "degrading"?  What are users gaining by this
> sacrifice?

The gain is that, with the above settings in effect, the text of a
line will not shift to the left when cursor moves into that line.

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Drew Adams]

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

Thanks for the explanation and experiment.

Apart from that example, I imagine that this also affects any text that uses a
face that has a box with a negative :line-width.  Is that correct?

If so, that will impact faces that I use.  And IIUC, it means that the text
displayed in the boxed face will have its first and last chars partly obscured
by the box border.  Is that right?

If so, I would object.  Most uses of such faces are not like the hl-line
example, where there is a lot of text so faced.  Most uses (most of mine, at
least) are short bits of text, such as words.  And for these uses it is more
important that the first and last chars be displayed clearly (entirely).  I even
use a boxed face for some single characters (including using it for face
`escape-glyph').

I guess I would not object to making such a change for situations where the
chars to be partly obscured are whitespace only.  But I do object to overwriting
typical chars such as those with word or symbol syntax.

At least I think I object.  This change seems like regression, not improvement.

Attached is a screenshot from emacs -Q.  IIUC, you are saying that instead of
the text shown in mode-line-highlight face being slightly misaligned wrt the
other text, so that the `a' is not partly obscured by the left box border, the
text would be aligned with the others and the boxed `a' would be partly obscured
by the left box border.

OK, so by default the boxing here is 2, not -2, but if you set it to -2 that
does not change the argument/situation, AFAICT.  Likewise, if I use 2 or 4 in
your example test I see the same effect of the text moving slightly to the right
as it is highlighted.  Is the proposed change only a "fix" for negative values
or does it affect also positive values?

What is the motivation for this change?  Is it only in order to have fixed-width
text be better aligned? To me, that is less important than for the text to be
clearly visible - esp. for single words etc.

The boxing is supposed to make the text stand out, not make it harder to read.
This change seems to go against the usefulness of boxed faces.

Would it be possible for this to be a user choice?  E.g., could this perhaps be
added to `box' as another attribute, in addition to width, color, and style?  If
so, that would perhaps be a solution everyone could live with.  If so, I would
suggest that the default be the current behavior (clear text, even if slightly
misaligned).

Just one opinion, of course.

[-- Attachment #2: throw-boxed-face.png --]
[-- Type: image/png, Size: 27111 bytes --]

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <handa@gnu.org>, <mario.giovinazzo@virgilio.it>, <13011@debbugs.gnu.org>
> Date: Mon, 3 Dec 2012 10:41:52 -0800
> 
> Apart from that example, I imagine that this also affects any text that uses a
> face that has a box with a negative :line-width.  Is that correct?

Yes.

> If so, that will impact faces that I use.  And IIUC, it means that the text
> displayed in the boxed face will have its first and last chars partly obscured
> by the box border.  Is that right?

Right.

> I guess I would not object to making such a change for situations where the
> chars to be partly obscured are whitespace only.  But I do object to overwriting
> typical chars such as those with word or symbol syntax.

How about doing that only for 1-pixel borders?

> Attached is a screenshot from emacs -Q.  IIUC, you are saying that instead of
> the text shown in mode-line-highlight face being slightly misaligned wrt the
> other text, so that the `a' is not partly obscured by the left box border, the
> text would be aligned with the others and the boxed `a' would be partly obscured
> by the left box border.

Yes, that's it.

> Is the proposed change only a "fix" for negative values or does it
> affect also positive values?

Only negative values will be affected.

> What is the motivation for this change?

See the beginning of this bug report: when a box face is used for
hl-line mode, moving cursor vertically produces an annoying shift of
the lines as the cursor moves through them.

> Would it be possible for this to be a user choice?

It's possible.

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Drew Adams]

> > I guess I would not object to making such a change for 
> > situations where the chars to be partly obscured are
> > whitespace only.  But I do object to overwriting
> > typical chars such as those with word or symbol syntax.
> 
> How about doing that only for 1-pixel borders?

Doing what?  Making the change or making the change only for whitespace?

Either way, I don't see why the width would make a difference.  What is the
rationale?

> Yes, that's it.
> 
> > Is the proposed change only a "fix" for negative values or does it
> > affect also positive values?
> 
> Only negative values will be affected.

Why?  The same jerkiness from alignment change occurs for both positive and
negative, AFAICT.

> > What is the motivation for this change?
> 
> See the beginning of this bug report: when a box face is used for
> hl-line mode, moving cursor vertically produces an annoying shift of
> the lines as the cursor moves through them.

Try it with a positive width - same thing.

Again, hl-line boxing is hardly typical, I think (again, not at all typical for
my use, at least).  More typical is boxing a word or two.

And one could even argue that that jerkiness was a feature (!) for hl-line mode.
Anyway, hl-line mode should not be important to this - boxing is for many more
use cases than that.

> > Would it be possible for this to be a user choice?
> 
> It's possible.

That I would be in favor of.  Simply changing the behavior/appearance without
user choice, I would be against.  Again, just one opinion, of course.

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <handa@gnu.org>, <mario.giovinazzo@virgilio.it>, <13011@debbugs.gnu.org>
> Date: Mon, 3 Dec 2012 11:09:13 -0800
> 
> > > I guess I would not object to making such a change for 
> > > situations where the chars to be partly obscured are
> > > whitespace only.  But I do object to overwriting
> > > typical chars such as those with word or symbol syntax.
> > 
> > How about doing that only for 1-pixel borders?
> 
> Doing what?  Making the change or making the change only for whitespace?

The former.

> Either way, I don't see why the width would make a difference.  What is the
> rationale?

1 pixel runs a very small risk of obscuring the character in the same
cell.

> > > Is the proposed change only a "fix" for negative values or does it
> > > affect also positive values?
> > 
> > Only negative values will be affected.
> 
> Why?  The same jerkiness from alignment change occurs for both positive and
> negative, AFAICT.

Yes, that's true.  But negative thickness does not enlarge the
vertical dimensions of character cells, whereas it does enlarge the
horizontal dimensions.  The request is to remove this asymmetry, as
the ELisp manual seems to promise:

    `(:line-width WIDTH :color COLOR :style STYLE)'
          This way you can explicitly specify all aspects of the box.
          The value WIDTH specifies the width of the lines to draw; it
          defaults to 1.  A negative width -N means to draw a line of
          width N that occupies the space of the underlying text, thus
          avoiding any increase in the character height or width.

But in fact, character width _is_ increased.

> > > What is the motivation for this change?
> > 
> > See the beginning of this bug report: when a box face is used for
> > hl-line mode, moving cursor vertically produces an annoying shift of
> > the lines as the cursor moves through them.
> 
> Try it with a positive width - same thing.

Yes, but the above says negative values should not have that effect.

> > > Would it be possible for this to be a user choice?
> > 
> > It's possible.
> 
> That I would be in favor of.  Simply changing the behavior/appearance without
> user choice, I would be against.  Again, just one opinion, of course.

What about using thickness of zero for drawing a 1-pixel border inside
of the character cell?

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Stefan Monnier]

>> That I would be in favor of.  Simply changing the behavior/appearance
>> without user choice, I would be against.  Again, just one opinion,
>> of course.
> What about using thickness of zero for drawing a 1-pixel border inside
> of the character cell?

I'd first like to hear why Drew uses negative thickness (and yet
wants it to be positive horizontally).

Also that's a hack, I can totally imagine someone using a very
high-resolution screen with largish fonts (measured in pixels) wanting
a -3 thickness around his hl-line box.


        Stefan

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Drew Adams]

> > > How about doing that only for 1-pixel borders?
> > 
> > Doing what?  Making the change or making the change only 
> > for whitespace?
> 
> The former.
> 
> > Either way, I don't see why the width would make a 
> > difference.  What is the rationale?
> 
> 1 pixel runs a very small risk of obscuring the character in the same
> cell.

I see.  Would probably need to see the effect to judge it.

> > > when a box face is used for
> > > hl-line mode, moving cursor vertically produces an 
> > > annoying shift of the lines as the cursor moves through them.
> > 
> > Try it with a positive width - same thing.
> 
> Yes, but the above says negative values should not have that effect.

Hm.  Is the problem the annoyance of the jerkiness or the fact that the doc does
not describe that jerkiness in the case of a negative value?

I would expect (imagine) that it is the jerkiness that is the problem.

> > > > Would it be possible for this to be a user choice?
> > > 
> > > It's possible.
> > 
> > That I would be in favor of.  Simply changing the 
> > behavior/appearance without user choice, I would be against.
> > Again, just one opinion, of course.
> 
> What about using thickness of zero for drawing a 1-pixel border inside
> of the character cell?

If the problem is only for a 1-pixel inside border, then perhaps that would be
the answer.  If the problem is for any number of pixels or for both inside and
outside borders (or both), then it would be appropriate to add a separate
attribute, independent from the width.

As far as I am concerned, if the only change is to add a new 0-width behavior
that produces a 1-pixel inside border that partially obscures the text, I would
have no problem with that.  In that case, IIUC, the existing attributes and
their values all would do the same thing they do now.  Currently, AFAICT, a
value of 0 means no box is shown.

On the other hand, any (existing or future) code that increments/decrements the
width would then be confronted with an anomaly, and if it expected a value of 0
to remove the box in that context, that would no longer work.

A new, independent attribute would be cleaner, but perhaps it is more difficult
to implement.

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Drew Adams]

> I'd first like to hear why Drew uses negative thickness (and yet
> wants it to be positive horizontally).

IIRC, I use negative thickness mainly so the height is not increased.  I
typically do not care so much about the width (length) of a boxed word.  But I
do not want added border pixels to change the line height etc.

It really doesn't matter why or when or whether I use negative thickness.  The
question is which of these is the case:

1. The box left & right borders should be allowed to bump into the text that is
boxed.

2. Instead, the box should be shifted to the right because we have added extra
pixel(s) for the box border to the left of the text.

3. We should let users decide between #1 and #2.  For example, using a new box
attribute.

It's really not about me.  It's somewhat about how users use this today, and
what they expect.  But it's also about how users might use it (whether they do
or do not today) and what a user might expect from it.

> Also that's a hack, I can totally imagine someone using a very
> high-resolution screen with largish fonts (measured in pixels) wanting
> a -3 thickness around his hl-line box.

Me too.

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Kenichi Handa]

In article <83ip8jrt7p.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> So does anyone object to lifting this limitation, even though it might
> degrade the quality of displaying the first and the last characters in
> the run of characters that have the box face?

I don't object to add a feature of drawing box edges inside
the left and right of characters, but I think it is better
to keep the current asymmetric feature too.

How about allowing (VWIDTH . HWIDTH) as a value of :line-width?

---
Kenichi Handa
handa@gnu.org

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Eli Zaretskii]

> Date: Fri, 30 Nov 2012 10:13:30 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 13011@debbugs.gnu.org
> 
> > Date: Fri, 30 Nov 2012 01:45:30 +0100 (CET)
> > From: "mario.giovinazzo@virgilio.it" <mario.giovinazzo@virgilio.it>
> > Cc:  <monnier@iro.umontreal.ca>
> > 
> > The horizontal flickering has 2 cases:
> > 
> > 1) font-lock mode disabled.
> > Current line has a single global box around current line 
> > Moving cursor vertically produce 1 pixel flickering due to the left border 
> > that adds 1 pixel.
> > Moving cursor horizontal (along the same line) produce flickering crossing 
> > parenthesis when paren-mode is enabled. 2 more pixels if the matching 
> > one is in another line, 4 more pixels if on the same. This because it draw 
> > a box on highlight parenthesis adding  2 pixels for box.
> 
> This is the same problem as with stretches of white space.  Its reason
> is separate from the one that causes the entire line to shift one
> pixel to the right when the line thickness is -1.
> 
> > 2) Font-lock-mode enabled.
> > Current line seems to have a single global box but looking careful it has 
> > many consecutive boxes, one for every font-lock-face.
> 
> Same as above: a different reason.

This part of the bug is now fixed in revision 111191 on the trunk.

For the rest of the bug I'm awaiting the decision wrt how to treat
vertical box borders whose width is negative.

bug#13011: 24.2; Text flickering moving cursor with box around text enabled

[Stefan Monnier]

> For the rest of the bug I'm awaiting the decision wrt how to treat
> vertical box borders whose width is negative.

I think the suggestion to support a new box width specification of the
form (WIDTH . HEIGHT) is the best option.  So for backward
compatibility -N will mean (N . -N) and if someone wants "all inside, no
flicker" she can use (-N . -N).


        Stefan