From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: linum.el: problem (bug ?) fix and improvement Date: Thu, 12 May 2011 10:58:58 -0300 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1305209354 11808 80.91.229.12 (12 May 2011 14:09:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 12 May 2011 14:09:14 +0000 (UTC) Cc: emacs-devel@gnu.org To: Toru TSUNEYOSHI Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 12 16:09:10 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QKWZf-0003Xf-PG for ged-emacs-devel@m.gmane.org; Thu, 12 May 2011 16:09:08 +0200 Original-Received: from localhost ([::1]:60394 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QKWZf-0007tV-8N for ged-emacs-devel@m.gmane.org; Thu, 12 May 2011 10:09:07 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:48439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QKWZc-0007tD-7I for emacs-devel@gnu.org; Thu, 12 May 2011 10:09:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QKWZb-0004Zc-2r for emacs-devel@gnu.org; Thu, 12 May 2011 10:09:04 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:43682) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QKWZa-0004ZY-W9 for emacs-devel@gnu.org; Thu, 12 May 2011 10:09:03 -0400 Original-Received: from 121-249-126-200.fibertel.com.ar ([200.126.249.121]:20276 helo=ceviche.home) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1QKWZa-00033f-Jm; Thu, 12 May 2011 10:09:02 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 9FF8166152; Thu, 12 May 2011 10:58:58 -0300 (ART) In-Reply-To: (Toru TSUNEYOSHI's message of "Sat, 7 May 2011 23:50:28 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:139325 Archived-At: > It is displaying a wrong line number when there is an invisible line. > (I don't know the problem is a bug clearly, but it is trouble to me.) > Example: > ==================================================================== > In buffer (linum-mode is enabled). > 1 abc > 2 def > 3 ghi > 4 jkl > Make the 2nd line ("def\n") invisible (by `facemenu-set-invisible'). > 1 abc > 2 ghi <= wrong > 4 jkl > ==================================================================== Actually, it's even more interesting: the line number displayed in front of `ghi' is sometimes 2 and sometimes 3, changing "at random" while editing that line or when mouse-1 clicking in that window. IIUC the problem is that Emacs "displays" both margin properties: the one from the `def' line and the one from the `ghi' line, and since in reality both can't be displayed it ends up choosing one of the two and depending on how the redisplay happens it picks one or the other. What we'd like here is for the redisplay to ignore the margin property placed on invisible text. This boils down to making Emacs ignore `before-string' properties placed at the beginning of invisible text. I don't think it's always right to ignore them, tho. Maybe a good way to make it work is to rely on the stickiness of the `before-string' property: by making it rear-sticky (i.e. making the overlay's front-advance non-nil) we'd be stating explicitly that the property belongs to the hidden text and should hence be hidden as well. > I fixed the problem. Alternatively we can let linum do the hard work, like your patch does, of course. > Additionally, I improved about invisible buffer string. > the attached file: "linum-mode.el.2.diff" > (including the above bug fix.) > (1) Indicating invisible line(s) by an underlined line number > when the following line(s) is/are invisible. > ==================================================================== > _1_ abc <= underline > 3 ghi > 4 jkl > ==================================================================== > (2) Indicating partial invisible string by a `strike-through' line > number when the line has partial invisible string. > ==================================================================== > _1_ abc > 3 ghi > 4 jkl > Make the 3rd line ("hi") invisible partially. > _1_ abc > -3- g <= strike-through > 4 jkl > Make the 1st line ("ab") invisible partially. > -_1_- c <= underline and strike-through > -3- g > 4 jkl > ==================================================================== Could you describe the context in which you've needed such a thing? The strike-through info seems to be redundant with the fact that the next line number is not the immediate successor, and I wonder when you'd be so interested in knowing if there's some hidden text on a particular line. Stefan