From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: forward-comment and syntax-ppss Date: Mon, 19 Dec 2016 09:17:40 -0500 Message-ID: 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> <58afc3fb-a191-40c5-a6e9-8666f3e9ee21@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1482157098 26138 195.159.176.226 (19 Dec 2016 14:18:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Dec 2016 14:18:18 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 19 15:18:14 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 1cIylZ-00063D-4u for ged-emacs-devel@m.gmane.org; Mon, 19 Dec 2016 15:18:13 +0100 Original-Received: from localhost ([::1]:45892 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cIyld-0006FR-FK for ged-emacs-devel@m.gmane.org; Mon, 19 Dec 2016 09:18:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49865) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cIylP-0006Dh-Sq for emacs-devel@gnu.org; Mon, 19 Dec 2016 09:18:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cIylK-0006PV-VS for emacs-devel@gnu.org; Mon, 19 Dec 2016 09:18:03 -0500 Original-Received: from [195.159.176.226] (port=34823 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cIylK-0006PB-OT for emacs-devel@gnu.org; Mon, 19 Dec 2016 09:17:58 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cIylA-0002lR-9V for emacs-devel@gnu.org; Mon, 19 Dec 2016 15:17:48 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 89 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:NcOzlsCoI7igXXnI5u0P8ncyiFs= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:210633 Archived-At: > 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. Then I misunderstood. What is the problem that your proposal aims to fix? > This seems necessary to have a stable syntax cache, e.g. to have it > as a basis of comments navigation. But if we have something like syntax-ppss-parse-start, why not use that same info more generally when some function wants to widen (e.g. make it also replace font-lock-dont-widen)? >> 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. But the problem is the linkage between the narrowing and the widening, not between the user-command and the widening. In general, the command currently executed does not know who put the narrowing nor why, so it still doesn't know what's the intention behind it, and hence can't decide whether to widen or not, nor or much to widen. >> 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 Not sure which problem you're referring to. Do you mean that when syntax-ppss-parse-start is changed, syntax-ppss is not warned? > haven't commented on syntax-ppss's cache management ideas. Not sure on which part you want my input. I can't remember all that's been suggested, so here's just some random opinions of mine on the subject: - we could/should have a macro (with-new-syntax-ppss-context ... &rest BODY) which runs BODY such that calls to syntax-ppss in there can be cached within this scope but don't use the outer syntax-ppss cache and don't affect it. This could be used when a command wants to temporarily use an ad-hoc syntax-table (typically using with-syntax-table), for example. It should probably be made to obey the current narrowing limits, since such uses often additionally want to restrict the parsing to a subpart of the buffer. - if we introduce a syntax-ppss-parse-start, it should not have `ppss` in its name, it should probably try to include some of the design of indentation-context, and it should probably be modified via functions (rather than directly via setq), so that those functions can flush the syntax-ppss cache when needed. This said, if needed it'd probably be OK to have syntax-ppss auto-detect changes instead (after all, syntax-ppss is still implemented in Elisp, so there is a lot of room for speed up). >> 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? Not necessarily, no. > I'm saying that's unnecessary, and that indent-for-tab-command can do all > the widening itself. I wouldn't do it in indent-for-tab-command, but I agree that it should be done in indent-according-to-mode rather than forcing every major mode's indentation function to widen. > 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. Sure. I think the current discussion is about "what should prog-widen/syntax-ppss-parse-start look like" more than "who/when should we call prog-widen". > Even if we add "something else", upon deciding that it's really needed, > later, the current proposal shouldn't hurt. If by "current proposal" you mean to prog-widen in indent-according-to-mode, then I agree it's a good idea. Stefan