bug#6077: 23.1.96; start-process error

bug#6077: 23.1.96; start-process error

[Leo]

When invoking browse-url in a buffer where the default directory no
longer exists which happens quite often if you have long-running emacs
session, the following error is generated and browse-url aborts the
action.

Debugger entered--Lisp error: (file-error "Setting current directory" "no such file or directory" "/Users/leo/Desktop/untitled folder/")
  start-process("open http://paste.lisp.org/display/98663" nil "open" "http://paste.lisp.org/display/98663")
  browse-url-default-macosx-browser("http://paste.lisp.org/display/98663" nil)
  apply(browse-url-default-macosx-browser "http://paste.lisp.org/display/98663" nil)
  browse-url("http://paste.lisp.org/display/98663")
  rcirc-browse-url-at-point(19540)
  rcirc-browse-url-at-mouse((mouse-2 (#<window 9505 on #emacs@irc.freenode.net> 19540 (375 . 232) 1105613306 nil 19540 (46 . 15) nil (7 . 7) (8 . 15))))
  call-interactively(rcirc-browse-url-at-mouse nil nil)


I wonder if it makes sense to make start-process more robust in this
case. Thanks.

Leo

bug#6077: 23.1.96; start-process error

[Glenn Morris]

Version: 24.1

This crops up in a few places. I have a vague memory that there is some
problem with/opposition to a general fix. Installed a fix for
browse-url.

bug#6077: 23.1.96; start-process error

[Leo]

On 2011-03-04 16:22 +0800, Glenn Morris wrote:
> Version: 24.1
>
> This crops up in a few places. I have a vague memory that there is some
> problem with/opposition to a general fix. Installed a fix for
> browse-url.

Yes, there is risk in setting a new default directory.

They were discussed in the followup to:
http://permalink.gmane.org/gmane.emacs.devel/135971

But I can't seem to find the thread.

Leo

bug#6077: 23.1.96; start-process error

[Stefan Monnier]

> This crops up in a few places. I have a vague memory that there is some
> problem with/opposition to a general fix. Installed a fix for
> browse-url.

There is opposition to fixing it in start/call-process since it does the
wrong thing if the command uses to relative filenames.  There is no
opposition to "a general fix" at all, although such a general fix would
look like a macro that can easily be added where useful/needed, or maybe
some additional arg, or clever reuse of existing arg.


        Stefan