unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Eli Zaretskii'" <eliz@gnu.org>
Cc: 13011@debbugs.gnu.org, mario.giovinazzo@virgilio.it
Subject: bug#13011: 24.2; Text flickering moving cursor with box around text enabled
Date: Mon, 3 Dec 2012 10:41:52 -0800	[thread overview]
Message-ID: <08681D95624F4B7AAD11488179A56F59@us.oracle.com> (raw)
In-Reply-To: <83624jrot8.fsf@gnu.org>

[-- 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 --]

  reply	other threads:[~2012-12-03 18:41 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-27 10:42 bug#13011: 24.2; Text flickering moving cursor with box around text enabled mario giovinazzo
2012-11-27 17:43 ` Eli Zaretskii
     [not found]   ` <1205106717.20121128161453@virgilio.it>
2012-11-28 17:54     ` Eli Zaretskii
2012-11-29  4:39       ` Stefan Monnier
2012-11-29 16:42         ` Eli Zaretskii
2012-11-29 19:06           ` Stefan Monnier
2012-12-03  9:29             ` Kenichi Handa
2012-12-03 16:33               ` Eli Zaretskii
2012-12-03 16:44                 ` Drew Adams
2012-12-03 18:08                   ` Eli Zaretskii
2012-12-03 18:41                     ` Drew Adams [this message]
2012-12-03 18:56                       ` Eli Zaretskii
2012-12-03 19:09                         ` Drew Adams
2012-12-03 21:04                           ` Eli Zaretskii
2012-12-03 22:20                             ` Stefan Monnier
2012-12-03 22:51                               ` Drew Adams
2012-12-03 22:21                             ` Drew Adams
2012-12-04  0:13                 ` Kenichi Handa
2018-01-19 18:08 ` bug#13011: Patch: " Alexandre Adolphe
2019-08-10 21:21 ` bug#13011: [PATCH] " Alexandre Adolphe
2019-08-20 13:44   ` Noam Postavsky
2019-10-11 23:31     ` Alexandre Adolphe
2019-10-15  7:40     ` Stefan Kangas
2020-04-01 22:05   ` Noam Postavsky
2020-04-03  1:27   ` Dmitry Gutov
     [not found] <13b4ec68081.mario.giovinazzo@virgilio.it>
2012-11-30  8:13 ` bug#13011: 24.2; " Eli Zaretskii
2012-12-11 12:26   ` Eli Zaretskii
2012-12-11 14:01     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=08681D95624F4B7AAD11488179A56F59@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=13011@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=mario.giovinazzo@virgilio.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).