From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Toru TSUNEYOSHI Newsgroups: gmane.emacs.devel Subject: Re: linum.el: problem (bug ?) fix and improvement Date: Sat, 14 May 2011 10:53:13 +0900 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1305338043 14552 80.91.229.12 (14 May 2011 01:54:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 14 May 2011 01:54:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: monnier@iro.umontreal.ca Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 14 03:53:58 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 1QL43K-0008Rk-7P for ged-emacs-devel@m.gmane.org; Sat, 14 May 2011 03:53:58 +0200 Original-Received: from localhost ([::1]:57233 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QL43J-0004tl-G1 for ged-emacs-devel@m.gmane.org; Fri, 13 May 2011 21:53:57 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:51422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QL43H-0004tg-CC for emacs-devel@gnu.org; Fri, 13 May 2011 21:53:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QL43G-00053J-AR for emacs-devel@gnu.org; Fri, 13 May 2011 21:53:55 -0400 Original-Received: from blu0-omc4-s34.blu0.hotmail.com ([65.55.111.173]:14518) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QL43G-00053F-8W for emacs-devel@gnu.org; Fri, 13 May 2011 21:53:54 -0400 Original-Received: from BLU0-SMTP106 ([65.55.111.135]) by blu0-omc4-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 May 2011 18:53:54 -0700 X-Originating-IP: [210.253.252.45] X-Originating-Email: [t_tuneyosi@hotmail.com] Original-Received: from localhost ([210.253.252.45]) by BLU0-SMTP106.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 May 2011 18:53:50 -0700 In-Reply-To: X-Mailer: Mew version 6.3.50 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) X-OriginalArrivalTime: 14 May 2011 01:53:52.0178 (UTC) FILETIME=[C6712120:01CC11D9] X-detected-operating-system: by eggs.gnu.org: Windows 2000 SP4, XP SP1+ X-Received-From: 65.55.111.173 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:139386 Archived-At: From: Stefan Monnier Subject: Re: linum.el: problem (bug ?) fix and improvement Date: Fri, 13 May 2011 13:26:04 -0300 Message-ID: >>>> I have a case that I make unimportant text invisible temporarily, to >>>> know only important information. >>> Any reason why you don't use the ellipsis (see buffer-invisibility-spec)? >> I can't check the ellipsis easily, if `truncate-lines' is non-nil and >> the ellipsis text is truncated. > > Indeed, that can be a problem. Tho, if you make "foo\n" (as you seem to > do) invisible, the "..." will end up at the beginning of the line rather > than its end. So it'll probably be too visible rather than not enough. > Yes. In that case, I would not use the ellipsis. > BTW, making "\nfoo" invisible instead of "foo\n" should circumvent the > current mis-numbering problem which your patch tries to circumvent. > Sorry, I am a little tired of trying. >> (In this case, I must scroll the window horizontally many times.) > > C-e does the trick if you're on the right line. > I see. (Although, the ellipsis is not always at the end of a line. So I must scroll ...) However, I still wish to know the invisibility information at a glance. Currently, it is useful to check the result by `hide-sublevels' or `hide-body' on `outline-minor-mode'. >> If linum-mode provides information about the invisible text, I can check >> the information very easily, I think. > > I understand that it makes sense in your particular case, but it seems > too tightly linked to a particular use of invisible (and this particular > use of invisible is in turn tightly linked to linum in order to make it > bearable). So I'm not convinced this belongs in linum.el as it stands. > OTOH maybe we could install a patch to linum.el that provides a hook > that you could use to add the same functionality. > > > Stefan > That's right. (I will use the function for my own solution.) Thank you.