From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Generic Elisp mechanism to declare file/URI handlers for Emacs Date: Tue, 19 Sep 2023 13:06:57 +0000 Message-ID: <87cyyenwge.fsf@localhost> References: <87v8d66r7l.fsf@localhost> <87led53q0c.fsf@thaodan.de> <87fs3bkho4.fsf@localhost> <835y47g2b2.fsf@gnu.org> <874jjrk48q.fsf@localhost> <87cyyfwqs5.fsf@yahoo.com> <87sf7ao1o0.fsf@localhost> <87wmwmv13q.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32512"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?utf-8?Q?Bj=C3=B6rn?= Bidar , eliz@gnu.org, stefankangas@gmail.com, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 19 15:07:00 2023 Return-path: Envelope-to: ged-emacs-devel@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 1qiaRO-0008Ed-Tv for ged-emacs-devel@m.gmane-mx.org; Tue, 19 Sep 2023 15:06:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiaQW-0007JL-DY; Tue, 19 Sep 2023 09:06:04 -0400 Original-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 1qiaQU-0007Cg-3X for emacs-devel@gnu.org; Tue, 19 Sep 2023 09:06:02 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qiaQO-0000EC-AC for emacs-devel@gnu.org; Tue, 19 Sep 2023 09:06:01 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id DE189240103 for ; Tue, 19 Sep 2023 15:05:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1695128751; bh=vlsjzu68XjqJx4GwrLNR8Nb4P23PrJtU3vwr4MqYUnY=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=MviclU/+7Bmh27pjt+OG4xa69jOBtQ5EtYkki+/1JBthNjsVrnreg/8mKN+XNJSnY Gk4CUjMW+aq5aWugtV7V8vYTFAS6pocssmQnHJm1Hf1YtXqXh8lLURNwPho4Gyz3yn pxF7+mTmQhm6gHIQ9ELB9RAqStb6d9YBwQWdGOz5SECvTZdPkSwz4wgBYfCDVKAALD BWprYjmx+pp4kDIbB6zqySuw9z3XIu2ajMVEIRi7jghnioyWJYqUiUwB1wI2AHuz47 NT9Bi+I/kpg7CNdp1iU/7DxlbCmWdE7VexS7LbovP7PkKw73D1R0tJwFzm6NpcvL9v BV9L7d+UcHj9A== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Rqhjp6pGrz6tvp; Tue, 19 Sep 2023 15:05:50 +0200 (CEST) In-Reply-To: <87wmwmv13q.fsf@yahoo.com> Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:310759 Archived-At: Po Lu writes: > Ihor Radchenko writes: > >> Apparently, Android builds have to implement handlers in the source code >> directly. This makes adding new handlers for Emacs non-trivial - one >> needs to know both about .desktop file and also about Android-specific >> code (and what about MacOS-specific and Windows-specific?). > > Introducing a handler for a new URL scheme only requires the > introduction of a single line of Java: > ... I agree that it is not difficult. But it is very easy to miss implementing a new scheme on _all_ the supported OSes. For example, I have no idea if Emacs even provides something similar to .desktop file on MacOS and Windows. >> Would it make sense to create a more generic mechanism to collect a list >> of handlers from all the Elisp sources in Emacs and then generate >> Linux/Android/etc-specific definitions automatically when Emacs is >> compiled? > > That's overengineering. What in Emacs, save for org-protocol, defines > such URL handlers? And are they particular to Emacs to the same extent > that org-protocol is, justifying Emacs's placement within the ``Open > With'' dialog on my phone? I mostly thought about file type handling. Wouldn't it be nice to allow built-in major modes also make Emacs register as application capable to open the corresponding file type/extension. For example, consider that we have built-in clojure-mode at some point. Then, it will make sense to tell OS that Emacs is able to open .clj files. Same for any other new major mode. Not every major mode author knows the specific ways how Emacs implements file type handling in different OSes. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at