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: Bug #25608 and the comment-cache branch Date: Tue, 14 Feb 2017 11:38:06 -0500 Message-ID: References: <20170202202418.GA2505@acm> <83lgtouxpf.fsf@gnu.org> <20170202215154.GB2505@acm> <83h94bvhzw.fsf@gnu.org> <20170203172952.GC2250@acm> <0a40d539-b7bc-2655-5429-6280022106ee@yandex.ru> <20170204102410.GA2047@acm> <8f9e68fc-4314-625d-b4bf-796c71c91798@yandex.ru> <20170206192423.GB3568@acm> <4f0fabf3-be9c-7492-379b-59dc93e72b4f@yandex.ru> <20170207192119.GA2490@acm> <424e6409-029c-d15d-421c-4fb90594329c@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1487090316 30701 195.159.176.226 (14 Feb 2017 16:38:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 14 Feb 2017 16:38:36 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 14 17:38:32 2017 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 1cdg7Z-0007SV-Tq for ged-emacs-devel@m.gmane.org; Tue, 14 Feb 2017 17:38:30 +0100 Original-Received: from localhost ([::1]:35803 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdg7f-0005oZ-C9 for ged-emacs-devel@m.gmane.org; Tue, 14 Feb 2017 11:38:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cdg7R-0005mh-2i for emacs-devel@gnu.org; Tue, 14 Feb 2017 11:38:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cdg7O-0002uP-FZ for emacs-devel@gnu.org; Tue, 14 Feb 2017 11:38:21 -0500 Original-Received: from [195.159.176.226] (port=58078 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cdg7O-0002te-7Z for emacs-devel@gnu.org; Tue, 14 Feb 2017 11:38:18 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cdg7D-0006Cv-6z for emacs-devel@gnu.org; Tue, 14 Feb 2017 17:38:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 45 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:Gl+BwLvY/rvMAhjXHp2Jp1Zp0O4= 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:212380 Archived-At: > What is "it"? I would imagine that to be sure that point is not > e.g. inside a string, the patch would have to consult the cache (or call > syntax-ppss) at least once per forward-comment call. Like all the sexp movement functions, `forward-comment` is allowed to assume that the starting position is outside of comments/strings, so it doesn't need to consult the cache to see if it's within a string. In the case we do scan forward (e.g. the case where we end up using parse-partial-sexp (or syntax-ppss in my patch)), we actually manually re-introduce that behavior: if the forward parse says that the end-comment-marker in inside a string (or inside another comment), we re-parse from the beginning of that string (or comment) to try and see if that end-comment-marker could be considered to close a comment nested within the string (or the other comment). > From there, I don't really see a real need for backward comment scanning. > So if you rewrote some code to use forward scanning, that approach should be > applicable on top of the AP as well. Calling syntax-ppss every time back_comment is invoked would probably result in bad performance currently: when parsing backward (e.g. backward-sexp), the syntax-ppss-last optimization is ineffective, so we'd fallback on syntax-ppss-cache which ends up scanning on the average syntax-ppss-max-span/2 (i.e. 10K) chars. When \n is a comment ender (i.e. in most programming language modes), it would imply a forward scan of 10K for every line. IOW, for such an approach to work, we'd have to rework syntax-ppss to be faster when scanning backward (e.g. reduce syntax-ppss-max-span, which would have other repercussions). >> That sounds like you've decided you want to use syntax-ppss no matter There's no alternative to syntax-ppss on the table, AFAIK. >> what, and the bugs this will cause will just be relabeled as features. Care to back up this claim? Where/when have we claimed that what you consider as a syntax-ppss bug is a feature? Stefan