From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: Emacs's handling of line numbers [from bug#5042] Date: Sun, 18 Apr 2010 19:52:11 +0200 Message-ID: References: <837ho6czb6.fsf@gnu.org> <8339yucbsg.fsf@gnu.org> <83wrw5bxkc.fsf@gnu.org> <83tyr9bgid.fsf@gnu.org> <83sk6sbre3.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1271613163 1167 80.91.229.12 (18 Apr 2010 17:52:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 18 Apr 2010 17:52:43 +0000 (UTC) Cc: monnier@iro.umontreal.ca, mark.lillibridge@hp.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 18 19:52:41 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 1O3Yfh-0000aV-1E for ged-emacs-devel@m.gmane.org; Sun, 18 Apr 2010 19:52:41 +0200 Original-Received: from localhost ([127.0.0.1]:45590 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O3Yfg-0002KF-IK for ged-emacs-devel@m.gmane.org; Sun, 18 Apr 2010 13:52:40 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O3Yfb-0002HY-8f for emacs-devel@gnu.org; Sun, 18 Apr 2010 13:52:35 -0400 Original-Received: from [140.186.70.92] (port=48278 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O3Yfa-0002Er-40 for emacs-devel@gnu.org; Sun, 18 Apr 2010 13:52:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O3YfY-0004c4-Mg for emacs-devel@gnu.org; Sun, 18 Apr 2010 13:52:33 -0400 Original-Received: from mail-bw0-f225.google.com ([209.85.218.225]:33153) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O3YfY-0004bt-EH; Sun, 18 Apr 2010 13:52:32 -0400 Original-Received: by bwz25 with SMTP id 25so3982133bwz.8 for ; Sun, 18 Apr 2010 10:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:received:message-id:subject:to:cc:content-type; bh=z6VEte8iKatTK8D/TQs+zQAtmfTy0Q/uZ8tL6xN4hYQ=; b=qw1WT/Ud5SMkQQ4br4CGNVBSkKalsR8Azhu1hGUGELyJYuuAaJomeVDhHrkSJPAcAX yOQZTWdsrpQ4i2X6oSn7lsgJiULzV1nnj1witERMrt1m4OXiAIH1mny0Jkdzxa+UaHcg BjxNucBqavS1ATAn4EF3rgaUviF0tzVd60RAo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=BxGO+F41X2wFL5yX1F/k6Gj0rbeDyCLzCCfY8YVwTf6lLoNX5eesWUB6RJU+65nc3s rfPWY4lQIf0a+DYPWTun499XSFpwYoc0bwGIj5zR3owKNTUD8y86b4WWEZg2rK0ogBbl xGrJUXODm4FGuVEYdoknRKqNr84xLwrZtL088= Original-Received: by 10.204.81.29 with HTTP; Sun, 18 Apr 2010 10:52:11 -0700 (PDT) In-Reply-To: <83sk6sbre3.fsf@gnu.org> Original-Received: by 10.204.157.17 with SMTP id z17mr3912619bkw.25.1271613151176; Sun, 18 Apr 2010 10:52:31 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:123849 Archived-At: On Sun, Apr 18, 2010 at 19:29, Eli Zaretskii wrote: > If that's the problem, we could disable narrowing/widening in Info > mode. Surely there are legitimate reasons why a user would want to use narrowing to show just part of an Info node. > (I'm not saying we should, but if we decided to do so, it would > be IMO a better solution than a whole new infrastructure with two > kinds of restrictions.) OK, don't think of it as two kinds of restrictions, but the current restriction user interface, and an additional elisp API to treat parts of a buffer as a "virtual buffer" or some such. > Actually, it happens to be a feature (more accurately, a basis for a > feature), both in Info and in Rmail. It is that feature inequivocally linked to being implemented via narrowing? > But you will never be able to disallow widening completely, because > the primitives are not going to go away, and there's nothing to > prevent a motivated individual from invoking them, even if they are > non-interactive. Of course. You can always shoot your own foot. That's no reason not to provide adequate abstractions. > IOW, I don't see how the suggested duplicity will solve enough of the > problem to justify the added complexity. I'm not sure, either. It's hard to say beforehand whether adding that would be a waste of resources (sort of like frame-local variables), or an enabling technology for some kind of problems... A priori, it seems like Info and rmail and some other packages could benefit from it. Juanma