GNU bug report logs - #13011
24.2; Text flickering moving cursor with box around text enabled

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: handa <at> gnu.org, 13011 <at> debbugs.gnu.org, mario.giovinazzo <at> virgilio.it
Subject: Re: bug#13011: 24.2;
	Text flickering moving cursor with box around text enabled
Date: Mon, 03 Dec 2012 23:04:40 +0200

> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <handa <at> gnu.org>, <mario.giovinazzo <at> virgilio.it>, <13011 <at> 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?

Previous Next

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