From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#13011: 24.2; Text flickering moving cursor with box around text enabled Date: Mon, 3 Dec 2012 14:21:22 -0800 Message-ID: <1C7A5D5E5BD847599E944D61E07853B5@us.oracle.com> 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> <83wqwyrgnr.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1354573309 3941 80.91.229.3 (3 Dec 2012 22:21:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Dec 2012 22:21:49 +0000 (UTC) Cc: 13011@debbugs.gnu.org, mario.giovinazzo@virgilio.it To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 03 23:22:02 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 1TfeOh-0007w8-Fl for geb-bug-gnu-emacs@m.gmane.org; Mon, 03 Dec 2012 23:21:55 +0100 Original-Received: from localhost ([::1]:56255 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfeOV-0004SY-LX for geb-bug-gnu-emacs@m.gmane.org; Mon, 03 Dec 2012 17:21:43 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:36247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfeOS-0004OD-4F for bug-gnu-emacs@gnu.org; Mon, 03 Dec 2012 17:21:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TfeOQ-0004u0-Uu for bug-gnu-emacs@gnu.org; Mon, 03 Dec 2012 17:21:40 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41815) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfeOQ-0004tR-Hi for bug-gnu-emacs@gnu.org; Mon, 03 Dec 2012 17:21:38 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TfeQk-0002z3-Lm for bug-gnu-emacs@gnu.org; Mon, 03 Dec 2012 17:24:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 03 Dec 2012 22:24: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.135457343411446 (code B ref 13011); Mon, 03 Dec 2012 22:24:02 +0000 Original-Received: (at 13011) by debbugs.gnu.org; 3 Dec 2012 22:23:54 +0000 Original-Received: from localhost ([127.0.0.1]:52065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TfeQc-0002yZ-65 for submit@debbugs.gnu.org; Mon, 03 Dec 2012 17:23:54 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:26889) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TfeQZ-0002yP-BV for 13011@debbugs.gnu.org; Mon, 03 Dec 2012 17:23:52 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qB3MLPEn026955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Dec 2012 22:21:26 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qB3MLOA7013052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2012 22:21:24 GMT Original-Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qB3MLOge032136; Mon, 3 Dec 2012 16:21:24 -0600 Original-Received: from dradamslap1 (/130.35.178.8) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 03 Dec 2012 14:21:24 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83wqwyrgnr.fsf@gnu.org> Thread-Index: Ac3RmdNerB8DL5AiTi2FYMAXpsO0CwACUyPA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: acsinet22.oracle.com [141.146.126.238] 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:67874 Archived-At: > > > 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.