From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id WFEwNf2wJmC7TgAA0tVLHw (envelope-from ) for ; Fri, 12 Feb 2021 16:46:53 +0000 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id SKDhMP2wJmD+UwAAB5/wlQ (envelope-from ) for ; Fri, 12 Feb 2021 16:46:53 +0000 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 6317027595 for ; Fri, 12 Feb 2021 17:46:53 +0100 (CET) Received: from localhost ([::1]:52870 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lAbam-0003Ds-J3 for larch@yhetil.org; Fri, 12 Feb 2021 11:46:52 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37802) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAba9-0003C2-B7 for emacs-orgmode@gnu.org; Fri, 12 Feb 2021 11:46:13 -0500 Received: from ciao.gmane.io ([116.202.254.214]:43750) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAba7-00014U-Ut for emacs-orgmode@gnu.org; Fri, 12 Feb 2021 11:46:13 -0500 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1lAba4-0008KI-IG for emacs-orgmode@gnu.org; Fri, 12 Feb 2021 17:46:08 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Maxim Nikulin Subject: Re: greedy substitution in org-open-file Date: Fri, 12 Feb 2021 23:46:03 +0700 Message-ID: References: <874kih92nb.fsf@kyleam.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <874kih92nb.fsf@kyleam.com> Content-Language: en-US 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: 27 X-Spam_score: 2.7 X-Spam_bar: ++ X-Spam_report: (2.7 / 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.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.119, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 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" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -0.26 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@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 6317027595 X-Spam-Score: -0.26 X-Migadu-Scanner: scn1.migadu.com X-TUID: U/9m4ISscAIJ On 12/02/2021 14:16, Kyle Meyer wrote: >> #+begin_src elisp >> (setq org-file-apps '(("\\.pdf::\\([0-9]+\\)\\'" . "xpdf %s %1"))) >> #+end_src > > Not relevant for the underlying issue, but doesn't xpdf require a colon > before the page number (i.e. ":%1")? At least for the application in debian & ubuntu xpdf package, page number should be specified without a colon. It is Xt interface to poppler PDF library, recently its maintainer decided to switch to xpopple project as upstream. UI is derived from old version of xpdf. Latest original xpdf version is based on Qt and might have different convention in respect to page numbers. > I believe format-spec requires the placeholder to be A-z: > > (format-spec "xpdf %s" '((?s . "a"))) => "xpdf a" > (format-spec "xpdf %s %1" '((?s . "a") (?1 . "b"))) ;; Invalid format string You are right. I missed that format-spec allows to specify field width, so digits could not be used. > What about flipping the processing, handling the %N placeholders first > and then formatting the file name? Seems to work on my end, though I > haven't tested it thoroughly. I could anticipate similar problems if named destinations are involved. I have not checked but I expect that internal links might have "%s" in their names at least for some file types. That is why I would strongly prefer substitutions performed in a single pass. I do not like it, but it seems that simplified variant of format-spec is better. It should allows substitutions with digit. I hope, single digit should be enough.