From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Andreas_R=c3=b6hler?= Newsgroups: gmane.emacs.devel Subject: Re: font-lock-syntactic-keywords obsolet? Date: Mon, 20 Jun 2016 22:22:57 +0200 Message-ID: <831cb780-abde-f9f8-3fe6-ee7082bcb4ca@online.de> References: <20160619151227.GD5875@acm.fritz.box> <20160620115726.GD3166@acm.fritz.box> <34a11f84-c6c8-0fb2-f289-e4cadf83193c@online.de> <20160620185513.GD2192@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1466454072 9182 80.91.229.3 (20 Jun 2016 20:21:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2016 20:21:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 20 22:21:02 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 1bF5gk-0001b2-J4 for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2016 22:20:54 +0200 Original-Received: from localhost ([::1]:46259 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF5gj-0003UP-IK for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2016 16:20:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44371) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF5ed-0002hT-9r for emacs-devel@gnu.org; Mon, 20 Jun 2016 16:18:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bF5eZ-0004Ox-9z for emacs-devel@gnu.org; Mon, 20 Jun 2016 16:18:43 -0400 Original-Received: from mout.kundenserver.de ([212.227.126.134]:62774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bF5eY-0004O8-Uo for emacs-devel@gnu.org; Mon, 20 Jun 2016 16:18:39 -0400 Original-Received: from [192.168.178.35] ([77.12.77.196]) by mrelayeu.kundenserver.de (mreue002) with ESMTPSA (Nemesis) id 0MH9BC-1bBI2I1fda-00DpSG; Mon, 20 Jun 2016 22:18:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Icedove/45.1.0 In-Reply-To: <20160620185513.GD2192@acm.fritz.box> X-Provags-ID: V03:K0:wSQoCsAIt0DmW2PW1BRb1QCfaf4UESm431SPFomh1zg8pO7mvKb wt4WJcvnTdmGxUCq+/0SWMsMFK5uRljOxPIG+0LhThdccf7QLqyfu4D0p0vAkAm9oqPUIK+ VBMUjYwH7h5eh4Yob0ymhgiVunhNlIHc4JCYJ/JXnMIwt93VcgNUPTT6UlcUhNeNjZdKsUC gd9qXZLbDpdfMUogG2hQQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:1GsUxzVUHPI=:JGcO3U5IrKU22ErIpkZ1Z4 iKbBrQFr/KhDdDe6thAfMly/FU5eZVKmVkiH1J+rxYO8y8tOimQKrPE6uuHw99I2A9zmZH+PN DhQa9qoTZxZ8e3VWqIeAsSnbuYyjKEQf+kYoW1V/xZOlLLA3wsN0Wf8/urZH+iyE0jujlWaAq ASLPKV6oPnLwxtGRn/0bAkqGI+g/qcUML3MSTqlBsPPXRbYUn1FoSB88h96G6QVWg6MRcBjgy zP4GHRaW9gLIWBDvia650DA6fqOWS9UyXkdmNntU97UQSDVYQOyE6syHd7LDupJurlE4dkCZj YzoJ4FPjW52a0yBLiGbPyieKxCQX/Hj1DhCzzvx2MtlcqrhqVDGkLIeqH+8DU43NgcpNVbM3K gdwFcHRBK0BFZzxwN5ztC6+uXjKN6pn17bJHr3b4DjbydwElaBXkEyk5bNzf7Zb4unE97hWhr 7JpZGJjhemxY5IZYB8YPOKHsN06uN0QRcOHoUvwsY9empcGY/ZcolN5BhPYotWdGMCqpLhKEV 37j8D3Gmx+8djWeoPVBjnM7+aT8X3K7gPu6yuhJYbFNA4poUePh4CNLtcsfIniJNy4ReDxcrF jcqhZgUVippcp5LUX5OmfQ6P3SiTZOH9qETqV1Y3mpEOoFgvZ93Wkd48t7NytIh3KjoDPdKDG h33hOVzzNhZ4poUvxy6BCzobXaRgZtoHe09zxfHUQhGcJqskYsEXHdfTPZ6lJgBCXBQmp7gdq VppPL+HbBdAZ15Pv X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.126.134 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:204610 Archived-At: On 20.06.2016 20:55, Alan Mackenzie wrote: > Hello, Andreas. > > On Mon, Jun 20, 2016 at 06:00:01PM +0200, Andreas Röhler wrote: > > >> On 20.06.2016 15:50, Dmitry Gutov wrote: >>> On 06/20/2016 04:37 PM, Stefan Monnier wrote: >>>>> I've tried doing this with an actual bug, namely bug #22983 >>>>> "syntax-ppss >>>>> returns wrong result". That was over three months ago, and still there >>>>> is no fix. >>>> Indeed, no fix. A few reasons: >>>> - Lack of a concrete case which suffers from it (not much immediate >>>> benefit). >>>> - In many cases, it's easier to fix the other side (the caller of >>>> syntax-ppss). >>>> - It's hard to fix it right, not because of syntax-ppss in particular, >>>> but because it's hard to make a generic facility which can be fast by >>>> using a cache, yet is not being told where is the real intended >>>> beginning of the buffer. In CC-mode you just decided to punt and >>>> disallow the use of cc-mode where 1 is not the real beginning of the >>>> C code. So your approach suffers from the same problem (just the >>>> other side of it) and you haven't fixed it either. >>>> This said, a quick&dirty fix (if such was needed, e.g. because of a >>>> concrete >>>> case which exhibits the problem) would be to make syntax-ppss >>>> always widen (and maybe add a syntax-ppss-dont-widen). Given that >>>> there's no real hurry to fix it, I'd rather we fix it right. >>> I'm very tempted to fix it by pushing the proposed patch into master, >>> considering no viable alternative patch has been proposed so far, if >>> only to avoid seeing Alan mention that bug for the 101th time > >> IMHO syntax-ppss has many design issues, not a single one. > I agree wholeheartedly. > >> I'd prever to see an example, where syntax-ppss can't be replaced by >> parse-partial-sexp. > Well, syntax-ppss was originally intended to give the result equivalent > to (parse-partial-sexp (point-min) pos), and probably does, providing the > buffer is never narrowed - with narrowing, you get a somewhat random > result. > >> From there designing a syntax-ppss capable of its tasks might be of >> interest. > One of the problems is that syntax-ppss, rather than just performing its > function, has the subsidiary function of applying syntax-table text > properties. Eliminating this incoherence would be a good design aim. > In fact, finding a good way of applying the text properties would win > you a medal, in my eyes. > Thanks Alan. It should be possible to find a simpler solution avoiding circular calls. Nonetheless, rethinking it from scratch might take some time too. May you open a branch for this? Ideally with its own bug-tracker? Another problem: signed only the disclaimer to FSF, not the complete copyright assignment paper. So my role would be restricted being a tester and critique rather than an active writer... ;)