Re: async export and then do something with file
Matt Price writes: > Hi everyone, > > I am wondering if I can perform and export asynchronously and then, without > tying up emacs, wait around for the export to finish and then perform > some other task, like upload the file to a server. Has anyone tried this > before? I think perhaps the easiest thing to do would be to use async.el or > some similar third-party, but I can't tell what the preferred method is. I > would love osme guidance! > The asynchronous export should be possible and I've seen some proposed patches for this discussed recently. The challenge is your second part. In other languages, you could use something like a 'future' (Clojure) or a Promise (Javascript), but I'm not 100% sure with Elisp. I suspect you would need to create the async process and use the :sentinal option to pass in a process sentinal function, which is essentially a function that will run whenever the status of a process changes. The sentinal would need to watch for a status change which indicates the process has finished and then call whatever your post-export actions are. HTH Tim -- Tim Cross
Re: [PATCH] Fix numbering of captioned images
Kyle Meyer writes: What about returning to the boundp/fboundp combination that was in place before ab1ce2a75? (and (boundp 'my/foo) (fboundp my/foo)); => nil (let ((my/foo #'ignore)) (and (boundp 'my/foo) (fboundp my/foo))) ; => t Sounds good to me! I've modified the patch to reflect this change. >From a8d653efcdbe42e887aba7f8895de413ffaa53c4 Mon Sep 17 00:00:00 2001 From: Pablo Barraza Cornejo Date: Thu, 29 Apr 2021 20:15:08 -0600 Subject: [PATCH] ox-html.el/inline-image export: Fix caption numbering * lisp/ox-html.el (org-html-standalone-image-p): Remove quote which causes `org-html-standalone-image-p' to not check if `org-html-standalone-image-predicate' is fbound and see if it's initialized. TINYCHANGE --- lisp/ox-html.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 47122314c..12d511c28 100644 --- a/lisp/ox-html.el +++ b/lisp/ox-html.el @@ -3039,7 +3039,8 @@ images, set it to: (`paragraph element) (`link (org-export-get-parent element) (and (eq (org-element-type paragraph) 'paragraph) - (or (not (fboundp 'org-html-standalone-image-predicate)) + (or (not (and (boundp 'org-html-standalone-image-predicate) + (fboundp org-html-standalone-image-predicate))) (funcall org-html-standalone-image-predicate paragraph)) (catch 'exit (let ((link-count 0)) -- 2.31.1
Re: [PATCH] ol.el: Fix confusing variable name
"Aaron L. Zeng" writes: > * ol.el (org-link--open-help): Fix a confusing variable name. No > behavior changes. > > TINYCHANGE > --- > lisp/ol.el | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/lisp/ol.el b/lisp/ol.el > index 62ea6d2bc..617223cb5 100644 > --- a/lisp/ol.el > +++ b/lisp/ol.el > @@ -1325,8 +1325,8 @@ PATH is the sexp to evaluate, as a string." >"Open a \"help\" type link. > PATH is a symbol name, as a string." >(pcase (intern path) > -((and (pred fboundp) variable) (describe-function variable)) > -((and (pred boundp) function) (describe-variable function)) > +((and (pred fboundp) function) (describe-function function)) > +((and (pred boundp) variable) (describe-variable variable)) > (name (user-error "Unknown function or variable: %s" name > > (defun org-link--store-help () Hi Aaron, thanks for the patch. It looks straight forward, does seem to be less confusing and in-line with the intention of the code and is only a tiny change, so I think it should be applied. Tim -- Tim Cross
Re: stability of toc links
Samuel Wales writes: > hi trs, > > thank you. i can imagine that could be useful for a lot of users, but > for me, as i said in my op, "short of adding custom id > or id to everything" --- i didn't want to add custom id. i will try > to clarify why in case it is useful. > > in addition to performance, and clutter, there is a semantic issue in > my case. typically, if i see that there is a properties drawer, i > know that it is there because of an org id or a manual custom id or a > special purpose of my own. if i know it, i don't need to open it. > > however, adding custom id automatically for so many links means that > there is a new meaning for properties drawers [namely, for stable > linking done automatically]. i would have to open the drawer to > determine if i personally wanted something there. > > and thus, the extra properties drawers would cause effort and > distraction in this semantic sense, where i would be opening them > because i would be thinking "did i really have a reason to add a > properties drawer here? i don't recall so... better check" > > also, there is the issue that if i decide not to include something in > the toc, it will still have a properties drawer lying around. > > > in the op, i was not looking for a solution for one blog post, but > thought a general solution for all org users might be possible. > > and this would likely be at the html level, probably by using e.g. > header text, fuzzy or strict hashes, or a combination. > > when tec posted his html level code, it looked like the right type of > solution to the problem. i have not tried it, however. > > i hope that clarifies. tec said he originally did not get much > interest. then there was interest on this thread. then nothing. > A question to help me understand this issue. If I understand correctly, exporting to HTML does not guarantee stability of TOC links. If you export as HTML, send someone a link from the toc and then re-export the document, the link will possibly be broken. Essentially, exporting to HTML has no guarantee of stability in toc links. However, if you use publish instead of exporting to HTML, there is a guarantee of stability in toc links. When publishing a second time, the link will be consistent and still valid. If you want stability in toc links, why not use publish instead of export to html? Is there some difference between the two mechanisms which prevents you from being able to use publish instead to get stable links?
Bug (HTML/TexInfo etc): Commented code block gets through to exporter when it shouldn't [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
Bug (HTML/TexInfo etc):
Commented code block gets through to exporter when it shouldn't
[9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
See the attached files. The `.txt' file is actually a `.org' file.
The surprising behaviour--surprising at least to me--is because of the
presence of tabs in the source block, that is commented out.
Screenshots show where the tabs are in org file, and how the HTML
output is rendered.
When I untabify the file, everything looks fine.
I have created this report with `emacs -Q' (i.e., with a capital Q),
and whatever Org that ships with it.
Emacs : GNU Emacs 28.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version 3.24.24,
cairo version 1.16.0)
of 2021-04-28
Package: Org mode version 9.4.4 (release_9.4.4 @
/usr/local/share/emacs/28.0.50/lisp/org/)
Title:
Table of Contents
1. Minimal setup using straight.el
1 Minimal setup using straight.el
Add this to your init file,
(straight-use-package 'helm)
or
# :straight t
# :config
# […])
(use-package helm :straight t)
For further information, see straight.el's user manual.
Author: Ramesh Nedunchezian
Created: 2021-04-30 Fri 10:27
Validate
# -*- mode: org; -*-
*** Minimal setup using =straight.el=
# =straight.el=[fn:xxx3]
Add this to your init file,
#+begin_src emacs-lisp
(straight-use-package 'helm)
#+end_src
or
# #+begin_src emacs-lisp
# (use-package helm
#:straight t
#:config
#[...])
# #+end_src
#+begin_src emacs-lisp
(use-package helm :straight t)
#+end_src
For further information, see =straight.el='s user manual.
# To upgrade =helm=, do {{kbd(M-x straight-pull-package)}} and restart
# Emacs. =straight.el= will rebuild helm for you.
Re: Bug (HTML/TexInfo etc): Commented code block gets through to exporter when it shouldn't [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)]
This is not an exporter bug, but a fontifier bug. There is no space after the leading '#' in the "problematic" lines. Yet, the fontifier seems to think that lines which shouldn't be commented-out lines are actually commented-out lines. I think I should have trusted my own screenshots rather than the org's default fontifier :-( I really don't know how I got that snippet in that state. When I comment out a source snippet afresh, Org untabifies the snippet. On 30/04/21 10:30 am, Ramesh Nedunchezian wrote: > > Bug (HTML/TexInfo etc): > > Commented code block gets through to exporter when it shouldn't > [9.4.4 (release_9.4.4 @ /usr/local/share/emacs/28.0.50/lisp/org/)] > > See the attached files. The `.txt' file is actually a `.org' file. > > The surprising behaviour--surprising at least to me--is because of the > presence of tabs in the source block, that is commented out. > Screenshots show where the tabs are in org file, and how the HTML > output is rendered. > > When I untabify the file, everything looks fine. > > I have created this report with `emacs -Q' (i.e., with a capital Q), > and whatever Org that ships with it. > > > > Emacs : GNU Emacs 28.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version > 3.24.24, cairo version 1.16.0) > of 2021-04-28 > Package: Org mode version 9.4.4 (release_9.4.4 @ > /usr/local/share/emacs/28.0.50/lisp/org/) >
Re: [PATCH] Fix numbering of captioned images
Pablo Barraza Cornejo writes: > When exporting to HTML, the exporter is supposed to check if there > are additional constraints over a paragraph using > `org-html-standalone-image-predicate'. A misplaced quote causes > `org-html-standalone-image-p' to not apply them. Thanks for catching the issue and for sending a patch. This looks like a regression introduced way back in 8.2.7 by ab1ce2a75 (ox-html: Fix spurious "figure" divs on empty paragraphs, 2014-05-15). > Subject: [PATCH] ox-html.el/inline-image export: Fix caption numbering. The convention in this project is to leave off the trailing period from the subject. > * lisp/ox-html.el (org-html-standalone-image-p): Remove quote which > causes `org-html-standalone-image-p' to not check if > `org-html-standalone-image-predicate' is bound. Please fill this line to ~70 characters (set in the repo's .dir-locals.el). > (and (eq (org-element-type paragraph) 'paragraph) > - (or (not (fboundp 'org-html-standalone-image-predicate)) > + (or (not (fboundp org-html-standalone-image-predicate)) >(funcall org-html-standalone-image-predicate paragraph)) This quote will indeed result in the fboundp call always returning nil: (let ((org-html-standalone-image-predicate #'org-html--has-caption-p)) (fboundp 'org-html-standalone-image-predicate)) ; => nil (let ((org-html-standalone-image-predicate #'org-html--has-caption-p)) (fboundp org-html-standalone-image-predicate)) ; => t However, the proposed change will introduce another issue. org-html-standalone-image-predicate is defined as (defvar org-html-standalone-image-predicate) That means it's left uninitialized: (defvar my/foo) ; => my/foo (boundp 'my/foo) ; => nil (fboundp my/foo) ; error: (void-variable my/foo) What about returning to the boundp/fboundp combination that was in place before ab1ce2a75? (and (boundp 'my/foo) (fboundp my/foo)); => nil (let ((my/foo #'ignore)) (and (boundp 'my/foo) (fboundp my/foo))) ; => t
Transforming table and then exporting as CSV
I have the following requirement. For this I have written the code that follows. Bank requires from me a CSV file in this format: --8<---cut here---start->8--- ACCOUNT NO,DR/CR,AMOUNT,NARRATION 50...658,C,x.xx,APR2021 50...590,C,x.xx,APR2021 50...904,C,x.xx,APR2021 06...965,C,x.xx,APR2021 50...489,C,x.xx,APR2021 50...680,C,x.xx,APR2021 50...357,C,x.xx,APR2021 --8<---cut here---end--->8--- But this doesn’t have names of the people. First column shows the account numbers. So I have created an org-table like this --8<---cut here---start->8--- * April 2021 :PROPERTIES: :TABLE_EXPORT_FILE: enet_apr_2021/0684SAL2904.001.csv :TABLE_EXPORT_FORMAT: orgtbl-to-csv :END: #+NAME: APR2021 | NAME | ACCOUNT NO | DR/CR |AMOUNT | NARRATION | |---++---+---+---| | Dhma...arwal | 50.658 | C | x.xx | APR2021 | | Prar | 50.590 | C | x.xx | APR2021 | | Oly | 50.904 | C | x.xx | APR2021 | | Sagid | 06.965 | C | x.xx | APR2021 | | Pagid | 50.489 | C | x.xx | APR2021 | | Maar | 50.680 | C | x.xx | APR2021 | | Shagi | 50.357 | C | x.xx | APR2021 | |---++---+---+---| | TOTAL || | xx.xx | | #+TBLFM: $4=$4;%.2f --8<---cut here---end--->8--- I have written below code for the conversion. This code removes the first column and last row. And then run ‘org-table-export‘. This works fine. #+begin_src elisp (require 'org) (defun enet-export (name) (interactive "MTable Name: ") (outline-show-all) (let ((case-fold-search t)) (goto-char (point-min)) (if (search-forward-regexp (concat "#\\+NAME: +" name) nil t) (progn (forward-line) (let* ((beg (org-table-begin)) (end (org-table-end)) (txt (buffer-substring-no-properties beg end)) (file (org-entry-get (point) "TABLE_EXPORT_FILE")) (format (org-entry-get (point) "TABLE_EXPORT_FORMAT"))) (with-temp-buffer (insert txt) (goto-char (point-min)) (org-table-next-field) (org-table-delete-column) (goto-char (org-table-end)) (backward-char) (org-table-kill-row) (org-table-kill-row) (org-entry-put (point) "TABLE_EXPORT_FILE" file) (org-entry-put (point) "TABLE_EXPORT_FORMAT" format) (make-directory (file-name-directory file) t) (org-table-export (message "Not Found" #+end_src Same org file has multiple tables, so I am asking for “Table Name”. I want to do two improvements: 1. When asking for table name, I want to offer all the table names in the file as completion options. 2. Current table at point as default 3. I want to run the function from command line. Like, --8<---cut here---start->8--- emacs --batch enet_2021_22.org -l enet.el --eval="(enet-export \"APR2021\")" --8<---cut here---end--->8--- Do I need to change the (interactive...) part in any way to enable this? -- Regards Pankaj
[PATCH] Fix numbering of captioned images
When exporting to HTML, the exporter is supposed to check if there are additional constraints over a paragraph using `org-html-standalone-image-predicate'. A misplaced quote causes `org-html-standalone-image-p' to not apply them. To number captions on images the `org-html-paragraph' binds `org-html-standalone-image-predicate' to `org-html--has-caption-p', but since it gets ignored, `org-export-get-ordinal' considers all standalone images, not just captioned ones. This throws off the numbering. >From 85e0b2da37f914458d71bd3a5797298ca3a4e0ce Mon Sep 17 00:00:00 2001 From: Pablo Barraza Cornejo Date: Thu, 29 Apr 2021 20:15:08 -0600 Subject: [PATCH] ox-html.el/inline-image export: Fix caption numbering. * lisp/ox-html.el (org-html-standalone-image-p): Remove quote which causes `org-html-standalone-image-p' to not check if `org-html-standalone-image-predicate' is bound. TINYCHANGE --- lisp/ox-html.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 47122314c..df270b22b 100644 --- a/lisp/ox-html.el +++ b/lisp/ox-html.el @@ -3039,7 +3039,7 @@ images, set it to: (`paragraph element) (`link (org-export-get-parent element) (and (eq (org-element-type paragraph) 'paragraph) - (or (not (fboundp 'org-html-standalone-image-predicate)) + (or (not (fboundp org-html-standalone-image-predicate)) (funcall org-html-standalone-image-predicate paragraph)) (catch 'exit (let ((link-count 0)) -- 2.31.1
Re: stability of toc links
On 2021-04-29 18:18, Samuel Wales wrote: On 4/29/21, TRS-80 wrote: My "quick and dirty" solution was to make a function to map over each heading and assign a custom ID based on the text of the heading. It only assigned one if one did not exist already (so in case you had done any manual adjustments they would not be overwritten). I had posted it very early in the thread, but it did not seem to gain much interest. It was not posted as a "long term and proper solution to be included into Orgmode" but rather a quick and easy workaround in the meantime. thank you. i can imagine that could be useful for a lot of users, but for me, as i said in my op, "short of adding custom id or id to everything" --- i didn't want to add custom id. i will try to clarify why in case it is useful. Well, FWIW, I did not want to assign custom IDs, either. :) Like you, I didn't want to "pollute" the properties drawer, etc. However after looking into the options, including discussing this issue on the mailing list myself some time ago, I realized that this was going to be a major change in Orgmode, that it had been discussed before (multiple times), and therefore would require (perhaps significant) politicking, etc... And so then I assigned custom IDs to all my entries, and got on about my business. I now have achieved stable links when exporting. ;) I still support your (and others') efforts toward a more proper and long term solution, I just think they are going to take a while to bear fruit is all. Cheers, TRS-80
Re: Programmatically set TODO labels per file?
Arthur Miller writes: > I have a simple question, but I wasn't able to find answer on the web, > so finally I'll try my luck here. > > I know I can setq org-todo-keywords with a list '((sequence "TODO" > DONE")), as an example. But what variable is used for per-file keywords? > Once that are set with #+TODO: ... line? > > I guess when org mode parses a file when starting up the mode, it has to > parse that line into some var, where do I find it? > It is parsed into a buffer-local variable by the name of `org-todo-keywords-1'. Do `C-h v org-todo-keywords' and `C-h v org-todo-keywords-1' for all the details. BTW, when the interwebs fail you (or even before that), use the source :-) -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: [WDYT, mini] key h in agenda for quick help
Samuel Wales writes: > links to the info manual from help pages and vice-versa would be keen. See helpful [1] package. It provides links from help buffers to manual. For links from manual, there is always v/f/. [1] https://github.com/Wilfred/helpful Best, Ihor
Re: How to use `open` to handle `message:*` links on macOS
Hello Tim, Tim Visher writes: > [...] > Thanks for the tips here. I finally got around to trying them out. Here's > what I ended up with and it's working perfectly. > [...] Glad I could be of assistance! > Pairing that with my org-capture TODO Current Mail Template is a dream come > true. :) > [...] That's interesting how you pull the information from Mail app. How do you trigger the capture? Do you have to select the message in Mail app, then move over to Emacs and trigger the capture there? or do you have a way to trigger the Emacs capture from within Mail app? The next level of productivity could perhaps be to switch to notmuch[1], and do all you email from within Emacs. Use yasnippet[2] for composing mails. And have snippets be presented to you by company[3]. Just saying... ;-) [1] https://notmuchmail.org/ [2] http://joaotavora.github.io/yasnippet/ [3] https://company-mode.github.io/ Cheers, --alexander
Re: [WDYT, mini] key h in agenda for quick help
On 2021-04-28 00:59, Timothy wrote: Bastien writes: thanks for the proposal. I'm not convinved that users who don't know about `C-h m' will think of hitting `h' or another key. I might be wrong, so if beginners suggest they expect such a key and were amazed at how useful C-h m was for them when reading this thread, I might change my mind. I can distinctly recall hitting "?" in Org agenda when I was getting started, after getting used to Magit. For some reason, "?" is the single key that comes to my mind as well (rather than "h" or any other). I don't know if I got that from Magit, general GNU/Linux usage, or what? Having said that, I am not arguing in favor of OPs proposal. Just mentioning the "single key" that came to mind, FWIW. As I mentioned in another reply, I think things are fine the way they are. ¯\_(ツ)_/¯ Cheers, TRS-80
Re: [WDYT, mini] key h in agenda for quick help
links to the info manual from help pages and vice-versa would be keen. On 4/29/21, TRS-80 wrote: > On 2021-04-28 02:08, Tim Cross wrote: >> I've rarely found describe mode to be terribly useful > > I'm the opposite. I find it a great way to quickly look up (or search > for) some keybinding or function I forgot. > > But then again, I know the difference between C-h m and C-h i (as well > as other help options) so if I need the manual (or other information) > I go straight there. They each have their place, IMO. > > Cheers, > TRS-80 > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [WDYT, mini] key h in agenda for quick help
On 2021-04-28 02:08, Tim Cross wrote: I've rarely found describe mode to be terribly useful I'm the opposite. I find it a great way to quickly look up (or search for) some keybinding or function I forgot. But then again, I know the difference between C-h m and C-h i (as well as other help options) so if I need the manual (or other information) I go straight there. They each have their place, IMO. Cheers, TRS-80
Re: [PATCH] Fontification for inline src blocks
On 2021-03-31 11:00, Timothy wrote: I've been using inline src blocks a fair bit more recently, and I've thought it's a pity how bad they look as they are currently without fontification. A little digging into Org internals and font-lock later and we have this patch. I recall trying inline src blocks once, a year or two ago. I couldn't get it to work, so I gave up. Of course I figured I was doing something "wrong" or whatever, so it's nice to see "it's not just me." :) So, 3x thanks! One for confirming the bug, and 2 more for actually providing a solution! I look forward to circling back to it when I have some time. Cheers, TRS-80
Re: Turning off all indentation in 9.4.4
On 2021-04-28 00:03, Bastien wrote: TRS-80 writes: In the same timeframe, I have also noticed my Logbook entries not being indented (when changing TODO states) which I think was also brought about by this change (or rather, my changes to org-adapt-indentation). I am not sure if I should make a separate thread about that, or not? this particular issue has been fixed yesterday in master, if you want to give it a try. Again, thanks for follow up. I think I had given up on this because of the strange behavior I couldn't figure out at the time. In fact, looking again today, my setting for org-adapt-indentation was commented out in my init file. Hopefully this is what was fixed recently. Here is what I remember: ** Heading :LOGBOOK: - State "CREATED" from [2021-01-22 Fri 12:56] \\ - Some comments here. :END: Then doing in/out dent with org-adapt-indentation set to 'headline-data would break just the comment part of the logbook entry, like so (everything else seemed to move OK): *** Heading :LOGBOOK: - State "CREATED" from [2021-01-22 Fri 12:56] \\ - Some comments here. :END: I am a Debian user, so I will get to test the latest commit in about 2 more years maybe? :D Jokes aside, I appreciate your follow up and so wanted to report back. I don't know when I will get to actually test the new fix, but if this is what was fixed I greatly appreciate it. Cheers, TRS-80
Re: Programmatically set TODO labels per file?
Samuel Wales writes:
> as you discovered, spaces can work for todo kw for at least some
> purposes. [i have one, because i prefer space to snake_case and
> kebab-case might not search well.] but you should check to see if it
> is guaranteed to work. i vaguely recall spc is not allowable.
>
> if it were guaranteed to work, then there would likely be a mechanism
> to include it in the #+ syntax. :)
Indeed, I am aware that spaces are not so welcome in some places
:). However this works fine:
(setq org-todo-keywords '((sequence "first label" "second label")))
If it is guaranteed or not I have no idea, maybe some other APIs in org
are expecting labels to be single words, but for simple purpose it seems
to work. #+ could actually use just "" as grouping items or {}. For
example:
#+TODO: "item one" "item two" ... "item n"
or with {}
#+TODO: {item one} {item two} ... {item n}
When I tried, I got citation characters included in my label, which
wasn't really what I wanted either :).
>
>
> On 4/29/21, Arthur Miller wrote:
>> Russell Adams writes:
>>
>>> On Thu, Apr 29, 2021 at 10:49:54PM +0200, Arthur Miller wrote:
Hi all,
I have a simple question, but I wasn't able to find answer on the web,
so finally I'll try my luck here.
I know I can setq org-todo-keywords with a list '((sequence "TODO"
DONE")), as an example. But what variable is used for per-file keywords?
Once that are set with #+TODO: ... line?
I guess when org mode parses a file when starting up the mode, it has to
parse that line into some var, where do I find it?
Thanks in advance!
Best regards
/a
>>>
>>> https://orgmode.org/manual/Per_002dfile-keywords.html
>>
>> Thanks Rusell; but I have seen the manual as I wrote. I am aware I can
>> use
>>
>> #+TODO:
>>
>> syntax to set per file keywords. I wanted to do this from lisp, since I
>> can't use labels with multiple words with that syntax since spaces are
>> used as delimiters for keywords, but I can pass strings (with spaces)
>> with lisp.
>>
>>
>>
Re: [PATCH] Bug: fragile org refile cache
some users of org might not know that org-refile can go to the location without refiling anything if you pass a c-u arg. thus, org-goto is not the only header-selecting goto mechanism; there is also refile goto. [and imenu, helm, etc.] i use refile-goto and find it satisfying for my purposes. the selection mechanism is exactly the same as for org-refile.
Re: Programmatically set TODO labels per file?
as you discovered, spaces can work for todo kw for at least some purposes. [i have one, because i prefer space to snake_case and kebab-case might not search well.] but you should check to see if it is guaranteed to work. i vaguely recall spc is not allowable. if it were guaranteed to work, then there would likely be a mechanism to include it in the #+ syntax. :) On 4/29/21, Arthur Miller wrote: > Russell Adams writes: > >> On Thu, Apr 29, 2021 at 10:49:54PM +0200, Arthur Miller wrote: >>> >>> Hi all, >>> >>> I have a simple question, but I wasn't able to find answer on the web, >>> so finally I'll try my luck here. >>> >>> I know I can setq org-todo-keywords with a list '((sequence "TODO" >>> DONE")), as an example. But what variable is used for per-file keywords? >>> Once that are set with #+TODO: ... line? >>> >>> I guess when org mode parses a file when starting up the mode, it has to >>> parse that line into some var, where do I find it? >>> >>> Thanks in advance! >>> >>> Best regards >>> /a >>> >> >> https://orgmode.org/manual/Per_002dfile-keywords.html > > Thanks Rusell; but I have seen the manual as I wrote. I am aware I can > use > > #+TODO: > > syntax to set per file keywords. I wanted to do this from lisp, since I > can't use labels with multiple words with that syntax since spaces are > used as delimiters for keywords, but I can pass strings (with spaces) > with lisp. > > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Turning off all indentation in 9.4.4
On 2021-04-28 00:09, Bastien wrote: TRS-80 writes: So, my reading of this new(?) headline-data setting, was that it seemed to be exactly what I had been looking for! But perhaps I misunderstood? So core idea behind (setq org-adapt-indentation 'headline-data) is to let people end up with: * TODO item :PROPERTIES: :CUSTOM_ID: item :END: :LOGBOOK: ... :END: A paragraph here. Let me know if if does not what you want, including what you expect from hitting RET after the headline, with the various combinations of org-adapt-indentation and electric-indent-mode. Thank you for the follow-up, Bastien. I haven't touched this in a while, but I do believe it does as I had always wanted (mainly leaving the body alone at column 0 as I in/out-dent the heading (and its associated data)) which sounds like the intention. The one issue I recall experiencing (breaking indentation of logbook entries) you seem to have addressed in another reply in this thread, where I will reply with more specifics. Cheers, TRS-80
[PATCH] ol.el: Fix confusing variable name
* ol.el (org-link--open-help): Fix a confusing variable name. No behavior changes. TINYCHANGE --- lisp/ol.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/ol.el b/lisp/ol.el index 62ea6d2bc..617223cb5 100644 --- a/lisp/ol.el +++ b/lisp/ol.el @@ -1325,8 +1325,8 @@ PATH is the sexp to evaluate, as a string." "Open a \"help\" type link. PATH is a symbol name, as a string." (pcase (intern path) -((and (pred fboundp) variable) (describe-function variable)) -((and (pred boundp) function) (describe-variable function)) +((and (pred fboundp) function) (describe-function function)) +((and (pred boundp) variable) (describe-variable variable)) (name (user-error "Unknown function or variable: %s" name (defun org-link--store-help () -- 2.31.1
Re: stability of toc links
hi trs, thank you. i can imagine that could be useful for a lot of users, but for me, as i said in my op, "short of adding custom id or id to everything" --- i didn't want to add custom id. i will try to clarify why in case it is useful. in addition to performance, and clutter, there is a semantic issue in my case. typically, if i see that there is a properties drawer, i know that it is there because of an org id or a manual custom id or a special purpose of my own. if i know it, i don't need to open it. however, adding custom id automatically for so many links means that there is a new meaning for properties drawers [namely, for stable linking done automatically]. i would have to open the drawer to determine if i personally wanted something there. and thus, the extra properties drawers would cause effort and distraction in this semantic sense, where i would be opening them because i would be thinking "did i really have a reason to add a properties drawer here? i don't recall so... better check" also, there is the issue that if i decide not to include something in the toc, it will still have a properties drawer lying around. in the op, i was not looking for a solution for one blog post, but thought a general solution for all org users might be possible. and this would likely be at the html level, probably by using e.g. header text, fuzzy or strict hashes, or a combination. when tec posted his html level code, it looked like the right type of solution to the problem. i have not tried it, however. i hope that clarifies. tec said he originally did not get much interest. then there was interest on this thread. then nothing. On 4/29/21, TRS-80 wrote: > On 2021-04-21 19:30, Samuel Wales wrote: >> as it has been a long time my original post is >> >> Message >> ID >> >> and the content is >> >> === >> when you link to a section using toc, you get a link like >> >> >> https://thekafkapandemic.blogspot.com/2020/02/crimes-against-humanity_3.html#org080f0ab >> >> will these links break if somebody copies them and pastes them >> elsewhere? what if you add a section? >> >> there doesn't seem to be a perfect solution, short of adding custom id >> or id to everything, but perhaps a fuzzy hash of the header and >> contents of the section could be used? or a strict hash of the >> header? is anything like this being done? just curious. > > My "quick and dirty" solution was to make a function to map over each > heading and assign a custom ID based on the text of the heading. It > only assigned one if one did not exist already (so in case you had > done any manual adjustments they would not be overwritten). > > I had posted it very early in the thread, but it did not seem to gain > much interest. It was not posted as a "long term and proper solution > to be included into Orgmode" but rather a quick and easy workaround in > the meantime. > > Cheers, > TRS-80 > > -- The Kafka Pandemic Please learn what misopathy is. https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: Programmatically set TODO labels per file?
Russell Adams writes: > On Thu, Apr 29, 2021 at 10:49:54PM +0200, Arthur Miller wrote: >> >> Hi all, >> >> I have a simple question, but I wasn't able to find answer on the web, >> so finally I'll try my luck here. >> >> I know I can setq org-todo-keywords with a list '((sequence "TODO" >> DONE")), as an example. But what variable is used for per-file keywords? >> Once that are set with #+TODO: ... line? >> >> I guess when org mode parses a file when starting up the mode, it has to >> parse that line into some var, where do I find it? >> >> Thanks in advance! >> >> Best regards >> /a >> > > https://orgmode.org/manual/Per_002dfile-keywords.html Thanks Rusell; but I have seen the manual as I wrote. I am aware I can use #+TODO: syntax to set per file keywords. I wanted to do this from lisp, since I can't use labels with multiple words with that syntax since spaces are used as delimiters for keywords, but I can pass strings (with spaces) with lisp.
async export and then do something with file
Hi everyone, I am wondering if I can perform and export asynchronously and then, without tying up emacs, wait around for the export to finish and then perform some other task, like upload the file to a server. Has anyone tried this before? I think perhaps the easiest thing to do would be to use async.el or some similar third-party, but I can't tell what the preferred method is. I would love osme guidance! Thanks, Matt
Re: Programmatically set TODO labels per file?
writes: > On Thu, Apr 29, 2021 at 10:49:54PM +0200, Arthur Miller wrote: >> >> Hi all, >> >> I have a simple question, but I wasn't able to find answer on the web, >> so finally I'll try my luck here. >> >> I know I can setq org-todo-keywords with a list '((sequence "TODO" >> DONE")), as an example. But what variable is used for per-file keywords? >> Once that are set with #+TODO: ... line? >> >> I guess when org mode parses a file when starting up the mode, it has to >> parse that line into some var, where do I find it? > > Use a file local variable? > > That said (or rather, asked), I don't know whether there is a specific > Org way to achieve that. As I understand the manual, the org specific way is to use per file variable, but instead of using Emacs _*_ for file variables, org uses #+ and they do their own parsing seems like. I might missunderstand, but the syntax to use is: #+TODO: keyword1 keyword2 ... keywordN I was looking around in org.el a bit now, and I see there are three vars associated with per-file todo keywords: org-todo-keywords-1 org-todo-kwd-alist and org-todo-key-alist which seem to be set in org-set-regexps-and-options function. I'll see if I can refactore something out from there for my purpose.
Re: stability of toc links
On 2021-04-21 19:30, Samuel Wales wrote: as it has been a long time my original post is Message ID and the content is === when you link to a section using toc, you get a link like https://thekafkapandemic.blogspot.com/2020/02/crimes-against-humanity_3.html#org080f0ab will these links break if somebody copies them and pastes them elsewhere? what if you add a section? there doesn't seem to be a perfect solution, short of adding custom id or id to everything, but perhaps a fuzzy hash of the header and contents of the section could be used? or a strict hash of the header? is anything like this being done? just curious. My "quick and dirty" solution was to make a function to map over each heading and assign a custom ID based on the text of the heading. It only assigned one if one did not exist already (so in case you had done any manual adjustments they would not be overwritten). I had posted it very early in the thread, but it did not seem to gain much interest. It was not posted as a "long term and proper solution to be included into Orgmode" but rather a quick and easy workaround in the meantime. Cheers, TRS-80
Re: Programmatically set TODO labels per file?
On Thu, Apr 29, 2021 at 10:49:54PM +0200, Arthur Miller wrote: > > Hi all, > > I have a simple question, but I wasn't able to find answer on the web, > so finally I'll try my luck here. > > I know I can setq org-todo-keywords with a list '((sequence "TODO" > DONE")), as an example. But what variable is used for per-file keywords? > Once that are set with #+TODO: ... line? > > I guess when org mode parses a file when starting up the mode, it has to > parse that line into some var, where do I find it? > > Thanks in advance! > > Best regards > /a > https://orgmode.org/manual/Per_002dfile-keywords.html -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Programmatically set TODO labels per file?
On Thu, Apr 29, 2021 at 10:49:54PM +0200, Arthur Miller wrote: > > Hi all, > > I have a simple question, but I wasn't able to find answer on the web, > so finally I'll try my luck here. > > I know I can setq org-todo-keywords with a list '((sequence "TODO" > DONE")), as an example. But what variable is used for per-file keywords? > Once that are set with #+TODO: ... line? > > I guess when org mode parses a file when starting up the mode, it has to > parse that line into some var, where do I find it? Use a file local variable? That said (or rather, asked), I don't know whether there is a specific Org way to achieve that. Cheers - t signature.asc Description: Digital signature
Re: How to use `open` to handle `message:*` links on macOS
On Thu, Apr 29, 2021 at 3:40 PM Tim Cross wrote: > > Tim Visher writes: > > > Thanks for the tips here. I finally got around to trying them out. > Here's what I ended up with and it's working perfectly. > > > > … > > > > Pairing that with my org-capture TODO Current Mail Template is a dream > come true. :) > > > > … > > I think this would be great content to add to the worg site. Would you > be willing to add this, plus a short outline of the issue you needed to > resolve so that others might benefit from your experience? > I'd be happy to if you wouldn't mind shepherding me through the process a bit. How does one go about "add[ing] to the worg site"? :)
Programmatically set TODO labels per file?
Hi all, I have a simple question, but I wasn't able to find answer on the web, so finally I'll try my luck here. I know I can setq org-todo-keywords with a list '((sequence "TODO" DONE")), as an example. But what variable is used for per-file keywords? Once that are set with #+TODO: ... line? I guess when org mode parses a file when starting up the mode, it has to parse that line into some var, where do I find it? Thanks in advance! Best regards /a
[PATCH] ob-eval.el: Refactoring `org-babel-eval' to improve readability
Hello everyone,
I have attached a patch to refactor `org-babel-eval' and
`org-babel--shell-command-on-region' to improve readability and to make
local variables more consistent between functions.
This also removes two parameters from
`org-babel--shell-command-on-region', START and END. The function was
created as a simplified `shell-command-on-region' that does only part of
what it does. Those two parameters were included. As far as I can tell,
`org-babel--shell-command-on-region' is only ever called by
`org-babel-eval', and there is never any uncertainty over the contents
of START and END as they are only ever (point-min) and (point-max).
Given how specialized this function is, I believe it highly unlikely
this is called anywhere else. I searched github too and didn't find
anywhere where where code is calling this so I felt it was safe. I'm
happy to change it back if necessary.
Please let me know what you think.
Thanks,
Nick
>From ac0cdc66374f1c99aadd5f07e0c6d65eaaa158cc Mon Sep 17 00:00:00 2001
From: Nicholas Savage
Date: Wed, 28 Apr 2021 06:15:47 -0400
Subject: [PATCH] ob-eval.el: Refactoring `org-babel-eval' to improve
readability
* ob-eval.el (org-babel-eval): Improve documentation and rename local
variables to be consistent with `org-babel--shell-command-on-region'
* (org-babel--shell-command-on-region): Remove START and END as
parameters.
* (org-babel--shell-command-on-region): Refactored out parts of
function to `org-babel--write-temp-buffer-input-file' and `org-babel--get-shell-file-name'.
This removes two parameters from
`org-babel--shell-command-on-region'. It appears that START and END
were parameters only because shell-command-on-region has them. This
function is only called by org-babel-eval so it looks safe to remove
those parameters, since they are always (point-min) and (point-max)
and are never changed. Given the way the function works and that it
is, it is unlikely that any user code relies on it.
---
lisp/ob-eval.el | 87 -
1 file changed, 50 insertions(+), 37 deletions(-)
diff --git a/lisp/ob-eval.el b/lisp/ob-eval.el
index b0fca7bd9..cfde4f1ca 100644
--- a/lisp/ob-eval.el
+++ b/lisp/ob-eval.el
@@ -41,20 +41,22 @@
(display-buffer buf))
(message "Babel evaluation exited with code %S" exit-code))
-(defun org-babel-eval (cmd body)
- "Run CMD on BODY.
-If CMD succeeds then return its results, otherwise display
-STDERR with `org-babel-eval-error-notify'."
- (let ((err-buff (get-buffer-create " *Org-Babel Error*")) exit-code)
-(with-current-buffer err-buff (erase-buffer))
+(defun org-babel-eval (command query)
+ "Run COMMAND on QUERY.
+Writes QUERY into a temp-buffer that is processed with
+org-babel--shell-command-on-region. If COMMAND succeeds then return
+its results, otherwise display STDERR with
+`org-babel-eval-error-notify'."
+ (let ((error-buffer (get-buffer-create " *Org-Babel Error*")) exit-code)
+(with-current-buffer error-buffer (erase-buffer))
(with-temp-buffer
- (insert body)
+ (insert query)
(setq exit-code
(org-babel--shell-command-on-region
- (point-min) (point-max) cmd err-buff))
+ command error-buffer))
(if (or (not (numberp exit-code)) (> exit-code 0))
(progn
- (with-current-buffer err-buff
+ (with-current-buffer error-buffer
(org-babel-eval-error-notify exit-code (buffer-string)))
(save-excursion
(when (get-buffer org-babel-error-buffer-name)
@@ -71,26 +73,19 @@ STDERR with `org-babel-eval-error-notify'."
(with-temp-buffer (insert-file-contents file)
(buffer-string)))
-(defun org-babel--shell-command-on-region (start end command error-buffer)
+(defun org-babel--shell-command-on-region (command error-buffer)
"Execute COMMAND in an inferior shell with region as input.
+Stripped down version of `shell-command-on-region' for internal use in
+Babel only. This lets us work around errors in the original function
+in various versions of Emacs. This expects the query to be run to be
+in the current temp buffer. This is written into
+input-file. ERROR-BUFFER is the name of the file which
+`org-babel-eval' has created to use for any error messages that are
+returned."
-Stripped down version of shell-command-on-region for internal use
-in Babel only. This lets us work around errors in the original
-function in various versions of Emacs.
-"
(let ((input-file (org-babel-temp-file "ob-input-"))
(error-file (if error-buffer (org-babel-temp-file "ob-error-") nil))
- ;; Unfortunately, `executable-find' does not support file name
- ;; handlers. Therefore, we could use it in the local case
- ;; only.
- (shell-file-name
- (cond ((and (not (file-remote-p default-directory))
- (executable-find shell-file-name))
- shell-file-name)
- ((file-executable-p
- (concat (file-remote-p default-directory) shell-file-name))
- shell-file-name)
- ("/bin/sh")))
+ (shell-file-name
Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
Timothy writes: > Colin Baxter writes: > >> Debian 9.13 may be old but updates are still made available. While >> Debian supports the os-version and therefore by implication emacs-24, I >> feel org-mode shouldn't deliberately break that support. > > I have to admit, I'm not sure why Org support should stretch so far > back. If it was a standalone thing, I could see it, but as it's > vendored with Emacs I'm not sure why we don't just do stable Emacs - 1 > (i.e. 26.3 ATM). I don't think we can set an absolute limit. It really depends on what has changed in Emacs. For example, if Emacs adds some feature or capability which really improves org performance, we might decide to drop older versions sooner to try and get everyone onto a more performant version. On the other hand, if new versions of Emacs don't really add any significantly beneficial changes, we might continue to support older versions for longer. We also need to consider changes in the Emacs release cycle. In recent years, this seems to have been faster than it use to be. Emacs 24.5 was released in April 2015, which is only 6 years ago. Emacs 25.3 was less than 4 years ago. People do tend to upgrade their hardware every 3 - 5 years and it can take distributions 2+ years to update the version they are shipping, so in general, we probably do need to support major versions for up to 5 or so years after release. However, this also needs to consider the adding of lexical binding as a significant enhancement. The next 'big one' is likely to be native compilation support for *.el files. I do think it is probably time to drop support for Emacs 24 in the next major release. However, we cannot drop it 'mid release'. -- Tim Cross
Re: How to use `open` to handle `message:*` links on macOS
Tim Visher writes:
> Hi Diego and Alexander,
>
> Thanks for the tips here. I finally got around to trying them out. Here's
> what I ended up with and it's working perfectly.
>
> (defun timvisher-org-link-mac-mail-open-link
> (mid _)
> (start-process "open-link" nil "open" (format "message://%%3C%s%%3E"
> mid)))
>
> (defun timvisher-org-link-mac-mail-add-message-links
> ()
> (org-link-set-parameters
>"message" :follow #'timvisher-org-link-mac-mail-open-link))
>
> (eval-after-load 'org
> '(timvisher-org-link-mac-mail-add-message-links))
>
> Pairing that with my org-capture TODO Current Mail Template is a dream come
> true. :)
>
> (defun timvisher-org-current-mail-get-selected-message-subject
> ()
> (with-temp-buffer
> (call-process
> "osascript" nil t nil
> "-e" "tell application \"Mail\" to get subject of item 1 of (selection
> as list)")
> (buffer-substring-no-properties (point-min) (- (point-max) 1
>
> (defun timvisher-org-current-mail-get-selected-message-id
> ()
> (with-temp-buffer
> (call-process
> "osascript" nil t nil
> "-e" "tell application \"Mail\" to get message id of item 1 of
> (selection as list)")
> (browse-url-url-encode-chars
> (buffer-substring-no-properties (point-min) (- (point-max) 1))
> "[/]")))
>
> (defun timvisher-org-current-mail-get-link-string
> ()
> (let ((subject (timvisher-org-current-mail-get-selected-message-subject))
> (message-id (timvisher-org-current-mail-get-selected-message-id)))
> (org-link-make-string (format "message:%s" message-id)
> subject)))
>
> (defun timvisher-org-current-mail-get-body-quote-template-element
> ()
> (let ((body (setq body (with-temp-buffer
> (call-process
> "osascript" nil t nil
> "-e" "tell application \"Mail\" to get content of item 1 of
> (selection as list)")
> (buffer-substring-no-properties (point-min) (- (point-max)
> 1))
> (format "
>
> #+begin_quote
> %s
> #+end_quote"
> (string-join
> (seq-reduce
> (lambda (acc next)
> (if (string= next (or (car (last acc)) ""))
> acc
> (append acc (list next
> (mapcar (lambda (string)
> (let ((string (string-trim string)))
> (if (string= "" string)
> string
> (format " %s" string
> (split-string body "\n"))
> '())
> "\n"
>
> (setq org-capture-templates
> '(…
> ("twcm" "TODO Work Current Mail" entry
> (file+headline "~/Dropbox/todo/work.org" "Inbox")
> "* TODO %(timvisher-org-current-mail-get-link-string)
>
> %U%(timvisher-org-current-mail-get-body-quote-template-element)" :prepend t
> :immediate-finish t)
> …))
>
> Thanks so much! :)
I think this would be great content to add to the worg site. Would you
be willing to add this, plus a short outline of the issue you needed to
resolve so that others might benefit from your experience?
--
Tim Cross
Re: [PATCH] Bug: fragile org refile cache
Ihor Radchenko writes: > Samuel Wales writes: > >> would it be more useful if it automaticaly generated the cache instead >> of telling you to runt he command to do so? > > I think so. To be frank, I do not understand the reason why it is not > done by default. > >> if a solid, perhaps unified, cache existed, would org-id use it too? > > Sure. Why not? I imagine such cache can store the following info: > > org files in system -> per-file cache -> per-heading cache -> ... > I suspect the reason it is not done automatically is that getting that right for all use cases is very hard to do without adding adverse impact to performance. A cache which is marked as 'dirty' too often results in too frequent cache refresh operations, but at the same time, determining what changes in an org file actually invalidate the cache can be a process intensive operation. Allowing the user to force cache refresh when needed is likely a reasonable compromise. I recall having a lot of trouble getting org-refile to work well for me. I use it a lot, but it was so long ago, I don't recall how I got to my final configuration (I think I may have modified my workflow to work better with what I was able to get working reasonably reliably and efficiently). I now tend to refile to a fairly static set of paths, so all works OK. Sorry I cannot provide anything more substantial. I do understand your frustration, but not sure what the right fix is. I can see having a cache which is automatically refreshed when necessary will be problematic to get working for all use cases. Having the ability to turn automatic refresh on/off and having the ability to manually force a refresh will likely always be required. -- Tim Cross
Re: How to use `open` to handle `message:*` links on macOS
Hi Tim,
Cool - thanks for the code! I may use it to improve my email capture
workflow :)
--Diego
On Thu, Apr 29, 2021 at 6:23 PM Tim Visher wrote:
> Hi Diego and Alexander,
>
> Thanks for the tips here. I finally got around to trying them out. Here's
> what I ended up with and it's working perfectly.
>
> (defun timvisher-org-link-mac-mail-open-link
> (mid _)
> (start-process "open-link" nil "open" (format "message://%%3C%s%%3E"
> mid)))
>
> (defun timvisher-org-link-mac-mail-add-message-links
> ()
> (org-link-set-parameters
>"message" :follow #'timvisher-org-link-mac-mail-open-link))
>
> (eval-after-load 'org
> '(timvisher-org-link-mac-mail-add-message-links))
>
> Pairing that with my org-capture TODO Current Mail Template is a dream
> come true. :)
>
> (defun timvisher-org-current-mail-get-selected-message-subject
> ()
> (with-temp-buffer
> (call-process
> "osascript" nil t nil
> "-e" "tell application \"Mail\" to get subject of item 1 of (selection
> as list)")
> (buffer-substring-no-properties (point-min) (- (point-max) 1
>
> (defun timvisher-org-current-mail-get-selected-message-id
> ()
> (with-temp-buffer
> (call-process
> "osascript" nil t nil
> "-e" "tell application \"Mail\" to get message id of item 1 of
> (selection as list)")
> (browse-url-url-encode-chars
> (buffer-substring-no-properties (point-min) (- (point-max) 1))
> "[/]")))
>
> (defun timvisher-org-current-mail-get-link-string
> ()
> (let ((subject (timvisher-org-current-mail-get-selected-message-subject))
> (message-id (timvisher-org-current-mail-get-selected-message-id)))
> (org-link-make-string (format "message:%s" message-id)
> subject)))
>
> (defun timvisher-org-current-mail-get-body-quote-template-element
> ()
> (let ((body (setq body (with-temp-buffer
> (call-process
> "osascript" nil t nil
> "-e" "tell application \"Mail\" to get content of item 1 of
> (selection as list)")
> (buffer-substring-no-properties (point-min) (- (point-max)
> 1))
> (format "
> #+begin_quote%s #+end_quote"
> (string-join
> (seq-reduce
> (lambda (acc next)
> (if (string= next (or (car (last acc)) ""))
> acc
> (append acc (list next
> (mapcar (lambda (string)
> (let ((string (string-trim string)))
> (if (string= "" string)
> string
> (format " %s" string
> (split-string body "\n"))
> '())
> "\n"
>
> (setq org-capture-templates
> '(…
> ("twcm" "TODO Work Current Mail" entry
> (file+headline "~/Dropbox/todo/work.org" "Inbox")
> "* TODO %(timvisher-org-current-mail-get-link-string)
> %U%(timvisher-org-current-mail-get-body-quote-template-element)" :prepend t
> :immediate-finish t)
> …))
>
> Thanks so much! :)
>
Re: [PATCH] Bug: fragile org refile cache
On 29/04/2021 23:08, Ihor Radchenko wrote: Maxim Nikulin writes: Curiously my experience is that avoiding this lazy cache with backtracking and maintaining custom structure during sequential scan of the buffer works several times faster. My experience is exactly opposite. Or maybe I miss something. Can you elaborate? My benchmarks may be incorrect due to for development version I did not compile files. I did not purged outline path cache as well. https://orgmode.org/list/s1qola$158l$1...@ciao.gmane.io/ Outline path without cache: (benchmark-run 1 (goto-char (point-min)) (while (re-search-forward "^\\*+" nil t) (org-get-outline-path t nil))) => (6.051079914 1 0.286472487869) Outline path with cache: (benchmark-run 1 (goto-char (point-min)) (while (re-search-forward "^\\*+" nil t) (org-get-outline-path t nil))) => (1.658461165 0 0.0) ^ t I suppose. I agree with such test. Notice however the following patch (warning: :level and :max-level a cached with the same key) https://orgmode.org/list/s209r8$16en$1...@ciao.gmane.io/ Avoiding call to org-get-outline-path and using custom structure during single pass scan through the buffer allowed to significantly improve performance. Just cleanup heading text: (benchmark-run 1 (goto-char (point-min)) (while (re-search-forward "^\\*+" nil t) (let ((case-fold-search nil)) (looking-at org-complex-heading-regexp) (if (not (match-end 4)) "" ;; Remove statistics cookies. (org-trim (org-link-display-format (replace-regexp-in-string "\\[[0-9]+%\\]\\|\\[[0-9]+/[0-9]+\\]" "" (match-string-no-properties 4 => (0.013364877 0 0.0) I may be wrong with the following statement. Attempt to profile org-refile-get-targets could give quite different results. I have seen a note that Emacs use internally a cache for only 5 compiled regular expressions. Just one extra regexp and every matching function require compiling of its regexp just wiped from the cache. It is a time consuming procedure. I am unsure whether you added all regexps used (directly or through function calls) by inner loop of org-refile-get-targets.
Re: [PATCH] org-protocol: decode "+" in query part as space (v2)
I have realized that only a half of new apostrophes in doc strings were
properly escaped, so I am attaching updated patch. I still consider the
change as a minor improvement.
On 06/04/2021 21:47, Maxim Nikulin wrote:
When I tried org-protocol for the first time, I was quite surprised that
query parameters generated using URLSearchParams JavaScript class are
decoded incorrectly. "+" characters representing space are passed as is.
I hope, I have found a proper place in the code to handle such case.
It does not affect previously recommended bookmarklets with abundant
calls of encodeURIComponent that escapes spaces as "%20". I believe, new
option is more readable:
javascript:location.href='org-protocol://capture?' +
new URLSearchParams({
template: 'x',
url: location.href,
title: document.title,
body: window.getSelection()});
I guess, with old org-protocol syntax only pure percent encoding was
necessary due to each parameter was represented as path component. "+"
is allowed only in query part. Such variant was just missed when new
query-like syntax was introduced.
>From 9bacd0761acd14fb5809042d96977bfd3088bee3 Mon Sep 17 00:00:00 2001
From: Max Nikulin
Date: Tue, 6 Apr 2021 21:30:06 +0700
Subject: [PATCH] org-protocol.el: decode "+" in query part as space
* lisp/org-protocol.el (org-protocol-convert-query-to-plist):
Replace "+" chars by spaces before passing parameter string
to decoder. Allow making org-protocol URIs with help of URLSearchParams
JavaScript class.
* lisp/org-protocol.el doc/org-manual.org etc/ORG-NEWS: Add examples
demonstrating new opportunity for browser bookmarklets.
Make parsing of URI parameters a bit closer to URL standard
https://url.spec.whatwg.org/#urlencoded-parsing
---
doc/org-manual.org | 22
etc/ORG-NEWS | 11 ++
lisp/org-protocol.el | 48 ++--
3 files changed, 75 insertions(+), 6 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index b547a8a5f..d91aa7a50 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -19596,11 +19596,20 @@ slashes, and probably quote those for the shell.
To use this feature from a browser, add a bookmark with an arbitrary
name, e.g., =Org: store-link= and enter this as /Location/:
+#+begin_example
+javascript:location.href='org-protocol://store-link?' +
+ new URLSearchParams({url:location.href, title:document.title});
+#+end_example
+
+Title is an optional parameter. Another expression was recommended earlier:
+
#+begin_example
javascript:location.href='org-protocol://store-link?url='+
encodeURIComponent(location.href);
#+end_example
+The latter form is compatible with older Org versions from 9.0 to 9.4.
+
*** The ~capture~ protocol
:PROPERTIES:
:DESCRIPTION: Fill a buffer with external information.
@@ -19616,6 +19625,15 @@ using acapture template.
To use this feature, add a bookmark with an arbitrary name, e.g.,
=Org: capture=, and enter this as =Location=:
+#+begin_example
+javascript:location.href='org-protocol://capture?' +
+ new URLSearchParams({
+template: 'x', url: window.location.href,
+title: document.title, body: window.getSelection()});
+#+end_example
+
+You might have seen another expression:
+
#+begin_example
javascript:location.href='org-protocol://capture?template=x'+
'='+encodeURIComponent(window.location.href)+
@@ -19623,6 +19641,10 @@ javascript:location.href='org-protocol://capture?template=x'+
'='+encodeURIComponent(window.getSelection());
#+end_example
+It is a bit more cluttered than the former one, but it is compatible with
+previous Org versions 9.0-9.4. In these versions encoding of space as "+"
+character was not supported by URI decoder.
+
#+vindex: org-protocol-default-template-key
The capture template to be used can be specified in the bookmark (like
=X= above). If unspecified, the template key is set in the variable
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 83dca5c03..724adc486 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -269,6 +269,17 @@ back to the filename as before.
The function does not allow for a third optional parameter anymore.
+*** Make org-protocol compatible with =URLSearchParams= JavaScript class
+
+Decoder of query part of org-protocol URI recognizes "+" as an encoded
+space characters now, so it is possible to avoid call to =encodeURIComponent=
+for each parameter and use more readable expression in bookmarklet:
+
+#+begin_example
+'org-protocol://store-link?' + new URLSearchParams({
+ url: location.href, title: document.title})
+#+end_example
+
* Version 9.4
** Incompatible changes
*** Possibly broken internal file links: please check and fix
diff --git a/lisp/org-protocol.el b/lisp/org-protocol.el
index 30f5bc040..a09d7fbed 100644
--- a/lisp/org-protocol.el
+++ b/lisp/org-protocol.el
@@ -94,6 +94,15 @@
;; You may use
Re: How to use `open` to handle `message:*` links on macOS
Hi Diego and Alexander,
Thanks for the tips here. I finally got around to trying them out. Here's
what I ended up with and it's working perfectly.
(defun timvisher-org-link-mac-mail-open-link
(mid _)
(start-process "open-link" nil "open" (format "message://%%3C%s%%3E"
mid)))
(defun timvisher-org-link-mac-mail-add-message-links
()
(org-link-set-parameters
"message" :follow #'timvisher-org-link-mac-mail-open-link))
(eval-after-load 'org
'(timvisher-org-link-mac-mail-add-message-links))
Pairing that with my org-capture TODO Current Mail Template is a dream come
true. :)
(defun timvisher-org-current-mail-get-selected-message-subject
()
(with-temp-buffer
(call-process
"osascript" nil t nil
"-e" "tell application \"Mail\" to get subject of item 1 of
(selection as list)")
(buffer-substring-no-properties (point-min) (- (point-max) 1
(defun timvisher-org-current-mail-get-selected-message-id
()
(with-temp-buffer
(call-process
"osascript" nil t nil
"-e" "tell application \"Mail\" to get message id of item 1 of
(selection as list)")
(browse-url-url-encode-chars
(buffer-substring-no-properties (point-min) (- (point-max) 1))
"[/]")))
(defun timvisher-org-current-mail-get-link-string
()
(let ((subject (timvisher-org-current-mail-get-selected-message-subject))
(message-id (timvisher-org-current-mail-get-selected-message-id)))
(org-link-make-string (format "message:%s" message-id)
subject)))
(defun timvisher-org-current-mail-get-body-quote-template-element
()
(let ((body (setq body (with-temp-buffer
(call-process
"osascript" nil t nil
"-e" "tell application \"Mail\" to get content of
item 1 of (selection as list)")
(buffer-substring-no-properties (point-min) (-
(point-max) 1))
(format "
#+begin_quote%s #+end_quote"
(string-join
(seq-reduce
(lambda (acc next)
(if (string= next (or (car (last acc)) ""))
acc
(append acc (list next
(mapcar (lambda (string)
(let ((string (string-trim string)))
(if (string= "" string)
string
(format " %s" string
(split-string body "\n"))
'())
"\n"
(setq org-capture-templates
'(…
("twcm" "TODO Work Current Mail" entry
(file+headline "~/Dropbox/todo/work.org" "Inbox")
"* TODO %(timvisher-org-current-mail-get-link-string)
%U%(timvisher-org-current-mail-get-body-quote-template-element)"
:prepend t :immediate-finish t)
…))
Thanks so much! :)
Re: [PATCH] Bug: fragile org refile cache
Maxim Nikulin writes: > Curiously my experience is that avoiding this lazy cache with > backtracking and maintaining custom structure during sequential scan of > the buffer works several times faster. My experience is exactly opposite. Or maybe I miss something. Can you elaborate? > ... However it is appropriate time to > populate the cache you mentioned. Unfortunately it is still necessary to > cleanup heading text, and it consumes significant time. Did you do any benchmarks? I just tried Outline path without cache: (benchmark-run 1 (goto-char (point-min)) (while (re-search-forward "^\\*+" nil t) (org-get-outline-path t nil))) => (6.051079914 1 0.286472487869) Outline path with cache: (benchmark-run 1 (goto-char (point-min)) (while (re-search-forward "^\\*+" nil t) (org-get-outline-path t nil))) => (1.658461165 0 0.0) Just cleanup heading text: (benchmark-run 1 (goto-char (point-min)) (while (re-search-forward "^\\*+" nil t) (let ((case-fold-search nil)) (looking-at org-complex-heading-regexp) (if (not (match-end 4)) "" ;; Remove statistics cookies. (org-trim (org-link-display-format (replace-regexp-in-string "\\[[0-9]+%\\]\\|\\[[0-9]+/[0-9]+\\]" "" (match-string-no-properties 4 => (0.013364877 0 0.0) Best, Ihor
Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
> Timothy writes: > Colin Baxter writes: >> Debian 9.13 may be old but updates are still made >> available. While Debian supports the os-version and therefore by >> implication emacs-24, I feel org-mode shouldn't deliberately >> break that support. > I have to admit, I'm not sure why Org support should stretch so > far back. If it was a standalone thing, I could see it, but as > it's vendored with Emacs I'm not sure why we don't just do stable > Emacs - 1 (i.e. 26.3 ATM). That's another view, and quite reasonable. I'll stick to mine but I'm happy to be "out-voted". Best wishes,
Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
Colin Baxter writes: > Debian 9.13 may be old but updates are still made available. While > Debian supports the os-version and therefore by implication emacs-24, I > feel org-mode shouldn't deliberately break that support. I have to admit, I'm not sure why Org support should stretch so far back. If it was a standalone thing, I could see it, but as it's vendored with Emacs I'm not sure why we don't just do stable Emacs - 1 (i.e. 26.3 ATM). -- Timothy
Re: could a :var header argument refer to a data table in another file?
On Thursday, 29 Apr 2021 at 10:51, John Kitchin wrote: > I don't know if it is in the manual. It would be great to have it in > https://orgmode.org/manual/Environment-of-a-Code-Block.html. Indeed. I'll add this to my todo list. (although happy if anybody else steps up and does it, of course) -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-381-g17ef1b.dirty
Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
> Robert Horn writes: > Colin Baxter writes: >>> Robert Horn writes: >> >> > Timothy writes: >> >> >> Ihor Radchenko writes: >> >> >> >> Maybe this is a good time to start a discussion about moving >> >> Org's minimum supported Emacs to 25...? >> >> > I checked Red Hat, Centos, Debian, SuSE, and Ubuntu. They are >> all > 25.1 or later in their current distributions. So that will >> > probably not cause too much breakage. >> >> > -- Robert Horn rjh...@alum.mit.edu >> >> Debian 9.13 (which is still supported) has emacs-24. > Interesting question about LTS. How far back should we consider > when estimating the impact of a change like this? I was looking > at current stable versions to estimate the impact of the change. > Lots of users avoid the bleeding edge distribution releases, but > most update to track the current stable/LTS releases. Or they > won't complain that it's unfair for org to expect them to update > emacs to the current stable/LTS version. > Ubuntu, Red Hat, CentOS and SuSE are 25.1 or above for their most > recent long term support releases. Some of these distributions go > a lot further with various forms of long term support. I think > Red Hat goes back 8 years for example, and that emacs is really > old. > It looks like 25.1 is available, but not yet the default for > Debian "stretch" (Debian 9.13), which is the "oldstable" for > Debian. With Debian backport efforts I don't know if this means > months or years. The web page for Emacs25inStretch has not > changed since 2017, so it might never happen. Debian 9.13 may be old but updates are still made available. While Debian supports the os-version and therefore by implication emacs-24, I feel org-mode shouldn't deliberately break that support.
Re: [PATCH] Bug: fragile org refile cache
On 29/04/2021 21:12, Ihor Radchenko wrote: There is org-outline-path-cache used by org-get-outline-cache. It avoids computing parent's outline path multiple times, which is already a great improvement. Curiously my experience is that avoiding this lazy cache with backtracking and maintaining custom structure during sequential scan of the buffer works several times faster. However it is appropriate time to populate the cache you mentioned. Unfortunately it is still necessary to cleanup heading text, and it consumes significant time. org-refile-cache can be simply let-bound to nil (in my case) or alternative cache variable, if the alternative cache should persist. Thank you for the idea. But I still hope that both function could use the same cache.
Re: could a :var header argument refer to a data table in another file?
I don't know if it is in the manual. It would be great to have it in https://orgmode.org/manual/Environment-of-a-Code-Block.html. John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Thu, Apr 29, 2021 at 9:42 AM Eric S Fraga wrote: > On Thursday, 29 Apr 2021 at 09:17, John Kitchin wrote: > > This syntax works for me. > > > > #+BEGIN_SRC python :var data=data.org:remote-table > > Brilliant! As usual, if I want to do something in org, it can be done. > > Did you find this in the manual? I did look but must have missed it. > > thank you, > eric > > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-381-g17ef1b.dirty >
Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
Colin Baxter writes: >> Robert Horn writes: > > > Timothy writes: > > >> Ihor Radchenko writes: > >> > >> Maybe this is a good time to start a discussion about moving > >> Org's minimum supported Emacs to 25...? > > > I checked Red Hat, Centos, Debian, SuSE, and Ubuntu. They are all > > 25.1 or later in their current distributions. So that will > > probably not cause too much breakage. > > > -- Robert Horn rjh...@alum.mit.edu > > Debian 9.13 (which is still supported) has emacs-24. Interesting question about LTS. How far back should we consider when estimating the impact of a change like this? I was looking at current stable versions to estimate the impact of the change. Lots of users avoid the bleeding edge distribution releases, but most update to track the current stable/LTS releases. Or they won't complain that it's unfair for org to expect them to update emacs to the current stable/LTS version. Ubuntu, Red Hat, CentOS and SuSE are 25.1 or above for their most recent long term support releases. Some of these distributions go a lot further with various forms of long term support. I think Red Hat goes back 8 years for example, and that emacs is really old. It looks like 25.1 is available, but not yet the default for Debian "stretch" (Debian 9.13), which is the "oldstable" for Debian. With Debian backport efforts I don't know if this means months or years. The web page for Emacs25inStretch has not changed since 2017, so it might never happen. -- Robert Horn rjh...@alum.mit.edu
Re: Concerns about community contributor support
Hi Bastien, Hi Ihort > https://updates.orgmode.org whoops, I completely overlooked that. > Org, whether they want to help, fix confirmed bugs or review patches. > > Of course, https://updates.orgmode.org is in alpha and we can still > improve it a lot. In particular, I plan to let it track unconfirmed > bugs too, to help with bug triage, and to provide woof.el to ease > interaction with this tool directly from within Emacs. > > Ideas are welcome: https://github.com/bzg/woof/issues I'll look into it, thank you! > In general, I find it good to have a central communication place for > the community, where newcomers can learn from more experienced users > and I've always resisted to the urge of having e.g. org-users@ and > org-devel@ mailing lists, as some projects have. Nowadays, users who > don't want to mix with Org's development can interact on many other > places (SO, reddit and others). I'm not sure sure whether it is about mixing with development personally, but I think my point is largely addressed by updates.orgmode.org. Cheers, D.
Re: Notes about citations in Org (part 3)
On Thu, Apr 29, 2021 at 10:06 AM Nicolas Goaziou wrote: > ... at this point, I would suggest to spend energy porting "citeproc-org" or > "org-ref" to > this API instead. +1 Thanks for the update, and the work, Nicolas! I agree any remaining details are best worked out in the process of adapting existing solutions to this. I assume it should be a relatively small step for citeproc-org to support this, but obviously that's for Andras to confirm. I will do my small part by updating my function to generate that modified syntax from a list of keys. Bruce
Re: Concerns about community contributor support
D writes: > TL;DR: Maybe we could improve the visibility of patches by having a > dedicated mailing list for them? This would also allow for a greater > deal of automation in the way we deal with patches. What about https://updates.orgmode.org/? Or do you refer to something else? Best, Ihor
Re: Concerns about community contributor support
Hi, D writes: > TL;DR: Maybe we could improve the visibility of patches by having a > dedicated mailing list for them? This would also allow for a greater > deal of automation in the way we deal with patches. We do have a dedicated information channel for patches: https://updates.orgmode.org/#patches You can subscribe to it with this RSS feed: https://updates.orgmode.org/feed/patches Once subscribed, you will only receive the patches, nothing else. You can track all updates via the gwene.org.orgmode.updates newsgroup on news.gmane.io. This idea is precisely to help people organize their contributions to Org, whether they want to help, fix confirmed bugs or review patches. Of course, https://updates.orgmode.org is in alpha and we can still improve it a lot. In particular, I plan to let it track unconfirmed bugs too, to help with bug triage, and to provide woof.el to ease interaction with this tool directly from within Emacs. Ideas are welcome: https://github.com/bzg/woof/issues In general, I find it good to have a central communication place for the community, where newcomers can learn from more experienced users and I've always resisted to the urge of having e.g. org-users@ and org-devel@ mailing lists, as some projects have. Nowadays, users who don't want to mix with Org's development can interact on many other places (SO, reddit and others). -- Bastien
Re: [PATCH] Allow multiple %(expression) instances in org-agenda-prefix-format
Bastien writes: > Applied as 0260d2fcf, thanks! Looking at the patch again, I notice that it will break code like "%((this (has (many parenthesis". Though I have no clue how to match balanced parenthesis using Elisp regexps. Best, Ihor
org-attach-attach in an org-capture template?
Hi Everyone,
*TL;DR:* I've recently started using org-capture and I'd like to run
org-attach-attach during the expansion of a few of my templates. Doing so
from a template function seems not to work (meaning a function in a
template string called with %(…)). What's the best way to go about this?
--
I've recently started to explore org-capture and it's pretty great. I'm
interested in having one of my templates search for a file somewhere and,
if it finds one, add it to the current template as an attachment.
My initial test template looks something like:
(defun attach-file
()
(org-attach-attach (expand-file-name "a file")
nil
'cp))
(setq org-capture-templates
'("T" "TEST" entry
(file+headline "~/x.org" "Inbox")
"* TODO Foo%(attach-file)
%U"))
The idea being that attach-file would call org-attach-attach if it could
find a file and always expand to nothing.
Upon testing that I see the following (org 9.4.5-g287af2, emacs 27.2 (build
1, x86_64-apple-darwin18.7.0)):
** TODO Foo%![Error: (error bug: org-id-get expects a file-visiting buffer)]
:PROPERTIES:
:ID: 05837793-5A4F-42FC-AB50-5165FA7ECC4B
:END:
[2021-04-29 Thu 09:52]
If I then call org-attach manually on the resulting entry I can attach a
file fine to it.
I'm aware that I can make the template an elisp function and do the work
all internally. That's probably what I'll start doing presently. But it's a
little annoying that I then need to reimplement org-capture's built-in
template expansion in some way (like %U for the current inactive timestamp).
I also believe I could do this with one of the org-capture hooks but
examining them I didn't see the obvious right one to add my function to. I
would think it would be the org-capture-prepare-finalize-hook and I may
just give that a try. I further assume then that I'd need to to apply the
advice here
Re: [PATCH] ob-C.el: Fix a number a bugs related to table parameters
Hi Asa, Bastien writes: > thanks for the patch. I'm copying Thierry as the (new) maintainer for > ob-C.el. Thierry applied a variant of the patch in maint with commit 38f87a26. Thanks, -- Bastien
Re: [PATCH] Bug: fragile org refile cache
Maxim Nikulin writes: > Maybe I could avoid org-goto as well. Actual reason to use it was that > it does not ask for file name as the first step in the case of > (org-refile-use-outline-path 'file). It took enough time to me to > realize how to jump/refile to non-leaf heading without such settings. Note that Org mode has integration with imenu. It is an alternative you can use to jump around current buffer. > Just an idea. Is it possible to implement some specific text property > for heading lines, namely cleaned out heading text (no cookies, tags, > hidden parts of links), that is updated after each editing (likely > something like font locks)? It could significantly speed up scanning > buffer for goto/refile targets. Unfortunately it would not help for > files that have not opened yet. There is org-outline-path-cache used by org-get-outline-cache. It avoids computing parent's outline path multiple times, which is already a great improvement. For the cleaned heading text, I do not think that re-calculating the heading text on each change is a good idea. It may degrade typing latency. Yet, an acceptable approach could be simply invalidating cache for the changed headings. Then, outline paths can be re-calculated on changed headings when needed. This should be an improvement compared to blanket (setq org-outline-path-cache nil) in org-refile-get-targets. > To be clear, org-refile and org-goto share the same cache and it is the > source of the problem. I would say that the problem is rather org-goto (ab)using org-refile incorrectly. I have the following piece of elisp using org-refile mechanism for headline selection: (let ((org-refile-history (append saved-id parent-project)) (org-refile-cache nil) (org-refile-target-verify-function #'org-att-id-skip-function)) (let ((prompt-ans (org-refile-get-location "Link to attachment from"))) (prog1 (org-id-get (seq-find #'markerp prompt-ans) 'create org-refile-cache can be simply let-bound to nil (in my case) or alternative cache variable, if the alternative cache should persist. Best, Ihor
Re: Concerns about community contributor support
Hi Timothy,
I was quite weary to bring up this point, but given the sheer volume of
patch-related exchanges in recent memory I feel that it may be worth
bringing up as I have not yet seen it discussed (if I overlooked it, my
apologies): I don't think the core problem can (or maybe should) be
solved by sheer manpower alone. I would argue that the issue may be
partially infrastructural in nature. This ML is incredibly active, with
a lot of different people surely following it for different reasons.
However, I am not entirely convinced that having patches, bug reports
and general discussions all in one place is necessarily a net positive
for people wanting to contribute to the project (once a project hits a
certain size, at least). It lacks a certain separation of concerns that
clearly informed the design of forges like GitHub (having separate
"Issues" and "PRs").
I may be alone with this opinion, given manually organizing is a
personal weakness of mine, and something I prefer to avoid at all costs,
but I think having a separate list for patches would greatly improve
their visibility without having to resort to band-aids like automated
subject-based filtering schemes which are thwarted by mundane human
error ("[PTACH]"). On the other hand, were I completely alone with this
opinion, then we wouldn't have dozens of emacs-* mailing lists already.
TL;DR: Maybe we could improve the visibility of patches by having a
dedicated mailing list for them? This would also allow for a greater
deal of automation in the way we deal with patches.
Cheers,
D.
Notes about citations in Org (part 3)
Hello,
This post is an update about "wip-cite-new" branch, which I rebased
a few minutes ago. It introduces changes that make previous reports
obsolete. In particular, the "demo" I wrote in the previous thread is no
longer applicable directly, even though the ideas developed there still
hold. Please comment on this thread from now on.
The first noteworthy changes are about the syntax.
1. I re-introduced objects in prefixes and suffixes, which can again
contain usual emphasis (bold, italic, strike-through, underscore,
code, verbatim), subscript, superscript, entities and LaTeX
fragments.
2. I removed support for "suppress author" minus symbol.
The complete syntax is now
[cite/style:common prefix ;prefix @key suffix; ... ; common suffix]
Everything is optional, except the brackets, "cite" and the colon. Also
the citation must contain at least a key. So its minimal form is:
[cite:@key]
Spaces are meaningful in prefixes and suffixes, except for those right
after the colon and those before the closing bracket.
As a reminder, the syntax also supports the following keywords.
#+bibliography: file
#+cite_export: [processor] [bibliography-style] [citation-style]
#+print_bibliography: [style]
For complete information about styles, please refer to the last post,
"(Not so) Short note about citations in Org".
>From a technical standpoint, as a consequence of item 1,
(org-element-property :prefix citation)
or
(org-element-property :prefix citation-reference)
may return so-called "secondary strings", i.e., lists of strings and
objects. In order to deal with this additional complexity, I implemented
some specific tooling in "oc.el": `org-cite-concat' and
`org-cite-mapconcat' are similar to `concat' and `mapconcat', but can
also operate on secondary strings and objects. For example, a processor
developer could write:
(org-cite-concat "(" (org-element-property :prefix citation) ")")
and later export the result with `org-export-data' as if the central
argument were a string.
This new revision also introduces additional tooling, which I won't
comment but is worth looking at if you consider giving a try at writing
a citation processor: `org-cite-key-number', `org-cite-wrap-citation',
`org-cite-make-paragraph', and `org-cite-emphasize'.
The other incompatibility is about function signatures for
`:export-bibliography' and `:export-finalizer' keywords. This change
should not be an issue at this point in the development. Citation
processors are registered using `org-cite-register-processor'. Its
docstring follows:
--8<---cut here---start->8---
Mark citation processor NAME as available.
NAME is a symbol. BODY is a property list, where the following optional keys
can be set:
`:activate'
Function activating a citation. It is called with a single argument: a
citation object extracted from the current buffer. It may add text
properties to the buffer. If it is not provided, `org-cite-fontify-default'
is used.
`:export-bibliography'
Function rendering a bibliography. It is called with five arguments:
the list of citation keys used in the document, as strings, a list
of bibliography files, the style, as a string or nil, the export back-end,
as a symbol, and the communication channel, as a property list.
It is called at each \"print_bibliography\" keyword in the parse tree.
It may return a string or nil. When it returns nil, the keyword is ignored.
Otherwise, the string it returns replaces the keyword in the export output.
`:export-citation'(mandatory for \"export\" capability)
Function rendering citations. It is called with four arguments: a citation
object, the style, as a string or nil, the export back-end, as a symbol,
and the communication channel, as a property list.
It is called on each citation object in the parse tree. It may return
a string or nil. When it returns nil, the citation is ignored. Otherwise,
the string it returns replaces the citation object in the export output.
`:export-finalizer'
Function called at the end of export process. It must accept six arguments:
the output, as a string, a list of citation keys used in the document,
a list of bibliography files, a list of bibliography styles requested by
\"print_bibliography\" keywords, as strings or nil, the export back-end,
as a symbol, and the communication channel, as a property list
It must return a string, which will become the final output from the export
process, barring subsequent modifications from export filters.
`:follow'
Function called to follow a citation. It accepts two arguments, the
citation or citation reference object at point, and any prefix argument
received during interactive call of `org-open-at-point'.
--8<---cut here---end--->8---
Ah! I almost forgot… This new revision introduces a
Re: could a :var header argument refer to a data table in another file?
And, just to add: it works like a charm! Thank you again. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-381-g17ef1b.dirty
Re: could a :var header argument refer to a data table in another file?
On Thursday, 29 Apr 2021 at 09:17, John Kitchin wrote: > This syntax works for me. > > #+BEGIN_SRC python :var data=data.org:remote-table Brilliant! As usual, if I want to do something in org, it can be done. Did you find this in the manual? I did look but must have missed it. thank you, eric -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-381-g17ef1b.dirty
Re: [PATCH] Bug: fragile org refile cache
Samuel Wales writes: > would it be more useful if it automaticaly generated the cache instead > of telling you to runt he command to do so? I think so. To be frank, I do not understand the reason why it is not done by default. > if a solid, perhaps unified, cache existed, would org-id use it too? Sure. Why not? I imagine such cache can store the following info: org files in system -> per-file cache -> per-heading cache -> ... Best, Ihor
Re: could a :var header argument refer to a data table in another file?
This syntax works for me. #+BEGIN_SRC python :var data=data.org:remote-table print(data) #+END_SRC John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Thu, Apr 29, 2021 at 8:36 AM Eric S Fraga wrote: > Hello all, > > TL;DR: I have the need to reference a table that is in another file to > pass as data to a src block in the current file. Is this possible? > Hints welcome! > > Longer version: I am running a series of numerical experiments, each of > which generates output files (using org syntax!). I want to process the > data in those files for inclusion in a paper. Now, I could write a > shell script which extracts all these data and collates them etc. but it > would be ideal if I could simply refer to a table in another file > directly. The tables are all named although a given table in each > output file will have the same name (I hope that makes sense). > > One thing that comes to mind is some elisp in the argument to the :var > header argument. Is this possible? I've not tried... > > Thank you, > eric > > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-381-g17ef1b.dirty > >
Re: [PATCH] Bug: fragile org refile cache
On 29/04/2021 08:29, Ihor Radchenko wrote: I do not observe the breakage as described in the first message, mostly because I use refile cache exclusively for org-refile. Maybe I could avoid org-goto as well. Actual reason to use it was that it does not ask for file name as the first step in the case of (org-refile-use-outline-path 'file). It took enough time to me to realize how to jump/refile to non-leaf heading without such settings. A faster, more reliable, caching would be certainly welcome. Just an idea. Is it possible to implement some specific text property for heading lines, namely cleaned out heading text (no cookies, tags, hidden parts of links), that is updated after each editing (likely something like font locks)? It could significantly speed up scanning buffer for goto/refile targets. Unfortunately it would not help for files that have not opened yet. I am aware at least about org-element, org-scan-tags, org-agenda, org-refile, and org-goto. To be clear, org-refile and org-goto share the same cache and it is the source of the problem. A good > implementation coming to my mind is org-ql [1]. I have not looked into the code yet, so I am not ready to discuss it. At least Adam should agree to submit patches to org and Bastien and Nicolas should agree to support it. On 29/04/2021 08:34, Samuel Wales wrote: would it be more useful if it automaticaly generated the cache instead of telling you to runt he command to do so? I am surprised as well that cache is not just regenerated when org-refile detects that it is stale. Can it be that under certain circumstances it just causes delay and, even with updated cache, user action fails anyway? On 29/04/2021 07:50, Samuel Wales wrote: i cannot reach the thread you point to, however. Actually namely your response inspired me to look closer at the implementation of collection of refile targets. Is there a particular form of Message-Id that is convenient for you? The date of initial message is 2021-03-02 (in UTC).
could a :var header argument refer to a data table in another file?
Hello all, TL;DR: I have the need to reference a table that is in another file to pass as data to a src block in the current file. Is this possible? Hints welcome! Longer version: I am running a series of numerical experiments, each of which generates output files (using org syntax!). I want to process the data in those files for inclusion in a paper. Now, I could write a shell script which extracts all these data and collates them etc. but it would be ideal if I could simply refer to a table in another file directly. The tables are all named although a given table in each output file will have the same name (I hope that makes sense). One thing that comes to mind is some elisp in the argument to the :var header argument. Is this possible? I've not tried... Thank you, eric -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-381-g17ef1b.dirty
Re: [PATCH] Have C-c C-c recognise #+plot lines
Hi Timothy, On Thursday, 29 Apr 2021 at 02:04, Timothy wrote: > Have you had a chance to test this out? Yes, sorry for the delay; work pressures... C-c C-c seems to work fine on #+plot lines and the point does not move. thank you, eric -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-381-g17ef1b.dirty
Re: Bug: Org mode fails to compile using Emacs 24.5-r10 [9.4.5 (9.4.5-g3ea248 @ /home/yantar92/.emacs.d/straight/build/org/)]
> Robert Horn writes: > Timothy writes: >> Ihor Radchenko writes: >> >> Maybe this is a good time to start a discussion about moving >> Org's minimum supported Emacs to 25...? > I checked Red Hat, Centos, Debian, SuSE, and Ubuntu. They are all > 25.1 or later in their current distributions. So that will > probably not cause too much breakage. > -- Robert Horn rjh...@alum.mit.edu Debian 9.13 (which is still supported) has emacs-24.
