GNU bug report logs -
#78830
30.1; M- browse-url-of-buffer doesn't work second time in a row
Previous Next
Reported by: Milen Hristov <milen <at> andreshko.com>
Date: Wed, 18 Jun 2025 21:42:01 UTC
Severity: normal
Found in version 30.1
Fixed in version 31.1
Done: Michael Albinus <michael.albinus <at> gmx.de>
To reply to this bug, email your comments to 78830 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Wed, 18 Jun 2025 21:42:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Milen Hristov <milen <at> andreshko.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 18 Jun 2025 21:42:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
X-Debbugs-Cc:
--text follows this line--
I’m editing pure HTML file over TRAMP. I want to preview it locally and I’m using M- browser-url-of-buffer. The command works flawlessly the first time and it opens the default browser (Safari in my case). I see that Emacs created a local temp file which the browser renders.
When I try to invoke the command second time, after I have done changes to the HTML file (saved or not, the behaviour is the same) - Emacs invokes Mac OS native “Connect to server” menu, which tries automatically to connect to the remote server, where the actual file is.
Expected behaviour is to make another temporary file with the new changes in the buffer and show it locally in the browser or if it needs to fetch the file from the remote, then use tramp, not MacOS “Connect to server"
When I restart the buffer and try again M- browse-url-of-buffer, it works again as expected. However every next time it shows the above described behaviour.
In short, "M- browse-url-of-buffer" always works the first time it is invoked for a buffer, but not after that.
In GNU Emacs 30.1 (build 1, aarch64-apple-darwin21.6.0, NS
appkit-2113.65 Version 12.7.6 (Build 21H1320)) of 2025-02-24 built on
armbob.lan
Windowing system distributor 'Apple', version 10.3.2575
System Description: macOS 15.5
Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp' --with-modules 'CFLAGS=-DFD_SETSIZE=10000
-DDARWIN_UNLIMITED_SELECT' --with-x-toolkit=no'
Configured features:
ACL GLIB GMP GNUTLS JPEG LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER PNG
RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM ZLIB
Important settings:
value of $LANG: en
locale-coding-system: utf-8-unix
Major mode: Web
Minor modes in effect:
envrc-global-mode: t
global-undo-tree-mode: t
undo-tree-mode: t
global-corfu-mode: t
corfu-mode: t
all-the-icons-completion-mode: t
marginalia-mode: t
override-global-mode: t
vertico-mode: t
mood-line-mode: t
delete-selection-mode: t
global-whitespace-mode: t
whitespace-mode: t
pixel-scroll-precision-mode: t
global-display-line-numbers-mode: t
display-line-numbers-mode: t
global-so-long-mode: t
global-eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-regexp-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
hs-minor-mode: t
Load-path shadows:
/Users/milen/.emacs.d/elpa/which-key-20240620.2145/which-key hides /Applications/Emacs.app/Contents/Resources/lisp/which-key
/Users/milen/.emacs.d/elpa/transient-20250609.1609/transient hides /Applications/Emacs.app/Contents/Resources/lisp/transient
/Users/milen/.emacs.d/elpa/bind-key-20230203.2004/bind-key hides /Applications/Emacs.app/Contents/Resources/lisp/bind-key
/Users/milen/.emacs.d/elpa/eglot-1.18/eglot hides /Applications/Emacs.app/Contents/Resources/lisp/progmodes/eglot
Features:
(shadow sort flyspell ispell mail-extr emacsbug message yank-media
rfc822 mml mml-sec epa epg rfc6068 epg-config mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums quail eww url-queue shr pixel-fill kinsoku
url-file svg xml dom puny mm-url gnus nnheader gnus-util mail-utils
range wid-edit mm-util mail-prsvr help-fns radix-tree cl-print eglot
external-completion jsonrpc xref ert ewoc debug backtrace filenotify
imenu mood-line-segment-checker flymake warnings python consult vc-hg
vc-bzr mood-line-segment-vc vc-git vc-dispatcher tramp-cmds
vertico-directory vertico-sort tramp-cache time-stamp tramp-sh project
envrc inheritenv diff-mode track-changes undo-tree diff queue
casual-dired casual-dired-settings dired-aux casual-dired-version
casual-dired-sort-by casual-dired-utils casual-dired-variables elint
checkdoc lisp-mnt casual-lib casual-lib-version transient image-dired
image-dired-tags image-dired-external image-dired-util image-mode exif
wdired dired-x dired dired-loaddefs highlight-indentation hideshow
web-mode advice derived toc-org org ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-macro org-src sh-script smie treesit executable ob-comint
org-pcomplete org-list org-footnote org-faces org-entities noutline
outline org-version ob-emacs-lisp ob-core ob-eval org-cycle org-table ol
org-fold org-fold-core org-keys oc org-loaddefs thingatpt cal-menu
calendar cal-loaddefs org-compat org-macs vterm bookmark pp face-remap
compile text-property-search color term ehelp find-func vterm-module
term/xterm xterm corfu all-the-icons-completion marginalia orderless
edmacro kmacro use-package-bind-key bind-key easy-mmode vertico compat
mood-line all-the-icons all-the-icons-faces data-material
data-weathericons data-octicons data-fileicons data-faicons
data-alltheicons dracula-theme use-package-ensure tramp trampver
tramp-integration files-x tramp-message tramp-compat xdg shell pcomplete
comint ansi-osc parse-time iso8601 time-date format-spec ansi-color
tramp-loaddefs exec-path-from-shell cl-extra help-mode use-package-core
finder-inf delsel disp-table whitespace pixel-scroll cua-base ring
display-line-numbers so-long all-the-icons-completion-autoloads
all-the-icons-autoloads anaphora-autoloads async-autoloads
better-defaults-autoloads ca65-mode-autoloads casual-dired-autoloads
casual-lib-autoloads corfu-autoloads deferred-autoloads
devdocs-autoloads dired-hacks-utils-autoloads dracula-theme-autoloads
eglot-autoloads elfeed-autoloads embark-consult-autoloads
consult-autoloads embark-autoloads envrc-autoloads
erc-terminal-notifier-autoloads exec-path-from-shell-autoloads
flycheck-autoloads forth-mode-autoloads frame-local-autoloads
hideshow-org-autoloads highlight-indent-guides-autoloads
highlight-indentation-autoloads inheritenv-autoloads json-mode-autoloads
rx json-snatcher-autoloads language-id-autoloads magit-autoloads pcase
magit-section-autoloads llama-autoloads marginalia-autoloads
markdown-mode-autoloads mathjax-autoloads mood-line-autoloads
multiple-cursors-autoloads nerd-icons-corfu-autoloads
nerd-icons-autoloads orderless-autoloads pkg-info-autoloads
epl-autoloads polymode-autoloads posframe-autoloads
python-mode-autoloads request-autoloads shrink-path-autoloads
f-autoloads dash-autoloads s-autoloads spinner-autoloads
toc-org-autoloads transient-autoloads tree-sitter-autoloads
tsc-autoloads undo-tree-autoloads queue-autoloads
unicode-fonts-autoloads ucs-utils-autoloads font-utils-autoloads
persistent-soft-autoloads list-utils-autoloads pcache-autoloads
validate-html-autoloads vertico-autoloads vscode-icon-autoloads
vterm-autoloads web-completion-data-autoloads websocket-autoloads
wfnames-autoloads which-key-autoloads info with-editor-autoloads
yasnippet-autoloads package browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs icons password-cache json subr-x map byte-opt
gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl
tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/ns-win ns-win ucs-normalize
mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads kqueue cocoa ns multi-tty make-network-process emacs)
Memory information:
((conses 16 2899022 838266) (symbols 48 66576 8)
(strings 32 354672 42841) (string-bytes 1 6266242) (vectors 16 68170)
(vector-slots 8 1425779 995357) (floats 8 962 9122)
(intervals 56 104036 1815) (buffers 992 23))
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Thu, 19 Jun 2025 06:02:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 78830 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 18 Jun 2025 14:40:49 +0300
> From: Milen Hristov via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> X-Debbugs-Cc:
> --text follows this line--
>
> I’m editing pure HTML file over TRAMP. I want to preview it locally and I’m using M- browser-url-of-buffer. The command works flawlessly the first time and it opens the default browser (Safari in my case). I see that Emacs created a local temp file which the browser renders.
>
> When I try to invoke the command second time, after I have done changes to the HTML file (saved or not, the behaviour is the same) - Emacs invokes Mac OS native “Connect to server” menu, which tries automatically to connect to the remote server, where the actual file is.
> Expected behaviour is to make another temporary file with the new changes in the buffer and show it locally in the browser or if it needs to fetch the file from the remote, then use tramp, not MacOS “Connect to server"
>
> When I restart the buffer and try again M- browse-url-of-buffer, it works again as expected. However every next time it shows the above described behaviour.
>
> In short, "M- browse-url-of-buffer" always works the first time it is invoked for a buffer, but not after that.
I seem to be unable to reproduce this problem, perhaps because I'm not
on macOS. Could you perhaps step with Edebug through
browse-url-of-file (which is called from browse-url-of-buffer) on the
second invocation, and see what goes wrong there and why?
I suspect this part could be relevant:
(when (and (file-remote-p file)
(not browse-url-temp-file-name))
(setq browse-url-temp-file-name (file-local-copy file)
file browse-url-temp-file-name))
(browse-url (browse-url-file-url file))
perhaps because browse-url-temp-file-name is non-nil the second time?
But I don't know how the macOS "Connect to server" menu is invoked;
can you clarify that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Thu, 19 Jun 2025 07:10:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 78830 <at> debbugs.gnu.org (full text, mbox):
[Please use Reply All to reply, to keep our bug tracker CC'ed.]
> From: Milen Hristov <milen <at> andreshko.com>
> Date: Thu, 19 Jun 2025 09:37:32 +0300
>
>
>
> > On 19 Jun 2025, at 9:01, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> >> Date: Wed, 18 Jun 2025 14:40:49 +0300
> >> From: Milen Hristov via "Bug reports for GNU Emacs,
> >> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >>
> >> X-Debbugs-Cc:
> >> --text follows this line--
> >>
> >> I’m editing pure HTML file over TRAMP. I want to preview it locally and I’m using M- browser-url-of-buffer. The command works flawlessly the first time and it opens the default browser (Safari in my case). I see that Emacs created a local temp file which the browser renders.
> >>
> >> When I try to invoke the command second time, after I have done changes to the HTML file (saved or not, the behaviour is the same) - Emacs invokes Mac OS native “Connect to server” menu, which tries automatically to connect to the remote server, where the actual file is.
> >> Expected behaviour is to make another temporary file with the new changes in the buffer and show it locally in the browser or if it needs to fetch the file from the remote, then use tramp, not MacOS “Connect to server"
> >>
> >> When I restart the buffer and try again M- browse-url-of-buffer, it works again as expected. However every next time it shows the above described behaviour.
> >>
> >> In short, "M- browse-url-of-buffer" always works the first time it is invoked for a buffer, but not after that.
> >
> > I seem to be unable to reproduce this problem, perhaps because I'm not
> > on macOS. Could you perhaps step with Edebug through
> > browse-url-of-file (which is called from browse-url-of-buffer) on the
> > second invocation, and see what goes wrong there and why?
> >
> > I suspect this part could be relevant:
> >
> > (when (and (file-remote-p file)
> > (not browse-url-temp-file-name))
> > (setq browse-url-temp-file-name (file-local-copy file)
> > file browse-url-temp-file-name))
> > (browse-url (browse-url-file-url file))
> >
> > perhaps because browse-url-temp-file-name is non-nil the second time?
> > But I don't know how the macOS "Connect to server" menu is invoked;
> > can you clarify that?
>
>
> I stepped through it and it seems the MacOS dialog window is triggered on line 822 of browse-url.el:
>
> (setq file-name browse-url-temp-file-name)
> (write-region (point-min) (point-max) file-name nil 'no-message))
> (browse-url-of-file file-name))))
>
> more specifically here: (browse-url-of-file file-name)
Thanks, that was my guess. I asked you to step through the code of
browse-url-of-file itself, for that reason. (Let me know if you need
help with using Edebug to step into function calls like this.) The
code snippet I show is from browse-url-of-file, and it specifically
tests whether the file is remote or not, so I think something is wrong
in that logic.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Sat, 28 Jun 2025 09:23:03 GMT)
Full text and
rfc822 format available.
Message #14 received at 78830 <at> debbugs.gnu.org (full text, mbox):
Ping! Milen, could you please answer my questions, so we could make
progress with this bug?
> Cc: 78830 <at> debbugs.gnu.org
> Date: Thu, 19 Jun 2025 10:09:11 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> [Please use Reply All to reply, to keep our bug tracker CC'ed.]
>
> > From: Milen Hristov <milen <at> andreshko.com>
> > Date: Thu, 19 Jun 2025 09:37:32 +0300
> >
> >
> >
> > > On 19 Jun 2025, at 9:01, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > >
> > >> Date: Wed, 18 Jun 2025 14:40:49 +0300
> > >> From: Milen Hristov via "Bug reports for GNU Emacs,
> > >> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> > >>
> > >> X-Debbugs-Cc:
> > >> --text follows this line--
> > >>
> > >> I’m editing pure HTML file over TRAMP. I want to preview it locally and I’m using M- browser-url-of-buffer. The command works flawlessly the first time and it opens the default browser (Safari in my case). I see that Emacs created a local temp file which the browser renders.
> > >>
> > >> When I try to invoke the command second time, after I have done changes to the HTML file (saved or not, the behaviour is the same) - Emacs invokes Mac OS native “Connect to server” menu, which tries automatically to connect to the remote server, where the actual file is.
> > >> Expected behaviour is to make another temporary file with the new changes in the buffer and show it locally in the browser or if it needs to fetch the file from the remote, then use tramp, not MacOS “Connect to server"
> > >>
> > >> When I restart the buffer and try again M- browse-url-of-buffer, it works again as expected. However every next time it shows the above described behaviour.
> > >>
> > >> In short, "M- browse-url-of-buffer" always works the first time it is invoked for a buffer, but not after that.
> > >
> > > I seem to be unable to reproduce this problem, perhaps because I'm not
> > > on macOS. Could you perhaps step with Edebug through
> > > browse-url-of-file (which is called from browse-url-of-buffer) on the
> > > second invocation, and see what goes wrong there and why?
> > >
> > > I suspect this part could be relevant:
> > >
> > > (when (and (file-remote-p file)
> > > (not browse-url-temp-file-name))
> > > (setq browse-url-temp-file-name (file-local-copy file)
> > > file browse-url-temp-file-name))
> > > (browse-url (browse-url-file-url file))
> > >
> > > perhaps because browse-url-temp-file-name is non-nil the second time?
> > > But I don't know how the macOS "Connect to server" menu is invoked;
> > > can you clarify that?
> >
> >
> > I stepped through it and it seems the MacOS dialog window is triggered on line 822 of browse-url.el:
> >
> > (setq file-name browse-url-temp-file-name)
> > (write-region (point-min) (point-max) file-name nil 'no-message))
> > (browse-url-of-file file-name))))
> >
> > more specifically here: (browse-url-of-file file-name)
>
> Thanks, that was my guess. I asked you to step through the code of
> browse-url-of-file itself, for that reason. (Let me know if you need
> help with using Edebug to step into function calls like this.) The
> code snippet I show is from browse-url-of-file, and it specifically
> tests whether the file is remote or not, so I think something is wrong
> in that logic.
>
>
>
>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Sat, 28 Jun 2025 12:15:06 GMT)
Full text and
rfc822 format available.
Message #17 received at 78830 <at> debbugs.gnu.org (full text, mbox):
Apologies, I think I misunderstood which function should I step through.
I’ve stepped in through browse-url-of-file now and I think I found a suspect:
on line 754 in: (browse-url (browse-url-file-url file))
`browse-url-file-url file` seems to be evaluated to `ftp://ssh/_path_to_the_remote_file`, which is the remote file path but with ftp:// protocol added for some reason at the beginning, whereas the first time when the function is triggered the evaluated url is file://_path_to_the_local_rendered_html i.e. the correct path to the local rendered html.
I hope this helps.
> On 28 Jun 2025, at 12:22, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> Ping! Milen, could you please answer my questions, so we could make
> progress with this bug?
>
>> Cc: 78830 <at> debbugs.gnu.org
>> Date: Thu, 19 Jun 2025 10:09:11 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>>
>> [Please use Reply All to reply, to keep our bug tracker CC'ed.]
>>
>>> From: Milen Hristov <milen <at> andreshko.com>
>>> Date: Thu, 19 Jun 2025 09:37:32 +0300
>>>
>>>
>>>
>>>> On 19 Jun 2025, at 9:01, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>>
>>>>> Date: Wed, 18 Jun 2025 14:40:49 +0300
>>>>> From: Milen Hristov via "Bug reports for GNU Emacs,
>>>>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>>>>
>>>>> X-Debbugs-Cc:
>>>>> --text follows this line--
>>>>>
>>>>> I’m editing pure HTML file over TRAMP. I want to preview it locally and I’m using M- browser-url-of-buffer. The command works flawlessly the first time and it opens the default browser (Safari in my case). I see that Emacs created a local temp file which the browser renders.
>>>>>
>>>>> When I try to invoke the command second time, after I have done changes to the HTML file (saved or not, the behaviour is the same) - Emacs invokes Mac OS native “Connect to server” menu, which tries automatically to connect to the remote server, where the actual file is.
>>>>> Expected behaviour is to make another temporary file with the new changes in the buffer and show it locally in the browser or if it needs to fetch the file from the remote, then use tramp, not MacOS “Connect to server"
>>>>>
>>>>> When I restart the buffer and try again M- browse-url-of-buffer, it works again as expected. However every next time it shows the above described behaviour.
>>>>>
>>>>> In short, "M- browse-url-of-buffer" always works the first time it is invoked for a buffer, but not after that.
>>>>
>>>> I seem to be unable to reproduce this problem, perhaps because I'm not
>>>> on macOS. Could you perhaps step with Edebug through
>>>> browse-url-of-file (which is called from browse-url-of-buffer) on the
>>>> second invocation, and see what goes wrong there and why?
>>>>
>>>> I suspect this part could be relevant:
>>>>
>>>> (when (and (file-remote-p file)
>>>> (not browse-url-temp-file-name))
>>>> (setq browse-url-temp-file-name (file-local-copy file)
>>>> file browse-url-temp-file-name))
>>>> (browse-url (browse-url-file-url file))
>>>>
>>>> perhaps because browse-url-temp-file-name is non-nil the second time?
>>>> But I don't know how the macOS "Connect to server" menu is invoked;
>>>> can you clarify that?
>>>
>>>
>>> I stepped through it and it seems the MacOS dialog window is triggered on line 822 of browse-url.el:
>>>
>>> (setq file-name browse-url-temp-file-name)
>>> (write-region (point-min) (point-max) file-name nil 'no-message))
>>> (browse-url-of-file file-name))))
>>>
>>> more specifically here: (browse-url-of-file file-name)
>>
>> Thanks, that was my guess. I asked you to step through the code of
>> browse-url-of-file itself, for that reason. (Let me know if you need
>> help with using Edebug to step into function calls like this.) The
>> code snippet I show is from browse-url-of-file, and it specifically
>> tests whether the file is remote or not, so I think something is wrong
>> in that logic.
>>
>>
>>
>>
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Sat, 05 Jul 2025 08:32:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 78830 <at> debbugs.gnu.org (full text, mbox):
> From: Milen Hristov <milen <at> andreshko.com>
> Date: Sat, 28 Jun 2025 15:13:37 +0300
> Cc: 78830 <at> debbugs.gnu.org
>
> Apologies, I think I misunderstood which function should I step through.
>
> I’ve stepped in through browse-url-of-file now and I think I found a suspect:
>
> on line 754 in: (browse-url (browse-url-file-url file))
>
> `browse-url-file-url file` seems to be evaluated to `ftp://ssh/_path_to_the_remote_file`, which is the remote file path but with ftp:// protocol added for some reason at the beginning, whereas the first time when the function is triggered the evaluated url is file://_path_to_the_local_rendered_html i.e. the correct path to the local rendered html.
Thanks, I think we are close.
Michael, could you please help? I see that browse-url-file-url could
prepend "ftp://" to the file name, but I don't understand the logic of
doing that. Perhaps the regexps in the default value of
browse-url-filename-alist need some adjustments?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Mon, 07 Jul 2025 08:49:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 78830 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli & Milen,
>> I’ve stepped in through browse-url-of-file now and I think I found a suspect:
>>
>> on line 754 in: (browse-url (browse-url-file-url file))
>>
>> `browse-url-file-url file` seems to be evaluated to
>> `ftp://ssh/_path_to_the_remote_file`, which is the remote file path
>> but with ftp:// protocol added for some reason at the beginning,
>> whereas the first time when the function is triggered the evaluated
>> url is file://_path_to_the_local_rendered_html i.e. the correct path
>> to the local rendered html.
>
> Thanks, I think we are close.
>
> Michael, could you please help? I see that browse-url-file-url could
> prepend "ftp://" to the file name, but I don't understand the logic of
> doing that. Perhaps the regexps in the default value of
> browse-url-filename-alist need some adjustments?
I could reproduce the problem locally. The problem is the inconsistent
handling of browse-url-temp-file-name. The appended patch (on top of
Emacs master, aka 31.0.50) fixes this for me.
Milen, do you have a chance to test it?
Best regards, Michael.
[Message part 2 (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Wed, 09 Jul 2025 21:02:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 78830 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thank you, Michael. However, I’m struggling to find out how to apply this patch. Is it suppose to be applied only on the source of Emacs or can I “live patch” my instance on Mac OS? I found the target file in Applications/Emacs folder on MacOS but it’s .gz and the paths in the patch file you provided are different.
> On 7 Jul 2025, at 11:48, Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Hi Eli & Milen,
>
>>> I’ve stepped in through browse-url-of-file now and I think I found a suspect:
>>>
>>> on line 754 in: (browse-url (browse-url-file-url file))
>>>
>>> `browse-url-file-url file` seems to be evaluated to
>>> `ftp://ssh/_path_to_the_remote_file`, which is the remote file path
>>> but with ftp:// protocol added for some reason at the beginning,
>>> whereas the first time when the function is triggered the evaluated
>>> url is file://_path_to_the_local_rendered_html i.e. the correct path
>>> to the local rendered html.
>>
>> Thanks, I think we are close.
>>
>> Michael, could you please help? I see that browse-url-file-url could
>> prepend "ftp://" to the file name, but I don't understand the logic of
>> doing that. Perhaps the regexps in the default value of
>> browse-url-filename-alist need some adjustments?
>
> I could reproduce the problem locally. The problem is the inconsistent
> handling of browse-url-temp-file-name. The appended patch (on top of
> Emacs master, aka 31.0.50) fixes this for me.
>
> Milen, do you have a chance to test it?
>
> Best regards, Michael.
>
[Mail Attachment (text/x-patch, attachment)]
[Message part 3 (text/plain, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Thu, 10 Jul 2025 07:12:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 78830 <at> debbugs.gnu.org (full text, mbox):
Milen Hristov <milen <at> andreshko.com> writes:
Hi Milen,
> Thank you, Michael. However, I’m struggling to find out how to apply
> this patch. Is it suppose to be applied only on the source of Emacs or
> can I “live patch” my instance on Mac OS? I found the target file in
> Applications/Emacs folder on MacOS but it’s .gz and the paths in the
> patch file you provided are different.
browse-url.el is too different between Emacs 30 and 31; you cannot apply
the patch on top of Emacs 30.
What you could try is to use browse-url.el from Emacs 31 with your Emacs
30. Something like this:
- Download the recent broese-url.el from Emacs git repo.
<https://cgit.git.savannah.gnu.org/cgit/emacs.git/plain/lisp/net/browse-url.el>.
- Apply the patch on top of it.
- Start Emacs koading this file, for example from ~/lisp:
# emacs -l ~/lisp/browse-url.el
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Thu, 10 Jul 2025 13:26:06 GMT)
Full text and
rfc822 format available.
Message #32 received at 78830 <at> debbugs.gnu.org (full text, mbox):
Hi Michael,
I’ve applied the patch as per your instructions and loaded the patched browse-ulr.el in emacs with -l flag, however I don’t think the file overrides the original browse-url.el
The bug is still there and when I try to step through the function, edebug opens the original file in /Applications/Emacs.app/Contents/Resources/lisp/net/browse-url.el.gz , not the one I loaded with -l flag.
Is there a way to override the original?
Best regards,
Milen
> On 10 Jul 2025, at 10:11, Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Milen Hristov <milen <at> andreshko.com> writes:
>
> Hi Milen,
>
>> Thank you, Michael. However, I’m struggling to find out how to apply
>> this patch. Is it suppose to be applied only on the source of Emacs or
>> can I “live patch” my instance on Mac OS? I found the target file in
>> Applications/Emacs folder on MacOS but it’s .gz and the paths in the
>> patch file you provided are different.
>
> browse-url.el is too different between Emacs 30 and 31; you cannot apply
> the patch on top of Emacs 30.
>
> What you could try is to use browse-url.el from Emacs 31 with your Emacs
> 30. Something like this:
>
> - Download the recent broese-url.el from Emacs git repo.
> <https://cgit.git.savannah.gnu.org/cgit/emacs.git/plain/lisp/net/browse-url.el>.
>
> - Apply the patch on top of it.
>
> - Start Emacs koading this file, for example from ~/lisp:
>
> # emacs -l ~/lisp/browse-url.el
>
> Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Thu, 10 Jul 2025 13:34:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 78830 <at> debbugs.gnu.org (full text, mbox):
Milen Hristov <milen <at> andreshko.com> writes:
> Hi Michael,
Hi Milen,
> I’ve applied the patch as per your instructions and loaded the patched
> browse-ulr.el in emacs with -l flag, however I don’t think the file
> overrides the original browse-url.el
Could you pls show how you did start Emacs from the shell?
> Best regards,
> Milen
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Thu, 10 Jul 2025 13:38:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 78830 <at> debbugs.gnu.org (full text, mbox):
Sure. The patched file is in ~/Downloads/lisp
From terminal I start it with:
emacs -l ~/Downloads/lisp/browse-url.el
> On 10 Jul 2025, at 16:33, Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Milen Hristov <milen <at> andreshko.com> writes:
>
>> Hi Michael,
>
> Hi Milen,
>
>> I’ve applied the patch as per your instructions and loaded the patched
>> browse-ulr.el in emacs with -l flag, however I don’t think the file
>> overrides the original browse-url.el
>
> Could you pls show how you did start Emacs from the shell?
>
>> Best regards,
>> Milen
>
> Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Thu, 10 Jul 2025 13:42:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 78830 <at> debbugs.gnu.org (full text, mbox):
Milen Hristov <milen <at> andreshko.com> writes:
Hi Milen,
> Sure. The patched file is in ~/Downloads/lisp
>
> From terminal I start it with:
>
> emacs -l ~/Downloads/lisp/browse-url.el
Is the file really in ~/Downloads/lisp/? Perhaps, it is in ~/Downloads/?
What happens if you call
# emacs -Q -l ~/Downloads/lisp/browse-url.el
Is there an error message in *Messages* after starting Emacs like this?
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Thu, 10 Jul 2025 13:46:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 78830 <at> debbugs.gnu.org (full text, mbox):
Actually I just tried just opening the file in Emacs and doing ‘eval-buffer’ and the new file has overridden the original one.
Doing it like this, the patch now works fine and the bug disappeared!
As for the loading suggestions, there are no error messages only when i put -l flag.
> On 10 Jul 2025, at 16:41, Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Milen Hristov <milen <at> andreshko.com> writes:
>
> Hi Milen,
>
>> Sure. The patched file is in ~/Downloads/lisp
>>
>> From terminal I start it with:
>>
>> emacs -l ~/Downloads/lisp/browse-url.el
>
> Is the file really in ~/Downloads/lisp/? Perhaps, it is in ~/Downloads/?
>
> What happens if you call
>
> # emacs -Q -l ~/Downloads/lisp/browse-url.el
>
> Is there an error message in *Messages* after starting Emacs like this?
>
> Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Thu, 10 Jul 2025 13:49:03 GMT)
Full text and
rfc822 format available.
Message #47 received at 78830 <at> debbugs.gnu.org (full text, mbox):
Milen Hristov <milen <at> andreshko.com> writes:
Hi Milen,
> Actually I just tried just opening the file in Emacs and doing ‘eval-buffer’ and the new file has overridden the original one.
> Doing it like this, the patch now works fine and the bug disappeared!
Good. The patch works :-)
> As for the loading suggestions, there are no error messages only when i put -l flag.
I cannot parse this sentence. Is there an error message, or not, when you
use the -l option?
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Thu, 10 Jul 2025 13:57:04 GMT)
Full text and
rfc822 format available.
Message #50 received at 78830 <at> debbugs.gnu.org (full text, mbox):
Apologies, someone distracted me when I was writing LOL :)
No, there are no errors when I use -l flag. I started Emacs from the directory where the file is located to avoid any possible path problems. This is the only output:
emacs -l browse-url.el
2025-07-10 16:37:33.650 Emacs-arm64-11[70065:4215613] TSM AdjustCapsLockLEDForKeyTransitionHandling - _ISSetPhysicalKeyboardCapsLockLED Inhibit
Best regards, Milen
>
>> As for the loading suggestions, there are no error messages only when i put -l flag.
>
> I cannot parse this sentence. Is there an error message, or not, when you
> use the -l option?
>
> Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Thu, 10 Jul 2025 14:06:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 78830 <at> debbugs.gnu.org (full text, mbox):
Milen Hristov <milen <at> andreshko.com> writes:
Hi Milen,
> No, there are no errors when I use -l flag. I started Emacs from the directory where the file is located to avoid any possible path problems. This is the only output:
>
> emacs -l browse-url.el
> 2025-07-10 16:37:33.650 Emacs-arm64-11[70065:4215613] TSM AdjustCapsLockLEDForKeyTransitionHandling - _ISSetPhysicalKeyboardCapsLockLED Inhibit
I meant the *Messages* buffer from the started Emacs.
Could you try to start
# emacs -Q -l browse-url.el
What does 'C-h f browse-url-of-buffer' tells you about the used file?
> Best regards, Milen
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Thu, 10 Jul 2025 14:17:04 GMT)
Full text and
rfc822 format available.
Message #56 received at 78830 <at> debbugs.gnu.org (full text, mbox):
Hi Michael,
>
> Could you try to start
>
> # emacs -Q -l browse-url.el
I started it like this.
> I meant the *Messages* buffer from the started Emacs.
This is the *Messages* buffer content:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit
Type q in help window to delete it.
Type q in help window to delete it.
uncompressing browse-url.el.gz...done
browse-url.el.gz has auto save data; consider M-x recover-this-file
uncompressing .!Applications!Emacs.app!Contents!Resources!lisp!net!browse-url.el.gz.~undo-tree~...done
>
> What does 'C-h f browse-url-of-buffer' tells you about the used file?
>
It shows the usual help:
browse-url-of-buffer is an autoloaded interactive byte-code-function
in ‘browse-url.el’.
(browse-url-of-buffer &optional BUFFER)
Use a web browser to display BUFFER.
See ‘browse-url’ for details.
Display the current buffer if BUFFER is nil. Display only the
currently visible part of BUFFER (from a temporary file) if buffer is
narrowed.
When I click on the link to the file, it opens the original el.gz file.
Best regards, Milen
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Thu, 10 Jul 2025 14:26:04 GMT)
Full text and
rfc822 format available.
Message #59 received at 78830 <at> debbugs.gnu.org (full text, mbox):
Milen Hristov <milen <at> andreshko.com> writes:
> Hi Michael,
Hi Milen,
>> I meant the *Messages* buffer from the started Emacs.
>
> This is the *Messages* buffer content:
>
> For information about GNU Emacs and the GNU system, type C-h C-a.
> Quit
> Type q in help window to delete it.
>
> Type q in help window to delete it.
> uncompressing browse-url.el.gz...done
This is a clear indication, that the original browse-url.el from Emacs
30 has used.
>> What does 'C-h f browse-url-of-buffer' tells you about the used file?
>
> It shows the usual help:
>
> browse-url-of-buffer is an autoloaded interactive byte-code-function
> in ‘browse-url.el’.
And this as well. Otherwise, it would show you the complete ‘/path/to/browse-url.el’.
> When I click on the link to the file, it opens the original el.gz file.
Sigh.
Please call Emacs like I have shown, as
# emacs -l /path/to/browse-url.el
> Best regards, Milen
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Thu, 10 Jul 2025 14:39:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 78830 <at> debbugs.gnu.org (full text, mbox):
Hi Michael,
I’ve started emacs with the full absolute path to the file:
emacs -l /Users/milen/Downloads/lisp/browse-url.el
and 'C-h f browse-url-of-buffer’ shows again the same as I wrote in my last message. It still loads the original file. Here’s *Messages* buffer:
For information about GNU Emacs and the GNU system, type C-h C-a.
Type q in help window to delete it.
uncompressing browse-url.el.gz...done
browse-url.el.gz has auto save data; consider M-x recover-this-file
uncompressing .!Applications!Emacs.app!Contents!Resources!lisp!net!browse-url.el.gz.~undo-tree~...done
It seems -l flag doesn’t work at all? It could be the specific build. I’m using one from https://emacsformacosx.com/
Best regards,
Milen
> On 10 Jul 2025, at 17:24, Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Milen Hristov <milen <at> andreshko.com> writes:
>
>> Hi Michael,
>
> Hi Milen,
>
>>> I meant the *Messages* buffer from the started Emacs.
>>
>> This is the *Messages* buffer content:
>>
>> For information about GNU Emacs and the GNU system, type C-h C-a.
>> Quit
>> Type q in help window to delete it.
>>
>> Type q in help window to delete it.
>> uncompressing browse-url.el.gz...done
>
> This is a clear indication, that the original browse-url.el from Emacs
> 30 has used.
>
>>> What does 'C-h f browse-url-of-buffer' tells you about the used file?
>>
>> It shows the usual help:
>>
>> browse-url-of-buffer is an autoloaded interactive byte-code-function
>> in ‘browse-url.el’.
>
> And this as well. Otherwise, it would show you the complete ‘/path/to/browse-url.el’.
>
>> When I click on the link to the file, it opens the original el.gz file.
>
> Sigh.
>
> Please call Emacs like I have shown, as
>
> # emacs -l /path/to/browse-url.el
>
>> Best regards, Milen
>
> Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Thu, 10 Jul 2025 14:42:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 78830 <at> debbugs.gnu.org (full text, mbox):
Milen Hristov <milen <at> andreshko.com> writes:
> Hi Michael,
Hi Milen,
> I’ve started emacs with the full absolute path to the file:
>
> emacs -l /Users/milen/Downloads/lisp/browse-url.el
>
> and 'C-h f browse-url-of-buffer’ shows again the same as I wrote in my last message. It still loads the original file. Here’s *Messages* buffer:
>
> For information about GNU Emacs and the GNU system, type C-h C-a.
> Type q in help window to delete it.
> uncompressing browse-url.el.gz...done
> browse-url.el.gz has auto save data; consider M-x recover-this-file
> uncompressing .!Applications!Emacs.app!Contents!Resources!lisp!net!browse-url.el.gz.~undo-tree~...done
>
> It seems -l flag doesn’t work at all? It could be the specific build. I’m using one from https://emacsformacosx.com/
Have you tried to start 'emacs -Q -l ...'?
> Best regards,
> Milen
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#78830
; Package
emacs
.
(Thu, 10 Jul 2025 14:56:03 GMT)
Full text and
rfc822 format available.
Message #68 received at 78830 <at> debbugs.gnu.org (full text, mbox):
Hi Michael,
I think I found the problem.
`emacs` is an alias to the actual binary on MacOS:
which emacs
emacs: aliased to $(/Applications/Emacs.app/Contents/MacOS/Emacs "$@“)
When calling the alias it doesn’t accept the cli parameters for some reason. If I call the actual binary with the flags it works perfectly - it doesn’t load my config and loads the patched .el file just fine:
browse-url-of-buffer is an autoloaded interactive interpreted-function
in ‘~/Downloads/lisp/browse-url.el’.
(browse-url-of-buffer &optional BUFFER)
Use a web browser to display BUFFER.
See ‘browse-url’ for details.
Display the current buffer if BUFFER is nil. Display only the
currently visible part of BUFFER (from a temporary file) if buffer is
narrowed.
Best regards,
Milen
> On 10 Jul 2025, at 17:41, Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Milen Hristov <milen <at> andreshko.com> writes:
>
>> Hi Michael,
>
> Hi Milen,
>
>> I’ve started emacs with the full absolute path to the file:
>>
>> emacs -l /Users/milen/Downloads/lisp/browse-url.el
>>
>> and 'C-h f browse-url-of-buffer’ shows again the same as I wrote in my last message. It still loads the original file. Here’s *Messages* buffer:
>>
>> For information about GNU Emacs and the GNU system, type C-h C-a.
>> Type q in help window to delete it.
>> uncompressing browse-url.el.gz...done
>> browse-url.el.gz has auto save data; consider M-x recover-this-file
>> uncompressing .!Applications!Emacs.app!Contents!Resources!lisp!net!browse-url.el.gz.~undo-tree~...done
>>
>> It seems -l flag doesn’t work at all? It could be the specific build. I’m using one from https://emacsformacosx.com/
>
> Have you tried to start 'emacs -Q -l ...'?
>
>> Best regards,
>> Milen
>
> Best regards, Michael.
Reply sent
to
Michael Albinus <michael.albinus <at> gmx.de>
:
You have taken responsibility.
(Thu, 10 Jul 2025 15:28:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Milen Hristov <milen <at> andreshko.com>
:
bug acknowledged by developer.
(Thu, 10 Jul 2025 15:28:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 78830-done <at> debbugs.gnu.org (full text, mbox):
Version: 31.1
Milen Hristov <milen <at> andreshko.com> writes:
> Hi Michael,
Hi Milen,
> I think I found the problem.
>
> `emacs` is an alias to the actual binary on MacOS:
>
> which emacs
> emacs: aliased to $(/Applications/Emacs.app/Contents/MacOS/Emacs "$@“)
I cannot comment seriously; no idea what macOS does.
> When calling the alias it doesn’t accept the cli parameters for some reason. If I call the actual binary with the flags it works perfectly - it doesn’t load my config and loads the patched .el file just fine:
>
> browse-url-of-buffer is an autoloaded interactive interpreted-function
> in ‘~/Downloads/lisp/browse-url.el’.
>
> (browse-url-of-buffer &optional BUFFER)
>
> Use a web browser to display BUFFER.
> See ‘browse-url’ for details.
>
> Display the current buffer if BUFFER is nil. Display only the
> currently visible part of BUFFER (from a temporary file) if buffer is
> narrowed.
Great, so we're done. I've pushed the patch to the Emacs repository,
closing the bug therefore.
> Best regards,
> Milen
Best regards, Michael.
This bug report was last modified 5 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.