From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs's handling of line numbers [from bug#5042] Date: Sun, 18 Apr 2010 20:38:35 +0300 Message-ID: <83r5mcbqzo.fsf@gnu.org> References: <837ho6czb6.fsf@gnu.org> <8339yucbsg.fsf@gnu.org> <83wrw5bxkc.fsf@gnu.org> <83tyr9bgid.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1271612361 30500 80.91.229.12 (18 Apr 2010 17:39:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 18 Apr 2010 17:39:21 +0000 (UTC) Cc: lekktu@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: mark.lillibridge@hp.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 18 19:39:18 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O3YSj-0003CR-OV for ged-emacs-devel@m.gmane.org; Sun, 18 Apr 2010 19:39:18 +0200 Original-Received: from localhost ([127.0.0.1]:37602 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O3YSi-0007By-NV for ged-emacs-devel@m.gmane.org; Sun, 18 Apr 2010 13:39:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O3YSK-00079V-O1 for emacs-devel@gnu.org; Sun, 18 Apr 2010 13:38:52 -0400 Original-Received: from [140.186.70.92] (port=47947 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O3YSI-00079N-6S for emacs-devel@gnu.org; Sun, 18 Apr 2010 13:38:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O3YSG-0002WU-LT for emacs-devel@gnu.org; Sun, 18 Apr 2010 13:38:50 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:46615) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O3YSG-0002WI-Ef for emacs-devel@gnu.org; Sun, 18 Apr 2010 13:38:48 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0L1300A002A3B700@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Sun, 18 Apr 2010 20:38:31 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.69.249]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L13006KN2C6WMC0@a-mtaout23.012.net.il>; Sun, 18 Apr 2010 20:38:31 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:123848 Archived-At: > Date: Sun, 18 Apr 2010 10:00:45 -0700 > From: Mark Lillibridge > CC: lekktu@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > The issue is that font-lock mode, goto-line, linum mode, and perhaps > other features need to treat them differently. These features want to > widen to the "application" restriction when processing the current > buffer, ignoring any temporary restriction. But if this is the problem you want to solve, you cannot solve it by introducing yet another kind of restriction: there's always a chance that a command will want to use the "application" restriction, when one is already in place, because, e.g., you have font-lock or whatever active. And then you are back at the same problem. IOW, by introducing 2 kinds of restriction, you don't solve the problem, you just push it a bit farther. Moreover, I'm not sure I see the problem that is grave enough to justify this. The 3 examples you mentioned can be solved by programming the features to do what you want (I believe font-lock already solved it, albeit not too elegantly). I understand now the difference between two classes of use of restriction (thanks to all who labored to explain that to this old fart), but are there _practical_ use-cases where the current situation gets in our way so badly that such a new feature would be justified? I wonder.