From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: Image-conversion shims Date: Sun, 29 Sep 2019 13:44:41 +0200 Message-ID: <87ftkfnx7a.fsf@gnus.org> References: <87v9tctcca.fsf@gnus.org> <87impct2xf.fsf@gnus.org> <83zhinfufb.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="88813"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 29 13:46:34 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iEXer-000N0O-Kk for ged-emacs-devel@m.gmane.org; Sun, 29 Sep 2019 13:46:33 +0200 Original-Received: from localhost ([::1]:38274 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iEXeq-0001TR-9U for ged-emacs-devel@m.gmane.org; Sun, 29 Sep 2019 07:46:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49182) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iEXdB-0001T0-Mi for emacs-devel@gnu.org; Sun, 29 Sep 2019 07:44:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iEXd9-0000QA-D4 for emacs-devel@gnu.org; Sun, 29 Sep 2019 07:44:49 -0400 Original-Received: from quimby.gnus.org ([80.91.231.51]:46808) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1iEXd9-0000IU-5R; Sun, 29 Sep 2019 07:44:47 -0400 Original-Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iEXd3-0008St-DT; Sun, 29 Sep 2019 13:44:43 +0200 In-Reply-To: <83zhinfufb.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 29 Sep 2019 10:11:52 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 80.91.231.51 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:240388 Archived-At: Eli Zaretskii writes: >> (setq convert-images-externally t) > > That variable's name should start with "image-", IMO, and the same for > the (confusingly similar) convert-external-images. Hm... I moved that variable from image-converter.el to image.el and slightly renamed it, but apparently forgot to remove it. Now fixed. I tried to come up with several variations for the variable name, but they all sounded even more awkward. Uhm... what about... image-use-external-converter? > It should also be documented in the user manual (I'd simply move what > you wrote for the ELisp manual to the user manual, since I see no > reason to document this in the former). Makes sense; now done. > When looking for an installed converter, shouldn't we put ImageMagick > last? Yup. > I also think that using call-process for invoking the converter makes > the feature less flexible and more "tricky" to maintain. Already you > needed to jump through some hoops to support "gm convert". I think > using shell-command would have made all this much simpler and more > straightforward. It's true that it's simpler, but I've been bitten by corner cases in escape handling of file names before (and we're dealing with file names that are under some degree of control by an attacker), so I just think it's easier to not have to think about those issues at all (i.e., use call-process). >> But if that hasn't been computed, then image-mode won't be triggered, >> and so create-image won't be called. > > Maybe we need a new hook? That would be possible, but would require more work for the user, possibly. I was pondering whether something could be done in `set-auto-mode'. It already consults a wide number of variables to determine the mode. Could we add yet another one that's more flexible? That is, it would be an alist on the form (variable . action) and would be consulted last in that function as the final fallback. Like: (defvar auto-mode-dependent-action-alist '((convert-images-externally . image-image-converter-file-alist))) and the code would be (dolist (elem auto-mode-dependent-action-alist) (when (bound-and-true-p (car elem)) (let ((alist (cdr elem))) ;; Do the same thing as with auto-mode-alist )) It would provide a mechanism for users to switch on/off a group of mode alist entries with a single setq... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no