Re: Org Publish HTML and PDF With GPG Files
> Tim Cross theophil...@gmail.com writes: > I do not think that things are that difficult. org->html link conversion > > assumes that the linked .org file is also exported generating the > .html file. If I understand correctly, .org.gpg files are also exported > during publishing process. (Lehi Toskin, could you kindly confirm this?) > > Thus, we may simply extend `org-html-link' to work on .org.gpg files in > addition to .org files. Yes, this is it exactly.
Re: Support for tagging (special) blocks
Sébastien Miquel writes: > To clarify, here are the two alternatives I have in mind. > > #+tag: easy > #+attr_latex: A classic > #+begin_exercice > Find a necessary and sufficient condition on $N$ and $P$ for $P = NP$ > to hold. > #+end_exercice > > #+begin_exercice A classic :easy: > Find a necessary and sufficient condition on $N$ and $P$ for $P = NP$ > to hold. > #+end_exercice > > In my first message, I argue that wasting two lines of my screen > hinders reading and navigating the whole org file. > > I'm not sure what fontification trick you had in mind to compact the > space, but if you were thinking of making the meta lines smaller, by > say 50%, I argue in my second message that this hinders the > readability of this single exercice. The first three lines each > contain information that is important to me when I browse the file (as > opposed to information that's only relevant for org export). Thanks for the clarification! I did not mean to reduce the font size in affiliated keywords. I was referring to replacing the display of affiliated keywords: #+name: A classic #+tag: easy will be displayed by Emacs as #+... A classic :easy: The underlying text will not be changed. The hidden parts will be revealed upon cursor entering the affiliated keywords. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [PATCH] Prevent mixed installation
Ihor Radchenko writes: > The annoying mixed installation problems keep popping up in the mailing > list and other communication channels. > > The attached is a patch trying to forbid loading multiple Org versions. > The idea is putting a macro that internally expands Org git version at > compile time and later compares the expanded value with the runtime > value. Applied onto main via e81a09438 after amendments. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e81a094383a2e06a80e6dfb5ed0ca1ece44026f2 -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [BUG] ob-shell: cmdline and stdin broken when used with TRAMP
Ihor Radchenko writes:
> Thanks for the patch!
>
Thanks for the review!
>> I've also included a test, as the problem is reproducible with TRAMP
>> "/mock::" connection. But, that test will only work on GNU/Linux
>> systems.
> Then you also need to guard the tests against system-type variable
> value. If we cannot tests things on Windows, we should at least make the
> tests not fail when they should not.
Done. I've told ERT to skip this new test for ms-dos and windows-nt
systems. Thanks for the variable to use.
> You patch is >15LOC so we do need your copyright assignment before
> merging. Let me know if you face any difficulties with the copyright
> process. Note that FSF should reply within 5 working days.
Done. I just learnt a few days ago the process is done.
> Note that we quote symbols like `symbols'.
> See https://orgmode.org/worg/org-contribute.html#commit-messages
> Also, please link to the bug report in the commit message for future
> reference.
Should be now OK too.
> > + (list shell-command-switch
> > +(concat (file-local-name script-file) " "
> > cmdline)))
>
> Probably you do not need concat here.
> AFAIU, (list shell-command-switch (file-local-name script-file) cmdline)
> should be good enough as ARGS argument of `process-file'.
The shell process should receive 2 arguments: the switch and the
command to execute. I think the 'concat' is mandatory here.
Am I missing something?
>> + (:stdin t :shebang t)
>> + (:cmdline t :stdin t :shebang t)
>> + ))
>
> Please do not leave closing parenthesis at a separate line. See D.1
> Emacs Lisp Coding Conventions section of Elisp manual for details.
Oops. Fixed.
>> +(defconst org-test-tramp-remote-dir "/mock::/tmp/"
>> + "Remote tramp directory.
>> +We really should use 'tramp-test-temporary-file-directory', but that would
>> require TRAMP sources.")
>
> Since TRAMP sources are not normally available, we can add this variable
> as defined in tramp-tests.el somewhere into testing/org-test.el, for
> example.
I've copy/pasted the logic used in GNU Emacs Tramp and added a macro.
I've added (require 'tramp) in the body; should I move it to the top
of the file ?
Thanks again for the review,
Bruno
>From d9abfb423bff620dee15d204f4bab48e2ec8dc4e Mon Sep 17 00:00:00 2001
From: Bruno BARBIER
Date: Sat, 18 Jun 2022 09:48:01 +0200
Subject: [PATCH] ob-shell: Use 'process-file' when stdin or cmdline
lib/ob-shell.el (org-babel-sh-evaluate): Use `process-file' (instead
of `call-process-shell-command') so that `org-babel-sh-evaluate' will
invoke file name handlers based on `default-directory', if needed,
like when using a remote directory.
testing/lisp/test-ob-shell.el (ob-shell/remote-with-stdin-or-cmdline):
New test.
testing/org-test.el (org-test-with-tramp-remote-dir): New macro.
Fixes https://list.orgmode.org/CKMOBWBK709F.1RUN69SRWB64U@laptop/.
---
lisp/ob-shell.el | 16 +++-
testing/lisp/test-ob-shell.el | 49 +++
testing/org-test.el | 29 +
3 files changed, 88 insertions(+), 6 deletions(-)
diff --git a/lisp/ob-shell.el b/lisp/ob-shell.el
index 44efb4ea1..51071d40a 100644
--- a/lisp/ob-shell.el
+++ b/lisp/ob-shell.el
@@ -279,12 +279,16 @@ (defun org-babel-sh-evaluate (session body &optional params stdin cmdline)
(set-file-modes script-file #o755)
(with-temp-file stdin-file (insert (or stdin "")))
(with-temp-buffer
- (call-process-shell-command
- (concat (if shebang script-file
- (format "%s %s" shell-file-name script-file))
- (and cmdline (concat " " cmdline)))
- stdin-file
- (current-buffer))
+(with-connection-local-variables
+ (apply #'process-file
+(if shebang (file-local-name script-file)
+ shell-file-name)
+ stdin-file
+(current-buffer)
+nil
+(if shebang (when cmdline (list cmdline))
+ (list shell-command-switch
+(concat (file-local-name script-file) " " cmdline)
(buffer-string
(session ; session evaluation
(mapconcat
diff --git a/testing/lisp/test-ob-shell.el b/testing/lisp/test-ob-shell.el
index 2f346f699..442e70372 100644
--- a/testing/lisp/test-ob-shell.el
+++ b/testing/lisp/test-ob-shell.el
@@ -106,6 +106,55 @@ (ert-deftest ob-shell/simple-list ()
"#+BEGIN_SRC sh :results output :var l='(1 2)\necho ${l}\n#+END_SRC"
(org-trim (org-babel-execute-src-block))
+(ert-deftest ob-shell/remote-with-stdin-or-cmdline ()
+ "Test :stdin and :cmdline with a remote directory."
+ ;; We assume 'default-directory' is a local directory.
+ (skip-unless (not (memq system-type '(ms-dos windows-nt
+ (org-test-with-tramp-remote-dir remote-dir
+ (
Re: org-time-stamp-custom-formats with out the name of the day of the week
writes:
>> This cannot currently be customized. However, you can change
>> org-time-stamp-formats constant. Removing the %a should be safe.
>
> FWIW, I have this in an (eval-after-load 'org ...)
>
> (setq org-time-stamp-formats
> '("<%Y-%m-%d>" ."<%Y-%m-%d %H:%M>"))
>
> since years (> 5) and haven't observed any side effects. But then
> I don't meet every nook and cranny of org (I bow in awe to those
> who meet half of them :-)
This only works because you changed org-time-stamp-formats in one of the
few safe ways.
Org declares org-time-stamp-formats and Org code treats its value as a
constant making various kinds of unsafe assumptions that can break
things if the value of org-time-stamp-formats is changed. For example,
it is assumed that first/last characters are triangular brackets; it is
assumed that the output can be parsed using parse-time-string; it is
assumed that 1..11 substring in the format contains a full date; it is
assumed that the formatted output conforms to timestamp syntax; etc.
--
Ihor Radchenko,
Org mode contributor,
Learn more about Org mode at https://orgmode.org/.
Support Org development at https://liberapay.com/org-mode,
or support my work at https://liberapay.com/yantar92
Re: Volunteering to maintain ob-asymptote.el within Org
Greetings Bastien! Bastien writes: >> I hereby volunteer to maintain ob-asymptote.el. This file has been >> moved to org-contrib, but I would like it to be brought back into Org >> itself. > > I added Luc (cc'ed) as the maintainer of ob-asymptote.el a while ago: > > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=27621a5b > > Perhaps you can discuss with him to decide whether you both want to > maintain this file or just one of you? I do not wish to "steal" ob-asymptote.el from anyone; if Luc is happy being the maintainer, this is fine by me. In fact, perhaps it would be best at this point if Luc would maintain ob-asymptote.el and I would create a good set of examples in Worg: https://www.orgmode.org/worg/org-contrib/babel/languages/ob-doc-asymptote.html If ob-asymptote.el is moved out of org-contrib, where whould this page reside? > As maintainer(s) or ob-asymptote.el, the first step should probably be > to package it for GNU ELPA: both you and Luc have signed the FSF > copyright assignment, so there is no blocker for joining GNU ELPA. > Then we can move it out of org-contrib, which just serves as a > transitory repository. This is an excellent idea. I would certainly want ob-asymptote.el out of org-contrib, since the advertisement for org-contrib almost guarantees that the files are not maintained. :-) > For now, I'd rather be conservative with what is added to Org's core: > GNU ELPA is reachable enough for "niche" features. If/when Asymptote > gets more support within Emacs core, we can move ob-asymptote.el in > Org's core back again. > > Would that be okay for you (both)? This is fine by me. I can start marketing to increase level of interest. All the best, Jarmo
Re: Org mode links: Open a PDF file at a given page and highlight a given string
On 03/03/2021 03:07, Rodrigo Morales wrote:
#+begin_src emacs-lisp :results silent
(setq org-file-apps
'(("\\.pdf::\\([0-9]+\\)::\\([^:]+\\)\\'" . "zathura -P %1 -f %2 %s")))
#+end_src
I am going to respond to a message from another thread containing
discussion of a patch, but I suppose the following considerations are
more appropriate in the thread discussing combined specifier for
location withing a PDF document. For me it is more convenient to test
ideas using okular, I hope, changing code for zathura or other PDF
viewer is trivial.
Ihor Radchenko. Re: [PATCH] org.el: Fix percent substitutions in
`org-open-file' Fri, 02 Sep 2022 20:08:17 +0800.
https://list.orgmode.org/87tu5qm11q.fsf@localhost
+;; Page and search string,
+;; e.g. .
+(\".pdf::([0-9]+)::(.+)\\='\"
+. \"okular --page %1 --find %2 %s\")
+;; Internal anchor and search string,
+;; e.g. .
+(\".pdf::(.+)::(.+)\\='\"
+. \"okular --find %2 file://%s#%1\")
+;; Page number, e.g. .
+(\".pdf::([0-9]+)\\='\" . \"okular --page %1 %s\")
+;; Internal reference, e.g.
.
+(\".pdf::(.+)\\='\" . \"okular file://%s#%1\")
+;; No location within the file, optionally followed by \"::\",
+;; e.g. .
+(\".pdf(?:::)?\\='\" . \"okular %s\")
This is a nice set of examples, but it probably does not belong to this
docstring. I'd rather see this in `org-file-apps' docstring or even in
the manual.
It is a part of docstring, so number of slashes is doubled.
First of all, I overlooked possibility to distinguish text search
"file:text.pdf::patttern" and cross reference target within the document
"file:text.pdf::#anchor". Secondly, I forgot that PDF viewers may
support compressed files.
Currently I believe that instead of injecting up to 6 entries into
`org-file-apps' for various combinations of page, anchor, and search
pattern, it is better to add single record with function handler. Notice
that the approach presented above is not affected by the bug with
multiple regexp group. Its additional advantage is that shell is not
involved, so peculiar file names can not cause execution of some code
when quoting and escaping are messed up.
I think a set of functions for popular PDF viewers (evince, zathura,
okular, xpdf, xpopple, firefox, chromium & Co., etc.) should be defined
in some package, but I am in doubts if it suitable for Org core.
Proof of concept implementation.
Configuration:
(add-to-list
'org-file-apps
`(("\\.pdf\\(?:\\.gz\\|\\.bz2\\|\\.xz\\)?\\(?:::.*\\)?\\'"
. ,#'my-open-file-pdf-okular)))
Helper functions:
(defun my--parse-file-link-search (suffix-re link)
"Parse PDF file LINK for page number, cross reference anchor, search
string.
Return nil if it is not a link to some PDF file. Any element may be nil."
(let ((case-fold-search t)) ; Handle files having .PDF suffix as well
(and (string-match
(concat suffix-re
(rx
(optional "::"
(or (group (+ digit))
(group "#" (+ (not (any ?:
(optional "#")))
(optional "::"
(optional (group (+ anything
string-end))
link)
(mapcar (lambda (i) (match-string i link)) '(1 2 3)
(defun my-launch-viewer (command arguments)
"Launch external application COMMAND with ARGUMENTS.
The function allows to avoid intermediate shell and so escaping
of arguments that otherwise might be considered as shell
specialls and run arbitrary commands. The function launches
viewer process using shoot ant forget method like `browse-url-xdg-open',
so the application may run even after quit from Emacs."
(apply #'call-process command nil 0 nil args))
(defun my-open-file-pdf-okular (file link)
"PDF files handler for usage as a command in `org-file-apps' alist.
Customize `org-file-apps' to add the following entry:
\\='(\".pdf(?:.gz|.bz2|.xz)?(?:::.*)?\\='\"
. #\\='my-open-file-pdf-okular)
Open FILE at the location specified by LINK (page, internal
reference, search string). Supported link search options (side
note: in the particular case of bash manual
link may be used instead):
- Page number .
- Page number and search text
.
- Cross reference anchor
.
- Cross reference anchor and search text
.
- Search text .
Optionally the FILE may be compressed by gzip, bzip2, or xz."
(pcase-let* ((pdf-re (rx ".pdf"
;; .Z and .zip are not supported by okular
(optional (or ".gz" ".bz2" ".xz"
(`(,page ,ref ,find)
(or (my--parse-file-link-search pdf-re link)
(error "Not a PDF file link: %S" link)))
(args (list "-
Re: Support for tagging (special) blocks
Ihor Radchenko writes: >> >> On a slightly related note, I find it quite unfortunate that one >> >> presently cannot make use of the #+begin_ line of special blocks to >> >> set some kind of optional title instead of using #+name or >> >> #+attr_latex. That's a lot of wasted real estate. >> > >> > Yes, but we do not want to overcomplicate Org syntax. Affiliated >> > keywords are universal across multiple element types. Adding a >> > specialized syntax for src blocks will make things complex technically >> > and create duplicate code. >> > >> > We can alter the fontification to compact the screen space though. Will >> > it suffice? >> > >> >> I don't see any possible compactification that doesn't hinder >> readability. From my perspective, it is important that the type of the >> special block, its title, and its tags are readable. > I feel that I either misunderstand you here or in the previous message. To clarify, here are the two alternatives I have in mind. #+tag: easy #+attr_latex: A classic #+begin_exercice Find a necessary and sufficient condition on $N$ and $P$ for $P = NP$ to hold. #+end_exercice #+begin_exercice A classic :easy: Find a necessary and sufficient condition on $N$ and $P$ for $P = NP$ to hold. #+end_exercice In my first message, I argue that wasting two lines of my screen hinders reading and navigating the whole org file. I'm not sure what fontification trick you had in mind to compact the space, but if you were thinking of making the meta lines smaller, by say 50%, I argue in my second message that this hinders the readability of this single exercice. The first three lines each contain information that is important to me when I browse the file (as opposed to information that's only relevant for org export). The only line that contains no content information is the #+end_exercice line, which is only here for the org parser. -- Sébastien Miquel
Re: Support for tagging (special) blocks
Sébastien Miquel writes: > > We already have ":exports none" header argument. > > For src block yes, but not for special blocks. > > To explain where I'm coming from : I write mathematical content > categorized using special blocks, such as theorems, exercices, proofs, > personnal notes, etc. Then from a single org file, I export several > pdf files, filtering the content according to the types and tags of > special blocks : for example, to exclude some proofs, or exercices > that are too hard. We may allow something like #+attr_all: :exports no in export. > > Affiliated keywords are indeed not uniform with headlines. But they are > > uniform with everything else. Paragraphs can have affiliated keywords. > > Or other blocks. Or lists. Or tables... > > That's indeed a good point. In fact, I had been wondering recently how > I could tag a single list item, but I guess affiliated keywords still > can't do that. Affiliated keywords can be assigned to lists. Not single items though: #+CAPTION: test1 - item 1 #+CAPTION: test2 - item 2 #+CAPTION: test3 - item 3 > >> On a slightly related note, I find it quite unfortunate that one > >> presently cannot make use of the #+begin_ line of special blocks to > >> set some kind of optional title instead of using #+name or > >> #+attr_latex. That's a lot of wasted real estate. > > > > Yes, but we do not want to overcomplicate Org syntax. Affiliated > > keywords are universal across multiple element types. Adding a > > specialized syntax for src blocks will make things complex technically > > and create duplicate code. > > > > We can alter the fontification to compact the screen space though. Will > > it suffice? > > > > I don't see any possible compactification that doesn't hinder > readability. From my perspective, it is important that the type of the > special block, its title, and its tags are readable. I feel that I either misunderstand you here or in the previous message. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: [PATCH] org.el: Fix percent substitutions in `org-open-file'
Max Nikulin writes: >>> +(\".pdf::(.+)\\='\" . \"okular file://%s#%1\") >>> +;; No location within the file, optionally followed by \"::\", >>> +;; e.g. . >>> +(\".pdf(?:::)?\\='\" . \"okular %s\") >> >> This is a nice set of examples, but it probably does not belong to this >> docstring. I'd rather see this in `org-file-apps' docstring or even in >> the manual. > > I thought on this and I do not think it should be added to the manual. > Instead a set of hooks should be defined for popular PDF viewers: > evince, zathura, xpdf, firefox, chromium & Co, etc. Such hook injects a > number of supported `org-file-apps' records and users may add suitable > hook to e.g. (with-eval-after-load 'org (push ...)). It may be > implemented as a dedicated package org-pdf-viewers.el. The only problems > is that adding entries programmatically breaks easy customization > interface for `org-file-apps'. Currently there is the same issue with > `org-link-parameters' that is a defcustom variables with entries added > by various org extensions. We may alter the :type specifier in `org-file-apps' to something like :type `(repeat (choice ,org-file-apps-presets ...)) `org-file-apps-presets' will then contain :type specs for some common file types and the apps. The variable can be easily populated by third-party packages as well. > I added the example with hope to better explain the purpose of this > function. I do not think that it is needed in the `org--open-file-format-command' docstring. If you wish, it would be better to add examples of the arguments and return values of `org--open-file-format-command' instead of showing `org-file-apps' examples. -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: Unicode TODO keyword issues in agenda search leading to org-scan-tags regex
Marcel Lauhoff writes: > My TODO keywords: > ┌ > │ org-todo-keywords '((sequence "≣(p)" "|" "∎(f)") > │ (sequence "◇(t)" "★" "⌛(w)" "🔥(.)" "⚙(s)" "⎇(r)" "⏵(e)" "|" > "✔(d)" "✘(c)") > │ (sequence "⛱(m)" "|")) > │ > └ > ... > The `(regexp-opt org-todo-keywords-1 'words)' excludes most of my TODO > keywords (but not all). Changing `'words' to `'symbols' give me my > desired result. Thanks for reporting! Fixed on main via a1c923afd. https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a1c923afda22089cbf14c7b7a175cee10bfd297b -- Ihor Radchenko, Org mode contributor, Learn more about Org mode at https://orgmode.org/. Support Org development at https://liberapay.com/org-mode, or support my work at https://liberapay.com/yantar92
Re: org-time-stamp-custom-formats with out the name of the day of the week
On Fri, Sep 02, 2022 at 09:33:40PM +0800, Ihor Radchenko wrote:
> Uwe Brauer writes:
>
> > I see, the question simply is this:
> >
> > How can I achieve that org-time-stamp inserts the date *without* the day
> > name?!
>
> This cannot currently be customized. However, you can change
> org-time-stamp-formats constant. Removing the %a should be safe.
FWIW, I have this in an (eval-after-load 'org ...)
(setq org-time-stamp-formats
'("<%Y-%m-%d>" ."<%Y-%m-%d %H:%M>"))
since years (> 5) and haven't observed any side effects. But then
I don't meet every nook and cranny of org (I bow in awe to those
who meet half of them :-)
Cheers
--
t
signature.asc
Description: PGP signature
