unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Image-conversion shims
Date: Sun, 29 Sep 2019 13:44:41 +0200	[thread overview]
Message-ID: <87ftkfnx7a.fsf@gnus.org> (raw)
In-Reply-To: <83zhinfufb.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 29 Sep 2019 10:11:52 +0300")

Eli Zaretskii <eliz@gnu.org> 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



  reply	other threads:[~2019-09-29 11:44 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-28 20:06 Image-conversion shims Lars Ingebrigtsen
2019-09-28 20:37 ` Clément Pit-Claudel
2019-09-28 21:20   ` Lars Ingebrigtsen
2019-09-29  6:24   ` Eli Zaretskii
2019-09-28 21:05 ` Stefan Monnier
2019-09-28 21:21   ` Lars Ingebrigtsen
2019-09-28 23:29   ` Lars Ingebrigtsen
2019-09-29  0:01     ` Lars Ingebrigtsen
2019-09-29  7:11     ` Eli Zaretskii
2019-09-29 11:44       ` Lars Ingebrigtsen [this message]
2019-09-29 11:56         ` Eli Zaretskii
2019-09-30  4:12           ` Lars Ingebrigtsen
2019-09-30  7:06             ` Eli Zaretskii
2019-09-30 13:42               ` Lars Ingebrigtsen
2019-09-30 14:01                 ` Eli Zaretskii
2019-10-01 12:06                   ` Lars Ingebrigtsen
2019-10-01 12:36                     ` Eli Zaretskii
2019-09-30 17:27             ` Stefan Monnier
2019-10-01 12:08               ` Lars Ingebrigtsen
2019-10-01 13:09                 ` Stefan Monnier
2019-10-06 20:58             ` Juri Linkov
2019-10-07  1:41               ` Lars Ingebrigtsen
2019-10-07 18:48                 ` Juri Linkov
2019-10-08 16:06                   ` Lars Ingebrigtsen
2019-10-08 17:47                     ` Stefan Monnier
2019-10-09 19:26                       ` Lars Ingebrigtsen
2019-10-09 19:53                         ` Stefan Monnier
2019-10-14  4:53                           ` Lars Ingebrigtsen
2019-10-14 19:27                             ` Juri Linkov
2019-10-14 19:41                               ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ftkfnx7a.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).