From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please. Date: Sat, 11 Jun 2016 19:50:16 +0000 Message-ID: <20160611195016.GE2776@acm.fritz.box> References: <20160607220928.GA5155@acm.fritz.box> <7eeaa57a-698d-bde0-d740-efa8968c7583@yandex.ru> <20160607224829.GC5155@acm.fritz.box> <20160611100750.GB2776@acm.fritz.box> <774fce31-fdea-1b85-fa09-07a901b00ab3@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1465674633 20360 80.91.229.3 (11 Jun 2016 19:50:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Jun 2016 19:50:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 11 21:50:24 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 1bBovG-0008KP-UE for ged-emacs-devel@m.gmane.org; Sat, 11 Jun 2016 21:50:23 +0200 Original-Received: from localhost ([::1]:48237 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBovC-0000mT-W0 for ged-emacs-devel@m.gmane.org; Sat, 11 Jun 2016 15:50:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBov5-0000mN-Ro for emacs-devel@gnu.org; Sat, 11 Jun 2016 15:50:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bBov2-0003J5-N9 for emacs-devel@gnu.org; Sat, 11 Jun 2016 15:50:11 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:45365) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bBov2-0003Gd-Cf for emacs-devel@gnu.org; Sat, 11 Jun 2016 15:50:08 -0400 Original-Received: (qmail 36734 invoked by uid 3782); 11 Jun 2016 19:50:05 -0000 Original-Received: from acm.muc.de (p548C7AF3.dip0.t-ipconnect.de [84.140.122.243]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 11 Jun 2016 21:50:04 +0200 Original-Received: (qmail 30783 invoked by uid 1000); 11 Jun 2016 19:50:16 -0000 Content-Disposition: inline In-Reply-To: <774fce31-fdea-1b85-fa09-07a901b00ab3@yandex.ru> User-Agent: Mutt/1.5.24 (2015-08-30) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 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:204290 Archived-At: Hello, Dmitry. On Sat, Jun 11, 2016 at 07:10:03PM +0300, Dmitry Gutov wrote: > On 06/11/2016 01:07 PM, Alan Mackenzie wrote: > I'm still not even clear which branch 25.2 will come from, and that's an > important concern. My guess is it'll will come from the master branch. Otherwise, there'll be too much work in cherry picking commits back to the emacs-25 branch. That's just a guess, though. > > Is Vitalie still working on ... anything else to do with > > Emacs)? > Yes: > https://github.com/emacs-ess/ESS/commits/master > https://github.com/vspinu/polymode/commits/master Glad to hear that! > Adding hard-widen, however, is a low-level endeavor, and it seems nobody > sufficiently proficient there is in any hurry to help. > > I can't say I feel enthusiastic about "hard-widen". I haven't looked > > into it that thoroughly, but it feels a bit like an ugly hack whose > > ramifications might percolate all the way through Emacs, and that might > > make us regret it fairly heavily in the not too distant future. > Hadn't you yourself proposed a far more invasive solution, not too long > ago? Intrusive it is, but an ugly hack it certainly isn't. It's aim is to bring Emacs to the state it would have been in if it had been designed for multiple major modes per buffer right from the start. As such it will be free from ugly workarounds. The main problem with it is the amount of work to implement it is huge. So much so, that I might well never finish it myself. There was not a great deal of enthusiasm expressed for it all these weeks ago, apart from from Eli and yourself, and even then, Eli was unhappy about a fairly important part of it. > I think hard-widen strikes a certain balance, in that is will require a > moderate amount of changes in Emacs, and little to no changes in the > user code, considering we've always (or at least for a long time) had > to write it with consideration for the current narrowing. hard-widen seems to destroy the simplicity evident in narrow-to-region and widen. It's an ugly hack, and I fear that if we implement it, it will have ugly unforeseen consequences which it will then be too late to do anything about. Why does (presumably) a super mode want to do anything with narrowing anyway? Narrowing is needed by users and by major modes, and its use by a super mode might well clash. Is this hard-widen proposal at all documented in any coherent fashion? > If there's anything to complain about it, it's that it doesn't bring new > niceties. So: modest gains, and little amount of pain. Seems > conservative enough for the Emacs community. I'm not convinced. But then, I don't know how the proposal will work in any great detail. > >>> Yes, I think having the binary toggle `syntax-ppss-dont-widen' purely to > >>> direct the innards of the function is poor programming (since it > >>> explicitly toggles a toggle inside a supposedly abstract function). > >> Abstract? > > Yes, abstract. `syntax-ppss' has an specification and interface on the > > one side, and an implementation on the other. > Just like any other function? No, some so-called functions, though thankfully few in Emacs, are incoherent assemblages, with callers having to reach in and manipulate the innards (and hence be aware of the implementation). And so on. Look up terms like "coherence" and "coupling" in computer science text books. > >>> I think an improvement would be to dispense with that toggle, and > >>> have two distinct functions, one in place of > >>> `syntax-ppss-dont-widen' being nil, and the other in place of > >>> `s-p-d-w' being non-nil. The latter function might usefully have an > >>> extra parameter specifying the base point that parse-partial-sexp > >>> should be calculated from. That would leave quite a few options > >>> open for the internal logic of the function. > >> That wouldn't help in the multi-mode case, which is the primary use I > >> have in mind for syntax-ppss-dont-widen. > > Why would it not help? > Because you (in CC Mode) will choose the more straightforward version > that does widen. And I, in mmm-mode, will thus have no ability to modify > what your code is doing by narrowing, and will send you dark thoughts > instead. That paragraph worries me greatly. OF COURSE CC Mode uses narrow-to-region and widen freely, there being code which can scarcely work without it. I and other major mode maintainers will expect to continue to be able to do so. A super mode should, should it use widening and narrowing, do so in a manner which won't interfere with major modes' and users' use of it. > What's the purpose of the other function? Who's going to use it? Maybe nobody. ;-) What I missed was the need to insert it far and wide into existing code. -- Alan Mackenzie (Nuremberg, Germany).