From unknown Fri Jun 20 18:09:18 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#4819 <4819@debbugs.gnu.org> To: bug#4819 <4819@debbugs.gnu.org> Subject: Status: file-truename's undocumented behavior Reply-To: bug#4819 <4819@debbugs.gnu.org> Date: Sat, 21 Jun 2025 01:09:18 +0000 retitle 4819 file-truename's undocumented behavior reassign 4819 emacs submitter 4819 MON KEY severity 4819 normal tag 4819 wontfix thanks From stan@derbycityprints.com Tue Oct 27 17:28:50 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 28 Oct 2009 00:28:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-0.5 required=4.0 tests=AWL,MURPHY_DRUGS_REL8 autolearn=ham version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9S0Smlv018665 for ; Tue, 27 Oct 2009 17:28:50 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N2wP9-0004tq-UT for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 20:28:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N2wP3-0004nd-Dn for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 20:28:45 -0400 Received: from [199.232.76.173] (port=51311 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N2wP3-0004nV-BR for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 20:28:41 -0400 Received: from mail-yw0-f194.google.com ([209.85.211.194]:33185) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N2wP3-0007kG-14 for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 20:28:41 -0400 Received: by ywh32 with SMTP id 32so241487ywh.14 for ; Tue, 27 Oct 2009 17:28:40 -0700 (PDT) MIME-Version: 1.0 Sender: stan@derbycityprints.com Received: by 10.150.44.2 with SMTP id r2mr27843987ybr.77.1256689720441; Tue, 27 Oct 2009 17:28:40 -0700 (PDT) Date: Tue, 27 Oct 2009 20:28:40 -0400 X-Google-Sender-Auth: 2daeca6eea06147a Message-ID: Subject: file-truename's undocumented behavior From: MON KEY To: bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) This form returns a value. (file-truename "") WHY? I just spent 2 1/2 hours in a break-loop three functions away trying to debug _undocumented_ behavior. GNU Emacs 23.1.50.1 (i386-mingw-nt5.1.2600) of 2009-06-30 on LENNART-69DE564 (patched) From monnier@iro.umontreal.ca Tue Oct 27 18:52:32 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 28 Oct 2009 01:52:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9S1qUfV027736 for ; Tue, 27 Oct 2009 18:52:31 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N2xiA-00076v-9t for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 21:52:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N2xi5-0006xs-Or for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 21:52:29 -0400 Received: from [199.232.76.173] (port=50623 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N2xi5-0006xf-LB for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 21:52:25 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.183]:29845 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N2xi5-00033u-AU for bug-gnu-emacs@gnu.org; Tue, 27 Oct 2009 21:52:25 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwEAOdA50pLd/xb/2dsb2JhbACBT9hOhD8Egl+FXQ X-IronPort-AV: E=Sophos;i="4.44,636,1249272000"; d="scan'208";a="48276094" Received: from 75-119-252-91.dsl.teksavvy.com (HELO ceviche.home) ([75.119.252.91]) by ironport2-out.pppoe.ca with ESMTP; 27 Oct 2009 21:52:24 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 3323D70019; Tue, 27 Oct 2009 21:52:24 -0400 (EDT) From: Stefan Monnier To: MON KEY Cc: 4819@debbugs.gnu.org, bug-gnu-emacs@gnu.org Subject: Re: bug#4819: file-truename's undocumented behavior Message-ID: References: Date: Tue, 27 Oct 2009 21:52:24 -0400 In-Reply-To: (MON KEY's message of "Tue, 27 Oct 2009 20:28:40 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. > This form returns a value. > (file-truename "") > WHY? Why not? What value did you expect? > I just spent 2 1/2 hours in a break-loop three functions away trying > to debug _undocumented_ behavior. Which part of the documentation do you think this behavior contradicts? Stefan From stan@derbycityprints.com Wed Oct 28 13:01:44 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 28 Oct 2009 20:01:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-1.7 required=4.0 tests=AWL,FOURLA,HAS_BUG_NUMBER, MDO_CABLE_TV3 autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9SK1g5X017261 for ; Wed, 28 Oct 2009 13:01:43 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3EiD-0005Io-Km for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 16:01:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3Ei7-00057V-2C for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 16:01:39 -0400 Received: from [199.232.76.173] (port=58430 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3Ei6-000570-8J for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 16:01:34 -0400 Received: from mail-yw0-f194.google.com ([209.85.211.194]:39664) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N3Ei5-00047L-Qd for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 16:01:34 -0400 Received: by ywh32 with SMTP id 32so1006950ywh.14 for ; Wed, 28 Oct 2009 13:01:32 -0700 (PDT) MIME-Version: 1.0 Sender: stan@derbycityprints.com Received: by 10.150.171.17 with SMTP id t17mr8690819ybe.303.1256760092335; Wed, 28 Oct 2009 13:01:32 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Oct 2009 16:01:32 -0400 X-Google-Sender-Auth: 28579b3c0fb5da9f Message-ID: Subject: Re: bug#4819: file-truename's undocumented behavior From: MON KEY To: Stefan Monnier Cc: 4819@debbugs.gnu.org, bug-gnu-emacs@gnu.org Content-Type: multipart/mixed; boundary=000e0cd5c6c0df2f8a04770442ad X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) --000e0cd5c6c0df2f8a04770442ad Content-Type: text/plain; charset=UTF-8 On Tue, Oct 27, 2009 at 9:52 PM, Stefan Monnier wrote: >> This form returns a value. >> (file-truename "") > >> WHY? > > Why not? What value did you expect? I assumed nil. I'm not sure what I would expect esp. having since noted that: (file-relative-name "") ;=> "." (file-exists-p "") ;=> t (file-readable-p "") ;=> t (file-directory-p "") ;=> t (file-name-as-directory "") ;=> "./" However, discarding the state of my "least surprisedness", I would _not_ expect that file-truename would step all over the match-data, and where it does so not before first: a) Using string-match-p where applicable; b) Noting that it does so in the documention. i.e. as per `split-string'. > >> I just spent 2 1/2 hours in a break-loop three functions away trying >> to debug _undocumented_ behavior. > > Which part of the documentation do you think this behavior contradicts? > This part: (file-name-absolute-p "") ;=> nil (file-symlink-p "") ;=> nil On which systems/platforms does "" denote an absolute filename? On which systems/platforms does "" denote a symbolic link for a filename? ,---- (documentation 'file-truename) | Return the truename of filename, which should be absolute. | The truename of a file name is found by chasing symbolic links | both at the level of the file and at the level of the directories | containing it, until no links are left at any level. `---- And, this other part where documentation: a) Neglects to mention that this function invokes repeatedly invokes `string-match' twice per invokation. {...} (unless (string-match "[[*?]" filename) (string-match "~[^/]*/?" filename)) {...} {...} ((and (string= (substring filename 0 1) "~") (string-match "~[^/]*/?" filename)) {...} b) Neglects to mention that the remaining args COUNTER and PREV-DIRS are iterative counters for operations on recursive calls. Which means that where file-truename recurses `string-match' may be invoked more than twice times. ,---- Comments in the definition of `file-truename' in files.el |;; Don't document the optional arguments. |;; COUNTER and PREV-DIRS are only used in recursive calls. |;; COUNTER can be a cons cell whose car is the count of how many |;; more links to chase before getting an error. |;; PREV-DIRS can be a cons cell whose car is an alist |;; of truenames we've just recently computed. `---- It was only as a late afterthought that I realized that it wasn't _MY-CODE+ clobbering the match-data - as is usual : ) but maybe Emacs'. The realization was elusive because the recursion only happens when the w32 conditional which drops into a recursion predicated on the return value of `w32-long-file-name'. {...} (setq filename (concat (file-truename rest) missing)) {...} Why not mention in the docs that on w32 `w32-long-file-name' may be a more suitable alternative esp. as it is a primitive and as it will expand "8.3 DOS" short name aliases in the process. (Again, per _existing_ comments in body of `file-truename's definition). I understand _why_ the optional args have been left undocumented - they are essentially hacks which the user shouldn't rely on. However, I don't understand _why_ the w32 hack isn't made known esp. where the hack is applicable for user code and is indicated as the preferred solution... W/re the string-match vs. string-matchp doesn't the following accomplish the same: ;;; ============================== *** /files.el-p 2009-10-28 15:49:38.843750000 -0400 --- /emacs/lisp/files.el 2009-06-30 15:51:22.000000000 -0400 *************** *** 893,904 **** (setq filename (expand-file-name filename)) (if (string= filename "") (setq filename "/"))) ! ((and (string= (substring filename 0 1) "~") ! (string-match-p "~[^/]*/?" filename)) ! (string-match "~[^/]*/?" filename) ! (let ((first-part ! (substring filename 0 (match-end 0))) ! (rest (substring filename (match-end 0)))) (setq filename (concat (expand-file-name first-part) rest))))) (or counter (setq counter (list 100))) --- 893,903 ---- (setq filename (expand-file-name filename)) (if (string= filename "") (setq filename "/"))) ! ((and (string= (substring filename 0 1) "~") ! (string-match "~[^/]*/?" filename)) ! (let ((first-part ! (substring filename 0 (match-end 0))) ! (rest (substring filename (match-end 0)))) (setq filename (concat (expand-file-name first-part) rest))))) (or counter (setq counter (list 100))) *************** *** 930,936 **** (if handler (setq filename (funcall handler 'file-truename filename)) ;; If filename contains a wildcard, newname will be the old name. ! (unless (string-match-p "[[*?]" filename) ;; If filename exists, use the long name. If it doesn't exist, ;; drill down until we find a directory that exists, and use ;; the long name of that, with the extra non-existent path --- 929,935 ---- (if handler (setq filename (funcall handler 'file-truename filename)) ;; If filename contains a wildcard, newname will be the old name. ! (unless (string-match "[[*?]" filename) ;; If filename exists, use the long name. If it doesn't exist, ;; drill down until we find a directory that exists, and use ;; the long name of that, with the extra non-existent path --000e0cd5c6c0df2f8a04770442ad Content-Type: application/octet-stream; name="diff.files.el" Content-Disposition: attachment; filename="diff.files.el" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g1ciforc0 KioqIC9maWxlcy5lbC1wIDIwMDktMTAtMjggMTU6NDk6MzguODQzNzUwMDAwIC0wNDAwCi0tLSAv ZW1hY3MvbGlzcC9maWxlcy5lbAkyMDA5LTA2LTMwIDE1OjUxOjIyLjAwMDAwMDAwMCAtMDQwMAoq KioqKioqKioqKioqKioKKioqIDg5Myw5MDQgKioqKgogIAkgKHNldHEgZmlsZW5hbWUgKGV4cGFu ZC1maWxlLW5hbWUgZmlsZW5hbWUpKQogIAkgKGlmIChzdHJpbmc9IGZpbGVuYW1lICIiKQogIAkg ICAgIChzZXRxIGZpbGVuYW1lICIvIikpKQohICAgICAgICAgKChhbmQgKHN0cmluZz0gKHN1YnN0 cmluZyBmaWxlbmFtZSAwIDEpICJ+IikKISAgICAgICAgICAgICAgIChzdHJpbmctbWF0Y2gtcCAi flteL10qLz8iIGZpbGVuYW1lKSkKISAgICAgICAgICAoc3RyaW5nLW1hdGNoICJ+W14vXSovPyIg ZmlsZW5hbWUpCiEgICAgICAgICAgKGxldCAoKGZpcnN0LXBhcnQKISAgICAgICAgICAgICAgICAg KHN1YnN0cmluZyBmaWxlbmFtZSAwIChtYXRjaC1lbmQgMCkpKQohICAgICAgICAgICAgICAgIChy ZXN0IChzdWJzdHJpbmcgZmlsZW5hbWUgKG1hdGNoLWVuZCAwKSkpKQkKICAJICAgKHNldHEgZmls ZW5hbWUgKGNvbmNhdCAoZXhwYW5kLWZpbGUtbmFtZSBmaXJzdC1wYXJ0KSByZXN0KSkpKSkKICAK ICAgIChvciBjb3VudGVyIChzZXRxIGNvdW50ZXIgKGxpc3QgMTAwKSkpCi0tLSA4OTMsOTAzIC0t LS0KICAJIChzZXRxIGZpbGVuYW1lIChleHBhbmQtZmlsZS1uYW1lIGZpbGVuYW1lKSkKICAJIChp ZiAoc3RyaW5nPSBmaWxlbmFtZSAiIikKICAJICAgICAoc2V0cSBmaWxlbmFtZSAiLyIpKSkKISAJ KChhbmQgKHN0cmluZz0gKHN1YnN0cmluZyBmaWxlbmFtZSAwIDEpICJ+IikKISAJICAgICAgKHN0 cmluZy1tYXRjaCAiflteL10qLz8iIGZpbGVuYW1lKSkKISAJIChsZXQgKChmaXJzdC1wYXJ0CiEg CQkoc3Vic3RyaW5nIGZpbGVuYW1lIDAgKG1hdGNoLWVuZCAwKSkpCiEgCSAgICAgICAocmVzdCAo c3Vic3RyaW5nIGZpbGVuYW1lIChtYXRjaC1lbmQgMCkpKSkKICAJICAgKHNldHEgZmlsZW5hbWUg KGNvbmNhdCAoZXhwYW5kLWZpbGUtbmFtZSBmaXJzdC1wYXJ0KSByZXN0KSkpKSkKICAKICAgIChv ciBjb3VudGVyIChzZXRxIGNvdW50ZXIgKGxpc3QgMTAwKSkpCioqKioqKioqKioqKioqKgoqKiog OTMwLDkzNiAqKioqCiAgCShpZiBoYW5kbGVyCiAgCSAgICAoc2V0cSBmaWxlbmFtZSAoZnVuY2Fs bCBoYW5kbGVyICdmaWxlLXRydWVuYW1lIGZpbGVuYW1lKSkKICAJICA7OyBJZiBmaWxlbmFtZSBj b250YWlucyBhIHdpbGRjYXJkLCBuZXduYW1lIHdpbGwgYmUgdGhlIG9sZCBuYW1lLgohIAkgICh1 bmxlc3MgKHN0cmluZy1tYXRjaC1wICJbWyo/XSIgZmlsZW5hbWUpCiAgCSAgICA7OyBJZiBmaWxl bmFtZSBleGlzdHMsIHVzZSB0aGUgbG9uZyBuYW1lLiAgSWYgaXQgZG9lc24ndCBleGlzdCwKICAg ICAgICAgICAgICA7OyBkcmlsbCBkb3duIHVudGlsIHdlIGZpbmQgYSBkaXJlY3RvcnkgdGhhdCBl eGlzdHMsIGFuZCB1c2UKICAgICAgICAgICAgICA7OyB0aGUgbG9uZyBuYW1lIG9mIHRoYXQsIHdp dGggdGhlIGV4dHJhIG5vbi1leGlzdGVudCBwYXRoCi0tLSA5MjksOTM1IC0tLS0KICAJKGlmIGhh bmRsZXIKICAJICAgIChzZXRxIGZpbGVuYW1lIChmdW5jYWxsIGhhbmRsZXIgJ2ZpbGUtdHJ1ZW5h bWUgZmlsZW5hbWUpKQogIAkgIDs7IElmIGZpbGVuYW1lIGNvbnRhaW5zIGEgd2lsZGNhcmQsIG5l d25hbWUgd2lsbCBiZSB0aGUgb2xkIG5hbWUuCiEgCSAgKHVubGVzcyAoc3RyaW5nLW1hdGNoICJb Wyo/XSIgZmlsZW5hbWUpCiAgCSAgICA7OyBJZiBmaWxlbmFtZSBleGlzdHMsIHVzZSB0aGUgbG9u ZyBuYW1lLiAgSWYgaXQgZG9lc24ndCBleGlzdCwKICAgICAgICAgICAgICA7OyBkcmlsbCBkb3du IHVudGlsIHdlIGZpbmQgYSBkaXJlY3RvcnkgdGhhdCBleGlzdHMsIGFuZCB1c2UKICAgICAgICAg ICAgICA7OyB0aGUgbG9uZyBuYW1lIG9mIHRoYXQsIHdpdGggdGhlIGV4dHJhIG5vbi1leGlzdGVu dCBwYXRoCg== --000e0cd5c6c0df2f8a04770442ad-- From monnier@iro.umontreal.ca Wed Oct 28 17:38:06 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 29 Oct 2009 00:38:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-3.3 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9T0c36q012118 for ; Wed, 28 Oct 2009 17:38:05 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3J1e-00072M-8Y for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 20:38:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3J1Z-000700-NW for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 20:38:01 -0400 Received: from [199.232.76.173] (port=57510 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3J1Z-0006zw-AF for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 20:37:57 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.183]:9968 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N3J1Y-0003hT-OF for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 20:37:57 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEAMiA6EpLd/xb/2dsb2JhbACBT9oAhD8EgmSFZw X-IronPort-AV: E=Sophos;i="4.44,642,1249272000"; d="scan'208";a="48337267" Received: from 75-119-252-91.dsl.teksavvy.com (HELO pastel.home) ([75.119.252.91]) by ironport2-out.pppoe.ca with ESMTP; 28 Oct 2009 20:37:53 -0400 Received: by pastel.home (Postfix, from userid 20848) id 946D98013; Wed, 28 Oct 2009 20:37:53 -0400 (EDT) From: Stefan Monnier To: MON KEY Cc: 4819@debbugs.gnu.org, bug-gnu-emacs@gnu.org Subject: Re: bug#4819: file-truename's undocumented behavior Message-ID: References: Date: Wed, 28 Oct 2009 20:37:53 -0400 In-Reply-To: (MON KEY's message of "Wed, 28 Oct 2009 16:01:32 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. > I assumed nil. That would be very unexpected, since file-truename otherwise always returns a string when passed a string. > However, discarding the state of my "least surprisedness", I would > _not_ expect that file-truename would step all over the match-data, > and where it does so not before first: Most functions don't preserve the match-data, and even more so for functions that manipulate strings or buffers. > b) Noting that it does so in the documention. i.e. as per `split-string'. It's the other way around: the few functions that preserve the match-data should be documented as such (better yet: the byte-compiler should be taught about them, so it can detect when we use the match-data after it got clobbered). >>> I just spent 2 1/2 hours in a break-loop three functions away trying >>> to debug _undocumented_ behavior. >> Which part of the documentation do you think this behavior contradicts? > This part: > (file-name-absolute-p "") ;=> nil > (file-symlink-p "") ;=> nil That's not a part of the documentation. > Why not mention in the docs that on w32 `w32-long-file-name' may be > a more suitable alternative esp. as it is a primitive and as it will > expand "8.3 DOS" short name aliases in the process. (Again, per > _existing_ comments in body of `file-truename's definition). Elisp should generally not be w32-specific, so ratehr than use w32-long-file-name we should maybe change file-truename correspondingly. That doesn't mean I think it's the right thing to do: I know next to nothing about this issue. > ! ((and (string= (substring filename 0 1) "~") > ! (string-match-p "~[^/]*/?" filename)) > ! (string-match "~[^/]*/?" filename) > ! (let ((first-part > ! (substring filename 0 (match-end 0))) > ! (rest (substring filename (match-end 0)))) What's the point? If you're going to use string-match in the end, you might as well do it right away. Stefan From lennart.borgman@gmail.com Wed Oct 28 17:56:55 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 29 Oct 2009 00:56:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9T0usm6014187 for ; Wed, 28 Oct 2009 17:56:55 -0700 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N3JJt-0007mu-Si for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 20:56:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N3JJo-0007mJ-AQ for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 20:56:52 -0400 Received: from [199.232.76.173] (port=39270 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N3JJo-0007mG-4P for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 20:56:48 -0400 Received: from mail-yx0-f191.google.com ([209.85.210.191]:58183) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N3JJn-0006M0-Pr for bug-gnu-emacs@gnu.org; Wed, 28 Oct 2009 20:56:47 -0400 Received: by yxe29 with SMTP id 29so1249587yxe.14 for ; Wed, 28 Oct 2009 17:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Ii9+IaHSMUW2ZEXCJqly2Gq1GnZHinEDOFxhJEv62I4=; b=tMjlQAFSKIVQhsqZ9UaTKBDx+/frhCAjV0+Y/xFN0m7Z4LsshB1B1tUNB0raEy4KB0 kI5Lef3GpcD2hH0UAu/lCGgJkq8KAQXtdLDYXyap426IaNVU+li15YeusajtC0HS81qJ +AigUOnNPKFa8eLgw9/2kKcsOj58olqGWPvg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=GqgJiPaEPDupPkfiXpOy8pCbijCvOL9voTSopVSNT8rW3i2qMBHwaOywNp5r3LQu0c YfJ3Wkr7bQTy1fQZLLJhOLuj7uOw4qarwg4yUY2v7PXu0xyv65tWZ1zl+/6lDO7yZl9d vUR16sWEe3tWOkzJLkrhjL/KQUyJj2Tw5eTm4= MIME-Version: 1.0 Received: by 10.101.34.19 with SMTP id m19mr708632anj.81.1256777806503; Wed, 28 Oct 2009 17:56:46 -0700 (PDT) In-Reply-To: References: From: Lennart Borgman Date: Thu, 29 Oct 2009 01:56:26 +0100 Message-ID: Subject: Re: bug#4819: file-truename's undocumented behavior To: Stefan Monnier , 4819@debbugs.gnu.org Cc: MON KEY , bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) On Thu, Oct 29, 2009 at 1:37 AM, Stefan Monnier wrote: > >> Why not mention in the docs that on w32 `w32-long-file-name' may be >> a more suitable alternative esp. as it is a primitive and as it will >> expand "8.3 DOS" short name aliases in the process. (Again, per >> _existing_ comments in body of `file-truename's definition). > > Elisp should generally not be w32-specific, so ratehr than use > w32-long-file-name we should maybe change > file-truename correspondingly. =C2=A0That doesn't mean I think it's the r= ight > thing to do: I know next to nothing about this issue. It already calls w32-long-file-name. (I am not sure what MON means.) From stan@derbycityprints.com Fri Nov 6 16:01:36 2009 Received: (at submit) by emacsbugs.donarmstrong.com; 7 Nov 2009 00:01:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.5-bugs.debian.org_2005_01_02 (2008-06-10) on rzlab.ucr.edu X-Spam-Level: X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. X-Spam-Status: No, score=-2.1 required=4.0 tests=AWL,HAS_BUG_NUMBER autolearn=unavailable version=3.2.5-bugs.debian.org_2005_01_02 Received: from lists.gnu.org (lists.gnu.org [199.232.76.165]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id nA701ZiO011423 for ; Fri, 6 Nov 2009 16:01:36 -0800 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N6YkJ-0004Az-5J for bug-gnu-emacs@gnu.org; Fri, 06 Nov 2009 19:01:35 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N6YkE-0004AM-J8 for bug-gnu-emacs@gnu.org; Fri, 06 Nov 2009 19:01:34 -0500 Received: from [199.232.76.173] (port=37677 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N6YkE-0004AH-GI for bug-gnu-emacs@gnu.org; Fri, 06 Nov 2009 19:01:30 -0500 Received: from mail-gx0-f212.google.com ([209.85.217.212]:39454) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N6YkE-0001sW-3F for bug-gnu-emacs@gnu.org; Fri, 06 Nov 2009 19:01:30 -0500 Received: by gxk4 with SMTP id 4so1604941gxk.8 for ; Fri, 06 Nov 2009 16:01:29 -0800 (PST) MIME-Version: 1.0 Sender: stan@derbycityprints.com Received: by 10.150.118.36 with SMTP id q36mr8885016ybc.277.1257552088940; Fri, 06 Nov 2009 16:01:28 -0800 (PST) In-Reply-To: References: Date: Fri, 6 Nov 2009 19:01:28 -0500 X-Google-Sender-Auth: 08b6f39a90f94703 Message-ID: Subject: Re: bug#4819: file-truename's undocumented behavior From: MON KEY To: Stefan Monnier Cc: 4819@debbugs.gnu.org, bug-gnu-emacs@gnu.org Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Stefan, I'm very sorry for the delayed response things have been hectic of late. On Wed, Oct 28, 2009 at 7:37 PM, Stefan Monnier wrote: >> I assumed nil. > > That would be very unexpected, since file-truename otherwise always > returns a string when passed a string. Yes, understood; most likely my assumptions are predicated by these seemingly contradictory behaviors: (file-name-absolute-p "") ;=> nil (file-symlink-p "") ;=> nil > > It's the other way around: the few functions that preserve the > match-data should be documented as such (better yet: the byte-compiler > should be taught about them, so it can detect when we use the > match-data after it got clobbered). No argument there :) >>> Which part of the documentation do you think this behavior contradicts? > >> This part: >> (file-name-absolute-p "") ;=> nil >> (file-symlink-p "") ;=> nil > > That's not a part of the documentation. You're right. None the less, this behaviour does contradict behaviour indicated by said docs. > Elisp should generally not be w32-specific, so ratehr than use > w32-long-file-name we should maybe change > file-truename correspondingly. That doesn't mean I think it's the right > thing to do: I know next to nothing about this issue. Best I can gather the existing w32 conditional branch has been around for a long time. i.e. the email address in the comments carry a {...}@harlequin.co.uk domain. > >> ! ((and (string= (substring filename 0 1) "~") >> ! (string-match-p "~[^/]*/?" filename)) >> ! (string-match "~[^/]*/?" filename) >> ! (let ((first-part >> ! (substring filename 0 (match-end 0))) >> ! (rest (substring filename (match-end 0)))) > > What's the point? To avoid setting the match-data b/c it _is not_ necessarily going to be used per the conditional. > If you're going to use string-match in the end, you might as well do it right > away. This is wrong. Though, it may explain how/why the existing situation persists :) > Stefan > s_P From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 16 15:44:22 2010 Received: (at control) by debbugs.gnu.org; 16 Jan 2010 20:44:22 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NWFVN-0001HK-N6 for submit@debbugs.gnu.org; Sat, 16 Jan 2010 15:44:21 -0500 Received: from pantheon-po39.its.yale.edu ([130.132.50.100]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NWFVL-0001HD-Sf for control@debbugs.gnu.org; Sat, 16 Jan 2010 15:44:20 -0500 Received: from furry (173-14-147-246-NewEngland.hfc.comcastbusiness.net [173.14.147.246]) (authenticated bits=0) by pantheon-po39.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o0GKiFUF028568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 16 Jan 2010 15:44:15 -0500 Received: by furry (Postfix, from userid 1000) id 9BFD0C05D; Sat, 16 Jan 2010 13:44:15 -0700 (MST) From: Chong Yidong To: control@debbugs.gnu.org Subject: tags 4819 + wontfix Date: Sat, 16 Jan 2010 15:44:15 -0500 Message-ID: <87aawd4w68.fsf@stupidchicken.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-Spam-Score: -3.5 (---) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.5 (---) tags 4819 + wontfix thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 09 01:51:14 2011 Received: (at 4819-done) by debbugs.gnu.org; 9 Jul 2011 05:51:14 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QfQRd-0004td-PK for submit@debbugs.gnu.org; Sat, 09 Jul 2011 01:51:13 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1QfQRb-0004tP-U2 for 4819-done@debbugs.gnu.org; Sat, 09 Jul 2011 01:51:12 -0400 Received: from localhost ([127.0.0.1]:52315) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QfQRW-0003vy-5k; Sat, 09 Jul 2011 01:51:06 -0400 From: Glenn Morris To: 4819-done@debbugs.gnu.org Subject: Re: bug#4819: file-truename's undocumented behavior References: X-Spook: Vickie Weaver Cohiba Baranyi Waco, Texas ammunition X-Ran: jB_="%-Q5MxJ^6WQ_8cgxccW$t58p/rkTqW|FVv%4u9<\R+$BvPKV"1H~mMBTZ4>TO+z|/ X-Hue: red X-Attribution: GM Date: Sat, 09 Jul 2011 01:51:06 -0400 In-Reply-To: (Stefan Monnier's message of "Wed, 28 Oct 2009 20:37:53 -0400") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: 4819-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) I don't see a need to keep open this particular report, which was marked "wontfix" some time ago. From unknown Fri Jun 20 18:09:18 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 06 Aug 2011 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator