bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Drew Adams
Subject: bug#13011: 24.2; Text flickering moving cursor with box around text enabled
Date: Mon, 3 Dec 2012 10:41:52 -0800

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: throw-boxed-face.png
Description: PNG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]