From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id 4Hq9DxC93WWfdAEAqHPOHw:P1 (envelope-from ) for ; Tue, 27 Feb 2024 11:44:32 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 4Hq9DxC93WWfdAEAqHPOHw (envelope-from ) for ; Tue, 27 Feb 2024 11:44:32 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1709030672; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=uuh+27o79xLdCg2nEcmnCCyCaIX8UVkV99lZoBD1pF0=; b=M6ej92ogCrR8wzOMy4SpL5rMfmw7ER3DzEyrBJ5aoDHZYs4D/iCQn9iy3coNjEJLEH4Cqg i844pAmGBeJdQctXxy/wulxNNooytQlM/KAVhL5BBDRpG8NUz/c47uZvs05ZPvyEK02eeI 5aRQ14Z9HWGwxGr+aU3wPHZ4baSe1ippovE6Lt3oQozHvYRE/opB/hDEF7hsUYZmXBjHhQ EYmUpzF8FvWF7oQXz1kFuAhKeNXfeChuRPMq5T6oxHfPfzmMcWeuP4AUWVJL4z0hvBNXWW MODn32iDNVBsjQRVYRiXnnjHAl5lrfgRC9/yYbfY84k6Eo9sTtoaAE16s1KJBw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1709030672; a=rsa-sha256; cv=none; b=YopV52nQfeSrOwFu15fGeYNfzM5ZCjIWmtSeCt1EukbHFUaomjd9bKVa7ueUHYKy90AH34 51ndgmncIEtcH01XVAlJpxwmmPZRZvdNH963brazT3dHg3Ur9Ohen2skzewdoZstIUWqeY n2t7lNfb1CfqmaR6K7YLFJWQg9gig5jQY/j2GsnHBn12D5QCSzVEhoW7Lo8AbW++xGk99f KHsL0J2AUa2yMHxfJzDaG2+RpVHWS7S28i6WJzdqbPZk+77rPRdDAIDNzhqBkortR7Zqhf gm6B65F8lg9utO+P9EEsblS5ztuSW2F4b4qVdkTKeJJRElUwy33tzgvYY+aVFA== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 211D73ADD5 for ; Tue, 27 Feb 2024 11:44:32 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1reuwV-0004Qu-6x; Tue, 27 Feb 2024 05:44:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1reuwR-0004Nr-5o for emacs-orgmode@gnu.org; Tue, 27 Feb 2024 05:44:09 -0500 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1reuwO-0000ul-Kb for emacs-orgmode@gnu.org; Tue, 27 Feb 2024 05:44:05 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1reuwJ-0009aL-6G for emacs-orgmode@gnu.org; Tue, 27 Feb 2024 11:43:59 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: [DISCUSSION, default settings] Using mailcap as default handler for opening file links Date: Tue, 27 Feb 2024 17:43:49 +0700 Message-ID: References: <963d5f94-3fdf-a01b-bc91-edc99222cb34@gmail.com> <877d6j2htv.fsf@localhost> <87ilq14p6p.fsf@localhost> <87v8u0396t.fsf@localhost> <87ilpz3bi0.fsf@localhost> <87h75ip5r6.fsf@localhost> <87zgj46hwo.fsf@localhost> <8735gr15ok.fsf@localhost> <878rqcy27h.fsf@localhost> <874jedoo4d.fsf@localhost> <87bk8kwqmu.fsf@localhost> <875xyrt7xy.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla Thunderbird Content-Language: en-US, ru-RU In-Reply-To: <875xyrt7xy.fsf@localhost> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 26 X-Spam_score: 2.6 X-Spam_bar: ++ X-Spam_report: (2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -0.76 X-Spam-Score: -0.76 X-Migadu-Queue-Id: 211D73ADD5 X-Migadu-Scanner: mx13.migadu.com X-TUID: wItPX4T4rZ4R Ihor, To be clear, I am not against taking into account XDG media types associations. I just believe that emacs settings should have higher priorities. Another point is that xdg-open is not intelligent enough to be used unconditionally. I have the following idea. If (mailcap-mime-info mime-type) returns a function then it is used to open the file. If it is a string (shell command) then depending on some user option and DISPLAY, WAYLAND_DISPLAY environment variables either xdg-open or mailcap shell command is executed. Notice the following issue: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12972 Move `org-open-file' and associated code out of Org mode Several issues with running external handlers are highlighted in comments. The changes were committed before I discovered history of code around xdg-open in browse-url.el. It is unclear to me what Eli had in mind. If some XDG-related code appears in Org then likely it will be demand to have it in Emacs core (dired already has some kludge). However my experience of communication with Emacs developers is not encouraging. A side note. On Debian there is the "open" command that may be configured to either xdg-open or run-mailcap through alternatives. Some notes are inline. On 14/02/2024 21:51, Ihor Radchenko wrote: > Max Nikulin writes: > > May you please explain more about this? > What happens if a mailcap entry, say, declares "less" as a mimetype > handler and Emacs is running in terminal? An entry for "less" likely has terminal requirement in the "test" field and likely will be discarded by mailcap.el (I have not checked it). > Also, I tried to run xdg-open from terminal (not emulator - C-M- on > Linux) and it runs w3m for .png image vs. feh when running from terminal > emulator on X. xdg-open has a fallback to some hardcoded list of browsers. It is far from mailcap configuration. It does not use "see" and similar mailcap-related tools. > So, I'd say that ordinary Emacs user probably has no idea that Emacs > consults .mailcap to open /files/. Maybe some users (who are already > familiar with .mailcap) expect .mailcap to be consulted when opening > email attachments. But I am not sure - even reading > https://man.archlinux.org/man/mailcap.5.en I cannot easily see why this > would be used to open files; not to render them inline. Users of mutt/pine/alpine have more chances to be familiar with mailcap. Debian's version https://manpages.debian.org/bookworm/mailcap/mailcap.5.en.html is linked to more informative https://manpages.debian.org/bookworm/mailcap/mailcap.order.5.en.html https://manpages.debian.org/bookworm/mailcap/update-mime.8.en.html though these tools are specific to Debian. > I feel that we are abusing the scope of mailcap when opening file links. From my point of view, Org just uses facility that Emacs provides. >> - Eli had objections, but did not provide any details. >> - Error handling code was dropped for the sake of Emacs-25. >> - In the case of no DE, quit from emacs means terminating of started >> applications. >> - I hope a bug I faced is exotic enough to never happen in real life. > > Sorry, but I have no idea what you are talking about. I assume that it > is some kind of Emacs bug you reported some time ago. I am not sure > which one. And I do not see how it is related to this discussion. See the link above. >> Ideally Emacs should provide API that uses either xdg.el or mailcap.el >> as backend depending on runtime and user configuration. Org is not the >> only package that needs it. > > Yes. But that's a lot of work; adding support of libmagic being just the > first step. Implementing something more reasonable for Org mode only is > a lower-handing fruit. There are two orthogonal XDG specs: - Lookup for a handler when media type is known - Database of media types with file suffixes and signatures (magic sequences) The former one is more important, unfortunately its implementation in Emacs has not nearly completed.