* bug#13011: 24.2; Text flickering moving cursor with box around text enabled [not found] <13b4ec68081.mario.giovinazzo@virgilio.it> @ 2012-11-30 8:13 ` Eli Zaretskii 2012-12-11 12:26 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2012-11-30 8:13 UTC (permalink / raw) To: mario.giovinazzo@virgilio.it; +Cc: 13011 [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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 2012-11-30 8:13 ` bug#13011: 24.2; Text flickering moving cursor with box around text enabled Eli Zaretskii @ 2012-12-11 12:26 ` Eli Zaretskii 2012-12-11 14:01 ` Stefan Monnier 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2012-12-11 12:26 UTC (permalink / raw) To: mario.giovinazzo; +Cc: 13011 > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 2012-12-11 12:26 ` Eli Zaretskii @ 2012-12-11 14:01 ` Stefan Monnier 0 siblings, 0 replies; 21+ messages in thread From: Stefan Monnier @ 2012-12-11 14:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13011, mario.giovinazzo > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled @ 2012-11-27 10:42 mario giovinazzo 2012-11-27 17:43 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: mario giovinazzo @ 2012-11-27 10:42 UTC (permalink / raw) To: 13011 *** 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) ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 2012-11-27 10:42 mario giovinazzo @ 2012-11-27 17:43 ` Eli Zaretskii [not found] ` <1205106717.20121128161453@virgilio.it> 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2012-11-27 17:43 UTC (permalink / raw) To: mario giovinazzo; +Cc: 13011 > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <1205106717.20121128161453@virgilio.it>]
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled [not found] ` <1205106717.20121128161453@virgilio.it> @ 2012-11-28 17:54 ` Eli Zaretskii 2012-11-29 4:39 ` Stefan Monnier 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2012-11-28 17:54 UTC (permalink / raw) To: mario giovinazzo; +Cc: 13011 [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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 2012-11-28 17:54 ` Eli Zaretskii @ 2012-11-29 4:39 ` Stefan Monnier 2012-11-29 16:42 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Stefan Monnier @ 2012-11-29 4:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13011, mario giovinazzo >> (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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 2012-11-29 4:39 ` Stefan Monnier @ 2012-11-29 16:42 ` Eli Zaretskii 2012-11-29 19:06 ` Stefan Monnier 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2012-11-29 16:42 UTC (permalink / raw) To: Stefan Monnier, Kenichi Handa; +Cc: 13011, mario.giovinazzo > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 2012-11-29 16:42 ` Eli Zaretskii @ 2012-11-29 19:06 ` Stefan Monnier 2012-12-03 9:29 ` Kenichi Handa 0 siblings, 1 reply; 21+ messages in thread From: Stefan Monnier @ 2012-11-29 19:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13011, mario.giovinazzo > 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 2012-11-29 19:06 ` Stefan Monnier @ 2012-12-03 9:29 ` Kenichi Handa 2012-12-03 16:33 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Kenichi Handa @ 2012-12-03 9:29 UTC (permalink / raw) To: Stefan Monnier; +Cc: 13011, mario.giovinazzo 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 2012-12-03 9:29 ` Kenichi Handa @ 2012-12-03 16:33 ` Eli Zaretskii 2012-12-03 16:44 ` Drew Adams 2012-12-04 0:13 ` Kenichi Handa 0 siblings, 2 replies; 21+ messages in thread From: Eli Zaretskii @ 2012-12-03 16:33 UTC (permalink / raw) To: Kenichi Handa; +Cc: mario.giovinazzo, 13011 > 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? ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 2012-12-03 16:33 ` Eli Zaretskii @ 2012-12-03 16:44 ` Drew Adams 2012-12-03 18:08 ` Eli Zaretskii 2012-12-04 0:13 ` Kenichi Handa 1 sibling, 1 reply; 21+ messages in thread From: Drew Adams @ 2012-12-03 16:44 UTC (permalink / raw) To: 'Eli Zaretskii', 'Kenichi Handa'; +Cc: 13011, mario.giovinazzo > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 2012-12-03 16:44 ` Drew Adams @ 2012-12-03 18:08 ` Eli Zaretskii 2012-12-03 18:41 ` Drew Adams 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2012-12-03 18:08 UTC (permalink / raw) To: Drew Adams; +Cc: 13011, mario.giovinazzo > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 2012-12-03 18:08 ` Eli Zaretskii @ 2012-12-03 18:41 ` Drew Adams 2012-12-03 18:56 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Drew Adams @ 2012-12-03 18:41 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: 13011, mario.giovinazzo [-- 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 --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 2012-12-03 18:41 ` Drew Adams @ 2012-12-03 18:56 ` Eli Zaretskii 2012-12-03 19:09 ` Drew Adams 0 siblings, 1 reply; 21+ messages in thread From: Eli Zaretskii @ 2012-12-03 18:56 UTC (permalink / raw) To: Drew Adams; +Cc: 13011, mario.giovinazzo > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 2012-12-03 18:56 ` Eli Zaretskii @ 2012-12-03 19:09 ` Drew Adams 2012-12-03 21:04 ` Eli Zaretskii 0 siblings, 1 reply; 21+ messages in thread From: Drew Adams @ 2012-12-03 19:09 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: 13011, mario.giovinazzo > > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 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:21 ` Drew Adams 0 siblings, 2 replies; 21+ messages in thread From: Eli Zaretskii @ 2012-12-03 21:04 UTC (permalink / raw) To: Drew Adams; +Cc: 13011, mario.giovinazzo > 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? ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 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 1 sibling, 1 reply; 21+ messages in thread From: Stefan Monnier @ 2012-12-03 22:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13011, mario.giovinazzo >> 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 2012-12-03 22:20 ` Stefan Monnier @ 2012-12-03 22:51 ` Drew Adams 0 siblings, 0 replies; 21+ messages in thread From: Drew Adams @ 2012-12-03 22:51 UTC (permalink / raw) To: 'Stefan Monnier', 'Eli Zaretskii'; +Cc: 13011, mario.giovinazzo > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 2012-12-03 21:04 ` Eli Zaretskii 2012-12-03 22:20 ` Stefan Monnier @ 2012-12-03 22:21 ` Drew Adams 1 sibling, 0 replies; 21+ messages in thread From: Drew Adams @ 2012-12-03 22:21 UTC (permalink / raw) To: 'Eli Zaretskii'; +Cc: 13011, mario.giovinazzo > > > 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. ^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#13011: 24.2; Text flickering moving cursor with box around text enabled 2012-12-03 16:33 ` Eli Zaretskii 2012-12-03 16:44 ` Drew Adams @ 2012-12-04 0:13 ` Kenichi Handa 1 sibling, 0 replies; 21+ messages in thread From: Kenichi Handa @ 2012-12-04 0:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: mario.giovinazzo, 13011 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 ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2012-12-11 14:01 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <13b4ec68081.mario.giovinazzo@virgilio.it> 2012-11-30 8:13 ` bug#13011: 24.2; Text flickering moving cursor with box around text enabled Eli Zaretskii 2012-12-11 12:26 ` Eli Zaretskii 2012-12-11 14:01 ` Stefan Monnier 2012-11-27 10:42 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 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
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.