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

["Drew Adams" <drew.adams@oracle.com>]

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