bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18132: Time for a smarter dired-guess-shell-alist-default? (dired-x.


From: Stefan Kangas
Subject: bug#18132: Time for a smarter dired-guess-shell-alist-default? (dired-x.el)
Date: Fri, 22 Oct 2021 22:25:09 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Reuben Thomas <rrt@sc3d.org> writes:

> Unfortunately, we seem to have strayed from my question, "can I
> replace dired-guess-shell-* with a function that calls a suitable
> file-type dispatcher (xdg-open, open, w32-shell-execute &c.)" to a
> discussion of mailcap support, which is related, but perhaps better
> dealt with separately (given that I'm talking about removing, not
> adding, functionality from Emacs).
>
> I was really trying to address two concerns:
>
> 1. Do other maintainers agree that it is sensible to remove Emacs's
> duplicated mechanism for guessing which command to run on a given
> filetype, and instead use a system mechanism (according to the
> underlying system)?

I agree, but I will add that it would be very nice if we don't lose the
capability of seeing which command will be run on a file when typing &
(dired-do-async-shell-command) on a file in Dired.  It sucks when the
default only says "xdg-open", as you don't know what program that will
open or if it is indeed the one you want.

Does xdg-open have the capability to just print what it would run
without actually executing it?  I can't see such a flag on Debian
stable/bookworm.  If that is missing, should we perhaps add a feature
request for it?

https://www.freedesktop.org/wiki/Software/xdg-utils/

But in that case, we would need to check for that capability first,
somehow...

> 2. I assume that for reasons of backward compatibility it would not be
> acceptable immediately to remove dired-guess-shell-*, hence my
> suggestion to implement step 1 in the first instance by supplying a
> new default value for dired-guess-shell-alist-default. If later this
> variable could be deprecated and replaced with a simple function, so
> much the better.

Right, we can't just remove it outright.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]