From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#13011: 24.2; Text flickering moving cursor with box around text enabled Date: Thu, 29 Nov 2012 18:42:47 +0200 Message-ID: <83vccouzqw.fsf@gnu.org> References: <793025287.20121127114224@virgilio.it> <838v9nx7q1.fsf@gnu.org> <1205106717.20121128161453@virgilio.it> <83a9u1wr3k.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1354207402 28024 80.91.229.3 (29 Nov 2012 16:43:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Nov 2012 16:43:22 +0000 (UTC) Cc: 13011@debbugs.gnu.org, mario.giovinazzo@virgilio.it To: Stefan Monnier , Kenichi Handa Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 29 17:43:32 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Te7Cw-0005Po-HW for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Nov 2012 17:43:26 +0100 Original-Received: from localhost ([::1]:34510 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Te7Cl-0007CO-A6 for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Nov 2012 11:43:15 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:58893) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Te7Cd-0007At-87 for bug-gnu-emacs@gnu.org; Thu, 29 Nov 2012 11:43:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Te7CY-0004ju-7j for bug-gnu-emacs@gnu.org; Thu, 29 Nov 2012 11:43:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35147) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Te7CY-0004jq-25 for bug-gnu-emacs@gnu.org; Thu, 29 Nov 2012 11:43:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Te7EU-0004F2-AA for bug-gnu-emacs@gnu.org; Thu, 29 Nov 2012 11:45:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 Nov 2012 16:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13011 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13011-submit@debbugs.gnu.org id=B13011.135420747316253 (code B ref 13011); Thu, 29 Nov 2012 16:45:02 +0000 Original-Received: (at 13011) by debbugs.gnu.org; 29 Nov 2012 16:44:33 +0000 Original-Received: from localhost ([127.0.0.1]:45398 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te7E1-0004E6-CA for submit@debbugs.gnu.org; Thu, 29 Nov 2012 11:44:33 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:64773) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te7Dx-0004Du-K2 for 13011@debbugs.gnu.org; Thu, 29 Nov 2012 11:44:32 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0ME900600CZ1V100@a-mtaout20.012.net.il> for 13011@debbugs.gnu.org; Thu, 29 Nov 2012 18:42:27 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ME90061XD2Q57G0@a-mtaout20.012.net.il>; Thu, 29 Nov 2012 18:42:26 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:67584 Archived-At: > From: Stefan Monnier > Cc: mario giovinazzo , 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