[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emacs and xdg-open
Re: emacs and xdg-open
Tue, 10 Jan 2012 11:07:16 +0800
Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux)
On Tue, Jan 10 2012, Philipp Haselwarter wrote:
> Eric Abrahamsen <address@hidden> writes:
>> I'm running archlinux, stumpwm and emacs, and have had pretty resounding
>> success using dired as my only file manager: in dired I've bound 'e' to
>> a command that passes files to xdg-open, and by dint of copying
>> /usr/share/applications/mimeinfo.cache into
>> ~/.local/share/applications/default.list, the right external
>> applications open files out of dired.
> Thanks for sharing, fits my setup quite well!
There may also be mimeinfo.cache files in
/usr/local/share/applications/, for packages you've installed yourself.
I could probably figure out why xdg-mime doesn't just read those files
directly, but life is short.
> What command you use to call `xdg-open'?
I modified something I found on the internet that originally used
(defun dired-xdg-open-file ()
"Opens the current file in a Dired buffer."
(defun xdg-open-file (filename)
"xdg-opens the specified file."
(interactive "fFile to open: ")
(let ((process-connection-type nil))
(start-process "" nil "/usr/bin/xdg-open" filename)))
;;'e' usually does 'dired-find-file, same as RET, rebinding it here
(define-key dired-mode-map (kbd "e") 'dired-xdg-open-file)))
(setq image-dired-external-viewer "/usr/bin/xdg-open")
> Some programs (eg. mplayer) exit uncleanly when their stderr and stdout
> are closed, which causes xdg-open to reopen the file with the default
> application for unknown mime types, as it appears.
> And allocating a buffer to every started program....
>> The one iffy thing is getting other applications to pass directory
>> references to emacs (ie clicking the dropbox applet icon in the system
>> tray and having the dropbox directory open in dired). Pointing
>> the inode/directory MIME type at emacs works, but starts a new emacs
>> instance. I created a "emacsclient.desktop" file:
>> [Desktop Entry]
>> Exec=emacsclient -n %F
>> And this nearly works, except that the '-n' flag to the emacsclient exec
>> doesn't appear to be respected: emacs still tells me "Press C-x # when
>> you're done editing this file" (this being a dired buffer), and if I
>> kill the buffer it asks: "Buffer `Dropbox' still has clients; kill it?"
>> I guess this is a long shot, but does anyone have a guess as to why the
>> '-n' flag is ignored, and how to fix it? If not, please consider this a
>> (nearly-functional) tutorial on using emacs as your only file manager on
>> linux systems without a proper desktop environment. :)
> I wrote a quick test script, and it looks like it's not Emacs' fault,
> arguments are just not passed on.
> Actually, it the Exec line seems not to be honored; instead simply the
> basename of the .desktop gets executed (ie. just emacsclient).
> So in order to make everything work, you need to create a script with a
> new name (and also beware of applications that don't call emacsclient
> with an argument, it'll fail):
> [ "$@" ] && emacsclient -n $@ || emacsclient -n ~/
> Leave out the -n in the desktop file and rename it accordingly:
This worked, by god, thank you! Just for the record, it seems the "Exec"
line in the desktop file *is* honored, it just drops command-line
arguments (perhaps the whole line could be wrapped in quotes or
something?). Just naming the desktop file the same as my
emacsclient-wrapper script wasn't enough, I had to point the Exec line
at the script itself (I know because when I misspelled that line the
whole thing stopped working). And a good thing too—how bizarre would it
be to have an Exec line that did nothing? Dropping command line
parameters seems weird enough, though…
Anyway, thanks for getting me the rest of the way there!
GNU Emacs 18.104.22.168 (i686-pc-linux-gnu, GTK+ Version 2.24.8)
of 2012-01-04 on pellet