From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#24172: 25.1; Doc of parse-sexp-ignore-comments: what does a value of nil mean? Date: Sun, 28 Jul 2019 12:11:16 +0200 Message-ID: References: <20190728082012.19960.qmail@mail.muc.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="261497"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Michael Heerdegen , 24172@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 28 12:12:16 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hrgA3-0015pv-AY for geb-bug-gnu-emacs@m.gmane.org; Sun, 28 Jul 2019 12:12:15 +0200 Original-Received: from localhost ([::1]:44368 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hrg9w-0005uu-Vw for geb-bug-gnu-emacs@m.gmane.org; Sun, 28 Jul 2019 06:12:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51276) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hrg9r-0005uo-Vo for bug-gnu-emacs@gnu.org; Sun, 28 Jul 2019 06:12:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hrg9q-0007v5-LM for bug-gnu-emacs@gnu.org; Sun, 28 Jul 2019 06:12:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36967) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hrg9q-0007uy-Hv for bug-gnu-emacs@gnu.org; Sun, 28 Jul 2019 06:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hrg9q-0005UA-9B for bug-gnu-emacs@gnu.org; Sun, 28 Jul 2019 06:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 28 Jul 2019 10:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24172 X-GNU-PR-Package: emacs Original-Received: via spool by 24172-submit@debbugs.gnu.org id=B24172.156430868421029 (code B ref 24172); Sun, 28 Jul 2019 10:12:02 +0000 Original-Received: (at 24172) by debbugs.gnu.org; 28 Jul 2019 10:11:24 +0000 Original-Received: from localhost ([127.0.0.1]:45788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hrg9D-0005T6-Pj for submit@debbugs.gnu.org; Sun, 28 Jul 2019 06:11:24 -0400 Original-Received: from quimby.gnus.org ([80.91.231.51]:53372) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hrg9B-0005Su-3w for 24172@debbugs.gnu.org; Sun, 28 Jul 2019 06:11:22 -0400 Original-Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=stories) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hrg96-0002xX-Iq; Sun, 28 Jul 2019 12:11:19 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAG1BMVEX+//z7+vb///z+//v/ ///lCgnb0s7Wjor9//VzIZgmAAACXElEQVQ4jWWUv3ObMBTHCdeLZ+NgOponBXcWOdtjoug6l/rk rEYUeS3mcOfUC3923xMIJ1ctwPvo+34KBYtc5Pn12r/3uK59n9MCPg8iuC18Z/h4Ukq9BnM52Vny p8KHDBHI4Mo5fqxCsmutUaQAgQqE25whI7suGOfKKQawFcA6Am8AHnAMItYRpNoB3PgBQGY8gAFg jJDA2gDTN1eSACUF5MrFKDCPUcG+oCSO4FQTaEWaqVu66SmHaq1dHaIcwF8sCDIrUpOh/RBtlr9G hUJPadFkggqpqkvJPUCybpLlJq31wdjSqAkAPNr5ZdnUui2TrSDFiwqeqMDHeWuTk347JqKEUeFA LCyUVhcmO5kJoCeoRVaZWhuzssIDV0cdgY1qLQx98A8gRgvrDqGlFk6Agp8RYJ++RxKkj0FnYL0H lum9AcNHO9VBvTqEkGE/wIzT8K6gEzCjWaCCe1fu+MQt3GttcJCTK5oXwP0hxNEWmJX0WQ2AddUK m3uMhu0PrnICsD2IGOfnQ08KlDQW5/QZUMKw0W2i38LPQEkJi+ScIuCfAOaOvTPJf0C9IHo5x7oB 2vT84IMrUmz3W91wiv58U7gp7rMZHumpJfTkpOh+LqE7+nH44FKuunMJsz2fJji4Uop1vw1kBVcc /GGg6JImG8Gs8DHk4IpArKu77scNOAX15ESH/TgOiiOA8Udv8f+4hOB+WjTRYXBrUzXzBV0MBF4l uCvjr2DslF2GHVwFij+rIAf4dhW7ZWlb8MSlm+e7Xd+/W7tY5BORdxDgZfS1H9auX9Id5a4g9g8B NQrPQLHE7QAAAABJRU5ErkJggg== In-Reply-To: <20190728082012.19960.qmail@mail.muc.de> (Alan Mackenzie's message of "28 Jul 2019 08:20:12 -0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:163939 Archived-At: (Looks like the debbugs address in the Cc was mangled, so I'm just resending the entire email to have it end up in the bug tracker.) Alan Mackenzie writes: > Hello, Lars. > > In article you wrote: >> Michael Heerdegen writes: > >>> in the docstring of `parse-sexp-ignore-comments' (or at least in the >>> manual), I miss a description about what a value of nil exactly means: >>> How are comments treated then? Are they treated as separate units that >>> can then be parsed as well, but separately from code, or are they treated >>> as indistinguishable from code? >>> >>> For example, if parsing starts from within a comment, and parsing finds >>> the end of the comment and is not yet finished, is parsing just >>> continued inside the following code, or does it fail? > >> After doing some testing, it seems that if it's nil, the commands >> affected by the setting just treat the commented-out text as if it >> wasn't commented out. > >> So the answer to your last question seems to be "yes". > >> ;; (foo > >> (bar zot)) > >> However, pretty much the same thing happens with a non-nil value, too -- >> with point before (foo C-M-f will advance past zot)). > >> So it doesn't treat comments as whitespace, really -- it only does that >> if point is outside (before, at the end of a line, etc) the comment to >> begin with. Seems like you could write an essay about it, but perhaps >> it's not worth listing the eccentricities here which I guess could change. > > parse-sexp-ignore-comments (or, rather, parse_sexp_ignore_comments) is > tested, and acted upon, by precisely one C function, scan_lists in > syntax.c. scan_lists is used by just two primitives, scan-lists and > scan-sexps. These, in turn, are called by forward-list, etc. > > When this variable is nil, scan_lists fails to recognise comment > delimiters - it just goes past them as though they were random > punctuation characters. By contrast, when parse-sexp-ignore-comments is > t, scan_lists calls a comment scanning function when it encounters a > comment delimiter. > > Noteworthy is that parse-partial-sexp doesn't respect the setting of > parse-sexp-ignore-comments. This might be considered a bug. > > All in all, this variable seems not to be a good idea. It is not tested > consistently by the syntax routines (see above), must be set explicitly > to t by any major mode with comments, the nil value is rarely used, and > it is not clear whether this nil value is actually ever useful. > > It would seem that if a major mode does not want comments to be > recognised, it would be better not to give any character comment syntax > in its syntax table. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no