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: Permission requested to merge branch comment-cache into master. Date: Sun, 13 Mar 2016 21:11:04 -0400 Message-ID: References: <20160312002837.GJ2888@acm.fritz.box> <83mvq4gni4.fsf@gnu.org> <20160312100843.GA2572@acm.fritz.box> <83a8m4gd7p.fsf@gnu.org> <20160312115021.GB2572@acm.fritz.box> <837fh7ho78.fsf@gnu.org> <20160312231713.GD10781@acm.fritz.box> <20160313152017.GD1871@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1457917893 25802 80.91.229.3 (14 Mar 2016 01:11:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Mar 2016 01:11:33 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 14 02:11:25 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 1afH2a-0004xQ-LG for ged-emacs-devel@m.gmane.org; Mon, 14 Mar 2016 02:11:24 +0100 Original-Received: from localhost ([::1]:38418 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afH2Z-0008Oe-L4 for ged-emacs-devel@m.gmane.org; Sun, 13 Mar 2016 21:11:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39594) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afH2V-0008OX-4l for emacs-devel@gnu.org; Sun, 13 Mar 2016 21:11:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afH2Q-0002H5-5b for emacs-devel@gnu.org; Sun, 13 Mar 2016 21:11:19 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:53080) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afH2P-0002H1-R8 for emacs-devel@gnu.org; Sun, 13 Mar 2016 21:11:14 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1afH2N-0004qu-TW for emacs-devel@gnu.org; Mon, 14 Mar 2016 02:11:11 +0100 Original-Received: from 24.140.224.194 ([24.140.224.194]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Mar 2016 02:11:11 +0100 Original-Received: from monnier by 24.140.224.194 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 14 Mar 2016 02:11:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 106 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 24.140.224.194 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:ZaGSnQHP3dy1H3TR1/t67y/oe1o= 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:201662 Archived-At: > syntax-ppss is simply unsuitable for use in a primitive, and using it > never entered into my considerations. It is difficult to understand, > difficult to maintain high level lisp Huh? syntax-ppss is very simple code, and I have no idea where you could have gotten the idea that it's "difficult to maintain". > and it calls out to user functions via a hook. It is crazy and in bad > taste to make a primitive depend on such a thing. It is just the > Wrong Thing to do. The only case where it calls to user function is via syntax-propertize. In the case of back_comment this should never happen (because we're moving backward, so syntax-propertize has already been called on positions further down and hence isn't needed at this position), but in case it were to happen it could only be because it's necessary *for correctness*. So, again: when my patch to back_comment calls syntax-ppss, it will not call syntax-propertize-function. Of course, it still means we call an Elisp function, which could be adviced and whatnot. If you want to rewrite it in C go for it, but I'd oppose it unless you have good *concrete* reasons for it, rather than vague allegations about it being "crazy" or "wrong". > Anything we use in primitives should be robust and rigorous, and as > far as possible, simple. Exactly. But in my book, robust includes "has the needed syntax-table properties applied". > Stefan's idea for a solution is to construe the problem as something > more limited, leave the backward scanning in place, and just make bug > #22884 go away (until the next bug happens). Alan, you're a good coder and good thinker. I know you can make a much better case against my code than that kind of FUD. I have acknowledged all the weaknesses you point out (hell, I could give you a few more if you were more welcoming). But syntax-ppss was introduced in Emacs-22.1, i.e. it has close to 9 years of wide use. So these issues aren't nearly as serious as you make it out to be. And furthermore, if/when they need to be fixed, they can be probably be fixed rather easily. > char foo[] = "asdf asdf" "asdf"; /* "asdf" */ /* */ /* '"'" */ > ^ > , narrow it such that point-min is at the marked point. syntax-ppss > then sees the following strings, but no comments: As mentioned, depending on the *reason* behind narrowing, what you say that syntax-ppss does actually makes perfect sense. Better yet: that's also what (forward-comment -1) does in Emacs-24. And it's not because of a bug in (forward-comment -1) but because (forward-comment -1) also decided to start parsing from (point-min) in that particular case. Now, I'm far from opposed to changing the behavior so as to treat the last /* '"'" */ as a comment in the narrowed region. I think this choice doesn't really matter much, except for a few specific circumstances, where the caller needs to provide more info in order to clarify which behavior she wants. [ Of course, syntax-ppss will sometimes do one and sometimes the other, depending on the state of its cache. So, yes, syntax-ppss's behavior in this respect is inconsistent. And noone has reported a single bug about it in all those years. Should we fix this problem? Why not! Is it urgent? Imperative? Worthy of writing a whole new system (which fundamentally suffers from the exact same problem just with different arbitrary choices)? Really? ] > " " > "; /* " > " */ /* */ /* '" > " */ ; no closing string quote > > (forward-comment -1) from the end of line, using syntax-ppss, thus > fails. And as mentioned it also fails in all versions of Emacs released so far. > In comment-cache, of course, it works without trouble. Hmm... sure sounds like a backward incompatibility to me. > What I predict is now going to happen is that a different function, > based on syntax-ppss, but returning the equivalent of > (parse-partial-sexp 1 pos) is going to get written. I also predict that > it will be given the name syntax-ppss, and the 200 or so calls in our > code, and an indeterminate number in users' code are going to be left as > they are to fend for themselves, regardless of the change in > functionality. Right, because they are already fending for themselves against syntax-ppss's inconsistent behavior in the presence of narrowing. > How about, as a compromise, merging comment-cache into master for now, > while syntax-ppss gets sorted out, then deciding what to do once that > has happened? You make it sound like your solution is rock-solid bullet-proof whereas syntax-ppss is completely wobbly. This verges on the ridiculous. They're both wobbly, by the very nature of their work. Stefan