Re: Possible bug getting bounds of URL at point?
On 17 Jul 2024, Ihor Radchenko wrote: The notion of "URL", and especially "URL at point" in Org mode needs to be special. Consider something like [[https://orgmode.org][this is a very long and /convoluted/ description of this url; all the text here is clickable as a link]]. Org mode will consider point anywhere inside the link as "at URL". That "URL" will be https://orgmode.org, and it is indeed what (thing-at-point 'url) will return on that link in Org mode, even when point is on the link description. Hope it makes sense. What does not make sense in such scenario is returning (bounds-of-thing-at-point 'url) to not include point. So, we instead return the relevant syntax object - link object. And that object includes description, brackets, and whitespace after. There is no reason to make plain links special in this regard, so we don't. Thank you for the explanation, Ihor. I'm sure there are people depending on the fact that the rest of the line, after a plain link, is still part of the same node. My code does a manipulation of just the link itself -- for example, in one keystroke, it turns https://example.org/ into [[https://example.org/][example.org]] In order for that to work, I needed the bounds to be the start and end of the link text itself. But that was easy to do: I just temporarily override `bounds-of-thing-at-point-provider-alist' in Org Mode, so that I get the default thingatpt handler instead. So: problem solved. Best regards, -Karl
Re: Possible bug getting bounds of URL at point?
On 16 Jul 2024, Ihor Radchenko wrote: Assume we have this line in an Org Mode buffer (note there are three trailing spaces after the final "m" -- hopefully the MTAs and MUAs will leave those spaces there): https://example.com Let's say the initial "h" is at position 22205, the position right after the final "m" is 4, and the final position on the line (after the three spaces) is 7. With point anywhere inside the URL, if I run (bounds-of-thing-at-point 'url), I currently get this result: (22205 . 7) But I expected this result instead: (22205 . 4) Is (22205 . 7) correct, and I'm just misunderstanding how URL boundaries are supposed to work in Org Mode? This is correct. Trailing whitespace belongs to the preceding node in Org syntax. This is not a bug. Moreover, if you have something like [[https//orgmode.org][description]] the whole thing will be considered a URL. Thank you, Ihor. I admit that I don't immediately understand why this is a good thing. The user asked for the bounds of the URL at point, but got instead the bounds of some other thing (the Org "node"). Especially in the case of a standalone URL, with no description text, I don't see how including the whitespace is useful. However, there could be issues here that I'm not familiar with. It sounds like you've already thought this out and concluded that that including the trailing whitespace is the right behavior. If you have time to explain why in more detail, I'd appreciate a chance to learn more about it. However, if you don't have time to do that, it's no problem. I can change the code I'm writing to do things a different way, so this behavior need not interfere with my current task, in any case. Best regards, -Karl
Possible bug getting bounds of URL at point?
In Org Mode buffers, `bounds-of-thing-at-point-provider-alist' names a Org-Mode-specific URL provider: ((url . org--bounds-of-link-at-point)) That handler is defined in org.el: (defun org--bounds-of-link-at-point () "`bounds-of-thing-at-point' provider function." (let ((context (org-element-context))) (when (eq (org-element-type context) 'link) (cons (org-element-begin context) (org-element-end context) (This is in the tree as of today, commit f2141541b45.) I think this is causing URL boundaries to be calculated incorrectly. REPRODUCTION: Assume we have this line in an Org Mode buffer (note there are three trailing spaces after the final "m" -- hopefully the MTAs and MUAs will leave those spaces there): https://example.com Let's say the initial "h" is at position 22205, the position right after the final "m" is 4, and the final position on the line (after the three spaces) is 7. With point anywhere inside the URL, if I run (bounds-of-thing-at-point 'url), I currently get this result: (22205 . 7) But I expected this result instead: (22205 . 4) Is (22205 . 7) correct, and I'm just misunderstanding how URL boundaries are supposed to work in Org Mode? I haven't yet debugged into `org-element-end' (nor into `org-element-property', which is what `org-element-end' wraps). First I want to check that my expectations are correct. Is there a bug here? Best regards, -Karl
Re: [FR] A more general case than footnotes
On 02 Nov 2023, Suhail Singh wrote: Karl Fogel writes: My original announcement post from a year ago [2] is a good place to get a quick overview of how oref.el works. ... [2] https://lists.gnu.org/archive/html/emacs-humanities/2022-10/msg9.html From [2]: Thus, in "jones-interview.org" you might have this: Blah blah blah and then she said that the rockets had reached speeds of .3c in testing scenarios on a few occasions. [ref:1c3a90a9] Is it intended to be [ref:1c3a90a9] or is it supposed to be [[ref:1c3a90a9]] (i.e., a regular link without description)? The former: [ref:1c3a90a9] oref.el isn't specific to Org Mode -- it's for use with any text-based format. In fact, our company's typical usage involves references that cross between text files of different formats: e.g., LaTeX <--> Markdown, Org <--> DocBook Lite XML, etc. Now, "[[ref:1c3a90a9]]" contains "[ref:1c3a90a9]" of course, so in an Org Mode file one could format oref origin links as regular Org Mode links without descriptions. But personally I find that I'm never doing that -- I just put "[ref:1c3a90a9]". On a related note, how are the references exported? There is no provision for exporting. That's an Org Mode concept, but not an oref.el concept. Best regards, -Karl
Re: [PATCH] Fix warning about using `eq' to compare strings.
On 01 Nov 2023, Ihor Radchenko wrote: Bastien writes: Karl Fogel writes: Hi, everyone. Small fix attached -- it just makes a warning go away. Applied against the main branch, thanks! Unfortunately, fixing this warning breaks org-table logic and tests. See previous discussion in https://list.orgmode.org/orgmode/20230827214320.46754-1-salu...@me.com/ Oh my goodness. That is... sigh. Wow. This is now beyond the "trivial fix" level of effort that I was prepared to invest to make this warning go away. Like Rudolf Adamkovič and others before him, I now retire to my country estate, to simultaneously lick my wounds and rest on my laurels (which I guess is better than licking my laurels and resting on my wounds). Thank you for noticing, and for adding the FIXME later. Best regards, -Karl
Re: [FR] A more general case than footnotes
Ihor Radchenko writes: Maske writes: I propose links to arbitrary points in different files. Furthermore, I think it would be a very nice new feature, probably more opinions than mine should be heard. See: - https://list.orgmode.org/orgmode/118435e8-0b20-46fd-af6a-88de8e19f...@app.fastmail.com/ - https://list.orgmode.org/orgmode/cajniy+ovd0ncwzztpit5t7wvsblbgllxzmpub5tgq3gshsg...@mail.gmail.com/ - https://list.orgmode.org/orgmode/CAJcAo8s=cjNY-7-mA1zQk3R9HEWYreTatdVeHfJ39ccM9=k...@mail.gmail.com/ The idea is not new, but we need someone to implement it one way or another. At my company, I implemented something that (I think) does what Maske and those earlier threads are getting at: https://code.librehq.com/ots/ots-tools/-/blob/main/emacs-tools/oref.el We often use it with Org Mode files, but it's not specific to Org Mode -- it works with any plaintext format. In fact, our most common use case is cross-referencing from precise locations in LaTeX files to precise locations in Org Mode files. A couple of days ago I happened to post [1] on the Emacs Humanities list about a updated version of oref.el. Maske noticed that post, and referred me to this thread here. My original announcement post from a year ago [2] is a good place to get a quick overview of how oref.el works. At the time I wrote oref.el, I didn't know about org-id.el. But it wouldn't be too hard to make oref.el automagically compatible with Org ":ID:" properties. I.e., `oref-do-ref' would jump to them, copy them, etc, in just the same way it currently does with native oref references. And the oref ref files cache would just become the union of `oref-ref-files-cache' and `org-id-files'. While I'll hand-wave a bit on the details right now, I think there is a natural compatibility available. If people are interested in this extension of oref.el, let me know. Best regards, -Karl [1] https://lists.gnu.org/archive/html/emacs-humanities/2023-10/msg1.html [2] https://lists.gnu.org/archive/html/emacs-humanities/2022-10/msg9.html
[PATCH] Fix warning about using `eq' to compare strings.
Hi, everyone. Small fix attached -- it just makes a warning go away. Best regards, -Karl >From a1a939191af1a195f260037510d407e7483ba05f Mon Sep 17 00:00:00 2001 From: Karl Fogel Date: Mon, 30 Oct 2023 10:33:29 -0500 Subject: [PATCH] lisp/org-table.el: fix warning about `eq' usage * lisp/org-table.el (org-table-make-reference): Use `equal' instead of `eq' to compare strings. This change makes the following warning go away: Warning (comp): org-table.el:2867:23: \ Warning: `eq' called with literal string that may never match (arg 2) This change does not affect the behavior of `org-table-make-reference' because `eq' treats all instances of the empty string as the same object anyway, e.g., `(eq (string-trim "aaabbb" "a+" "b+") "")' ==> t. The only effect of this change is to eliminate the warning. --- lisp/org-table.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org-table.el b/lisp/org-table.el index f5a433c7d..860d7720d 100644 --- a/lisp/org-table.el +++ b/lisp/org-table.el @@ -2864,7 +2864,7 @@ list, `literal' is for the format specifier L." (if lispp (if (eq lispp 'literal) elements - (if (and (eq elements "") (not keep-empty)) + (if (and (equal elements "") (not keep-empty)) "" (prin1-to-string (if numbers (string-to-number elements) elements -- 2.42.0
Re: Worg: issue with org-tools page
Hi Ihor, * Ihor Radchenko wrote: > Karl Voit writes: > >> Okay, that was also my idea when I saw the log file. Can somebody >> fix ESS here or should we convert the R blocks to a different block >> type (EXAMPLE)? > > I believe that I fixed the issue in > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4929f0c55f > > But I am not sure if I actually did. We need to trigger WORG rebuild to > see, I think. I just committed a minimal change to that file which caused the CI to re-build the page: https://builds.sr.ht/~bzg/job/975519 which ended successfully but still shows an error: [...] [exporting] org-tests/index.org [exporting] org-tools/index.org Executing R code block at position 5304... Cannot open load file: No such file or directory, ess-r-mode [exporting] org-tutorials/org-R/org-R.org [...] https://orgmode.org/worg/org-tools/ doesn't show the current content from the Orgdown file. The issue still persists. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: org-crypt fails if default key is expired while non-default key is to be used
* Ihor Radchenko wrote: > Karl Voit writes: > >>> Ok. What about >>> >>> (let ((context (epg-make-context nil t t))) >>> (epg-decrypt-string context (epg-encrypt-string context "test" >>> (epg-list-keys context org-crypt-key >>> >> >> It asks me for the passphrase of the orgmode key (the correct one) >> and prints out "test". > > We just followed what org-crypt does... And you see no error. > I have no more ideas how to investigate the original failure without a > reproducer. Fully understand. If it was an issue that was caused just by me, the better. Thanks for investing into that issue or non-issue anyway! -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Worg: issue with org-tools page
* Ihor Radchenko wrote: > Karl Voit writes: > >> CI example: https://builds.sr.ht/~bzg/job/970651 lists all sorts of >> HTML pages but for org-tools, there is no HTML output generated as >> it seems. Whatever I write in org-tools/index.org doesn't get to the >> HTML version of it. >> >> Maybe somebody has an idea what's going on here? > > AFAIU, there is some problem installing "elpa-ess" Debian package. For > some reason, Emacs cannot find 'ess, which leads to export failures. > > [exporting] org-contrib/babel/examples/Rpackage.org > Executing R code block at position 5615... > Cannot open load file: No such file or directory, ess Okay, that was also my idea when I saw the log file. Can somebody fix ESS here or should we convert the R blocks to a different block type (EXAMPLE)? -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Worg: issue with org-tools page
Hi, After fixing my WORG setup and being able to push again, I found out that https://orgmode.org/worg/org-tools/ isn't updated by the CI job. https://git.sr.ht/~bzg/worg/tree/master/item/org-tools/index.org shows the latest changes, https://orgmode.org/worg/org-tools/ doesn't. CI example: https://builds.sr.ht/~bzg/job/970651 lists all sorts of HTML pages but for org-tools, there is no HTML output generated as it seems. Whatever I write in org-tools/index.org doesn't get to the HTML version of it. Maybe somebody has an idea what's going on here? -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: PROPOSAL: Bind `org-fold-hide-subtree' by default in Org Mode.
On 25 Feb 2023, Max Nikulin wrote: On 25/02/2023 07:13, Karl Fogel wrote: Okay, today I did some research and found that every "C-c C-" binding is used in Org Mode except for "C-c C-g". While that one is technically reserved for the mode's use No, there is an explicit exception for C-g, see (info "(elisp) Key Binding Conventions") in "Tips and Conventions" appendix. https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html Ah, thanks for pointing that out. Even C-c C-x prefix is quite busy. Other modifiers might be a rescue: C-c M-something. However perhaps M-x with fuzzy completion allowing typos (and ideally synonyms) might be a better solution. Well, sure -- we get that for free. I think we can consider this proposal over. While I find `org-fold-hide-subtree' very useful, the Org Mode default keyspace is very busy already, and we don't hear anyone proposing to drop something else in favor of `org-fold-hide-subtree'. Anyone can custom-bind it themselves, of course (which is what I'll continue doing). No, [Ctrl+Tab] and [Ctrl+Shift+Tab] is widely used in other applications to switch to next/previous tabs. I would strongly prefer to keep it consistent across as much applications as possible. (There are corner cases like e.g. vim with multiple tabs running in a terminal application having several tabs as well. E.g. gnome terminal is able to pass [Ctrl+PgDn], a [Ctrl+Tab] alternative, while it has single tab, but intercepts the same shortcut when more terminal tabs are opened, so vim keys have to be used.) Agreed. Best regards, -Karl
Re: PROPOSAL: Bind `org-fold-hide-subtree' by default in Org Mode.
Okay, today I did some research and found that every "C-c C-" binding is used in Org Mode except for "C-c C-g". While that one is technically reserved for the mode's use, I suspect the reason it's unbound is that people are accustomed to using C-g as a quit command (and they get that effect if they accidentally type C-c, because then they type C-g and it's just an undefined key -- i.e., it quits, which is what the user wanted). Note that while "C-c C-h" does not appear to be bound, it actually is: it gets you a help buffer about the Org Mode keybindings (which then, ironically, does not list "C-c C-h" as one of the bindings). (It's not clear to me whether Emacs's conventions consider "C-c C-i" to be a letter or whether they treat "C-i" as "TAB" and consider it special; based on the previous evidence in this thread, maybe the latter, so we shouldn't consider "C-c C-i" to be available.) I think what this is telling me is that Org Mode keybinding real estate is quite valuable :-), and that unless there are other people who feel as strongly as I do that `org-fold-hide-subtree' is amazingly useful, we probably won't decide to bind it by default in Org Mode. So I should just continue to bind it to a custom key myself and continue to live a glorious life all alone in my private keymap splendour. Best regards, -Karl I wrote: On 23 Feb 2023, Max Nikulin wrote: On 23/02/2023 00:01, Karl Fogel wrote: =C2=A0(when (not (keymap-lookup nil "C-")) =C2=A0=C2=A0 (keymap-local-set "C-" 'org-fold-hide-subtree)) So FWIW C- is not bound in Org Mode buffers for me, in=20 Emacs 30.x (i.e., recent development builds). lisp/tab-bar.el:130: (unless (global-key-binding [(control=20 tab)]) lisp/tab-bar.el:131:(global-set-key [(control tab)]=20 #'tab-next)) Minibuffer file cache completion should not be relevant to Org=20 buffers. Ah, I don't use tab-bar at all (at least not as far as I know), so=20 I'm not 100% sure what the above is saying. Are you saying that the only current default binding for C-=20 in Emacs is that one in tab-bar.el, and therefore we should feel=20 free to rebind it in Org Mode? If so, we should still be=20 cautious, since Emacs has policies for maintaining the keybinding=20 space. Generally, the space "C-c C-" is reserved for=20 major modes, so ideally we should find something in there if we=20 can -- although Org Mode has used up a lot of that space already=20 :-), so I'm not sure what's left, unless we decide to swap out=20 some existing binding in favor of this one. (I realize this contradicts what I said in my inital post. I had=20 forgotten that C- was not part of the mode-reserved space.)
Re: PROPOSAL: Bind `org-fold-hide-subtree' by default in Org Mode.
On 23 Feb 2023, Max Nikulin wrote: On 23/02/2023 00:01, Karl Fogel wrote: (when (not (keymap-lookup nil "C-")) (keymap-local-set "C-" 'org-fold-hide-subtree)) So FWIW C- is not bound in Org Mode buffers for me, in Emacs 30.x (i.e., recent development builds). lisp/tab-bar.el:130: (unless (global-key-binding [(control tab)]) lisp/tab-bar.el:131:(global-set-key [(control tab)] #'tab-next)) Minibuffer file cache completion should not be relevant to Org buffers. Ah, I don't use tab-bar at all (at least not as far as I know), so I'm not 100% sure what the above is saying. Are you saying that the only current default binding for C- in Emacs is that one in tab-bar.el, and therefore we should feel free to rebind it in Org Mode? If so, we should still be cautious, since Emacs has policies for maintaining the keybinding space. Generally, the space "C-c C-" is reserved for major modes, so ideally we should find something in there if we can -- although Org Mode has used up a lot of that space already :-), so I'm not sure what's left, unless we decide to swap out some existing binding in favor of this one. (I realize this contradicts what I said in my inital post. I had forgotten that C- was not part of the mode-reserved space.) Best regards, -Karl
Re: PROPOSAL: Bind `org-fold-hide-subtree' by default in Org Mode.
On 22 Feb 2023, Max Nikulin wrote: On 22/02/2023 14:29, Karl Fogel wrote: I put it on "C-" because that's normally unbound in Org Mode, and because so many of the Org Mode cycling commands involve modified tab already. Perhaps C- is not the best choice: 9092c289b6bea38bb519e6c59a60237ae5af8f08 author Bastien Mon Jun 1 14:39:28 2020 +0200 Bind `org-force-cycle-archived' to C-c C-TAB * lisp/org-keys.el (org-mode-map): Bind `org-force-cycle-archived' to C-c C-TAB instead of C-TAB to avoid conflict with native Emacs keybinding. Ah, clearly it is not a good choice -- thank you for noticing that. I think there are two separate questions here: 1) Would it be useful to bind `org-fold-hide-subtree' by default? 2) If yes to (1), then is there a good key to bind it to? (C-c C-something, I guess.) If we agree on (1), then let's figure out the answer to (2). I don't know if anyone else agrees about (1) yet, though. By the way, the binding in my Org Mode hook looks like this: (when (not (keymap-lookup nil "C-")) (keymap-local-set "C-" 'org-fold-hide-subtree)) So FWIW C- is not bound in Org Mode buffers for me, in Emacs 30.x (i.e., recent development builds). However, I agree with Bastien's logic: C- is not in the reserved keymap space, so Emacs might bind it (and perhaps does bind it in other modes). I don't know how widely-used `org-cycle-force-archived' is (that's the new name of that function). I don't use it, personally, so if we decide against (1)+(2) above, then perhaps I'll just override that binding for myself instead. Best regards, -Karl
PROPOSAL: Bind `org-fold-hide-subtree' by default in Org Mode.
Hey everyone, is there a reason we don't bind `org-fold-hide-subtree' by default in Org Mode? I bind it to C- and now find this to be one of the most useful keybindings in Org Mode. I suspect my workflow is pretty typical. The use case is simple: When reading material within a certain heading level, one often decides that one is done with that section (and therefore done with everything inside it -- including anything at deeper levels of nesting). So one just folds the entire subtree around point and moves on, without changing the visibility of any of the sibling-or-higher subtrees around it (because often the next place one is going is one of them). This is one of my most frequent actions in Org Mode. In fact, I think it might be the most common Org Mode command I run. It seems like an obvious thing have bound to a key, and yet Org Mode doesn't bind it by default. Should we? (I put it on "C-" because that's normally unbound in Org Mode, and because so many of the Org Mode cycling commands involve modified tab already. But I don't feel strongly about the particular key, as long as it's fast to type; maybe there's a better key available.) I looked for prior discussion about this in the archives and didn't find anything: https://list.orgmode.org/?q=org-fold-hide-subtree Best regards, -Karl
Re: org-crypt fails if default key is expired while non-default key is to be used
Hi Ihor, * Ihor Radchenko wrote: > Karl Voit writes: > >>> What is the return value of >>> >>> (epg-list-keys (epg-make-context nil t t) org-crypt-key) >>> >>> ? >>> >>> Does it show the right key? >> >> It shows: >> >> (#s(epg-key ultimate >> (#s(epg-sub-key ultimate ... nil 1 4096 "ABC12345" 1515327255 >> nil "...ABC12345") >>#s(epg-sub-key ultimate ... nil 1 4096 "FFF" 1515327255 >> nil ".")) >> (#s(epg-user-id ultimate "Karl Voit (Internal key for orgmode) >> " nil >> >> ... with ABC12345 being the correct key for org-crypt and FFF being my >> default OpenPGP key. > > Ok. What about > > (let ((context (epg-make-context nil t t))) > (epg-decrypt-string context (epg-encrypt-string context "test" > (epg-list-keys context org-crypt-key > It asks me for the passphrase of the orgmode key (the correct one) and prints out "test". -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: org-crypt fails if default key is expired while non-default key is to be used
Hi Ihor, * Ihor Radchenko wrote: > Karl Voit writes: > >>> May I know how exactly did you set `org-crypt-key'? Do you happen to >>> have CRYPTKEY properties somewhere in your buffer? >> >> Sure. My config is on >> https://github.com/novoid/dot-emacs/blob/master/config.org and I've >> set it with: >> >> (setq org-crypt-key "ABC12345") ;; I may have to mask this online as well >> ;-) > > What is the return value of > > (epg-list-keys (epg-make-context nil t t) org-crypt-key) > > ? > > Does it show the right key? It shows: (#s(epg-key ultimate (#s(epg-sub-key ultimate ... nil 1 4096 "ABC12345" 1515327255 nil "...ABC12345") #s(epg-sub-key ultimate ... nil 1 4096 "FFF" 1515327255 nil ".")) (#s(epg-user-id ultimate "Karl Voit (Internal key for orgmode) " nil ... with ABC12345 being the correct key for org-crypt and FFF being my default OpenPGP key. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: org-crypt fails if default key is expired while non-default key is to be used
Hi Ihor, * Ihor Radchenko wrote: > Karl Voit writes: > >> When I invoked org-decrypt-entry, decrypting works like always. Then >> I modified something in this heading which is tagged with :crypt:. >> On saving that buffer, org-crypt issues an error message: >> >> | Error: (error "GPG error: \"Encrypt failed\", \"Unusable public key: >> | A1234567; Exit\"") >> >> This A1234567 key is my default key and not the org-openpgp-key. >> >> org-encrypt-entry is causing this error at: >> >> |;; Text and key have to be identical, otherwise we >> |;; re-crypt. >> |(if (and (equal crypt-key key) >> | (string= checksum (sha1 contents))) >> |(get-text-property 0 'org-crypt-text contents) >> | (epg-encrypt-string epg-context contents crypt-key))) >> >> After fixing the expiry date of A1234567, org-crypt was working >> properly, using the correct org-openpgp-key again. >> >> I do think this is wrong behavior: when the default key is expired >> but a specific secondary key is used, encryption should be possible. > > All we do here is calling `epg-encrypt-string' with crypt key obtained > using `org-crypt-key-for-heading', which see. > > May I know how exactly did you set `org-crypt-key'? Do you happen to > have CRYPTKEY properties somewhere in your buffer? Sure. My config is on https://github.com/novoid/dot-emacs/blob/master/config.org and I've set it with: (setq org-crypt-key "ABC12345") ;; I may have to mask this online as well ;-) : grep -i CRYPTKEY * ... is empty when applied to my Org-mode files. The only thing to fix my situation was to re-import a non-expired version of my default OpenPGP sec key. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
org-crypt fails if default key is expired while non-default key is to be used
Hi, I think I've found a bug with org-crypt: Org mode version 9.5.5 (release_9.5.5 @ /home/vk/src/external_compilations/emacs/lisp/org/) GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.16.0) of 2023-01-09 SUMMARY: org-crypt fails to encrypt when org-encrypt-entry is set to a different key than the default openpgp key and the default key is expired. BACKGROUND: My setup involves an openpgp-key which is specifically used for org-crypt. This key is not my default key A1234567 which I'm using for encrypting and singing emails and such. org-crypt-key is set to this secondary key, let's call it org-openpgp-key. So the org-crypt setup is correct in that sense that org-mode should not care about other keys than my org-openpgp-key. However, I've had the situation where the default openpgp key expired on a machine. Please note that my org-openpgp-key did not expire. When I invoked org-decrypt-entry, decrypting works like always. Then I modified something in this heading which is tagged with :crypt:. On saving that buffer, org-crypt issues an error message: | Error: (error "GPG error: \"Encrypt failed\", \"Unusable public key: | A1234567; Exit\"") This A1234567 key is my default key and not the org-openpgp-key. org-encrypt-entry is causing this error at: | ;; Text and key have to be identical, otherwise we | ;; re-crypt. | (if (and (equal crypt-key key) |(string= checksum (sha1 contents))) | (get-text-property 0 'org-crypt-text contents) | (epg-encrypt-string epg-context contents crypt-key))) After fixing the expiry date of A1234567, org-crypt was working properly, using the correct org-openpgp-key again. I do think this is wrong behavior: when the default key is expired but a specific secondary key is used, encryption should be possible. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Org-mode syntax as a tool-independent MIME type
Hi Bastien, * Bastien wrote: > Hi Karl and Timothy, > > thank you Karl for reviving this important topic. > > I think our collective priority should be to work on > https://orgmode.org/worg/dev/org-synxtax.html so that it reflects the > current Org syntax. Hopefully we can do this before Org 9.6. As > discussed with TEC, we can factor out suggestions from this document > so that it is not a mix of facts and hypotheses. A valid approach. I think we do have two different approaches ongoing here. With OD1 I tried to come up with a minimal set of Org-mode syntax elements that are very easy to implement in non-Emacs tools in order to get an easy intro to this universe. This is a bottom-up approach. Defining the whole Org-mode syntax as you've suggested is a complete definition of Orgdown (or OD∞ as of https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Orgdown-Levels.org ) which is a top-down approach. So far, I don´t see a conflict here. This may arise with OD2, OD3, ... definitions if they will ever exist. > Then we can work on suggestions for evolutions of the current Org-mode > syntax chunk by chunk, as a long-term goal for stabilizing changes for > Org 10 (2023 ?) Sounds great! > What occurred to me while rereading this thread is that definining a > syntax for a IETF RFC on an Org mimetype probably needs to be done not > just by this Emacs Org-mode community, but by bringing together other > "consumers" of .org files, from ecosystems outside of Emacs. > > Such a collective work could lead to define what subset of the Org > syntax is useful as the corner-stone for .org files everywhere - which > is what you rightfully brought up with "Orgdown". I tried to collect projects on https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Tool-Support.org > If successful, such a process could end up in defining the minimal and > official "Org syntax" while allowing implementations (like the one for > Emacs org-mode) to supercharge this syntax if deemed useful. To me, this sound aligned with the idea of OD levels OD1 and OD∞. > Perhaps TEC is right and we will end up having the minimal syntax > being the one we currently use for Org-mode: we'll see. > > But we need volunteers: one to work on worg/dev/org-synxtax.org (I'm > assuming TEC can lead the work here) and one to set up a discussion > with people implementing Org in various places (you ?). What kind of discussion is on your mind? At the moment, I tend to think that the Org-mode community should provide directions by developing a formal definition of the syntax and maybe later-on define viable sub-sets (the OD levels?) so that tool developers don't have to implement the whole large thing. At this stage, I don't know what discussions you're trying to start here. Can you elaborate? > I suggest to take this sequentially and not tackle the second work > before we're done with the first one. I interpret this as "discussions with tool developers after working on the formal Org definition". This would be my understanding and also my thought. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Org-mode syntax as a tool-independent MIME type
Hi Timothy, * Timothy wrote: > --=-=-= > Content-Type: text/plain; charset=utf-8 > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable Off topic: Something's quite off here with the encoding at least at my side (using slrn). I might be related to my setup, can't tell at the moment. > Hi Karl, > >> For reasons explained in my Orgdown-related articles[1] I would >> propose to use this chance to introduce a different term for the >> Org-mode lightweight markup language in contrast to the Org-mode >> Elisp implementation in order to push the syntax in a tool-agnostic >> way. > > Personally, I don=E2=80=99t see the need for a split. If anything, it seems= > harmful to > me. In my personal experience, people often seem to mix both things in discussions, causing unnecessary loops and conflicts. To me, a different name is very important. From the response related to OD, I might be in a minority here. If you want to push the format, you'd have to use "Org-mode syntax" or "Org-mode syntax file" or similar. People who are aware of the difference to the implementation mostly do not use words that differ here. So in my opinion, a slightly different term would help. It's not a dramatic difference, it's more subtle for most people. > What I=E2=80=99ve taken to doing is referring to org-mode files outside= > Emacs simply > as Org files, and I think this works well for a number of reasons, not leas= > t because: > =E2=81=83 It creates a 1-1 corespondency with the file extension, think abo= > ut how > markdown is often referred to as =E2=80=9CMD=E2=80=9D due to the .md file= > extension. > =E2=81=83 I also see other people naturally talking about =E2=80=9COrg file= > s=E2=80=9D online, so this is > partway to being a de-facto convention You're right. I do think that this is mostly because of lack of an alternative. > =E2=81=83 I think it=E2=80=99s less confusing having =E2=80=9COrg=E2=80=9D = > be related with =E2=80=9Corg-mode=E2=80=9D than > =E2=80=9COrgDown=E2=80=9D (or similar), and should people familiar with o= > ne come across > mention of the other it should thus reduce the chance of confusion. > > What I do see the need for is the development of more resources on the form= > at > itself (like the org-syntax document). Done right this should be a boon to = > both > org-mode and Org outside Emacs. Absolutely. >> I proposed the term Orgdown for the Org-mode syntax and also >> proposed various levels in order to provide sub-sets of Org-mode >> syntax[3] that are realistic to implement with finite effort. Using >> those OD-levels to come up with a formal definition (EBNF?) might >> play perfectly well with different parameters of the MIME type[4]. >> >> In my opinion, this would be a huge step forward for the whole >> ecosystem that supports the same Org-mode syntax. >> >> If we do not keep the MIME type independent from the GNU Emacs >> Org-mode implementation, the overall use would be much smaller in >> the long run. > > I find myself holding a contrary position, that we should keep the notion o= > f an > =E2=80=9COrg=E2=80=9D format under the org-mode project to keep everything = > under one umbrella, > as it were. I don´t think that this is a contrary position. OD is supposed to be a 100% sub-set of Org-mode syntax as implemented in Elisp. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Org-mode syntax as a tool-independent MIME type (was: Shower thought: submit an IETF RFC to register Org as a MIME type)
Hi, * TEC wrote: > > I'm still hoping for that discussion :P > > To the Org community, if you have thoughts on this - please share them > :) For reasons explained in my Orgdown-related articles[1] I would propose to use this chance to introduce a different term for the Org-mode lightweight markup language in contrast to the Org-mode Elisp implementation in order to push the syntax in a tool-agnostic way. We should not think only of GNU Emacs because there is a rising number of tools that do support text files in Org-mode syntax[2] which is also a huge advantage for users of GNU Emacs: collaboration, public awareness of the syntax, more tool support, ... I proposed the term Orgdown for the Org-mode syntax and also proposed various levels in order to provide sub-sets of Org-mode syntax[3] that are realistic to implement with finite effort. Using those OD-levels to come up with a formal definition (EBNF?) might play perfectly well with different parameters of the MIME type[4]. In my opinion, this would be a huge step forward for the whole ecosystem that supports the same Org-mode syntax. If we do not keep the MIME type independent from the GNU Emacs Org-mode implementation, the overall use would be much smaller in the long run. Let's use that to establish a broad base for this great lightweight markup language syntax! [1] https://karl-voit.at/2021/11/27/orgdown/ https://emacsconf.org/2021/talks/org-outside/ https://gitlab.com/publicvoit/orgdown https://karl-voit.at/2021/12/02/Orgdown-feedback/ [2] https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Tool-Support.org [3] https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Orgdown-Levels.org [4] https://gitlab.com/publicvoit/orgdown/-/issues/8 -- Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Hi, * Christophe Schockaert wrote: > As for me, I am interested in having a way to manage cancels. > > I have always managed it with workarounds up to now, so it would be nice > to have a clean way for it. "Clean" depends on the definition. To me, a general convention with the statement that it does not have any tool-implication (progress indicators, ...) would also be cool. Maybe there will be an elisp function to toggle cancelled/non-cancelled list items instead of everybody is doing this in his/her own setup. > However, this is low priority to me regarding the effort to provide. > Also, since the suggestion from Daniel, I can consider it as a viable > option for my use case, to keep lists simple and use the strikethrough > would improve my readability. I agree. > This would allow several behaviors for counting the checkboxes as we > please : > > * TODO [2/2] Several checkboxes > > - [X] This one is done > - [X] +This once is cancelled as done+ > - +[ ] This one is forgotten completely+ And: - +[ ]+ This is cancelled ... which does not require or impose multi-line formatting to mark it as cancelled. > (my wish would be to have a robust way to handle multilines formating, > but that’s on another topic going on ^^) Yes, but probably not that easy. > I don’t know what’s the usual process : can’t we file an issue to track > it, and write down the options we have, then decide the outcome of it > (either development, or documenting options and ideas) ? Documenting a convention is good enough to me. At least people don't get too creative with different conventions by themselves which adds complexity when Orgdown files are shared among different people. I'm still dreaming of fool-proof real-world and real-time collaboration on Orgdown files using GNU Emacs and probably other tools as well. > Regarding the checkbox state, I wanted to have the impression of > maintainers, but I felt that choosing the character would not be easy to > handle not only for development, but even for reading documents from > different sources (custom TODO states have a meaning that we can infer, > but a single letter seems harder). > > As an after thought, about the "[C]" proposal, I wonder if it would not > be better to have a symbol, as "[X]" is not used for the letter, but for > the cross, same for the "space" and the "dash" which express "halfway > through". I didn’t have any idea the other day, but meanwhile, I have > come first with "[~]" which sounds like a wave and thus is not firm, and > is also a bitwise NOT in some programming languages. It could be easily mixed up with [-] - depending on font size, font style, and such. > Or, thinking about the "NOT", I thought about "[!]" which is a NOT > (not done) and also quite expressive. The only thing is that it is > quite catching attention, like if we need to pay attention for > something that was probably not that important since we cancelled > it :) I could not find many other options, as I feel we need to > stick to ASCII for a solution. An exclamation mark imposes importance from my point of view. > WDYT ? > Christophe HTH -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Hi Christophe, * Christophe Schockaert wrote: > > In a sense I can feel it’s useful to have an explicit cancel while > working. > But I don’t know how to handle it (see below). > I don’t think [/] would be a good candidate anyway, it’s used as a > statistic cookie, so it already has a meaning and would be confusing, > also it gets evaluated even in the body entry. > > Actually, I almost always use statistic cookies when using checkboxes, > and so how would we count the cancelled checkbox ? That was a huge mistake by me. I obviously did not think before choosing one of the few characters in between those brackets that are a clear no-go as you have mentioned above. Sorry. > As I didn’t imagine to alter the syntax as used it as it : > > - either, I add a note (usually dated) explicitly stating it’s > cancelled, and I check the box A viable workaround, yes. > - or, I force the closing of the whole entry with the C-u sequence, and > so it’s clear that some were cancelled or at least not fulfilled (which > in sort means that its follow up has been cancelled), as it writes [2/3] > in the heading for example. As the checkboxes don’t appear in the > agenda, it does not bother me so much to leave them uncompleted. Yes, also a workaround. I never used the C-u sequence for overriding that blocking feature so far. > * DONE [2/3] Some tasks to check >- [X] check 1 >- [ ] check 2 > - [2022-09-13] Cancelled. Won’t check this one >- [X] check 3 > > So, to me the main use case to have an explicit cancel, is when I have a > long list, and to remember that I stated it as "cancelled". > If we go that way, having no other nice idea at the moment, I quite like > the [C] which is explicit although language specific. ... if it is possible with the current implementation, we could introduce an official convention that any single (upper case?) character between the brackets is interpreted as a non-open checkbox. So any user is able to choose her character of choice even language-dependent. > However, this rises the question for the completeness : > > * TODO [1/3] Some tasks to check >- [X] check 1 >- [C] check 2 (or any other chosen token for [C]) >- [ ] check 3 > > Should we display [1/3] or [2/3] ? > Maybe we should align against the way it works for TODO/DONE/CANCELLED, > so it would be [2/3]... I'd say we should stick to that pattern, yes. > On the other hand, the "DONE [2/3]" above is quite visually explicit > that something was not fulfilled for the course of resolving the action. > > I hope this brought something useful for the thinking :) Oh yes, thank you! -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Hi Ihor, * Ihor Radchenko wrote: > Karl Voit writes: > >> I was using list checkboxes like that: >> - [ ] open task >> - [X] closed task >> - [-] cancelled task > > From the manual (5.6 Checkboxes): > > ‘C-c C-x C-b’ (‘org-toggle-checkbox’) > Toggle checkbox status or—with prefix argument—checkbox presence at > point. With double prefix argument, set it to ‘[-]’, which is > considered to be an intermediate state. > > [-] is not considered done by our conventions > >Here is an example of a checkbox list. > > * TODO Organize party [2/4] >- [-] call people [1/3] > - [ ] Peter > - [X] Sarah > - [ ] Sam >- [X] order food >- [ ] think about what music to play >- [X] talk to the neighbors Yes, that makes sense. [-] is not a candidate for a cancelled checkbox for that reason. :-( >> (setq org-enforce-todo-checkbox-dependencies t) >> ... any [-] checkbox will be regarded as non-finished contrary to >> the behavior of TODO/DONE/CANCELLED heading states. >> >> As a workaround, I may use: >> - +[ ]+ cancelled task > > As you can see, we already have conflicting convention, and we cannot > change it without breaking backwards compatibility. > > `org-block-todo-from-checkboxes', currently uses > > (org-list-search-forward >(concat (org-item-beginning-re) >"\\(?:\\[@\\(?:start:\\)?\\([0-9]+\\|[A-Za-z]\\)\\][ > \t]*\\)?" >"\\[[- ]\\]") >end t) > > as a condition that some list items are marked incomplete. > > So, you can use something like > - [C] cancelled task > > But beware that this is an internal implementation detail that might be > changed in future unless we decide to document the existing behaviour. In that case, I prefer not to depend on that internal detail and start using +[ ]+ as a workaround which causes the parser to not detect a checkbox at all, as far as I understood. Thanks for clarification. If we wanted to introduce a cancelled checkbox state, it seems to be the case that this would require a new approach like [/] or similar. Is it only me who is thinking that a non-blocking cancelled checkbox state would be a good idea? -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Suggested Syntax for cancelled checkboxes: [-] as non-blocking dependency
Hi, I was using list checkboxes like that: - [ ] open task - [X] closed task - [-] cancelled task The latter one is supported via C-u C-u C-c C-c. However, when I'm using: (setq org-enforce-todo-checkbox-dependencies t) ... any [-] checkbox will be regarded as non-finished contrary to the behavior of TODO/DONE/CANCELLED heading states. As a workaround, I may use: - +[ ]+ cancelled task ... but this is tedious. Therefore I'm asking if this might be a viable syntax change: handling [-] list items similar to CANCELLED headings as non-blocking when used with org-enforce-todo-checkbox-dependencies. Tested with Org mode version 9.5.3. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: How to export to markdown programmatically without the table of contents?
* Jeremie Juste wrote: > Hello Karl, Hi Jeremie, > On Tuesday, 3 May 2022 at 11:15, Karl Voit wrote: >> >> I tried this neat code snippet today with Emacs 26.3 and Org-mode >> 9.1.9 and I got an error: >> >> | org-export-barf-if-invalid-backend: Unknown "nil" back-end: Aborting export >> >> When I execute the following code, I get the same error: >> | (setq region "/foo/ *bar* https://example.com baz") >> | (org-export-string-as region 'md t '(:with-toc nil)) >> >> Could it be that I don't have "md" as backend somehow? Is there a >> hidden requirement? > > And I still work with (require 'ox-md). Unfortunately, I did not write down why I thought this is not necessary any more. However, with the require statement, the error is gone and the function works now. Thanks! -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Agenda without todos only if there is no other timestamp
Hi,
* TRS-80 wrote:
>
>> On 2022-04-05 04:48, Karl Voit wrote:
>>> Hi,
>>> I've got following custom agenda for exporting:
>>> | ("n" "no TODO events +180d"
>>> | ((agenda "no TODO events +180d"
>>> | ((org-agenda-span 180)
>>> |(org-agenda-time-grid nil)
>>> |(org-agenda-entry-types '(:timestamp :sexp))
>>> |(org-agenda-skip-function
>>> | '(or
>>> | (org-agenda-skip-entry-if 'todo 'any);; skip if any
>>> TODO state is found
>>> | (org-agenda-skip-entry-if 'category "errors");; skip
>>> if any TODO state is found
>>> | (my-skip-tag "lp")
>>> | )
>>> | nil (,(concat my-org-files-path "agenda_180d_filtered_raw.html")))
>>> (don't mind the stupid name - I may fix this as it is misleading
>>> here)
>>> This results in an HTML file that contains my appointments without
>>> the tasks.
>>> Unfortunately, I sometimes seem to schedule appointments within open
>>> todos such as:
>>> | * NEXT talk with Steve about the project X
>>> | SCHEDULED: <2022-04-05 Tue>
>>> |
>>> | - [X] ask him for a time-slot
>>> | - we settled for: <2022-04-05 Tue 14:00-15:00>
>>> Of course, those appointments are lost in my agenda export as
>>> specified above. This is a bummer and I want to fix this somehow.
>>> Tasks should be omitted only if there is no other time-stamp than
>>> deadline or scheduled.
>>> org-agenda-skip-if lists:
>>> | scheduled Check if there is a scheduled cookie
>>> | notscheduled Check if there is no scheduled cookie
>>> | deadline Check if there is a deadline
>>> | notdeadline Check if there is no deadline
>>> | timestamp Check if there is a timestamp (also deadline or
>>> scheduled)
>>> | nottimestamp Check if there is no timestamp (also deadline or
>>> scheduled)
>>> | regexpCheck if regexp matches
>>> | notregexp Check if regexp does not match.
>>> | todo Check if TODO keyword matches
>>> | nottodo Check if TODO keyword does not match
>>> How is it possible to accomplish this? I think this would require
>>> something like "Check if there is a timestamp (except deadline or
>>> scheduled)" which isn't available yet.
>>> Any ideas on that one?
>>
>> I think you will need to write a custom ~org-agenda-skip-function~.
>>
>
> I realized there is probably an even easier way (no custom ELisp
> required), simply by creating a separate child heading for the meeting,
> which should then show up.
Thanks for the idea. This is my current workaround. However, it
happens in longer headings that I insert a time/datestamp at the end
without realizing that I'm working in a todo heading. This is an
issue for me because I do have to check every time I'm using
timestamps. It's rather obvious that I fail from time to time and I
lose the entry on my non-todo-agenda.
--
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
> get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: How to export to markdown programmatically without the table of contents?
Hi, * Marcin Borkowski wrote: > > On 2022-05-01, at 22:01, Berry, Charles wrote: > >>> On May 1, 2022, at 2:20 AM, Marcin Borkowski wrote: >>> >>> I'd like to export a Org-mode formatted string to markdown, but without >>> the table of contents. >>> >>> (org-export-string-as my-string 'md t '(toc nil)) >> >> >> It does seem odd that BODY-ONLY as `t' gives a toc. With latex it does not >> regardless of `:with-toc'. >> : (org-export-string-as my-string 'md t '(:with-toc nil)) >> seems to give what you want. > > http://mbork.pl/2021-05-02_Org-mode_to_Markdown_via_the_clipboard I tried this neat code snippet today with Emacs 26.3 and Org-mode 9.1.9 and I got an error: | org-export-barf-if-invalid-backend: Unknown "nil" back-end: Aborting export When I execute the following code, I get the same error: | (setq region "/foo/ *bar* https://example.com baz") | (org-export-string-as region 'md t '(:with-toc nil)) Could it be that I don't have "md" as backend somehow? Is there a hidden requirement? Do I need something like "(require 'ox-md)"? I somehow noted that those export requirements are not necessary any more. Maybe this is wrong? Thanks! -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: [PATCH] CONTRIBUTE: Link WORG page when explaining commit message format
On 23 Apr 2022, Ihor Radchenko wrote: Applied. The patch is now on main as 67efaa739. Thanks, Ihor! Best regards, -Karl
Re: [PATCH] CONTRIBUTE: Link WORG page when explaining commit message format
On 15 Apr 2022, Robert Pluim wrote: On Fri, 15 Apr 2022 17:33:33 +0800, Ihor Radchenko said: Ihor> - Org mode no longer uses ChangeLog entries to document changes. Ihor> - Instead, special commit messages are used, as described in the Ihor> - `CONTRIBUTE' file in the main Emacs repository. Ihor> + Instead, special commit messages are used. The commit message Ihor> + format generally follows Emacs conventions, as described in the Ihor> + `CONTRIBUTE' file in the main Emacs repository. Several more Ihor> + Org-specific conventions are described in Ihor> + [[https://orgmode.org/worg/org-contribute.html#commit-messages][worg/org-contribute#commit-messages]]. It might be good to mention `magit-generate-changelog' there as an easy way to produce the ChangeLog format entry (it doesnʼt require you to iterate over the diff hunks, and you can call it from the magit commit buffer). I really like the patch, Ihor -- it's already a big improvement! (I haven't tested Robert's suggestion of `magit-generate-changelog', but it seems like a reasonable hint to include, given Magit's popularity.) Best regards, -Karl
Re: Removing obsolete function `org-truely-invisible-p'.
On 07 Apr 2022, Ihor Radchenko wrote: Karl Fogel writes: Unfortunately, the 'CONTRIBUTE' file at the top level of the Org Mode source tree gives incomplete guidance on commit messages (it just says to follow what Emacs does, so I did that). I didn't realize that https://orgmode.org/worg/org-contribute.html#commit-messages has further, slightly different guidance. Could you elaborate? We have the following in etc/CONTRIBUTE: * Main contribution rules ... See [[https://orgmode.org/worg/org-contribute.html][worg/org-contribute]] for guidance on how to contribute effectively. Sure, I'll elaborate. The "..." in your quoted text above contains, among other things, this item: - Org mode no longer uses ChangeLog entries to document changes. Instead, special commit messages are used, as described in the `CONTRIBUTE' file in the main Emacs repository. That item is just one in a list of several items in section 4 (which is under the top-level heading "Main contribution rules"). At the very end of the "Main contribution rules" top-level section comes this line: See [[https://orgmode.org/worg/org-contribute.html][worg/org-contribute]] for guidance on how to contribute effectively. So when I went searching in CONTRIBUTE specifically for guidance on commit messages, I searched for the string "commit message". That took me to the item I quote above, which states pretty clearly that the Emacs guidelines apply here. It does not state that there is any other source of guidance about commit messages, nor does it say anything to indicate that Org Mode has commit message guidelines that are a superset of (i.e., more complicated than) Emacs's guidelines. The string "commit message" does not appear anywhere else in Org Mode's CONTRIBUTE file. So, naturally, after I read that item, I assumed that I was ready to write the commit message, since I already knew Emacs's guidelines. Meanhwile, the https://orgmode.org/worg/org-contribute.html page is a bit long, and it starts out with a bunch of very generic guidance that is not useful to developer contributing a code patch. (I'm not saying that material isn't useful, by the way. I think it's good to have it there. I'm just saying it doesn't provide anything useful to one particular demographic. But it's still good because someone might be making some other kind of contribution.) In that page, the part about "Commit messages and ChangeLog entries" starts about three-quarters of the way down. Virtually none of the material preceding it had anything to do with my circumstances, and since I had just seen very clear guidance (in CONTRIBUTE) about how to write commit messages, I timed out before making it that far. A good solution to this would be to revise the item in CONTRIBUTE to make it clear that there is special Org Mode guidance on commit messages that goes beyond what Emacs itself wants. I was too tired to go through the process to contribute that change though, so instead I wrote this long email :-). Thanks! Merged as d80aa2776 to main. Thank you very much! Best regards, -Karl
Re: Removing obsolete function `org-truely-invisible-p'.
On 05 Apr 2022, Ihor Radchenko wrote: Sorry for not being clear. I was referring to the commit message - it is what you commonly see in git log. Having something like commit-hash Mark function obsolete & fix spelling of its name in git log is confusing because it is unclear what the commit is changing. If you look at https://git.savannah.gnu.org/cgit/emacs/org-mode.git/log/ then you can see that we generally follow certain style of the commit messages: changed-file-or-library: What is changed Also see https://orgmode.org/worg/org-contribute.html#commit-messages Oh, it was clear you were referring to the commit message -- what I now realize is that you were referring to the first line of the commit message (the summary line). Unfortunately, the 'CONTRIBUTE' file at the top level of the Org Mode source tree gives incomplete guidance on commit messages (it just says to follow what Emacs does, so I did that). I didn't realize that https://orgmode.org/worg/org-contribute.html#commit-messages has further, slightly different guidance. Thanks. I'm happy to adhere to the local standards, once I figure out what they are :-). I think we have a misunderstanding here. Unused functions are not necessarily obsolete. For example, we have org-list-to-texinfo, which is not used anywhere in the codebase, but could be useful for developers. org-compat.el contains functions that are planned for removal in future (and obsolete for the time being), obsolete function/variable names, and compatibility functions. As I mentioned in my previous email, I am slightly reluctant to remove org-truely-invisible-p. It means that it should remain available and no plans to remove it should be made (unless there are multiple devs/users who prefer removal). Hence, the function should stay in org-macs.el. org-macs.el is meant to store general-purpose functions that can be useful for development of the whole Org mode ecosystem. If we decide that org-truely-invisible-p stays in org-macs, we should fix the issue with its name. Renaming requires creating obsolete function name alias in org-compat.el to make sure that nothing gets broken unexpectedly for people who use org-truely-invisible-p with its current name. Hope I clarified my logic. You did! FYI, I do not know an easy way to search mailing list archives by Message-ID. Message-ID itself does not even provide information which mailing list it is referring to (maybe it is e.g. Emacs devel). That's why I prefer links - they can often be found using archive.org if nothing. On the other hand, extra information would not heart. In addition to link. Makes sense, yup. Actually, I usually include the link -- I just didn't think of it in this case because I rarely visit the Org Mode mailing list archives (unlike the Emacs Devel archives, which I often do visit, and therefore my commits in Emacs always include the link when referring to a mailing list post). A revised patch is attached. Now it's so simple that I think the commit message doesn't need to point to the mailing list discussion anyway. Review welcome. Best regards, -Karl >From 2cef1fdbe2b2aa40a2bb081eab4b2e2808000670 Mon Sep 17 00:00:00 2001 From: Karl Fogel Date: Thu, 31 Mar 2022 19:02:38 -0500 Subject: [PATCH] lisp/org-macs.el: Fix spelling of `org-truly-invisible-p' * lisp/org-macs.el (org-truly-invisible-p): Fix spelling of name. * lisp/org-compat.el (org-truely-invisible-p): Add compatibility alias for the old name. --- lisp/org-compat.el | 4 lisp/org-macs.el | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git lisp/org-compat.el lisp/org-compat.el index 38d330de6..00716ae13 100644 --- lisp/org-compat.el +++ lisp/org-compat.el @@ -752,6 +752,10 @@ context. See the individual commands for more information." (define-obsolete-function-alias 'org-get-last-sibling 'org-get-previous-sibling "9.4") +(define-obsolete-function-alias 'org-truely-invisible-p + 'org-truly-invisible-p "9.6" + "Compatibility alias for legacy misspelling of `org-truly-invisible-p'.") + Obsolete link types (eval-after-load 'ol diff --git lisp/org-macs.el lisp/org-macs.el index b39af9103..a09115e7c 100644 --- lisp/org-macs.el +++ lisp/org-macs.el @@ -1151,7 +1151,7 @@ fontification." (folding-only (memq value '(org-hide-block outline))) (t value -(defun org-truely-invisible-p () +(defun org-truly-invisible-p () "Check if point is at a character currently not visible. This version does not only check the character property, but also `visible-mode'." -- 2.35.1
Agenda without todos only if there is no other timestamp
Hi,
I've got following custom agenda for exporting:
| ("n" "no TODO events +180d"
| ((agenda "no TODO events +180d"
| ((org-agenda-span 180)
|(org-agenda-time-grid nil)
|(org-agenda-entry-types '(:timestamp :sexp))
|(org-agenda-skip-function
| '(or
| (org-agenda-skip-entry-if 'todo 'any);; skip if any TODO state
is found
| (org-agenda-skip-entry-if 'category "errors");; skip if any
TODO state is found
| (my-skip-tag "lp")
| )
| nil (,(concat my-org-files-path "agenda_180d_filtered_raw.html")))
(don't mind the stupid name - I may fix this as it is misleading
here)
This results in an HTML file that contains my appointments without the tasks.
Unfortunately, I sometimes seem to schedule appointments within open todos such
as:
| * NEXT talk with Steve about the project X
| SCHEDULED: <2022-04-05 Tue>
|
| - [X] ask him for a time-slot
| - we settled for: <2022-04-05 Tue 14:00-15:00>
Of course, those appointments are lost in my agenda export as
specified above. This is a bummer and I want to fix this somehow.
Tasks should be omitted only if there is no other time-stamp than
deadline or scheduled.
org-agenda-skip-if lists:
| scheduled Check if there is a scheduled cookie
| notscheduled Check if there is no scheduled cookie
| deadline Check if there is a deadline
| notdeadline Check if there is no deadline
| timestamp Check if there is a timestamp (also deadline or scheduled)
| nottimestamp Check if there is no timestamp (also deadline or scheduled)
| regexpCheck if regexp matches
| notregexp Check if regexp does not match.
| todo Check if TODO keyword matches
| nottodo Check if TODO keyword does not match
How is it possible to accomplish this? I think this would require
something like "Check if there is a timestamp (except deadline or
scheduled)" which isn't available yet.
Any ideas on that one?
--
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
> get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Removing obsolete function `org-truely-invisible-p'.
On 04 Apr 2022, Ihor Radchenko wrote: From bb229b4f8f78ae52962d7bc90c8b1d4993af8263 Mon Sep 17 00:00:00 2001 From: Karl Fogel Date: Thu, 31 Mar 2022 19:02:38 -0500 Subject: [PATCH] Mark function obsolete & fix spelling of its name This commit message is a bit confusing. I would mention the function name: "Mark `org-truely-invisible-p' obsolete and fix spelling of its name" * lisp/org-macs.el (org-truely-invisible-p): Move to... * lisp/org-compat.el (org-truly-invisible-p): ...here, and add... (org-truely-invisible-p): ...this compatibility alias. It does mention both names :-). But I'm happy to rewrite in the style you suggest above; I was just trying to follow the CONTRIBUTE guidelines. It is too much. We can either 1. Obsolete org-truely-invisible-p. Then, there is not much point renaming it. 2. Rename it without obsoletion. Then, there is not much point moving the function definition to org-compat. Hmm. From the prior conversation in this thread, I thought we'd decided to do both. There are two separate issues here: 1) The function is no longer used in Org Mode or Emacs. 2) Unrelatedly, the function's name has a misspelling. (1) suggests that the function should be moved to 'org-compat.el' (if I understand correctly what that file is for). (2) is usually fixed with a rename and a compatibility alias -- i.e., this is what we would do for any function, whether used or unused. In your message 87h7b5rm6f.fsf@localhost of 19 Dec 2021, you wrote: I feel slightly reluctant about removal. If nothing, this function can be a reminder about visible-mode and keeping it has little downside. Though if others think that removing would be better, I would also be fine with it. Renaming sounds reasonable. Just need to define obsolete alias for the old name in org-compat.el. My patch was based on the above, and on the fact that obsolete (i.e., unused) functions apparently get moved to org-compat.el, at least based on what I see already in that file. From: Ihor Radchenko Subject: Re: Removing obsolete function `org-truely-invisible-p'. To: Karl Fogel Cc: Org Mode Date: Sun, 19 Dec 2021 17:14:32 +0800 Message-ID: <87h7b5rm6f.fsf@localhost> I usually just leave an ML link in such cases: https://orgmode.org/list/87h7b5rm6f.fsf@localhost As long as the ML link contains the Message-ID, as appears to be the case here, yeah. Mailing list archives can move, which causes links to suddenly stop working. But if the Message-ID is in the link, then (with a little extra work) one can always find the message in the new archive. (The reason I typically include more is to make things as easy as possible for those who are searching in a local archive using their regular mailreader. But I can switch to the above way if you'd prefer.) Best regards, -Karl
Re: Removing obsolete function `org-truely-invisible-p'.
On 19 Dec 2021, Ihor Radchenko wrote:
Karl Fogel writes:
Should we just remove `org-truely-invisible-p'? Or at least
correct the spelling of its name ("truely" should be "truly")?
I feel slightly reluctant about removal. If nothing, this
function can
be a reminder about visible-mode and keeping it has little
downside.
Though if others think that removing would be better, I would
also be
fine with it.
Renaming sounds reasonable. Just need to define obsolete alias
for the
old name in org-compat.el.
Could you prepare a patch? Having a patch may encourage more
feedback.
Sure; please see attached.
Best regards,
-Karl
>From bb229b4f8f78ae52962d7bc90c8b1d4993af8263 Mon Sep 17 00:00:00 2001
From: Karl Fogel
Date: Thu, 31 Mar 2022 19:02:38 -0500
Subject: [PATCH] Mark function obsolete & fix spelling of its name
* lisp/org-macs.el (org-truely-invisible-p): Move to...
* lisp/org-compat.el (org-truly-invisible-p): ...here, and add...
(org-truely-invisible-p): ...this compatibility alias.
There are no callers of this function in Org Mode, nor in current
Emacs (on the 'master and 'emacs-28' branches at least). We discussed
whether to remove it entirely, and for now seem to have tentatively
decided not to remove it. See this thread for more details:
From: Ihor Radchenko
Subject: Re: Removing obsolete function `org-truely-invisible-p'.
To: Karl Fogel
Cc: Org Mode
Date: Sun, 19 Dec 2021 17:14:32 +0800
Message-ID: <87h7b5rm6f.fsf@localhost>
---
lisp/org-compat.el | 12
lisp/org-macs.el | 7 ---
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git lisp/org-compat.el lisp/org-compat.el
index 38d330de6..43d44211e 100644
--- lisp/org-compat.el
+++ lisp/org-compat.el
@@ -402,6 +402,18 @@ See `org-link-parameters' for documentation on the other
parameters."
(make-obsolete 'org-add-link-type "use `org-link-set-parameters' instead."
"9.0")
Functions unused in Org core.
+
+;; Not used since commit 3baf246f4f (Nicolas Goaziou, 2016-04-28)
+(defun org-truly-invisible-p ()
+ "Check if point is at a character currently not visible.
+This version does not only check the character property, but also
+`visible-mode'."
+ (unless (bound-and-true-p visible-mode)
+(org-invisible-p)))
+(define-obsolete-function-alias 'org-truely-invisible-p
+ 'org-truly-invisible-p "2022-03-31"
+ "Compatibility alias for legacy misspelling of `org-truly-invisible-p'.")
+
(defun org-table-recognize-table.el ()
"If there is a table.el table nearby, recognize it and move into it."
(when (org-at-table.el-p)
diff --git lisp/org-macs.el lisp/org-macs.el
index b39af9103..fb3c441e1 100644
--- lisp/org-macs.el
+++ lisp/org-macs.el
@@ -1151,13 +1151,6 @@ fontification."
(folding-only (memq value '(org-hide-block outline)))
(t value
-(defun org-truely-invisible-p ()
- "Check if point is at a character currently not visible.
-This version does not only check the character property, but also
-`visible-mode'."
- (unless (bound-and-true-p visible-mode)
-(org-invisible-p)))
-
(defun org-invisible-p2 ()
"Check if point is at a character currently not visible.
If the point is at EOL (and not at the beginning of a buffer too),
--
2.35.1
Re: [BUG] org-element--cache gives "Unregistered buffer modifications" warning [9.5 (9.5-g859984 @ /home/john/.emacs.d/straight/build/org/)]
Hi, * John Mathena wrote: > > First time sending mail to the list; please let me know if I commit any > breaches of etiquette or convention (e.g. on attaching backtraces as a file > vs sending in message body). You're doing fine. Thanks for handing in your issue and welcome to the list. I do get the same warning in a different situation so I just add my situation to this thread as well: Every time I execute =my-title-capitalization()= from https://github.com/novoid/dot-emacs/blob/master/config.org I get this: #+BEGIN_EXAMPLE Warning (emacs): Unrecognized key: _i_ Warning (emacs): org-element--cache: Unregistered buffer modifications detected. Resetting. If this warning appears regularly, please report it to Org mode mailing list (M-x org-submit-bug-report). The buffer is: README.org Current command: nil Backtrace: nil #+END_EXAMPLE Current versions: : Org mode version 9.5 (release_9.5-243-g048f47 @ mixed installation! /home/vk/.emacs.d/contrib/org-mode/lisp/ and /home/vk/.emacs.d/contrib/) : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14) of 2020-03-26, modified by Debian Any thoughts? -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
Hi, * Ihor Radchenko wrote: > > Now, we need to understand what kind of people may be looking to > orgmode.org website. > > 1. Existing emacs users > 2. Non-emacs users interested in plain text markup > 3. Non-emacs users interested in GTD/project management, etc >"Org mode: your life in plain text" is somewhat relevant when people >are looking to manage "life" (typically true for GTD enthusiasts). > 4. Researchers looking for ipython-like environment > 5. ??? (Suggestions are welcome) I don't think that you can come up with a good website that is able to serve all of them properly. For Orgdown I had in mind number 2 and 3. For supporting the idea for Orgdown, I thought of number 1. (Well, that turned out in a mixed way[1]). If you do want to have a go-to for people who should use the Org-mode syntax without the GNU/Emacs tool, you need to have a separate site. [1] https://karl-voit.at/2021/12/02/Orgdown-feedback -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Concrete suggestions to improve Org mode third-party integration :: an afterthought following Karl Voit's Orgdown proposal
Hi, * Ihor Radchenko wrote: > > The fact is that e.g. Github already provides support for Org markup. > They do it for their own profit and we cannot stop them. If we have a > controlled criteria about quality of third-party Org mode support, there > will be means to interfere with non-free software attempting to makes > profits out of Org mode. For example, if Github do not integrate our > recommended test suite (with all the legal consequences defined in > GPLv3), we will be able to have a list of third-party tools and, among > free alternatives, mention that Github support for Org is not verified > and most likely not consistent with other _free_ tools. We cannot do it > now. This is the main reason why I came up with the concept of Orgdown levels in the first place. Tools may choose their featureset independently and Orgdown assessments show the users the amount of features they can get. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Org Mode "Contribute", "Maintenance" pages don't give repository.
On 05 Dec 2021, Daniel Fleischer wrote: You're right; I'll think of a way to present the git repo link, i.e. the code earlier and more prominently for those who just want to jump and examine the code. +1, and thanks!
Re: Org Mode "Contribute", "Maintenance" pages don't give repository.
On 04 Dec 2021, Daniel Fleischer wrote:
The "Contribute" page at
https://orgmode.org/worg/org-contribute.html does not mention
git://git.sv.gnu.org/emacs/org-mode.git . Actually, now that I
look around, the "Maintenance" page at
https://orgmode.org/worg/org-maintenance.html doesn't mention
the repository address either. It does mention the word
"repository" a few times, but never actually links to it.
I've added a link to the org-maintenance page but there was a
link in
the org-contribute, in the "Your first commit as an Org
maintainer"
section. The git.sv.gnu.org is a shorthand for
git.savannah.gnu.org.
Thanks for reporting this,
Thanks, Daniel!
You're right about repository link on the Contribute page. It
might still be good to mention it earlier, like in the "Ways that
involve programming" section or even just in the first paragraph
of the page.
The reason I suggest this is that often when someone is hot on the
trail of debugging something, they haven't yet decided whether
they want to become a contributor or not. They just know they
want to ook at the latest sources so they can first figure out
more about whatever ${technical_thing} they encountered. So
making the latest sources very easy to find is a way of making it
more likely that someone becomes a contributor, by removing a
commonly-encountered barrier.
Best regards,
-Karl
Org Mode "Contribute", "Maintenance" pages don't give repository.
The "Contribute" page at https://orgmode.org/worg/org-contribute.html does not mention git://git.sv.gnu.org/emacs/org-mode.git . Actually, now that I look around, the "Maintenance" page at https://orgmode.org/worg/org-maintenance.html doesn't mention the repository address either. It does mention the word "repository" a few times, but never actually links to it. These oversights would be pretty easy to fix (if there is agreement that they shoud be fixed), so I haven't attached a patch here. It would be quick for someone who already maintains those pages to make the necessary changes. The only place I see the repository is at the top of the home page of https://orgmode.org/. That's nice and prominent :-), but developers would probably expect to find the address on those other two pages as well. Best regards, -Karl
Removing obsolete function `org-truely-invisible-p'.
The function `org-truely-invisible-p' is defined in
'lisp/org-macs.el', but it is not used anywhere anymore in Org
Mode, nor is it used anywhere in GNU Emacs (I checked on both
'emacs-28' branch and 'master' branch).
The last (and possibly only?) call to that function was removed
from `org-beginning-of-line' in this commit:
commit 3baf246f4f73005a4eacd7c368f7222f95d50243
Author: Nicolas Goaziou
AuthorDate: Thu Apr 28 23:28:15 2016 +0200
Commit: Nicolas Goaziou
CommitDate: Thu Apr 28 23:28:15 2016 +0200
Handle correctly `shift-select-mode'
* lisp/org.el (org-beginning-of-line): Handle correctly
`shift-select-mode'.
Reported-by: Mathieu Marques
<http://permalink.gmane.org/gmane.emacs.orgmode/106783>
Then, a few months later in commit 87116700e6e, Nicholas moved the
function to 'org-macs.el', where it has been sitting unused ever
since.
Should we just remove `org-truely-invisible-p'? Or at least
correct the spelling of its name ("truely" should be "truly")?
It seems fairly unlikely to me that people are using it in their
own code, although of course I cannot be sure of that. Partly, I
believe that because surely someone else would have noticed the
misspelling by now, if enough people were using it :-).
Best regards,
-Karl
Re: Orgdown: negative feedback & attempt of a root-cause analysis
Hi, I've summarized my current state of mind about the whole Orgdown fiasco into a blog article: https://karl-voit.at/2021/12/02/Orgdown-feedback/ Don't worry, I tried to analyze my own faults as well so that others might be able to learn from this unfortunate situation. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Orgdown: negative feedback & attempt of a root-cause analysis (was: "Orgdown", the new name for the syntax of Org-mode)
Hi, * M ‘quintus’ Gülker wrote: > > Am Montag, dem 29. November 2021 schrieb Karl Voit: >> It seems to be the case that the name "Orgdown" is the reason why >> the Org-mode community does not support the idea of an >> implementation-agnostic definition of the syntax. Which is ... kinda >> funny if you think about it. >> >> Well if the project is not working out, at least I made my point and >> we continue to have all those misunderstandings and lack of Orgdown >> support in 3rd party tools (because Org-mode is way too big). > > I think the project has value; better tooling outside of Emacs is > something org can only profit from in my opinion. One point that has not > been raised yet are scenarios of collaborative work; I would enjoy it > quite a bit if I could work on documents together with people who do not > like Emacs as an editor for whatever reason. Currently, org as a file > format is pretty much excluded if collaboration is intended with someone > who does not use Emacs. The natural choice in these cases is Markdown. I agree. One of the next things I do have on my list is to try out crdt as I've learned at EmacsConf21 that it is mature enough to be used in practice. If that holds true, we can start dreaming of having a Etherpad-like session from our GNU/Emacs while peers are connected to the same session via some web-based tool/service. > I agree that the name is kind of odd as it seems as if it is necessary > to invoke some association to Markdown. Other markup languages also do > not need that -- Textile, Asciidoc, etc. Perhaps it is best to simply > ignore the naming issue and focus on the actual work instead. It is far > more important to get the compatibility levels defined. After that you > can still reconsider the naming. The dominant feedback of https://www.reddit.com/r/emacs/comments/r4cq3o/orgdown_the_new_name_for_the_syntax_of_orgmode/ was negative comments on the name and nothing else. Even here, although due to a much more civilized style, the name choice was the dominant topic and not the idea. I have to take this as a strong signal here and I'm very close in giving up on Orgdown as a project. I did underestimate the power of the name choice as I clearly was impatient because I was looking forward to interesting discussions on the idea itself like in this sub-thread. There were two possible generic approaches for me: start from zero with an open process, involving peers in all choices such as naming, Orgdown1 syntax elements, ... While this approach offers maximum community involvement, my fear was to get into too many long discussions about details before I could express my vision to anybody in a concise way. Second approach: define everything myself up to Orgdown7 (as an example) and publish with a big bang. The downsides here are obvious. I chose an in-between approach: defining only a minimal set (name, common structure/idea/documentation, Orgdown1, providing a collaborative home on GitLab) and hope for a project community that will take over (or at least support) from there, discussing syntax elements for Orgdown2 and taking the project to its next logical steps. In hindsight, this decision was wrong. Quite frankly, I don't have the energy to throw away everything and start from zero with a different name. People do not seem to realize what it took to get there - which is partly understandingly because I had to learn by doing what it takes to get the idea into a coherent and consistent form. Simply switching to a different name is not just search It would reset the project almost to its very start again, losing the go-live effect of previous weekend (whose effect might be questionable considering the name discussion), its project URL that is now out there, the motivation video which aims to explain the motivation to users of Emacs, the EmacsConf21 talk publicity, and it would require much effort to reach the status where Orgdown is now. >> Oh, there is a very large danger here of getting something that is >> not compatible with Org-mode any more. I don't think that this would >> be a good thing. At least the different flavors killed the fun of >> Markdown for me. > > The astonishing thing is that most people manage to get along despite of > the incompatibilities of the different Markdown flavours. Otherwise > Markdown would not be such a success. Why is this? What can be learned > from this for creating org tools outside of Emacs? Actually surveying > this might be of interest. I agree and I have thought about it myself already. My guess is that most people do not suffer much from different Markdown flavors because they rarely mix them in their workflows. I guess most people are using Markdown only in their text editor OR only in GitHub/GitLab org files OR only within any other Markdown-tool. I might b
Re: "Orgdown", the new name for the syntax of Org-mode
Hi Tim, * Tim Cross wrote: > > Hi Karl, > > while I can appreciate the point you are making, I'm doubtful your > suggestion will gain the traction necessary to work. You might be right. Only time will tell. ;-) > To me, it feels a little like the frequent posts from RMS in the > emacs-devel list where he gets upset when people refer to Linux > instead of GNU Linux. I disagree here. Linux vs. GNU/Linux are two different names for the same thing. Org-mode is an Elisp implementation and Orgdown is just a syntax definition. So they are completely different things. > To some extent, the distinction will be too subtle for many and > often, it isn't clear whether an issue is a syntax definition > (orgdown) or an implementation bug or just simply user > misunderstanding. It seems to be the case that the name "Orgdown" is the reason why the Org-mode community does not support the idea of an implementation-agnostic definition of the syntax. Which is ... kinda funny if you think about it. Well if the project is not working out, at least I made my point and we continue to have all those misunderstandings and lack of Orgdown support in 3rd party tools (because Org-mode is way too big). > Perhaps we just need a name for the markup syntax which doesn't actually > reference 'org' at all - it simply is the markup syntax which org > happens to use. A completely separate name might avoid confusion and > would make it very clear that the markup syntax is not org mode. Problem > is, naming is terribly difficult and I have no suggestions on what would > be a good name. Oh, there is a very large danger here of getting something that is not compatible with Org-mode any more. I don't think that this would be a good thing. At least the different flavors killed the fun of Markdown for me. > I have not yet viewed your video, but will certainly be doing so. Again, > agree with the sentiment of what your trying to do, just not convinced > it is compatible with basic human nature. Maybe we need to differ between the Org-mode community with potential bias and the main target group of people who did use Markdown in the past and never have heard of Org-mode before? -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
"Orgdown", the new name for the syntax of Org-mode
Hi Org-mode community, At this year's EmascsConf, I had a 12 minute video where I explain why we do need a different name for the syntax of Org-mode in contrast to the Elisp implementation of GNU/Emacs Org-mode. I would like you to read my rationale and motivate you to use the term "Orgdown" for the syntax and "Orgdown1" for the first (very basic) level of Orgdown syntax elements. - The EmacsConf21 talk: https://emacsconf.org/2021/talks/org-outside - Orgdown site: https://gitlab.com/publicvoit/orgdown (please contribute!) - My motivation article: https://karl-voit.at/2021/11/27/orgdown/ - This is the longer version of my 12 minute EmacsConf21 video. - My personal copy of the video: https://tube.graz.social/w/bgJVfjPLQAoJwLJQZoo3Hu Just as a sneak preview (not as a replacement for my motivation article): Orgdown is and will be defined in a set of levels, starting with very basic Orgdown1 (or OD1 or O↓1 or ⧬1 - depending on your coolness factor of choice :-) ) - OD1 → https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Orgdown-Levels.org - OD2 → will be defined in future - OD3 → will be defined in future - ... - OD∞ = Org-mode (by definition) Any OD-level needs to be compatible with Org-mode as implemented in Elisp for GNU/Emacs Org-mode according to https://orgmode.org. Any ODx is a sub-set of the syntax elements of ODy (with y>x). With introducing a new term specific for the syntax, we do get the benefit of getting a better way to handle Org-mode support in 3rd-party tools such as listed on https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Tool-Support.org (please extend!). Having a well-defined sub-set of Org-mode, I also do think that formal definitions of the Org-mode syntax will be easier to develop, starting with the very simple OD1 level. It would be awesome if we start referring to syntax support in 3rd-party tools with the corresponding OD levels. I want to emphasize that the goal of Orgdown is NOT and will never be something that is an alternative to our golden standard Org-mode. We will try hard not to get into the Markdown situation where you need to know the exact flavor of the markup in order to produce text. So far, the response was great at the conference and I do hope that this idea will get a life of its own, developing the standard further, bringing this magnificent lightweight markup to the digital world. This also eases some pain for users of GNU/Emacs when it comes to exchanging text-based data. Thanks for your support here! -- Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Help requested: Support for basic Org mode support in tools outside of Emacs
* M ‘quintus’ Gülker wrote: > Am 04. August 2021 um 12:57 Uhr +0200 schrieb Karl Voit: >> My focus is on Emacs-independent tools, emphasizing the argument >> that Org mode is not Emacs-only and its syntax does have >> applications outside of Emacs as well because it is a well-defined >> syntax in the sense of >> https://karl-voit.at/2017/09/23/orgmode-as-markup-only/ > > It is an interesting post, thank you for sharing. Indeed, a list of > non-Emacs org tools would benefit org's popularity as a markup > language. Good luck with building one! > > The problem with the approach you describe in this article is that the > org markup is not really separatable from org as a part of Emacs. This is absolutely true and I'm going to try something to change that in the upcoming months. ;-) -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Help requested: Support for basic Org mode support in tools outside of Emacs
* Jens Neuhalfen wrote: > Hi > > on iOS the (really amazing) git client „working copy“ has support for org > rendering Interesting. Could you provide me a syntax compatibility row according to the table at the bottom of https://github.com/novoid/github-orgmode-tests/blob/master/orgmode_support.org ? > Jens > >> On 3. Aug 2021, at 11:32, Karl Voit wrote: >> >> Hi, >> >> I'm collecting information on basic Org mode support in tools that >> are not Emacs. >> >> I already have: GitHub, GitLab (exactly like GitHub), OrgModeWeb, >> Orgzly, Orgro, Emacs, vim-orgmode. >> >> What I need is information on much more tools. >> >> I have set up a syntax checking file on >> https://github.com/novoid/github-orgmode-tests/blob/master/orgmode_support.org >> which also contains my current compatibility table for the most >> basic set that makes sense as a Markdown-pendant outside of Emacs >> according to my subjective judgement on Org mode at the bottom. >> >> My focus is on tools that - at least - offer text formatting syntax >> highlighting for *bold* /italic/ and so forth. The rest could be >> "works as text but has no special support for outlining and more". >> >> The goals is to emphasize that there are much more tools that allow >> for viewing and/or editing data in Org mode syntax. >> >> Since I don't have an iPhone, iOS-based tools supporting Org mode >> syntax is very much appreciated. >> >> Please do hand in more lines for the table either here, via email or >> as a GitHub pull request. >> >> Thank you! >> >> -- >> get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: >>> get Memacs from https://github.com/novoid/Memacs < >> Personal Information Management > http://Karl-Voit.at/tags/pim/ >> Emacs-related > http://Karl-Voit.at/tags/emacs/ >> >> > > -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Help requested: Support for basic Org mode support in tools outside of Emacs
Hi Timothy, * Timothy wrote: > > Hi Karl, > > Just to check, have you seen <https://orgmode.org/tools.html> ? Yes, but thanks for reminding! -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Help requested: Support for basic Org mode support in tools outside of Emacs
Hi Tom, Great list you compiled here! * Tom Gillespie wrote: > Hi Karl, >Great initiative. For many of the things in the table you will > probably want to link to the underlying library For example for github > and gitlab there is https://github.com/wallyqs/org-ruby (which I have > been trying to find time to submit fixes to). I've linked a couple > relevant threads and repos. Best! > Tom > > python https://github.com/novoid/Memacs > python https://github.com/karlicoss/orgparse > python https://github.com/bjonnh/PyOrgMode > racket https://github.com/tgbugs/laundry/tree/next > racket https://github.com/jeapostrophe/org-mode > racket https://github.com/antoineB/org-mode > See https://github.com/tgbugs/laundry/blob/next/laundry/cursed.org for > an org file that github fails to render > clojure https://github.com/200ok-ch/org-parser/blob/master/resources/org.ebnf > > https://orgmode.org/list/ca+g3_pobab1qx1zv8q9sjfh4khuhvmanxp3xo7__6eosdxk...@mail.gmail.com/ > https://orgmode.org/list/ca+g3_pnj6pekqv+twfkwbd778xhw9wsfx+kjjhjsoreplhu...@mail.gmail.com/ Thanks for this list. Since my focus is on non-Emacs tools, many of those tools do not qualify although I found it very flattering that you were mentioning Memacs to me. :-) Parsers is a very good keyword. However, I will link https://orgmode.org/worg/org-tools/index.html because it already has a comprehensive list of Org mode parsers we should re-use here. Maybe you want to add the racket parsers to it? (I can't contribute to Worg any more because of some strange technical issue I can't solve myself). -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Help requested: Support for basic Org mode support in tools outside of Emacs
Hi, Thanks for all the feedback so far. It's really cool! I would like to add a clarification: the list of tools I'm collecting is a list *outside* of Emacs. Emacs is mentioned once because it needs to be there. However, I'm not interested in listing Emacs-related modules, projects like Memacs (thanks for mentioning that!), and such. My focus is on Emacs-independent tools, emphasizing the argument that Org mode is not Emacs-only and its syntax does have applications outside of Emacs as well because it is a well-defined syntax in the sense of https://karl-voit.at/2017/09/23/orgmode-as-markup-only/ And if you do mention a tool, it would be awesome when you could add a syntax compatibility check according to my table on https://github.com/novoid/github-orgmode-tests/blob/master/orgmode_support.org as well since I don't have the resources to try out all tools myself. Thanks! * Karl Voit wrote: > Hi, > > I'm collecting information on basic Org mode support in tools that > are not Emacs. > > I already have: GitHub, GitLab (exactly like GitHub), OrgModeWeb, > Orgzly, Orgro, Emacs, vim-orgmode. > > What I need is information on much more tools. > > I have set up a syntax checking file on > https://github.com/novoid/github-orgmode-tests/blob/master/orgmode_support.org > which also contains my current compatibility table for the most > basic set that makes sense as a Markdown-pendant outside of Emacs > according to my subjective judgement on Org mode at the bottom. > > My focus is on tools that - at least - offer text formatting syntax > highlighting for *bold* /italic/ and so forth. The rest could be > "works as text but has no special support for outlining and more". > > The goals is to emphasize that there are much more tools that allow > for viewing and/or editing data in Org mode syntax. > > Since I don't have an iPhone, iOS-based tools supporting Org mode > syntax is very much appreciated. > > Please do hand in more lines for the table either here, via email or > as a GitHub pull request. > > Thank you! > -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Help requested: Support for basic Org mode support in tools outside of Emacs
Hi Robert, * Robert Horn wrote: > > Karl Voit writes: > >> I'm collecting information on basic Org mode support in tools that >> are not Emacs. >> > > If email integration is considered support, you can add > > mu (searching for mu4e will eliminate most of the false positives for > "mu" when searching) > notmuch > > They both have org-mode integrations. E.g., create an org-mode task > from within the email reader, with link back to the email. Good to know but my focus are tools outside of Emacs. I just mentioned Emacs once in the table to make sure it's there. However, I won't collect all org-related modules within Emacs as it is a different use-case. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Help requested: Support for basic Org mode support in tools outside of Emacs
* Kristian Grönberg wrote: > > Beorg for iOS (https://beorgapp.com) , would be one. I don't have access to iOS devices. Could you hand in a compatibility row according to my table? -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Help requested: Support for basic Org mode support in tools outside of Emacs
Hi, I'm collecting information on basic Org mode support in tools that are not Emacs. I already have: GitHub, GitLab (exactly like GitHub), OrgModeWeb, Orgzly, Orgro, Emacs, vim-orgmode. What I need is information on much more tools. I have set up a syntax checking file on https://github.com/novoid/github-orgmode-tests/blob/master/orgmode_support.org which also contains my current compatibility table for the most basic set that makes sense as a Markdown-pendant outside of Emacs according to my subjective judgement on Org mode at the bottom. My focus is on tools that - at least - offer text formatting syntax highlighting for *bold* /italic/ and so forth. The rest could be "works as text but has no special support for outlining and more". The goals is to emphasize that there are much more tools that allow for viewing and/or editing data in Org mode syntax. Since I don't have an iPhone, iOS-based tools supporting Org mode syntax is very much appreciated. Please do hand in more lines for the table either here, via email or as a GitHub pull request. Thank you! -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Dynamic block tables: adding prefix of "id:" to %ID
* Ihor Radchenko wrote:
> Karl Voit writes:
>> Thanks, this sounds clever and I think I understand the code.
>> Although I would have preferred not to overwrite a function. I
>> always have a fear that this leads to nasty side-effects with future
>> updates.
>
> That's not overwriting. org-columns-modify-value-for-display-function is
> not a function, but a custom variable defaulting to nil. You have all
> rights to set it to whatever you wish.
Oh, this is reassuring. Thank you!
>> Without deeper knowledge, I was astonished that C-h f
>> org-columns-modify-value-for-display-function did not lead to a
>> matching function and C-h v ... to a matching variable.
>
> Hmm. You are right. This should be a bug. It happens because
> org-colview.el is only loaded after you actually run column view or
> corresponding dblock. Before that, Emacs is not aware about this
> variable (unless you require org-colview manually in your config).
>
>> When I applied the new change to update a table in a file of 71k
>> lines of org, I had to cancel the process after over two hours
>> without a result. Before the change, updating this table took
>> roughly 20 minutes.
>
> That's probably because the function I provided tries to compute the
> description part of the link by querying the headline for each result.
> You may get much better performance using the following version:
>
> (defun yant/org-columns-custom-formatter (column-title value)
> "Format column values for columns with ID-LINK title as proper Org mode id:
> link."
> (pcase column-title
> ("ID-LINK"
> (format "[[id:%s]]" value))
> (_ nil)))
I can confirm that this version does not have any negative impact
compared to the version without your code.
If anybody is interested why this is taking roughly 20min to update
one table:
| - command-execute 553233 93%
| - call-interactively 553233 93%
| - funcall-interactively 553233 93%
|- org-ctrl-c-ctrl-c 553233 93%
| - org-update-dblock553228 93%
| - org-dblock-write:columnview 553228 93%
| - org-columns--capture-view 553212 93%
|- org-columns 540042 91%
| - org-columns--display-here536947 90%
| - face-remap-add-relative 527000 88%
| - face-remap-order 526004 88%
|- sort 521312 88%
| face-attrs-more-relative-p 458136 77%
| + org-columns--new-overlay 2008 0%
|face-attribute 205 0%
| + org-columns--overlay-text 44 0%
|org-get-level-face 4 0%
| + org-map-entries1506 0%
| + org-columns-compute-all1441 0%
| + org-columns--set-widths 8 0%
|+ org-map-entries12126 2%
|+ org-columns-quit 16 0%
| + org-table-align12 0%
| + org-columns--clean-item 4 0%
| + org-element-context 5 0%
| + ... 38956 6%
| + timer-event-handler 166 0%
| + redisplay_internal (C function) 28 0%
> Best,
> Ihor
Thank Ihor, you have improved yet another part of my Emacs life!
--
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
> get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Dynamic block tables: adding prefix of "id:" to %ID
Hi Ihor,
* Ihor Radchenko wrote:
> Karl Voit writes:
>
>> I do have a dynamic block table like this:
>> ...
>> | NEXT| [0/0] proj bar | bar | :bar:project: |
>>
>> Is there a way to get the ID column with working ID links such as:
>> ...
>> | NEXT| [0/0] proj bar | id:bar | :bar:project: |
>
> You may customise org-columns-modify-value-for-display-function:
>
> (defun yant/org-columns-custom-formatter (column-title value)
> "Format column values for columns with ID-LINK title as proper Org mode id:
> link."
> (pcase column-title
> ("ID-LINK"
> (format "[[id:%s][%s]]"
>value
>(org-with-point-at (org-id-find value 'marker)
>(org-get-heading t t t t
> (_ nil)))
> (setq org-columns-modify-value-for-display-function
> #'yant/org-columns-custom-formatter)
>
> Then, you can use the following dblock. Note that I renamed the column
> name to "ID-LINK"
>
> #+BEGIN: columnview :id global :match
> "+project-focus/!+STARTED|+NEXT|+WAITING" :format "%TODO(State) %ITEM(What)
> %ID(ID-LINK) %TAGS(Tags)"
> #+END:
Thanks, this sounds clever and I think I understand the code.
Although I would have preferred not to overwrite a function. I
always have a fear that this leads to nasty side-effects with future
updates.
Without deeper knowledge, I was astonished that C-h f
org-columns-modify-value-for-display-function did not lead to a
matching function and C-h v ... to a matching variable.
However, I set up following test file and it worked:
#+BEGIN: columnview :id global :match
"+project+focus/!+STARTED|+NEXT|+WAITING" :format "%TODO(State) %ITEM(What)
%ID(ID-LINK) %TAGS(Tags)"
| State | What | ID-LINK| Tags|
|---+++-|
| NEXT | [/] focus proj | [[id:2021-07-27-focus-proj][[/] focus proj]] |
:focus:project: |
#+END:
* Test
** NEXT [/] focus proj
:focus:project:
:PROPERTIES:
:CREATED: [2021-07-27 Tue 13:59]
:COOKIE_DATA: todo recursive
:ID: 2021-07-27-focus-proj
:END:
** NEXT [/] non-focus proj
:project:
:PROPERTIES:
:CREATED: [2021-07-27 Tue 13:59]
:COOKIE_DATA: todo recursive
:ID: 2021-07-27-non-focus-proj
:END:
When I applied the new change to update a table in a file of 71k
lines of org, I had to cancel the process after over two hours
without a result. Before the change, updating this table took
roughly 20 minutes.
Therefore, this somehow makes a poor performance even worse.
--
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
> get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Dynamic block tables: adding prefix of "id:" to %ID
Hi, * Kristian Grönberg wrote: > > I didn't read your question properly. > Would it work for you to use the "<>"? > > *** <> barheading >:PROPERTIES: >:ID: [[bar][barheading]] >:END: > > /Kris I'm afraid not because the dynamic block would duplicate the target definition and not generating a link. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Dynamic block tables: adding prefix of "id:" to %ID
Hi Kristian, * Kristian Grönberg wrote: > > hi Karl, > > I had to solve this by putting the link inside of the heading, like so: > > * STARTED proj foo >:PROPERTIES: >:ID: [[foo][id]] >:END: I can't follow you here. How does a working link to your heading look like? Here are some of my tests: - id:bar → works - id:foo → not working - id:baz → not working - id:myfoo → not working - id:myid → not working *** barheading :PROPERTIES: :ID: bar :END: *** fooheading :PROPERTIES: :ID: [[foo]] :END: *** bazheading :PROPERTIES: :ID: id:baz :END: *** example :PROPERTIES: :ID: [[myfoo][myid]] :END: > However this is not optimal since viewing the same ID property with "org-a= > genda-custom-commands" includes the link as well (which for me is not good= > since I have long links). > > Perhaps someone else has a better solution. > > /Kris > > On Friday, July 23rd, 2021 at 11:46, Karl Voit wrot= > e: > >> Hi, >> = > > >> I do have a dynamic block table like this: >> = > > >> #+BEGIN: columnview :id global :match "+project-focus/!+STARTED|+NEXT|+W= > AITING" :format "%TODO(State) %ITEM(What) %ID(ID) %TAGS(Tags)" >> = > > >> | State | What | ID | Tags | >> = > > >> |-++-+---| >> = > > >> | STARTED | [12/14] proj foo | foo | :foo:project: | >> = > > >> | NEXT | [0/0] proj bar | bar | :bar:project: | >> = > > >> | STARTED | [191/191] proj baz | baz | :baz:project: | >> = > > >> #+END: >> = > > >> Is there a way to get the ID column with working ID links such as: >> = > > >> #+BEGIN: columnview :id global :match "+project-focus/!+STARTED|+NEXT|+W= > AITING" :format "%TODO(State) %ITEM(What) %ID(ID) %TAGS(Tags)" >> = > > >> | State | What | ID | Tags | >> = > > >> |-+++---| >> = > > >> | STARTED | [12/14] proj foo | id:foo | :foo:project: | >> = > > >> | NEXT | [0/0] proj bar | id:bar | :bar:project: | >> = > > >> | STARTED | [191/191] proj baz | id:baz | :baz:project: | >> = > > >> #+END: >> = > > >> Thanks! >> = > > >> = > --= > --= > --= > --= > --= > --= > --= > --= > --= > --= > --= > - >> = > > >> get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mod= > e: >> = > > >> > get Memacs from https://github.com/novoid/Memacs < >> = > > >> Personal Information Management > http://Karl-Voit.at/tags/pim/ >> = > > >> Emacs-related > http://Karl-Voit.at/tags/emacs/ > ---a8d906ea5b9eed33670cb7379910ea33-- > > ---34bede87e6eb1c0d1b98c778939fee68 > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: OpenPGP digital signature > Content-Disposition: attachment; filename="signature.asc" > > > > ---34bede87e6eb1c0d1b98c778939fee68-- > > > -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Dynamic block tables: adding prefix of "id:" to %ID
Hi, I do have a dynamic block table like this: #+BEGIN: columnview :id global :match "+project-focus/!+STARTED|+NEXT|+WAITING" :format "%TODO(State) %ITEM(What) %ID(ID) %TAGS(Tags)" | State | What | ID | Tags | |-++-+---| | STARTED | [12/14] proj foo | foo | :foo:project: | | NEXT| [0/0] proj bar | bar | :bar:project: | | STARTED | [191/191] proj baz | baz | :baz:project: | #+END: Is there a way to get the ID column with working ID links such as: #+BEGIN: columnview :id global :match "+project-focus/!+STARTED|+NEXT|+WAITING" :format "%TODO(State) %ITEM(What) %ID(ID) %TAGS(Tags)" | State | What | ID | Tags | |-+++---| | STARTED | [12/14] proj foo | id:foo | :foo:project: | | NEXT| [0/0] proj bar | id:bar | :bar:project: | | STARTED | [191/191] proj baz | id:baz | :baz:project: | #+END: Thanks! -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: how to document/comment a complex org table formula
Hi Uwe, * Uwe Brauer wrote: > > Is there any way to document or comment such a formula, since I am sure > that within days I don't remember why I chose that formula? This is not a solution for really complex formulas. However, please do note that standard org has: Named references: https://orgmode.org/manual/References.html Name assignment: https://orgmode.org/manual/Advanced-features.html#Advanced-features For some cases, this may help. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Export Org mode files to (gag, barf) MS Office?
Hi Brandon, * Brandon Taylor wrote: > --_000_SA1PR13MB4799DBE017BDC4DA869BA10BA2059SA1PR13MB4799namp_ > Content-Type: text/plain; charset="Windows-1252" > Content-Transfer-Encoding: quoted-printable > > I know we=92re not supposed to really even TALK about proprietary software = > in FOSS communities like this one, but I can=92t help but wonder if someone= > might consider making (an) Emacs plugin(s) that allow(s) a user to export = > Org mode files to Microsoft Office file formats such as .docx, .xlsx and th= > e like? Or is/are there already (a) plugin(s) in the MELPA that can do this= > ? If you go down the pandoc path and you need to comply with company templates and such, you might want to read https://karl-voit.at/2017/12/17/pandoc-docx-reference/ where you can place a docx file at a specific path and you end up with nice end results. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Feature request: M-u M-x org-babel-mark-block -> mark block including block definition
Hi,
I'd like to propose a new universal argument functionality for
org-babel-mark-block: it should mark the block content (as without
universal argument) and the whole block definition as well.
Current behavior with and without universal argument:
#+NAME: my-example
#+BEGIN_SRC python
print('hello world!') <-- marked
#+END_SRC
Proposed behavior:
Without universal argument:
#+NAME: my-example
#+BEGIN_SRC python
print('hello world!')<-- marked
#+END_SRC
With universal argument:
#+NAME: my-example <-- marked
#+BEGIN_SRC python <-- marked
print('hello world!')<-- marked
#+END_SRC<-- marked
Personal background/motivation:
I often add blocks of all kind to list items:
- foobar
#+BEGIN_SRC python
print('hello world!') <-- marked
#+END_SRC
This enables me to collapse and expand the list item together with
the block.
So far, my process of adding a block to a list item was:
- create list item
- press RET (which goes to column 1, not the indented list column)
- create the block (by using custom yankpad snippets, simulating the
outdated quick templates(?) with, e.g., THIS should be addressed
here
- move block to the right to match the desired column
- so far, I'm using "C-x r t SPC SPC RET" but I should switch to
indent-rigidly which I covered on
https://karl-voit.at/2021/04/10/GLT21-emacs-org-features/
--
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
> get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/
[PATCH] Fixed lstset where language= wipes out previous definitions
* ox-latex.el (org-latex-src-block): moved (("language" ,lst-lang)) to the head
of the list.
This fixes wiping out preceding definitions given in
`org-latex-listings-options'.
TINYCHANGE
---
lisp/ox-latex.el | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index b9ecf070a..f956c851e 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3075,13 +3075,13 @@ contextual information."
(concat
(org-latex--make-option-string
(append
- lst-opt
+ `(("language" ,lst-lang))
+ lst-opt
(cond
((and (not float) (plist-member attributes :float)) nil)
((string= "multicolumn" float) '(("float" "*")))
((and float (not (assoc "float" lst-opt)))
`(("float" ,(plist-get info :latex-default-figure-position)
- `(("language" ,lst-lang))
(if label
`(("label" ,(org-latex--label src-block info)))
'(("label" " ")))
--
2.31.0
Changed list indentation behavior: how to revert?
Hi! I'm on Org mode maint git repo, currently v9.3.6. I recently upgraded from an older git commit version. Since the upgrade I do have a different behavior: - Consider this list itemX A 1 2 When I press RET at the "X" above, I end up at position "1". With another RET, cursor ends up at "2". I'd love to get back the previous behavior where RET at "X" always ended up at "A". Unfortunately, there are tons of org*indent* variables out there. I'd appreciate it very much if somebody knows what variable I need to modify to get back to the previous behavior. Thanks! If somebody is interested why I do find the old one much better: When I need one multi-line list item, I just keep on typing while auto-wrap is active or I press M-q to re-format the item accordingly. For a new list item, I'm using M-RET which solves the indentation correctly. When I press RET after the last list item to continue with a non-list item, I prefer the old behavior which does not add the extra spaces. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: [bug] Display issue with broken links
* Nicolas Goaziou wrote: > Hello, Hi Nicolas, > Karl Voit writes: > >> I've found an issue that leads to broken Org mode syntax without >> noticing. Considering the following example: >> >> : foo [[https://Karl-Voit.at][bar]] baz >> >> When I put my cursor right after "foo" and press the DEL key, my Org >> mode shows this: >> >> : foo bar baz >> >> ... as if the link was removed properly, keeping only the >> description text. >> >> However, in reality, the remaining thing is different: >> >> : foo [https://Karl-Voit.at][bar]] baz >> >> This snippet is displayed properly at least after reloading the file >> or switching to text-mode and back to org-mode. > > FWIW I cannot reproduce it. Oh. Good to know. >> I've made a screencast to demo this: >> https://karl-voit.at/temp/2020-06-05T11.28.16_Org_mode_display_issue_with_broken_link_--_emacs_screencasts.gif > > Proofs including an animated Nyan Cat are not considered valid, sorry. Don't discriminate my horizontal scroll bar cat! :-) -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
[bug] Display issue with broken links
Hi! I've found an issue that leads to broken Org mode syntax without noticing. Considering the following example: : foo [[https://Karl-Voit.at][bar]] baz When I put my cursor right after "foo" and press the DEL key, my Org mode shows this: : foo bar baz ... as if the link was removed properly, keeping only the description text. However, in reality, the remaining thing is different: : foo [https://Karl-Voit.at][bar]] baz This snippet is displayed properly at least after reloading the file or switching to text-mode and back to org-mode. I've made a screencast to demo this: https://karl-voit.at/temp/2020-06-05T11.28.16_Org_mode_display_issue_with_broken_link_--_emacs_screencasts.gif This happens with Emacs 26.1 as well as 26.3 with Org mode from maint git (9.3.6). Fun fact: I initially thought, this is a hidden feature which I started to use happily ;-) Considering https://www.reddit.com/r/orgmode/comments/gwa2i4/i_want_to_remove_the_link_and_preserve_the_text/ I would love to see something like org-remove-link-and-keep-description-text built-in. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: ox-confluence.el: omit radio target links (that end up being dead links)
Bastien (b...@gnu.org) wrote: > Hi Karl, Hi Bastien, > I fixed this here: > https://code.orgmode.org/bzg/org-mode/commit/ceb0ef95fb > Thanks for the report, Perfect timing for the fix - thank you! -- Karl Voit
Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
Hi, * Karl Voit wrote: > Hi Ihor, > > * Ihor Radchenko wrote: >> >> So far, I came up with the following partial solution searching and >> showing hidden text. >> >> (defun org-find-text-property-region (pos prop) >> (define-advice isearch-search-string (:after ( _) put-overlay) >> (defun org-restore-invisibility-specs ( _) >> (add-hook 'post-command-hook #'org-restore-invisibility-specs) >> (defun org-flag-region (from to flag spec) >> (defun org-unfontify-region (beg end _maybe_loudly) > > After a couple of hours working with these patches, my feedback is > very positive. Besides some visual glitches when creating a new > heading with org-expiry-insinuate activated (which automatically > adds :CREATED: properties), I could not detect any side-effect so > far (will keep testing). > > The visual glitch looks like that: > >:PROPERTIES:X:CREATED: [2020-05-04 Mon 18>54] > X > > ... with "X" being my character that symbolizes collapsed content. > The way it looked without the patch was a simple collapsed property > drawer. Here some hard numbers to demonstrate the impact: my-org-agenda: from 11-16s down to 10 -> not much of a difference helm-org-contacts-refresh-cache: 29-59s down to 2½ -> HUGE Emacs boot time: 50-65s down to 10 -> HUGE Navigating the cursor in large Org files -> HUGE subjective impact >>> Anyway, the real fix should come from Emacs itself. There are ways to >>> make overlays faster. These ways have already been discussed on the >>> Emacs devel mailing list, but no one implemented them. It is a bit sad >>> that we have to find workarounds for that. >> >> I guess that it is a very old story starting from the times when XEmacs >> was a thing [1]. I recently heard about binary tree implementation of >> overlays (there should be a branch in emacs git repo) [2], but there was >> no update on that branch for a while. So, I do not have much hope on >> Emacs implementing efficient overlay access in the near future. (And I >> have problems with huge org files already). > > I can not express how this also reflects my personal situation. > >> [1] >> https://www.reddit.com/r/planetemacs/comments/e9lgwn/history_of_lucid_emacs_fsf_emacs_schism/ >> [2] https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00323.html > > [3] https://karl-voit.at/2020/05/03/current-org-files > -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
Hi Ihor, * Ihor Radchenko wrote: > > So far, I came up with the following partial solution searching and > showing hidden text. > > (defun org-find-text-property-region (pos prop) > (define-advice isearch-search-string (:after ( _) put-overlay) > (defun org-restore-invisibility-specs ( _) > (add-hook 'post-command-hook #'org-restore-invisibility-specs) > (defun org-flag-region (from to flag spec) > (defun org-unfontify-region (beg end _maybe_loudly) After a couple of hours working with these patches, my feedback is very positive. Besides some visual glitches when creating a new heading with org-expiry-insinuate activated (which automatically adds :CREATED: properties), I could not detect any side-effect so far (will keep testing). The visual glitch looks like that: :PROPERTIES:X:CREATED: [2020-05-04 Mon 18>54] X ... with "X" being my character that symbolizes collapsed content. The way it looked without the patch was a simple collapsed property drawer. To me, this is acceptable considering the huge performance gain I got. THANK YOU VERY MUCH! I can't remember where I had this way of working within my large Org files[3] since ages. >> Anyway, the real fix should come from Emacs itself. There are ways to >> make overlays faster. These ways have already been discussed on the >> Emacs devel mailing list, but no one implemented them. It is a bit sad >> that we have to find workarounds for that. > > I guess that it is a very old story starting from the times when XEmacs > was a thing [1]. I recently heard about binary tree implementation of > overlays (there should be a branch in emacs git repo) [2], but there was > no update on that branch for a while. So, I do not have much hope on > Emacs implementing efficient overlay access in the near future. (And I > have problems with huge org files already). I can not express how this also reflects my personal situation. > [1] > https://www.reddit.com/r/planetemacs/comments/e9lgwn/history_of_lucid_emacs_fsf_emacs_schism/ > [2] https://lists.gnu.org/archive/html/emacs-devel/2019-12/msg00323.html [3] https://karl-voit.at/2020/05/03/current-org-files -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: ox-confluence.el: omit radio target links (that end up being dead links)
Hi, * Karl Voit wrote: > > As stated on [1] I do have an issue with export to Confluence markup > via org-mode/contrib/lisp/ox-confluence.el and radio targets[2]. > > When I am using a snippet like: > >| - <> :: this is the explanation to this weird term >| >| [...] >| >| Please respect the foo bar everyhere. > > ... it gets exported like that: > >| - *foo bar* - this is the explanation to this weird term >| >| [...] >| >| Please respect the [foo bar|foo bar] everyhere. > > These "[foo bar|foo bar]" snippets are then interpreted by > Confluence as links to the Confluence pages named "foo bar" which > usually don't exist. > > I think it would be a good improvement to ignore radio links in the > ox-confluence output. Meanwhile, somebody posted a fix on [1]: (defun export-radio-links-as-plain-text (link desc info) (when (string= "radio" (org-element-property :type link)) desc)) (advice-add #'org-confluence-link :before-until #'export-radio-links-as-plain-text) Maybe this is a good idea to include this in the official source code? > [1] > https://www.reddit.com/r/emacs/comments/fk5z1b/how_to_remove_foo_barfoo_bar_links_via/ > I'm asking how to search/replace current expressions as a > short-term workaround. > > [2] https://orgmode.org/manual/Radio-Targets.html -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
ox-confluence.el: omit radio target links (that end up being dead links)
Hi! As stated on [1] I do have an issue with export to Confluence markup via org-mode/contrib/lisp/ox-confluence.el and radio targets[2]. When I am using a snippet like: | - <> :: this is the explanation to this weird term | | [...] | | Please respect the foo bar everyhere. ... it gets exported like that: | - *foo bar* - this is the explanation to this weird term | | [...] | | Please respect the [foo bar|foo bar] everyhere. These "[foo bar|foo bar]" snippets are then interpreted by Confluence as links to the Confluence pages named "foo bar" which usually don't exist. I think it would be a good improvement to ignore radio links in the ox-confluence output. Thanks! [1] https://www.reddit.com/r/emacs/comments/fk5z1b/how_to_remove_foo_barfoo_bar_links_via/ I'm asking how to search/replace current expressions as a short-term workaround. [2] https://orgmode.org/manual/Radio-Targets.html -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)
This week, the error re-appeared. * Karl Voit wrote: > > Thanks for the advice. I ran three test runs in order to find out how output > is > affected: > > > Testrun with disabled org-depend: > emacs-snapshot --batch --load /home/vk/.emacs.d/init.el --eval '(progn > (my-export-agenda)) >261.95s user 1.57s system 99% cpu 4:24.01 total > > → I got a result without error > > > Testrun with enabled org-depend: > emacs-snapshot --batch --load /home/vk/.emacs.d/init.el --eval '(progn > (my-export-agenda))' >117.58s user 1.46s system 99% cpu 1:59.60 total > > → much faster result without error :-) (probably caching?) > > > revoking the two suggested changes and do another test run with org-depend, > expecting error: > emacs-snapshot --batch --load /home/vk/.emacs.d/init.el --eval '(progn > (my-export-agenda))' >114.38s user 1.53s system 99% cpu 1:56.33 total > > → much faster result without error (contrary to expection) > > > → the two setting changes do not have an effect for now regarding > error/no error due to the fact that I can not reproduce the > error. > > Retrying when error re-appears. - setting `org-agenda-before-write-hook' to nil - `org-icalendar-include-body': 42 - enabled org-depend : emacs-snapshot --batch --load /home/vk/.emacs.d/init.el --eval '(progn (my-export-agenda))' → did not finish after running for 4 hours (aborted) - setting `org-agenda-before-write-hook' to nil - `org-icalendar-include-body': 42 - *disabled org-depend* → produced output within 4min39s - setting `org-agenda-before-write-hook' to default - `org-icalendar-include-body': to default - disabled org-depend → produced output within 2min07s Any other test you want me to run? -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)
Hi Bastien, * Bastien wrote: > > Karl Voit writes: > >> Easy: I could not find any change of the defaults in my >> configuration[1]. So all of them have to be the default values. >> >> [1] https://github.com/novoid/dot-emacs/blob/master/config.org > > I would try setting `org-agenda-before-write-hook' to nil (it is set > to `org-agenda-add-entry-text' by default. > > Also, I see `org-icalendar-include-body' is set to 1000 in your setup. > > That's a lot and this will generate a lot of strings replacements, > I suggest trying a lower value for your export-and-write function. Thanks for the advice. I ran three test runs in order to find out how output is affected: Testrun with disabled org-depend: emacs-snapshot --batch --load /home/vk/.emacs.d/init.el --eval '(progn (my-export-agenda)) 261.95s user 1.57s system 99% cpu 4:24.01 total → I got a result without error Testrun with enabled org-depend: emacs-snapshot --batch --load /home/vk/.emacs.d/init.el --eval '(progn (my-export-agenda))' 117.58s user 1.46s system 99% cpu 1:59.60 total → much faster result without error :-) (probably caching?) revoking the two suggested changes and do another test run with org-depend, expecting error: emacs-snapshot --batch --load /home/vk/.emacs.d/init.el --eval '(progn (my-export-agenda))' 114.38s user 1.53s system 99% cpu 1:56.33 total → much faster result without error (contrary to expection) → the two setting changes do not have an effect for now regarding error/no error due to the fact that I can not reproduce the error. Retrying when error re-appears. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)
* Bastien wrote: > Hi Karl, > > Karl Voit writes: > >> So maybe I have to invest a weekend or so to bisect the issue. My >> gut feeling tells me that I won't like the output somehow. > > In the meantime, can you share the values of your org-id-* options? Easy: I could not find any change of the defaults in my configuration[1]. So all of them have to be the default values. [1] https://github.com/novoid/dot-emacs/blob/master/config.org -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Feature request: shared radio targets with archive files
Hi Bastien, * Bastien wrote: > > Karl Voit writes: > >> Can somebody estimate on the effort and potential negative >> implications (performance, caching issues, ...) when this feature >> would be extended, so that radio targets of foo.org also work[2] in >> foo.org_archive and vice versa? > > Radio targets only work within the same file. > > Just like HTML anchor links: voila. > > Allowing a radio target to be reached outside the current file would > lead to blur the distinction between radio targets and... links. Oh, what a bummer. > That said, you can write your own function, taking inspiration from > org-link--search-radio-target and adding it to org-open-link-functions, > where your function searches the target outside of the current buffer. > > Not sure, of course, whether this is trivial or not :) Hehe. OK, it was worth the (short) discussion. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)
Bonjour Bastien, * Bastien wrote: > > Karl Voit writes: > >> With disabled org-depend, it is working and finishes in ~5 minutes. With >> enabled org-depend it (sometimes) end up in an error as described. > > Do you need org-depend when exporting? Well: in all cases where I defined a dependency of task B to a task A, with disabled org-depend I end up seeing task B on the agenda although I can not do it at the moment. So as long as I don't use dependencies, it does not matter. However, I'm organizing a lecture in the summer term using a very large and complicated yankpad/yasnippet template for the whole term that is using many dependencies for approx. 70 todos. With disabled org-depend, I end up seeing all 70 todos although I may be able to work on two or three of them at any moment in time. > If not, I simply suggest to turn org-depend off... or to let-bind > `org-trigger-hook' and `org-blocker-hook' to nil in your function. > > Probably org-depend does a lot of moving back and forth in files to > check for IDs, and that may explain the time spend by this command > when you export many files. This sounds reasonable. I'm fine with - let's say - +50% 1-day agenda duration and I'm fine with even an hour of 60d agenda export to ics with enabled org-depend. The show-stopper is, when org-depend does run in an error after hours of exporting without a result. This way, I'm losing my Org->Android/Radicale workflow or my dependencies. The longer this thread gets, the more I have to accept that I might be the only one using dependencies in Org mode. I'm puzzled here because I do think that dependencies are such a natural thing to want and use. (I also have several ideas to improve usability of them to minimize manual effort when defining dependencies.) So maybe I have to invest a weekend or so to bisect the issue. My gut feeling tells me that I won't like the output somehow. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Feature request: shared radio targets with archive files
Hi! Only recently, I found radio targets[1] very handy to implement a glossary within an Org file. This way, any instance of "PIM" can be linked to one single definition of "- <<>> :: Personal Information Management" for example. My question (and feature request): Can somebody estimate on the effort and potential negative implications (performance, caching issues, ...) when this feature would be extended, so that radio targets of foo.org also work[2] in foo.org_archive and vice versa? I often have the use-case that I wrote down some definitions as sub-heading to a task. Its related radio target gets a broken one as soon as I archive the associated and finished task heading. Example: ** Reading a paper on keyboards This is highly relevant to PIM research. [...] ** DONE Reading a paper about notebooks *** Notes on the paper about notebooks - <<>> :: Personal Information Management - mentioned in the research chapter - <<>> :: Another common mediocre example - rings a bell somehow The first PIM instance is highlighted and linked to its definition below. As soon as the DONE task gets archived, the first PIM instance is no longer linked to its definition since the related target got moved to the archive. Of course, *all* instances within the archive file are unlinked to their definition targets in the non-archive file as well. The example works both ways. Thanks for your ideas [1] https://orgmode.org/manual/Radio-Targets.html [2] as in: "links in both files get highlighted" and "all links can be followed to their target" -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)
* Bastien wrote: > Hi Karl, Hi, > another suggestion: just send us a minimal extract of your files so > that we see how org-depend is called, together with what you do and > what goes wrong when you do it. Perhaps this will lead to something. Sure. https://github.com/novoid/dot-emacs/blob/master/config.org contains: | (setq my-user-emacs-directory "~/.emacs.d/") | (use-package org-depend | :load-path (lambda () (expand-file-name (concat my-user-emacs-directory "contrib/org-mode/contrib/lisp/"))) | ) ... which loads org-depend from my maint Org mode (currently: 9.3 (release_9.3-102-gd20e45.dirty @ mixed installation![...]). I only use org-depend for: * TODO Example 1 :PROPERTIES: :ID: 2020-02-20-foo :END: * TODO Example 2 :PROPERTIES: :BLOCKER: 2020-02-20-foo :END: Very rarely, I am using: * TODO Example 3 :PROPERTIES: :TRIGGER: 2020-02-20-foo :END: Most of the time, source-destination are within the same file. However, in some cases of using BLOCKER, the two headings might be in two different files. That's basically it: mostly BLOCKER and a few TRIGGER. I'm unsure if there is currently a TRIGGER that is still waiting to be activated. (By the way: is there a built-in feature to look for IDs that are linked somewhere (BLOCKER properties or ID links) that are broken?) Ad "what goes wrong when you do it": in my daily work, org-depend is working fine. The only thing that does not work is exporting my agenda with: | emacs --batch --load /home/vk/.emacs.d/init.el --eval '(progn (my-export-agenda))' and: | (defun my-export-agenda() |"Exports Org-mode agenda to ics file" |(interactive) |(save-some-buffers) | |;; I don't want the error messages in my exported agenda: |(setq org-agenda-files (remove "~/org/errors.org" org-agenda-files)) | |(setq max-specpdl-size 1) ;; does not solve issue |(setq max-lisp-eval-depth 5) ;; does not solve issue | |(org-agenda-list nil nil 60) |(org-agenda-write (concat my-user-emacs-directory "var/export/agenda-export.ics")) |) With disabled org-depend, it is working and finishes in ~5 minutes. With enabled org-depend it (sometimes) end up in an error as described. This can take hours. > I've never used org-edna, I'm curious to know if there are many users. Me too ;-) It's a bit more complicated in syntax but has advanced features org-depend does not offer. The main reason why I'm thinking of switching is that org-edna supports something like TRIGGER that also adds relative SCHEDULED date-stamps. This allows for "if $THAT task gets done, mark $NEXT task as a TODO item and add a SCHEDULED with three days in the future" which is very handy in some cases. > Thanks, Oh, it's me, who is very thankful, considering the tricky situation to investigate this issue. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)
Hi, * Bastien wrote: > > Karl Voit writes: > >> A couple days ago, the issue re-appeared (with org-depend being >> active again). To me, this is a clear indicator, that the issue is >> content-related and not config/binary-related: > > Can you bisect and deduce what part of your contents is producing > this? This is not trivial in my case since I'd have to merge all my Org mode content into one single large file and make sure that I remove content during bi-secting that has no link destination from the remaining content. Personally, I'm not convinced that this method will lead to a minimum example in any case. I can imagine that "number of Org mode headings/lines" might be involved here which would not trigger the error when bi-secting via removing. Currently, I don't see that this is possible without half a day work or (IMHO more likely) longer which I can't afford right now. :-( > When you have a clue, could you also bisect and see what > change in Org introduced this problem for the problematic contents? This would be trivial when I could locate the issue in a minimal example. > Such issues are difficult to reproduce and track outside your files. Totally agree. I thought somebody else might have faced the same issue. As long as I am the only person affected, I don't assume that it can be solved in a proper way. :-( I ran another test with Emacs 27.0.50 and disabled org-depend. The task finished after 4½ minutes without any error. Therefore, following dependencies has to be the culprit here. Moving from org-depend to org-edna is not trivial for me as well, considering the amount of meta-data to be modified. On the other hand, this would be interesting to see if org-edna can handle this use-case in a better way. In case somebody has experience with migration process and/or dependency lookup performance, I'm very interested. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)
Hi Bastien, * Bastien wrote: > Hi Karl, > > did you manage to fix this one? > > I read "Property drawers allowed before first headline" in > etc/ORG-NEWS from the master branch: > > Property drawers are now allowed before the first headline. > > Org mode is moving more towards making things before the first > headline behave just as if it was at outline level 0. Inheritance > for properties will work also for this level. In other words: > defining things in a property drawer before the first headline will > make them "inheritable" for all headlines. > > I guess your problem might be related to this new behavior. A couple days ago, the issue re-appeared (with org-depend being active again). To me, this is a clear indicator, that the issue is content-related and not config/binary-related: Emacs 26.3: : emacs --batch --load /home/vk/.emacs.d/init.el --eval '(progn (my-export-agenda))' : [...] : Garbage collecting... : Garbage collecting...done : Garbage collecting... : Garbage collecting...done : Garbage collecting... : Garbage collecting...done : Position saved to mark ring, go back with ‘C-c &’. : Position saved to mark ring, go back with ‘C-c &’. : Position saved to mark ring, go back with ‘C-c &’. : Position saved to mark ring, go back with ‘C-c &’. : Position saved to mark ring, go back with ‘C-c &’. : Position saved to mark ring, go back with ‘C-c &’. : Garbage collecting... : Garbage collecting...done : Variable binding depth exceeds max-specpdl-size : emacs --batch --load /home/vk/.emacs.d/init.el --eval 8029,80s user 4,30s system 99% cpu 2:14:02,16 total Yes, that's over two hours. With Emacs 27.0.50, the same job is currently running for over five hours. I guess this will end with an error as well some day. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Emacs hangs sometimes for no reason
* briangpowell . wrote: > > Emacs periodically saves all files that you are visiting; this is called > auto-saving . Auto-saving prevents you from losing more than a limited > amount of work if the system crashes. By default, auto-saves happen every > 300 keystrokes, or after around 30 seconds of idle time. > > Suggest you try making your auto-save-interval variable much larger and see > if that helps I had to disable auto-save because I'm using org-crypt which would leak sensitive information to my disk (+ git repository). I'm using real-auto-save instead. > Also suggest making smaller .org files when practical Way too late for that ;-) So far, I've found no one with bigger Org files. I plan to blog about small versus big Org files in the upcoming weeks. However, your suggestions are valid points for the general situation. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)
* Bastien wrote: > Hi Karl, > > Karl Voit writes: > >> So the issue seems to be gone (for now) but I don't know why it >> appeared in the first place nor why it disappeared in the meantime. > > /me looks for a good xkcd quote. :) Alternatively: https://en.wikipedia.org/wiki/Haiku_in_English ;-) -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)
* Bastien wrote: > Hi Karl, Hi Bastien, > did you manage to fix this one? Well ... > I read "Property drawers allowed before first headline" in > etc/ORG-NEWS from the master branch: > > Property drawers are now allowed before the first headline. > > Org mode is moving more towards making things before the first > headline behave just as if it was at outline level 0. Inheritance > for properties will work also for this level. In other words: > defining things in a property drawer before the first headline will > make them "inheritable" for all headlines. > > I guess your problem might be related to this new behavior. Since I'm not using drawers before the first headline, I don't understand how this might relate to my issue. However, I just re-enabled org-depend which I had disabled for batch mode only in order to get the export done. Then I ran the batch process for the export and it finished without an error within 1min53sec. :-) So the issue seems to be gone (for now) but I don't know why it appeared in the first place nor why it disappeared in the meantime. I'm using Org mode from maint. Currently on my side: d20e45b18 (3 days ago). The version that had the issue was from November or December. I could provide the exact ID hash if anybody is interested. Thanks anyway and thanks for the pointer with the new feature. That might come handy when there is a property which does not have a file-local version. -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: Emacs hangs sometimes for no reason
* Sebastian Christ wrote: > Hi list, > > in the last couple weeks (perhaps months?) Emacs hangs for no specific > reason for me. The single constant is, that when it hangs, it hangs > while I'm in org-mode. This occurs on multiple circumstance as > > - changing the outline structure by demoting and promoting headline > - when refiling > - re-schedule in agenda > - yanking > - perhaps more Same here with 3 different Emacs versions. > The strange thing is that it happens unpredictably, e.g. I re-schedule > 11 items without problems and the 12th one lets Emacs crash. Sometimes > it works for days without problems and then I promote a headline and > Emacs crashes. Very sad :( I did not have a crash here, though. > My actual question is, had someone had similar issues? Or is it just me > with my configuration? > > Perhaps someone can guide me on how I can find the root cause for this? > I pretty much lost here. > > Thanks in advance for any hints. In a discussion on Org/Emacs scalability issues, I got a hint[1] to use gcmh.el which indicates garbage collecting activity. My freeze-moments are almost entirely related to garbage collecting. You might want to try that. I've got no solution or workaround so far. [1] https://www.reddit.com/r/orgmode/comments/e9p84n/scaling_org_better_to_use_more_medsize_files_or/fcm5bsc/ -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
ICS agenda export exceeds max-specpdl-size probably because of org-depend (org-edna same?)
Hi all, BACKGROUND: I'm using org-depend since ages[1]. As a matter of fact, it was the initial reason why I started with Org mode in the first place. One of my many workflows[2] exports the agenda for the upcoming 60 days into an ICS file via a cron job during night: : emacs-snapshot --batch --load /home/vk/.emacs.d/init.el --eval '(progn (my-export-agenda))' my-export-agenda[6] basically consists of: : (org-agenda-list nil nil 60) : (org-agenda-write (concat my-user-emacs-directory "var/export/agenda-export.ics")) This ICS file is then postprocessed and uploaded to my calendar server so that my mobile phone calendar is able to display events and appointments. This workflow stopped working end of December. ERRORS and INVESTIGATION: Error message when this batch run of Emacs exits after 5 hours(!): : Lisp nesting exceeds ‘max-lisp-eval-depth’ I updated my Org version[3] recently to get v9.3 from git maint. This was Wed Dec 4 10:37:19 2019 +0100. So the issue with the ICS export did not appear at the same time of the update. I also get: : [...] : Preparing diary...done : Preparing diary...done : Position saved to mark ring, go back with ‘C-c &’. [1038 times] : org-before-first-heading-p: Variable binding depth exceeds max-specpdl-size I changed the value for the variables without changing the result: : (setq max-specpdl-size 1) : (setq max-lisp-eval-depth 5) I even upgraded my Emacs version from 25 to 27[3]. No change. I reduced my set of org-agenda-files and did some test runs: most single org files resulted in an ICS export. Some single org files did result in the error. Reducing the export period from 60 to 7 days did not change the error. I also get following as execution cancellation error: : Before first headline at position 586 in buffer *temp*-99684 When running the job, I see *lots* lines like[4]: : Garbage collecting... : Garbage collecting...done To me, it's a data-related issue with my Org mode files so that others most likely are not able to reproduce my issue at all. Disabling org-depend results in a working ICS export that took much less time. I'm not sure if org-depend is directly related or just reduces "the complexity" such that the job is able to be finalized. QUESTIONS: I'm looking for ideas what I may check in order to be able to use org-depend again. Should I do a profiler report? How do I have to do this in order to get good results? Further more: is here somebody able to tell if org-edna[5] does have this issues as well? After all, org-edna is somewhat more complex than org-depend. A migration from org-depend to org-edna would be doable to me but with a decent effort. (I'm thinking of migrating only tasks that are not DONE or CANCELLED as I do think closed tasks do not irritate org-edna with old org-depend syntax.) [1] https://karl-voit.at/2016/12/18/org-depend/ Almost everything I use is :BLOCKER: properties and very rarely :TRIGGER: events. [2] just a selection is described on https://karl-voit.at/2019/09/25/using-orgmode/ [3] Org mode version 9.3 (release_9.3-3-g46319b.dirty @ mixed installation! GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.11) of 2019-12-15, unofficial emacs-snapshot build [4] I setup up "gcmh" package because of a comment on: https://www.reddit.com/r/orgmode/comments/e9p84n/scaling_org_better_to_use_more_medsize_files_or/fcm5bsc/ [5] https://elpa.gnu.org/packages/org-edna.html [6] https://github.com/novoid/dot-emacs/blob/master/config.org -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: [PROPOSAL] New function `org-headings-to-point' and displayer.
On 05 Dec 2019, Adam Porter wrote: >Karl Fogel writes: >> Unless you meant make a new interactive function to display a vertical >> hierarchy and base it on the existing Org Mode functions you informed >> me of the existence of? But I don't think there's a way to do that >> without adding some new parameters to those existing functions, and, >> as you point out, that's probably not worth the extra complexity. > >Forgive me, I think I misunderstood you. Yes, I meant to make a new >interactive function for displaying the vertical hierarchy. Oh, I still learned things from the code you posted in your previous message, though, thanks. (I didn't know about `thread-first', for example, even though it's been around for a while.) Yes, what I'd meant was that ideally this would just be an interactive wrapper around `org-format-outline-path'. Unfortunately there's no way to get the behavior I want from that function currently. This is not a showstopper -- I agree with you that adding yet more arguments to that function is not a complexity cost worth paying here. Another thing is that `org-get-outline-path' returns only the title portion of each heading, rather than the full heading. Even though the titles are all I need right now, I still would normally prefer that the underlying function provide more generality (i.e., return the full headings) and then the caller would use `(nth 4 heading)' or whatever to get the part it needs. That way if one wants to do something more sophisticated when displaying headings -- involving tags, for example -- the necessary information would be available. Again, these are not things that need to be "solved" in Org Mode; I'm not even sure we should consider them to be problems. I'm just explaining my earlier comment about how the existing functions in Org Mode don't provide quite the substrate I was hoping for for this particular task. >BTW, you might also find the org-sticky-header package helpful. Ah, very nice -- thank you! (https://github.com/alphapapa/org-sticky-header, for those who want the convenience of the a quick link.) Best regards, -Karl
Re: [PROPOSAL] New function `org-headings-to-point' and displayer.
On 03 Dec 2019, Adam Porter wrote: >You might consider adjusting your fontification settings. The >single-line outline path can be quite readable with the right faces (see >attached example). That's a useful hint generally, thank you. However, for most of the Org Mode files I work with, the heading lengths are pretty long, so I need vertical stacking in the minibuffer when displaying all the headings down to point. >I'd recommend against adding more optional arguments to that function, >because it already has four. Emacs/Org already have enough problems >with code like (org-whatever nil t nil t nil nil t). Sure, I can see how that tradeoff might not be worth it. >> There should also be some way to access the new functionality >> interactively; the solution might be a new interactive wrapper >> function with its own name, or maybe some new variables? I don't >> know; I haven't thought it all the way through yet. > >> Is there any interest in or opposition to such a patch? I'd like to >> get a sense of whether it would be able to land in Org Mode before I >> start working on it. > >I'd recommend simply making a new interactive function, putting it in >your personal config, and sharing it publicly (e.g. here and on >/r/orgmode). Use it "in anger" for a while, and solicit feedback from >other users for a while. Then, if it still seems widely useful enough >to deserve being added to Org proper, apply what you've learned in the >meantime to improve and simplify its implementation before proposing a >patch. Well, I already posted it here, so that's done. Those functions are publicly packaged (albeit with the `ots-' prefix) here: https://github.com/OpenTechStrategies/ots-tools/blob/master/emacs-tools/ots.el Unless you meant make a new interactive function to display a vertical hierarchy and base it on the existing Org Mode functions you informed me of the existence of? But I don't think there's a way to do that without adding some new parameters to those existing functions, and, as you point out, that's probably not worth the extra complexity. >You might also consider sending it to my "unpackaged.el" repo, which >might make a good home for it: http://github.com/alphapapa/unpackaged.el That's a nice collection! I'm enjoying browsing through it. I effectively already have a personal unpackaged-elisp repository at https://svn.red-bean.com/repos/kfogel/trunk/.emacs (if these functions weren't already in 'ots-tools', they'd be there). Best regards, -Karl
Re: ox-latex: missing :LATEX_HEADER:
* Kaushal Modi wrote: > > On Wed, Dec 4, 2019 at 1:32 PM Karl Voit wrote: > >> Hi, >> >> For LaTeX export, I'd love to use ::LATEX_HEADER: instead of >> file-based settings with #+LATEX_HEADER. > > Typically all Org export keywords work in properties too, but with an > "EXPORT_" prefix. > > See if the ":EXPORT_LATEX_HEADER:" property works .. Of course. Stupid me. I forgot the changed prefix when exporting my very old heading. AFAIR, this got changed a while ago and I did not update my current drawers. :-( Thanks for reminding me! -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
ox-latex: missing :LATEX_HEADER:
Hi, I tend to have everything within larger Org mode file. Therefore, I mostly rely on export settings I'm able to control via PROPERTY drawer values instead of file-based methods. Most of the time, there is always a property version as well as a file-based version for settings. For LaTeX export, I'd love to use ::LATEX_HEADER: instead of file-based settings with #+LATEX_HEADER. Is there a reason why this important variable is not available as per-sub-hierarchy/drawer? Thanks! -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
Re: [PROPOSAL] New function `org-headings-to-point' and displayer.
On 03 Dec 2019, Adam Porter wrote: >This seems to duplicate functionality from org-get-outline-path. As >well, org-eldoc displays in the minibuffer the outline path for the >heading at point. Thank you, Adam -- I didn't know about those. I had searched for something like that before implementing my own, but I think I searched using the term "heading" or something instead of "outline", unfortunately, so I never found them. Now that I know about `org-display-outline-path', the one improvement I'd like to make is to enable it to display the headings with per-level indentation, and treat the first level specially (with an anchoring dot instead of a directional arrow), as my code did. It's a lot more readable that way displayed in the minibuffer. I suppose I would implement this by adding two new optional arguments to `org-display-outline-path': * `per-level-indentation': add a newline followed by in front of each SEPARATOR * `level-1-prefix': a special prefix for the first level's heading ...and make corresponding changes to the helper functions of course. There should also be some way to access the new functionality interactively; the solution might be a new interactive wrapper function with its own name, or maybe some new variables? I don't know; I haven't thought it all the way through yet. Is there any interest in or opposition to such a patch? I'd like to get a sense of whether it would be able to land in Org Mode before I start working on it. Best regards, -Karl
Re: [PROPOSAL] New function `org-headings-to-point' and displayer.
On 03 Dec 2019, Adam Porter wrote: >This seems to duplicate functionality from org-get-outline-path. As >well, org-eldoc displays in the minibuffer the outline path for the >heading at point. By the way, when I run `M-x eldoc-mode' in a Org Mode buffer, I get this message: "There is no ElDoc support in this buffer" Am I doing it wrong?
[PROPOSAL] New function `org-headings-to-point' and displayer.
Hi. I've been using this for a while and find it very handy. If people like this and want it in Org Mode, I'll do the rest of the work to package it up as a patch, with ChangeLog entry, NEWS, etc, and post it here for review before committing. To try it out, just evaluate both functions and then run `M-x org-display-headings-to-point' from somewhere deep in an org subtree. Comments/feedback welcome. Best regards, -Karl (defun org-headings-to-point () "Return all the Org Mode headings leading to point." (when (not (eq major-mode 'org-mode)) (error "ERROR: this only works in Org Mode")) (let ((headings (list (org-heading-components (save-excursion (save-match-data (save-restriction (widen) (while (org-up-heading-safe) (setq headings (cons (org-heading-components) headings) headings))) (defun org-display-headings-to-point () "Display Org Mode heading titles from level 1 to current subtree. Display each title on its own line, indented proportionally to its level." (interactive) (let* ((heading-titles (mapcar (lambda (heading) (nth 4 heading)) (org-headings-to-point))) (level 0) (hierarchy (mapcar (lambda (title) (prog1 (if (zerop level) (concat "• " title) (concat "\n" (make-string (* level 2) ? ) "→ " title)) (setq level (1+ level heading-titles))) (display-message-or-buffer (string-join hierarchy
Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.
On 02 Dec 2019, Marco Wahl wrote: >Karl Fogel writes: >> Since `widen' itself is already available via C-x n w, it might be >> better to save a special flag value like that for some special >> behavior that we (or someone else) might think of in the future. I'm >> pretty sure that anyone using `org-narrow-to-subtree' must also know >> about the `widen' command, too. > >Okay, this sounds sound. > >Let me be a bit more explicit about my wish: I vote for the prefix arg 0 >to widen because this fits to the logic to view the whole file as level >0 subtree. With this perspective on the feature the effect of a numeric >prefix argument is clear as day: > >... >C-u 2 M-x org-narrow... => Narrow to the level-2 subtree containing point. >C-u 1 M-x org-narrow... => Narrow to the level-1 subtree containing point. >C-u 0 M-x org-narrow... => Narrow to the level-0 subtree containing point. > >The last line stands in opposition to the current behavior. > >C-u 0 M-x org-narrow... => Narrow to the level-1 subtree containing point. >^ ^ Oh, yes, I get the logic, from a consistency standpoint. My only concern is that a) it's unnecessary, because `widen' is available, and b) some day we might think of a better special meaning for C-u 0 (and in the meantime it could error instead of narrowing to the current level-1 subtree). But I don't feel strongly about it either way. Perhaps consistency is desirable here, although I tend to think that consistency is overrated in UI/UX in general -- the famous example of "`transpose-chars' at the end of a line" comes to mind. Hmm, but on the other hand, your proposed consistency *would* be good if anyone's ever calling `org-narrow-to-subtree' from Lisp with an algorithmically calculated STEPS argument. I can't imagine what kind of circumstance that would be, but if it's a general principle of Org Mode to consider "level 0" to be the entire buffer, then we should probably go with your proposed behavior. So I guess I'm tentatively +1... Does anyone else have any thoughts on this? Best regards, -Karl
Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.
On 02 Dec 2019, Marco Wahl wrote: >What about numeric prefix arg 0 to reveal the whole buffer (aka >'widen')? I think this would be a logical completion to the feature. Since `widen' itself is already available via C-x n w, it might be better to save a special flag value like that for some special behavior that we (or someone else) might think of in the future. I'm pretty sure that anyone using `org-narrow-to-subtree' must also know about the `widen' command, too. Thoughts? Best regards, -Karl
Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.
On 01 Dec 2019, Marco Wahl wrote: >I guess it's a good idea to write to Bastien explicitly. I will do so. >Thanks for asking about the version. AFAICT there is a feature freeze >right now for version 9.3. This means you would commit to the 'next' >branch which shall be the next master branch after the release. And >also you would add the news entry in section [Version Next] in >etc/ORG-NEWS. Ah, okay. Thanks for letting me know; I'll do all that. Best regards, -Karl
Re: [PATCH] Use prefix arg to control scope of org-narrow-to-subtree.
On 01 Dec 2019, Marco Wahl wrote: >+1 > >I think your enhancement is great and worth a news entry. What about >pushing your code if nobody objects within one week? Thanks, Marco; I'm glad you like it. I'll wait a week and then push (unless there's discussion, in which case we'll see what the outcome of the discussion is first, of course). I just created a "kfogel" account at https://code.orgmode.org/ and uploaded my SSH key. Should I mail Bastien about push access, or is posting here enough? Regarding a news entry: that means the 9.3 section of etc/ORG-NEWS, right? I will add a news entry to the commit at push time. Best regards, -Karl
[PATCH] Use prefix arg to control scope of org-narrow-to-subtree.
This is the enhancement to `org-narrow-to-subtree' that I suggested back in May [1]. It allows you to choose what level subtree to narrow to. There are two ways to specify the subtree: use repeated C-u's to select "upward" from the current subtree, or use a direct numeric prefix arg to specify the subtree "downward" from level 1. (This is a somewhat unusual prefix argument usage, but it's useful to be able to choose from either direction, and the convenience of using C-u to select upward is quite enormous -- I expect it to be the common case, and it's pretty much the only way I use the feature.) The prefix arg is optional, of course: if you don't pass it, then `org-narrow-to-subtree' behaves the same way it has always behaved. Best regards, -Karl [1] https://lists.gnu.org/archive/html/emacs-orgmode/2019-05/msg00225.html >From bbeca3c5444646685085c134b10f4883812068a0 Mon Sep 17 00:00:00 2001 From: Karl Fogel Date: Sat, 30 Nov 2019 01:33:15 -0600 Subject: [PATCH] Use prefix arg to narrow to a specific subtree * lisp/org.el (org-narrow-to-subtree): Take a prefix arg and use it to choose which subtree to narrow to. See thread for context: https://lists.gnu.org/archive/html/emacs-orgmode/2019-05/msg00225.html From: Karl Fogel To: Org Mode Subject: Re: [PROPOSAL] Use prefix arg to control scope \ of org-narrow-to-subtree. Date: Fri, 31 May 2019 02:33:03 -0500 Message-ID: <87y32ncc40@red-bean.com> --- lisp/org.el | 41 ++--- 1 file changed, 38 insertions(+), 3 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 90f222c8b..9b16c59e6 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -7743,11 +7743,46 @@ If yes, remember the marker and the distance to BEG." (move-marker (car x) (+ beg (cdr x (setq org-markers-to-move nil)) -(defun org-narrow-to-subtree () - "Narrow buffer to the current subtree." - (interactive) +(defun org-narrow-to-subtree ( steps) + "Narrow buffer to current subtree or to one specified by prefix arg STEPS. + +Interactively, use the prefix argument in one of two ways to +narrow to a specific subtree: either give one or more C-u's to +specify a subtree that many levels upward from the current +subtree (that is, go up as many levels as the number of C-u's +given -- each C-u counts for one level), or give a strictly +numeric argument to narrow to the subtree that is that many +levels downward from the current top level (level 1) subtree. + +From Lisp, if you want the C-u (upward) behavior, pass STEPS as a +list with the desired number as its sole element. Otherwise, +pass STEPS as a number to get the other (downward) behavior. + +If STEPS would specify a subtree higher than the current level 1 +subtree, then just narrow to that level 1 subtree (in other +words, you can use \"a lot of\" C-u's to narrow quickly to the +current top subtree). If STEPS would specify a subtree deeper +than the current subtree, just narrow to the current subtree." + (interactive "P") (save-excursion (save-match-data + (widen) + (if steps + (if (listp steps) + (progn + (setq steps (car steps)) + (when (< steps 0) + (error "Argument cannot be negative")) + (setq steps (round (log steps 4 + (when (< steps 0) ; awkward duplication, but hard to avoid + (error "Argument cannot be negative")) + (let ((cur-level (org-outline-level))) + (setq steps (max (- cur-level steps) 0 + (setq steps 0)) + (while (> steps 0) + (if (org-up-heading-safe) + (setq steps (1- steps)) + (setq steps 0))) (org-with-limited-levels (narrow-to-region (progn (org-back-to-heading t) (point)) -- 2.24.0
orgformat.py: util library for generating Org mode from Python
Hi, In the recent days, I've been busy migrating orgformat[1] from Memacs[2] and lazyblorg[3] to a repository on its own. It's a utility library that provides a variety of Python functions that help dealing with generating non-trivial Org mode content such as date- or time-stamps. I've added good documentation, valuable unit tests to all functions and even added type annotations to the library itself (playing around with mypy[4] which I recommend). You may find some of the functions interesting for your project and I'm happy to receive pull requests of functions that you'll move out from your project to this general purpose Org mode library as well. Find the (horrible coloured) HTML docu at [5]. HTH [1] https://github.com/novoid/orgformat [2] https://github.com/novoid/Memacs [3] https://github.com/novoid/lazyblorg [4] https://mypy.readthedocs.io/en/latest/introduction.html [5] http://htmlpreview.github.io/?https://github.com/novoid/orgformat/blob/master/orgformat.html -- get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode: > get Memacs from https://github.com/novoid/Memacs < Personal Information Management > http://Karl-Voit.at/tags/pim/ Emacs-related > http://Karl-Voit.at/tags/emacs/
