bug#42431: 28.0.50; browse-url-of-dired-file confusing messaging

[Lars Ingebrigtsen <larsi@gnus.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: michael.albinus@gmx.de,  42431@debbugs.gnu.org
>> Date: Sat, 08 Aug 2020 12:05:04 +0200
>> 
>> >> 	  (condition-case ()
>> >> 	      (let ((inhibit-read-only t))
>> >> 		(insert-file-contents-literally filename t))
>> >> 	    (file-error
>> >> 	     (when (and (file-exists-p filename)
>> >> 			(not (file-readable-p filename)))
>> >> 	       (kill-buffer buf)
>> >> 	       (signal 'file-error (list "File is not readable"
>> >> 					 filename)))
>> >
>> > Is this because file-readable-p returns nil for file:// URLs?
>> 
>> That's the direct cause of the message, but the underlying reason is
>> that insert-file-contents-literally signalled a file-error here (after
>> inserting the contents).  I haven't yet chased down why.

My analysis here was kinda wrong -- the code above isn't what gives the
warning, because all those functions up there do the right thing, since
file-name-handler-alist is set:

  (let ((file-name-handler-alist
         (cons (cons url-handler-regexp 'url-file-handler)
               file-name-handler-alist)))
    (list (file-exists-p "file:///tmp/a.txt")
	  (file-readable-p "file:///tmp/a.txt")))
=> (t t)

The problem is that insert-file-contents signals a file-error, and the
error string is "Success".  This makes things confused, because it knows
that it has an error, but when it tests for all things that could go
wrong, it doesn't find anything, and ends up here:

(defun after-find-file (&optional error warn noauto
				  _after-find-file-from-revert-buffer
				  nomodes)
[...]
	     ((and error (file-attributes buffer-file-name))
	      (setq buffer-read-only t)
	      (if (and (file-symlink-p buffer-file-name)
		       (not (file-exists-p
			     (file-chase-links buffer-file-name))))
		  "Symbolic link that points to nonexistent file"
		"File exists, but cannot be read"))

Which is where the message itself comes from.

> So one solution would be to convert file:// URLs into local file names
> in the above snippet, before calling insert-file-contents-literally.

It would be, but I think this points to an error in insert-file-contents
itself.  I'll poke around some more...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no