From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#24057: 25.1.50; ffap interprets comments beginning with "//" as file path Date: Mon, 25 Jul 2016 20:02:36 +0300 Message-ID: <83mvl5tzv7.fsf@gnu.org> References: <83lh0sx0yf.fsf@gnu.org> <83shv0v716.fsf@gnu.org> <83poq4v4jk.fsf@gnu.org> <83wpkbt92i.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1469466269 30681 80.91.229.3 (25 Jul 2016 17:04:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jul 2016 17:04:29 +0000 (UTC) Cc: 24057@debbugs.gnu.org, npostavs@users.sourceforge.net To: Kaushal Modi Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jul 25 19:04:18 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1bRjIg-0003jR-15 for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Jul 2016 19:04:18 +0200 Original-Received: from localhost ([::1]:33589 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRjIc-0003qA-0v for geb-bug-gnu-emacs@m.gmane.org; Mon, 25 Jul 2016 13:04:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58645) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRjIV-0003nf-OZ for bug-gnu-emacs@gnu.org; Mon, 25 Jul 2016 13:04:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRjIQ-0003rS-OY for bug-gnu-emacs@gnu.org; Mon, 25 Jul 2016 13:04:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53032) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRjIQ-0003rO-KU for bug-gnu-emacs@gnu.org; Mon, 25 Jul 2016 13:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bRjIQ-0003Kx-Ds for bug-gnu-emacs@gnu.org; Mon, 25 Jul 2016 13:04:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 25 Jul 2016 17:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24057 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24057-submit@debbugs.gnu.org id=B24057.146946620112779 (code B ref 24057); Mon, 25 Jul 2016 17:04:02 +0000 Original-Received: (at 24057) by debbugs.gnu.org; 25 Jul 2016 17:03:21 +0000 Original-Received: from localhost ([127.0.0.1]:37136 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bRjHl-0003K3-7N for submit@debbugs.gnu.org; Mon, 25 Jul 2016 13:03:21 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39183) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bRjHi-0003Jq-T7 for 24057@debbugs.gnu.org; Mon, 25 Jul 2016 13:03:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRjHZ-0003Xx-NU for 24057@debbugs.gnu.org; Mon, 25 Jul 2016 13:03:13 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRjHN-0003XB-Ha; Mon, 25 Jul 2016 13:02:57 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1063 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bRjHK-0000rX-47; Mon, 25 Jul 2016 13:02:55 -0400 In-reply-to: (message from Kaushal Modi on Mon, 25 Jul 2016 02:19:13 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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: 208.118.235.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:121524 Archived-At: > From: Kaushal Modi > Date: Mon, 25 Jul 2016 02:19:13 +0000 > Cc: 24057@debbugs.gnu.org, npostavs@users.sourceforge.net > > I tried with a comment that begins like this: > > ////share/foo > > and I don't think the proposed behavior will be correct in all cases. > The problem is that comment-search-forward moves all the way past the > leading 4 slashes, instead of only 2. > > That is expected, as I posted in a table earlier: If I understood you correctly, the table you posted didn't cover systems which support UNC file names, so you asked me to try on such a system. The above was my response to your request. > The problem with that is .. what is a user has a decorative comment like: > > ///I would like to > ///share foo > > It is not possible to know if the user liked to use "//" or "///" or "////" or .. as the comment prefix. Also it is not possible to know if the user meant "/share" or "//share". IMO, it isn't Emacs's place to second-guess the user in a way that prohibits valid use cases. > So the best way to make the user's intent clear is by preceding the path with a space. When there's whitespace between the comment leader and the rest, the problem I'm talking about doesn't exist. > Also thinking that the user meant "//share" in "////share" does not make much sense. It's very confusing to count the number of slashes in there. What is the user has "/////share" (5 slashes)? Where would we want the ffap-string-at-point to guess the comment-starter<>comment boundary then? If you want to code a backward-compatible solution, then skipping the comment-start regexp should do, I think. Where it stops, ffap should start looking for valid file names. > With the current state of ffap-string-at-point, it creates erroneous behavior for many people including me. But with the patch, if a user needs to put a path like "//share" in a comment for a major mode using "//" as comment prefix, all they need to do is use a space to separate the two. Also I think that it is very unlikely that someone would have a confusing comment like "////share" where the user meant "//share" (or "/share"). I see your point. My point is that when we introduce backward-incompatible behavior, which makes previously valid use cases invalid, such incompatible behavior should initially be opt-in, even if it looks to you that the previous behavior made no sense. I have enough gray hair to testify how such decisions in the past turned out to be annoyances for some users. Later, usually years later, we could collect user experience and decide to make this the default behavior. So if you disagree with my suggestion to skip comment-start instead of using comment-search-forward, the behavior you propose should IMO be off by default. Thanks.