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: Mon, 03 Dec 2012 23:04:40 +0200 Message-ID: <83wqwyrgnr.fsf@gnu.org> References: <87mwxvlc0h.fsf@gnu.org> <83ip8jrt7p.fsf@gnu.org> <562186ED35E84B3086ABFBDAB2F056FD@us.oracle.com> <83624jrot8.fsf@gnu.org> <08681D95624F4B7AAD11488179A56F59@us.oracle.com> <831uf7rmkt.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1354568749 27663 80.91.229.3 (3 Dec 2012 21:05:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Dec 2012 21:05:49 +0000 (UTC) Cc: 13011@debbugs.gnu.org, mario.giovinazzo@virgilio.it To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 03 22:06:01 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 1TfdDF-0004EU-Bf for geb-bug-gnu-emacs@m.gmane.org; Mon, 03 Dec 2012 22:06:01 +0100 Original-Received: from localhost ([::1]:49418 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfdD3-0004hq-Ay for geb-bug-gnu-emacs@m.gmane.org; Mon, 03 Dec 2012 16:05:49 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:58288) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfdCw-0004hh-Gq for bug-gnu-emacs@gnu.org; Mon, 03 Dec 2012 16:05:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TfdCs-00058g-57 for bug-gnu-emacs@gnu.org; Mon, 03 Dec 2012 16:05:42 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41749) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfdCs-00058c-18 for bug-gnu-emacs@gnu.org; Mon, 03 Dec 2012 16:05:38 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TfdFB-0001Cx-RY for bug-gnu-emacs@gnu.org; Mon, 03 Dec 2012 16:08:01 -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: Mon, 03 Dec 2012 21:08:01 +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.13545688334583 (code B ref 13011); Mon, 03 Dec 2012 21:08:01 +0000 Original-Received: (at 13011) by debbugs.gnu.org; 3 Dec 2012 21:07:13 +0000 Original-Received: from localhost ([127.0.0.1]:52000 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TfdEO-0001Bs-KS for submit@debbugs.gnu.org; Mon, 03 Dec 2012 16:07:12 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:45367) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TfdEL-0001Bk-T5 for 13011@debbugs.gnu.org; Mon, 03 Dec 2012 16:07:11 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MEH00K003I40U00@a-mtaout23.012.net.il> for 13011@debbugs.gnu.org; Mon, 03 Dec 2012 23:04:44 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MEH00J8D3VVSS30@a-mtaout23.012.net.il>; Mon, 03 Dec 2012 23:04:44 +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:67870 Archived-At: > From: "Drew Adams" > Cc: , , <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?