From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: forward-comment and syntax-ppss Date: Mon, 19 Dec 2016 15:34:17 +0200 Message-ID: <58afc3fb-a191-40c5-a6e9-8666f3e9ee21@yandex.ru> References: <83fd1db0-7362-6117-c5cd-715398c0dea4@gmail.com> <20161207220447.GA4503@acm.fritz.box> <20161208201517.GB3120@acm.fritz.box> <20161209190747.GC2203@acm.fritz.box> <5a70902f-882e-f616-74b2-df6eb81fc70c@yandex.ru> <20161211101715.GA14084@acm.fritz.box> <51c0554f-40d0-37a5-b134-17058343aa3f@yandex.ru> <20161216200630.GB3858@acm.fritz.box> <83r3576lxs.fsf@gnu.org> <838tre7gqt.fsf@gnu.org> <9e3a5f1b-2bd6-4223-bcb0-790be47d52ab@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1482154476 8459 195.159.176.226 (19 Dec 2016 13:34:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Dec 2016 13:34:36 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Thunderbird/50.0 Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 19 14:34:32 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cIy5H-0001A5-NZ for ged-emacs-devel@m.gmane.org; Mon, 19 Dec 2016 14:34:31 +0100 Original-Received: from localhost ([::1]:45531 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cIy5K-0002j8-O2 for ged-emacs-devel@m.gmane.org; Mon, 19 Dec 2016 08:34:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cIy5A-0002gm-O4 for emacs-devel@gnu.org; Mon, 19 Dec 2016 08:34:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cIy57-00046t-Jv for emacs-devel@gnu.org; Mon, 19 Dec 2016 08:34:24 -0500 Original-Received: from mail-wm0-x230.google.com ([2a00:1450:400c:c09::230]:38504) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cIy57-000469-Dw for emacs-devel@gnu.org; Mon, 19 Dec 2016 08:34:21 -0500 Original-Received: by mail-wm0-x230.google.com with SMTP id f82so101245506wmf.1 for ; Mon, 19 Dec 2016 05:34:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=31XFcYgDoN886HL2x9OB8YXpH8QBXrpug0XCmTqmIJA=; b=CJe23jNAuhVDtv/QiqXQTfM1fWH9fKN5AgfvtQ6KmCTyjrK36HhkSiNUbuCUXdlOl4 DvxbZmAgxra7ovgziyohayH6+Uy7tnkC2px+nQRzx0Uy9m6+QSYax3ha5Fec+UpUqdza 8v0l/JQAM8YLStTS+5xq+HAy72sjg3C+I5S8YiAOMgxZEQhiQNMcPpBdXPqbVU0B+gNX jIXDiWoDZ7yysmgMRHFnrtjX+cKd0gndB2t7SH5oATF3dgoq2NP9CV9NYFAOcchiGlgl Jh7f9U3dQ+eP753y2wnCtwXPTd0cuf+c45yN4ohyQt6ZA5hfx52O53qH36OLfH2lQ4qm Oy3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=31XFcYgDoN886HL2x9OB8YXpH8QBXrpug0XCmTqmIJA=; b=d0iA+sHocZ9A11A5JoqP33iazOPh1cqtmasV5j+ngK3EOpP94WZmrse9FDCIbu1iHr 7cndNccWqKc9rF8T1e3Y/gAccbRLGYs+lxioo+P9kkn3m4vhQI7OhmhbSQak4rFCsc8/ 64Z9PyPDJ4K8yqYXTVZ06mKu/Wi9N3C8mdi3DZgz/3pLE8CZv9wiSByhwvmIeAnKeTc2 NKbAtFPulFUa1tTynWJMXewfQbE7Wpo0A00IgcDji8uA5p4RARW6DU6SDNqjGX1HjxOc O/ldIWCTC/zHzxutEPOtIvKwiUuVk458M7FQY3ZCOM5OeSN7E7merOVd+ueiAb4d6y4u SVcA== X-Gm-Message-State: AIkVDXJceOxuF0B8MaeO1m2C27sLKf5L2rTpRRGol4modfm0UXJ62AYTYo8fvG0Y9h465w== X-Received: by 10.28.214.84 with SMTP id n81mr12607369wmg.120.1482154459914; Mon, 19 Dec 2016 05:34:19 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.173.41]) by smtp.googlemail.com with ESMTPSA id e188sm17287295wma.21.2016.12.19.05.34.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Dec 2016 05:34:19 -0800 (PST) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::230 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:210628 Archived-At: On 19.12.2016 15:12, Stefan Monnier wrote: > But that means any command which somewhere internally uses syntax-ppss > would need to widen? So any change which introduces a new call to > syntax-ppss would imply revising all callers of this code and all > callers of those callers (etc...) to make sure they widen? No, syntax-ppss would probably be an exception, and call `widen' itself, as well as include a syntax-ppss-dont-widen variable, or syntax-ppss-parse-start, like proposed by Alan. This seems necessary to have a stable syntax cache, e.g. to have it as a basis of comments navigation. > What if they don't want to widen because they're commands which *should* > limit themselves to the narrowed region? I see no big obstacles to that, so far. > That seems to presume that narrowing is only used for multi-mode kind of > contexts, which currently is the exception rather than the rule. The idea is to preserve its usability for both cases, by moving the choice when to narrow or widen up the stack, closer to the commands that the user invokes (if indeed the code is called interactively), because they are likely to be more aware of the user's intent. > I think the core of the problem is the use of narrowing for widely > different purposes, so indeed we should decide that some of those uses > are simply inappropriate and provided something else for those uses. That's one option. But again, prog-widen doesn't solve everything, and you haven't commented on syntax-ppss's cache management ideas. > But I think the case "user-level narrow for Q&R" is hard to replace > reliably, so I'd rather keep narrowing for *that* purpose, and try to > introduce something else for the other uses (e.g. for multi-mode). You're saying that python-indent-line and its callees should call prog-widen, right? I'm saying that's unnecessary, and that indent-for-tab-command can do all the widening itself. Same for font-lock. And that takes care of the two known obstacles in the mixed-major-mode space, with very little code or changes to the API. Even if we add "something else", upon deciding that it's really needed, later, the current proposal shouldn't hurt.