From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Reuben Thomas via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#18132: Time for a smarter dired-guess-shell-alist-default? (dired-x.el) Date: Sat, 23 Oct 2021 21:53:17 +0100 Message-ID: References: <87d2cn67zo.fsf@mail.jurta.org> <87bns6dcul.fsf@mail.jurta.org> <87silbstsc.fsf@mail.jurta.org> <83lf2k5gna.fsf@gnu.org> Reply-To: Reuben Thomas Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e3e39d05cf0b51a7" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23934"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 18132@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 23 22:54:11 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1meO1q-00060a-SG for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 Oct 2021 22:54:10 +0200 Original-Received: from localhost ([::1]:44502 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1meO1p-0005xh-Ex for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 Oct 2021 16:54:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58458) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1meO1i-0005xL-5N for bug-gnu-emacs@gnu.org; Sat, 23 Oct 2021 16:54:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54148) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1meO1h-0000gO-SR for bug-gnu-emacs@gnu.org; Sat, 23 Oct 2021 16:54:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1meO1h-0007xQ-RJ for bug-gnu-emacs@gnu.org; Sat, 23 Oct 2021 16:54:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Reuben Thomas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 23 Oct 2021 20:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18132 X-GNU-PR-Package: emacs Original-Received: via spool by 18132-submit@debbugs.gnu.org id=B18132.163502241930558 (code B ref 18132); Sat, 23 Oct 2021 20:54:01 +0000 Original-Received: (at 18132) by debbugs.gnu.org; 23 Oct 2021 20:53:39 +0000 Original-Received: from localhost ([127.0.0.1]:37461 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meO1L-0007wn-7l for submit@debbugs.gnu.org; Sat, 23 Oct 2021 16:53:39 -0400 Original-Received: from mail-pf1-f170.google.com ([209.85.210.170]:38786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1meO1H-0007wY-7b for 18132@debbugs.gnu.org; Sat, 23 Oct 2021 16:53:37 -0400 Original-Received: by mail-pf1-f170.google.com with SMTP id k26so6818253pfi.5 for <18132@debbugs.gnu.org>; Sat, 23 Oct 2021 13:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mChTIT2+0PYhPUZEBBHJ3PRd+J4CN2XqpqUDnrPVog4=; b=pLcyV+w6v7GGLK62pkMTU6wknZzrrn3KyVlSOmsoa4mhNlZBltInTg//422m/7AMPb ojul332lDMYcJqpahlcNOgWAPr5rBRRuZPg8afV6yrbD4yQk6IpX9yoRSnh67iwAe9Qp xdqCm/0Z0rBqZUbzQuhSBXxyuW8akVzgRRAbE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mChTIT2+0PYhPUZEBBHJ3PRd+J4CN2XqpqUDnrPVog4=; b=s8PsOzgcCP1fM0lGf8IPPAmKKanmmZUcLDeaaD18Pj7p49/f41ArXGYka+Z0P9aU2o xM9ZnDiUjxuSy5BKIqbr+o4662S7pASh4naRbhtwui8TuPS1eYJ2pdZ+ExW04ZteAlo3 shAOzaRKbPE2AgvXu7q7YxVBAw/nyErNFk06eLOz9EZ8gthaZxOAY+1x8QuVDRICwSzJ pzO7Psb7F0Q0SOQnvnmQPazX/Iyg/ERqfQjpUbZzSmX75QcST+VT0QRy5m4mXxzns2Fb IXqAAipVM3/rrF4Ar81+ryAwUWSaGbsX/vn42M2HhW7UFGbvd33U6RwZIGurblljeDjj plrg== X-Gm-Message-State: AOAM533JctNPRO6MelpuJU5Fu9o4P0E93m1p8mofnj3yFS7AS3yBJtjy RK0twroC0+8RHaOmo77lxtszP12XuyA+ZLkInKtqcw== X-Google-Smtp-Source: ABdhPJxZgwybv8M1I8Lm/xIEPu+Z9aOps4WA5qtihrr/PfmjvjUpEdOEe166zd7GbCXHyrNfRCP3H23GGxvSHXyiDLc= X-Received: by 2002:a63:2b85:: with SMTP id r127mr6199315pgr.215.1635022409025; Sat, 23 Oct 2021 13:53:29 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:218048 Archived-At: --000000000000e3e39d05cf0b51a7 Content-Type: text/plain; charset="UTF-8" On Sat, 23 Oct 2021 at 16:45, Stefan Kangas wrote: > > What I want is more or less the exact behavior of xdg-open, but I want > to be able to check the actual command (e.g. "evince", not just > "xdg-open") before pressing RET. > I don't understand why this is useful. If you want a particular command for every file of a type, configure it; if you want a particular command this time, specify it. I also want to be able to override xdg-open with customizations inside > Emacs. > This just adds complexity to the system. Please bare with me as I'm trying to understand. > "bear" ;) Is your preference still to just run "xdg-open", as you explained in > your original bug report? Yes. Do you agree that if we could get my idea to work, you could have your > cake and eat it too? No, because I was hoping we could make the cake smaller. IOW, do you disagree with the approach because you > think it is infeasible to make it work well, or because you don't think > that the feature sounds useful? Or do you merely disagree with using > mailcap to implement it? > I agree with Eli that mailcap is not a good match; also it's widely considered deprecated (for example, GNOME's mechanism doesn't use it), so its configuration is likely to be out of date. Mostly, I am afraid that a suggestion which satisfies everyone in terms of functionality will simply pile on more features to Emacs, in an area which is already too complicated. I don't see why launching external applications can't be left to the operating environment, as all environments now have mature systems for doing this. If someone such as you wants more complex functionality, that can be served by a third-party package; it doesn't need to be built in to Emacs. -- https://rrt.sc3d.org --000000000000e3e39d05cf0b51a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, 23 Oct 2021 at 16:45, Stefan Kangas <stefan@marxist.se> wrote:

What I want is more or less the exact behavior of xdg-open, but I want
to be able to check the actual command (e.g. "evince", not just "xdg-open") before pressing RET.

<= div>
I don't understand why this is useful. If you wa= nt a particular command for every file of a type, configure it; if you want= a particular command this time, specify it.

I also want to be able to override xdg-open with customizations inside
Emacs.

This just add= s complexity to the system.

Please bare with me as I'm trying to understand.
<= br>
"bear" ;)

Is your preference still to just run "xdg-open", as you explained= in
your original bug report?

Yes.

Do you agree that if we could get my idea to work, you could have your
cake and eat it too?

No,= because I was hoping we could make the cake smaller.

=C2=A0 IOW, do you disagree with the approach beca= use you
think it is infeasible to make it work well, or because you don't think=
that the feature sounds useful?=C2=A0 Or do you merely disagree with using<= br> mailcap to implement it?

I agree with Eli that mailcap is not a good match; also it's widel= y considered deprecated (for example, GNOME's mechanism doesn't use= it), so its configuration is likely to be out of date.

Mostly, I am afraid that a suggestion whi= ch satisfies everyone in terms of functionality will simply pile on more fe= atures to Emacs, in an area which is already too complicated. I don't s= ee why launching external applications can't be left to the operating e= nvironment, as all environments now have mature systems for doing this. If = someone such as you wants more complex functionality, that can be served by= a third-party package; it doesn't need to be built in to Emacs.

--
--000000000000e3e39d05cf0b51a7--