browse-url-of-buffer broken at HEAD?

browse-url-of-buffer broken at HEAD?

[T.V Raman]

Simple Test Case:

1. Create  a new empty buffer  called "foo" and switch to it
2. Type this in that buffer:
<p>test</p>
3. M-x browse-url-of-buffer
where browse-url is set up to render using EWW
4. You dont get a rendered result, instead you see the HTML source,
and a message in the minibuffer re loading the HTML5 schema.
5. But if you now switch to *Messages* you see an error
"File exists but cannot be read".
6. /tmp does contain the generated file, and eww-open-file renders it
correctly.

Might be useful when debugging, if you  again try
browse-url-of-buffer, you dont see the error message above (but you
dont get the result rendered either)

Using debug-on-error did not help, it did not enter the debugger.

This error appears relatively new,



-- 

-- 

Re: browse-url-of-buffer broken at HEAD?

[T.V Raman]

"T.V Raman" <raman@google.com> writes:
Additional info:

Restoring browse-url.el from early April makes the problem go away ---
suspect this breakage comes from the recent changes in browse-url to
 allow multiple handlers. I failed to spot the cause after staring at
 the diff 
> Simple Test Case:
>
> 1. Create  a new empty buffer  called "foo" and switch to it
> 2. Type this in that buffer:
> <p>test</p>
> 3. M-x browse-url-of-buffer
> where browse-url is set up to render using EWW
> 4. You dont get a rendered result, instead you see the HTML source,
> and a message in the minibuffer re loading the HTML5 schema.
> 5. But if you now switch to *Messages* you see an error
> "File exists but cannot be read".
> 6. /tmp does contain the generated file, and eww-open-file renders it
> correctly.
>
> Might be useful when debugging, if you  again try
> browse-url-of-buffer, you dont see the error message above (but you
> dont get the result rendered either)
>
> Using debug-on-error did not help, it did not enter the debugger.
>
> This error appears relatively new,
>
>
>
> -- 

-- 

Re: browse-url-of-buffer broken at HEAD?

[Tassilo Horn]

"T.V Raman" <raman@google.com> writes:

> Restoring browse-url.el from early April makes the problem go away ---
> suspect this breakage comes from the recent changes in browse-url to
> allow multiple handlers. I failed to spot the cause after staring at
> the diff

Oh, I'm sorry.  I'll have a look!

Bye,
Tassilo

Re: browse-url-of-buffer broken at HEAD?

[T.V Raman]

Thanks!
Tassilo Horn writes:
 > "T.V Raman" <raman@google.com> writes:
 > 
 > > Restoring browse-url.el from early April makes the problem go away ---
 > > suspect this breakage comes from the recent changes in browse-url to
 > > allow multiple handlers. I failed to spot the cause after staring at
 > > the diff
 > 
 > Oh, I'm sorry.  I'll have a look!
 > 
 > Bye,
 > Tassilo

-- 
Id: kg:/m/0285kf1 

-- 
Id: kg:/m/0285kf1 

Re: browse-url-of-buffer broken at HEAD?

[T.V Raman]

Thanks for checking in the fix so quickly, much appreciated since I
depend on EWW for too many things to count:-)
-- 

Re: browse-url-of-buffer broken at HEAD?

[Tassilo Horn]

"T.V Raman" <raman@google.com> writes:

> Thanks!

Ok, it's the handler for opening all file:// URLs using browse-url-emacs
which basically just visits them using find-file.  With commit
86fef6ab89 I've added another default handler before that which matches
file://.*\.html? URLs and opens those with browse-url-browser-function.
So it should work as you are accustomed again.

The error

  File mode specification error: (file-missing Setting current directory No such file or directory file:///tmp/)

is not my fault but I also get it when evaling

  (browse-url-emacs "file:///tmp/burl6qUEJq.html")

...

Ok, I found the culprit in my customization.  The buffer gets opened in
html-mode which inherits from prog-mode and in prog-mode-hook I enable
bug-reference-mode.  Inside bug-reference-mode-hook I have a function
which sets bug-reference-bug-regexp and bug-reference-url-format
depending on things like the current Gnus group or the current buffer
file's VCS URL.  For the latter, it does

  (shell-command-to-string "git ls-remote --get-url")

and that (or rather call-process called somewhere deeper in the stack)
barfs if default-directory is a file:///tmp/ URL.

I'm not sure if this is a bug but I think so.  I'll report it.

Thanks,
  Tassilo

Re: browse-url-of-buffer broken at HEAD?

[Tassilo Horn]

"T.V Raman" <raman@google.com> writes:

> Thanks for checking in the fix so quickly, much appreciated since I
> depend on EWW for too many things to count:-)

I know, you're welcome. :-)

If some other browse-url stuff behaves differently in the future, have a
look at the value of `browse-url-default-handlers'.  The culprit is most
likely in there.  You can override those default handlers using
`browse-url-handlers'.

Bye,
Tassilo

Re: browse-url-of-buffer broken at HEAD?

[T.V Raman]

Tassilo Horn <tsdh@gnu.org> writes:

Note the error I was seeing in *Messages* was different, it was
"File exists but cannot be read" or something similar
it's gone now.
> "T.V Raman" <raman@google.com> writes:
>
>> Thanks!
>
> Ok, it's the handler for opening all file:// URLs using browse-url-emacs
> which basically just visits them using find-file.  With commit
> 86fef6ab89 I've added another default handler before that which matches
> file://.*\.html? URLs and opens those with browse-url-browser-function.
> So it should work as you are accustomed again.
>
> The error
>
>   File mode specification error: (file-missing Setting current directory No such file or directory file:///tmp/)
>
> is not my fault but I also get it when evaling
>
>   (browse-url-emacs "file:///tmp/burl6qUEJq.html")
>
> ...
>
> Ok, I found the culprit in my customization.  The buffer gets opened in
> html-mode which inherits from prog-mode and in prog-mode-hook I enable
> bug-reference-mode.  Inside bug-reference-mode-hook I have a function
> which sets bug-reference-bug-regexp and bug-reference-url-format
> depending on things like the current Gnus group or the current buffer
> file's VCS URL.  For the latter, it does
>
>   (shell-command-to-string "git ls-remote --get-url")
>
> and that (or rather call-process called somewhere deeper in the stack)
> barfs if default-directory is a file:///tmp/ URL.
>
> I'm not sure if this is a bug but I think so.  I'll report it.
>
> Thanks,
>   Tassilo
>

-- 

Re: browse-url-of-buffer broken at HEAD?

[Tassilo Horn]

"T.V Raman" <raman@google.com> writes:

> Note the error I was seeing in *Messages* was different, it was
> "File exists but cannot be read" or something similar
> it's gone now.

Hm, interesting.  And indeed, files opened with

  (browse-url-emacs "file://...")

are read-only although the file is actually writable.  I'll add that to
bug#41114.

Bye,
Tassilo