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: [Patch] hard-widen-limits [was Re: Syntax tables for multiple modes [was: bug#22983: syntax-ppss returns wrong result.]] Date: Tue, 22 Mar 2016 12:44:27 -0400 Message-ID: References: <20160311151512.GD2888@acm.fritz.box> <20160314151621.GF1894@acm.fritz.box> <874mc2dqtk.fsf@gmail.com> <87egb5cpmg.fsf@gmail.com> <87a8lsd4j3.fsf@gmail.com> <87mvpsbeok.fsf_-_@gmail.com> <87pounew9e.fsf@gmail.com> <87twjzda4h.fsf@gmail.com> <87lh5bd4ib.fsf@gmail.com> <87egb3ryjc.fsf@gmail.com> <877fgusum3.fsf@gmail.com> <8737risu8d.fsf@gmail.com> <87mvpqqxy7.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1458665107 13076 80.91.229.3 (22 Mar 2016 16:45:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Mar 2016 16:45:07 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 22 17:44:58 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 1aiPQI-0003Ij-Bf for ged-emacs-devel@m.gmane.org; Tue, 22 Mar 2016 17:44:50 +0100 Original-Received: from localhost ([::1]:38405 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiPQH-0005EL-I9 for ged-emacs-devel@m.gmane.org; Tue, 22 Mar 2016 12:44:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46780) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiPQD-0005C8-Ea for emacs-devel@gnu.org; Tue, 22 Mar 2016 12:44:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aiPQ8-0008RQ-F7 for emacs-devel@gnu.org; Tue, 22 Mar 2016 12:44:45 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:37443) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aiPQ8-0008Qw-8P for emacs-devel@gnu.org; Tue, 22 Mar 2016 12:44:40 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aiPQ4-000382-8G for emacs-devel@gnu.org; Tue, 22 Mar 2016 17:44:36 +0100 Original-Received: from 69-196-182-150.dsl.teksavvy.com ([69.196.182.150]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Mar 2016 17:44:36 +0100 Original-Received: from monnier by 69-196-182-150.dsl.teksavvy.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 22 Mar 2016 17:44:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 35 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 69-196-182-150.dsl.teksavvy.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:VdoDwlpPQUO1P7sh9dQ3ECawHtA= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:202077 Archived-At: > Mixing hard limit into a common user level function is a bad marketing > strategy. `narrow-to-region' is not only a user-level command. It's also a low-level primitive. The narrow-to-region command can't set the optional argument unless we take extra steps to let it, so the "hard narrowing" would only be available from Elisp, not interactively. > If users and major modes decide to use hard limits we might end up in > the same situation as now when narrow/widen is not perceived as a good > tool for multi-modes. Could be. Maybe there are more "kinds of narrowing" than just 2, indeed. But for me, the main consideration is whether the text before/after point-min can be taken into account as a kind of context, or whether the text between point-min/max should be treated (even if temporarily) as being the whole&sole truth. That's what "hard narrowing" means to me. I don't think I'd be able to design something that can take into account finer distinctions of narrowings right now, for lack of understanding about what those finer distinctions could be and what kind of problems they lead to. > limits at the end. Problems will occur if major modes start using hard > limits in such contexts directly. I don't see any reason why problems *will* occur in that case (tho, of course, Murphy could be that reason). So until such problems do show up, I wouldn't worry. Stefan