From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality Date: Wed, 23 Mar 2016 07:29:55 -0700 (PDT) Message-ID: <78a08f80-30e2-4be1-a5e7-17c1c8fa866d@default> References: <20160322022539.16038.77264@vcs.savannah.gnu.org> <8737riqouj.fsf@gmail.com> <221845e0-b194-433e-bfbc-105272ae5752@default> <87twjyp21k.fsf@gmail.com> <56F242E0.7060004@online.de> <877fgtpfrw.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1458743457 18334 80.91.229.3 (23 Mar 2016 14:30:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Mar 2016 14:30:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Vitalie Spinu , =?utf-8?B?QW5kcmVhcyBSw7ZobGVy?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 23 15:30:39 2016 Return-path: Envelope-to: ged-emacs-devel@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 1aijny-0007Xy-Pa for ged-emacs-devel@m.gmane.org; Wed, 23 Mar 2016 15:30:38 +0100 Original-Received: from localhost ([::1]:44281 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aijnx-0001rx-W3 for ged-emacs-devel@m.gmane.org; Wed, 23 Mar 2016 10:30:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55197) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aijnc-0001mm-AC for emacs-devel@gnu.org; Wed, 23 Mar 2016 10:30:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aijnW-00022h-Iw for emacs-devel@gnu.org; Wed, 23 Mar 2016 10:30:16 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:40906) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aijnW-00022R-Bk for emacs-devel@gnu.org; Wed, 23 Mar 2016 10:30:10 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2NEU4kl017447 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Mar 2016 14:30:05 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2NEU466013719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 23 Mar 2016 14:30:04 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u2NETuYo011781; Wed, 23 Mar 2016 14:30:03 GMT In-Reply-To: <877fgtpfrw.fsf@gmail.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:202137 Archived-At: > > preventing unwanted widen instead seems the way to go. >=20 > That's precisely what extra limit do. Prevent unwanted widen. How do you > propose > to implement that? >=20 > I see 4 ways to go about it: >=20 > 1) Add an extra prog-widen and teach all modes out there to use it in > contexts like syntax-parsing, indentation, font-lock and who know what el= se. A > half backed version of this in already part of emacs. >=20 > 2) Have low level restrictions directly in `widen` and a macro > `with-widen-limit` that multi-modes can use. This is the current pat= ch. >=20 > 3) Have two types of narrowing (soft and hard). This is harder to > implement but has the benefit that it can be used in non-transient situat= ions > like Info mode. >=20 > 4) Bring widen to elisp and allow minor modes (and Info mode) advice wi= den > in whatever way they see. >=20 > I think (1) is a bad idea. (4) is simplest and very general. (3) might be > useful but it's hard. (2) is implemented to get rid of (1). >=20 > I proposed (4) very early in the thread, but didn't hear much support for > it. There are only three trivial usages of Fwiden in C code. Bringing > `narrow` to elisp is equally easy. At least now you're backing up to talk about multiple possible solutions, instead of digging in deeper in your discussion of a single implementation (or is it two implementations that you and Stefan are considering?). I asked for a clear statement (at least a summary, but preferably a mini-spec) of the _problem_ you are trying to solve. My request was ignored. So be it. Continue on, the two of you ... but don't be surprised if people wonder about your solution after a while. As for solutions (for what I'm only guessing might be the problem), I suppose there are additional possibilities, including perhaps a `with-buffer-limits' macro or perhaps even adapting `point-min' and `point-max' (e.g. by let-binding global variables that they respond to - e.g., variables `point-min' and `point-max'). Dunno. It's hard to guess at a solution without understanding the problem. All I've gathered so far is that you want certain zones of the buffer to act as if the major mode is this or that, and in those zones you want some code (which code? all code?) to treat `point-min' and `point-max' as the zone limits, i.e., to act as if there is nothing outside of the zone limits. Just what that means in detail is not clear (not specified). Something about font-locking ... and some other blah. Not clear. No, I don't need to understand; I'm just one user, and I probably have nothing useful to offer as a suggestion. But my guess is that if more people here had an idea of what problem you are trying to solve then you might get some useful input. Just a guess.