From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#70914: 29.3; Crashes often on Windows Date: Thu, 23 May 2024 16:33:13 +0300 Message-ID: <86cypc4pra.fsf@gnu.org> References: <86bk4z81cu.fsf@gnu.org> <554078779.3957737.1716318331280@mail.yahoo.com> <984937837.4078826.1716352322860@mail.yahoo.com> <829659206.4083070.1716354489264@mail.yahoo.com> <582535681.1158538.1716358337102@mail.yahoo.com> <86zfsi6qdx.fsf@gnu.org> <867cfm6j14.fsf@gnu.org> <86v835676h.fsf@gnu.org> <86le415cmz.fsf@gnu.org> <87v834yg5o.fsf@localhost> <86v8344xtc.fsf@gnu.org> <87pltcyfbk.fsf@localhost> <86ttio4ve7.fsf@gnu.org> <87fru8ycdk.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29805"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70914@debbugs.gnu.org, simendsjo@gmail.com, corwin@bru.st, ssbssa@yahoo.de To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu May 23 15:34:27 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sA8aQ-0007S0-CV for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 23 May 2024 15:34:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sA8a4-0008E6-4B; Thu, 23 May 2024 09:34:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sA8Zv-0008D5-OT for bug-gnu-emacs@gnu.org; Thu, 23 May 2024 09:33:56 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sA8Zv-0003EI-GX for bug-gnu-emacs@gnu.org; Thu, 23 May 2024 09:33:55 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sA8a1-0002rj-R1 for bug-gnu-emacs@gnu.org; Thu, 23 May 2024 09:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 23 May 2024 13:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70914 X-GNU-PR-Package: emacs Original-Received: via spool by 70914-submit@debbugs.gnu.org id=B70914.171647121311005 (code B ref 70914); Thu, 23 May 2024 13:34:01 +0000 Original-Received: (at 70914) by debbugs.gnu.org; 23 May 2024 13:33:33 +0000 Original-Received: from localhost ([127.0.0.1]:59086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sA8ZZ-0002rR-A6 for submit@debbugs.gnu.org; Thu, 23 May 2024 09:33:33 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44798) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sA8ZX-0002r6-5o for 70914@debbugs.gnu.org; Thu, 23 May 2024 09:33:32 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sA8ZK-0003Bl-Uw; Thu, 23 May 2024 09:33:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=mUChumteyiYt+wWDWQapdgEAEnMdQwCPUhgwXX8TFnQ=; b=X1mpqMzGfxSn rv11Dl3tujoDesZHz334llalHSr6kGAk3AUjK8+HtxsV7VR4ifcyv2j71W5H8O2GaM8dtaFV9mznL tSJx5nGy6LWle9+tX+EFmf2Ak45SBgNtTcY23oyiyR9YhQ/mCHK3hSx3oDCsXHWJfR8colv493b20 nwvYIiqwvhSMrSsaX/sf1Ddd8BWAMZaUE9oWFaF29LLkfVmijiiZvMIX55hDpZTFfgp/IJ8kgX2Gz cb8LCyzCMsCNZciTI49VsIq4FiYdkHqc6rP5o2LpqEBBznKe+P5mTjAPmPULs3xSZKtyM3CXTCXr/ u5dXcgqME1JMBOksszxOnQ==; In-Reply-To: <87fru8ycdk.fsf@localhost> (message from Ihor Radchenko on Thu, 23 May 2024 11:51:51 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:285707 Archived-At: > From: Ihor Radchenko > Cc: simendsjo@gmail.com, ssbssa@yahoo.de, corwin@bru.st, 70914@debbugs.gnu.org > Date: Thu, 23 May 2024 11:51:51 +0000 > > Eli Zaretskii writes: > > >> No. Org mode strips file: from the filename and only passes the links > >> path (link is defined as type:path) > > > > Where does that happen? If Org does that on Windows, that's a bug: > > file:// URIs on Windows should be interpreted differently. See > > > > https://en.wikipedia.org/wiki/File_URI_scheme > > There is no bug here. Org mode fontifies links defined by Org mode > syntax: type:path where type can be file,eww,help,etc and path is > text after type:. > > So, when a package/user is supplying custom :activate-func, Org calls it > according to the convention: > > `:activate-func' > > Function to run at the end of Font Lock activation. It must > accept four arguments: > - the buffer position at the start of the link, > - the buffer position at its end, > - the path, as a string, > - a boolean, non-nil when the link has brackets. > > Here, "path" is *Org link path, according to Org mode syntax*. > So, if there is a custom function that should fontify file: links, it > knows that PATH is everything that following file:. In the discussed > case Org mode's file:// link is structured as > > :type: "file" > :type-explicit-p: t > :path: "//" > :format: plain > :raw-link: "file://" > :application: nil > :search-option: nil > > The :activate-func is passed the :path part, and it should know that it > is used for "file" :type. So, it has all the information necessary to > reconstruct the raw link. It can do anything it wants to with that > information. My point is that if the URI is "file://", the corresponding :path on Windows is not "//". > IMHO, the bug is in file-exists-p: I don't think so. "//" is an invalid file name on Windows, so the only requirement from file-exists-p in that case is not to crash. Which it does, after the recent fix. So now the above case is not fatal as it was before, but it is still incorrect, and I hope will be fixed.