(Feature to Potentially Upstream) extending org-plot.el: some work done, more to go
Good news! This is the last of my "things I want to contact the mailing list about" backlog 😛 So, I recently wanted to be able to create a radar chart in org, using #+PLOT without a 500 character #+PLOT line. I started with advice-override, but quickly realised it would be better just to switch out org-plot.el with a modified version, which can be found here: https://github.com/tecosaur/emacs-config/blob/master/lisp/org-plot.el As this currently stands, with the below table and plot line I can produce this plot https://media.githubusercontent.com/media/tecosaur/emacs-config/master/misc/document-format-comparison.png. (https://media.githubusercontent.com/media/tecosaur/emacs-config/master/misc/document-format-comparison.png) #+PLOT: transpose:yes type:radar min:0 max:4 file:"misc/document-format-comparison.png" | Format | Fine-grained-control | Initial Effort | Syntax simplicity | Editor Support | Integrations | Ease-of-referencing | Versatility | |---+--++---++--+-+-| | Word | 2 | 4 | 4 | 2 | 3 | 2 | 2 | | LaTeX | 4 | 1 | 1 | 3 | 2 | 4 | 3 | | Org Mode | 4 | 2 | 3.5 | 1 | 4 | 4 | 4 | | Markdown | 1 | 3 | 3 | 4 | 3 | 3 | 1 | | Markdown + Pandoc | 2.5 | 2.5 | 2.5 | 3 | 3 | 3 | 2 | The colours are a doom-specific bit, because I draw them from the current doom theme. I figure this could just be replaced with a general purpose entry point into the plot generation script where the user can add a 'custom preamble' function. I'm also interested in refactoring the type:XXX bit so that it's more general, less hardcoded. I don't know what may be involved, but I'm thinking something similar to org export when you can define a new export function could be nice (hough I imagine that example is far more complicated than this would be). I'm hoping that someone may be interested enough to provide feedback, and idealy help me extend org-plot in this manner, with the goal of having this functionality upstreamed (assuming interest in doing so). Please let me know! All the best, Timothy (p.s. as mentioned in my first email, I am going to try getting dragged down this rabbit-hole again till late june)
(Feature Request) customise LaTeX-preview regex
Another email, another request 😀
Hoping that you aren't tired of me yet, I have … (drum-roll) another feature
request!
This time, I'm wanting to be able to use the lovely org latex preview
functionality for more than just the default blocks.
For instance, I'm interested in applying it to mhchem \ce{ … } fragments, as
well as siunitx \SI{ … }{ … }.
I thought modifying org-latex-regexps may do the trick, yet despite trying a
few different things, I was confused when unable to get it to work. It looks
like I'm being confounded by the fact that org-format-latex doesn't even
reference org-latex-regexps, and instead uses it's own hard-coded regexps.
Hopefully it may be possible to tweak this so that once can preview more than
just the defaults hardcoded into org-format-latex.
Warm regards,
Timothy
(Feature Request) add more entry points to configure some export functionality
It's me again! We're now onto email 2/4. This one is a wish-list of entry points for customising export functionality (well, styling). I'm a big fan of trying to make my documents look snazzy with minimal work (i.e. by cramming all the snazzyness in the back-end), which is why I was thrilled to be able to make use of customisations like org-html-checkbox-types (see https://tecosaur.github.io/emacs-config/config.html#change-checkbox-type for my use of it). However, there are a two areas where I am really interested in seeing similar customisations, ideally without the need to advice-override org functions. In the hope that these may be developed, I'll detail them below. LaTeX Export: Checkboxes - I also want to be able to tweak the checkboxes here. HTML Export: Headers - I'd quite like to customise the generation of headers This is with the aim of adding the rather nice github-style 🔗 to easily copy a link to that position to the clipboard. From memory modifying this would require overriding a large function, which I didn't like the look of. Best wishes, Timothy
(Feature Request) have org-edit-special work inside non-environment LaTeX blocks, i.e. \( \) and \[ \]
Hello All! I love the first-class LaTeX support in Org-mode, and discovering that org-edit-special worked inside LaTeX environments was a joyous moment for me. Shortly after that though, I was disappoint to discover that this didn't work with inline LaTeX equations \( … \) or LaTeX display equations \[ … \]. If it would be possible to account for this form of LaTeX too, that would be marvellous! A brief note on me Hola! Love the work that's gone on here, so first of all: thanks to all those who have helped make Org-mode so great 💖. I'm a new-ish Emacs user (~5 months old) currently using Doom (which I'm finding very comfortable), and my only regret is not getting into this all earlier 😛 First email to this mailing list, so please let me know if I'm not quite following protocol or anything like that. Otherwise, this is the first of a few emails that I've been meaning to send off for a while now. I'm also a uni student a few weeks off from exams so I am not able to really need to resist the urge to jump in and work on implementing these ideas. I should have significantly more time late june though :) All the best, Timothy
Re: [PATCH] agenda: Consider FILETAGS for archive skipping
George Sokolsky writes: > I had to apply it manually on the latest org-20200518 (line numbers > changed in this new version or me too lame) - the patch seem to fix the > below problem and works just fine! The patch was against the master branch (specifically 9bc0cc7fb), not the maint branch which is the source of the ELPA archive. > IMHO using "#+FILETAGS: ARCHIVE" is one of legitimate ways of applying > ARCHIVE tag to items in org. I think this statement is a reply to me saying that "I'd guess that it's uncommon to try to set the ARCHIVE tag at the file level [because...]". To be clear, that didn't contain a claim one way or the other about whether "#+FILETAGS: ARCHIVE" is a legitimate way to apply an archive tag. But based on me taking the time to look into a code change, it probably doesn't surprise you that my first thought was "hmph, yeah, seems like that _should_ work". George Sokolsky later writes: > Kyle, could you please apply the patch to the org repository? I sent out the patch so that others have the opportunity to provide feedback on it as well as your initial message. If no one does (which is fine), at some point in the next few days I'll revisit the patch, maybe inspect the surrounding code a bit more, and apply it (assuming I don't end up convincing myself that it's a bad idea or needs more work).
ISSUE: org publish document processor silently inserts licensed content into targets by default
ISSUE: An author should expect a compiler to avoid claiming authorship
over target code, however, currently the org-mode publish document
processor silently inserts licensed content into target documents by
default.
SOLUTION: The following script is a drop-in-replacement which provides
the same API as the original, without a license. It also opts not to
highlight code links, but only their targets, which seems less
distracting (it is a simple change to keep the original behavior if
preferred).
The public domain version works in a different way than the original,
fixing a potential bug. It adds(removes) highlighting rather than
replacing the original format. Ignoring the boilerplate, the new script is:
target.classList.add("code-highlighted")
The add method is idempotent. In contrast, the old version caches(restores):
elem.cacheClassTarget = target.className;
target.className = "code-highlighted";
Note that the cached value would be lost if this was called twice in
succession.
I've added the comment, "any content added to the source document by the
document processor, including this script, is in the public domain".
This statement may seem superfluous, since an author should expect the
compiler to avoid claiming authorship over target code anyway. I've only
added it in contrast with the original claim.
Assuming the org-mode authors agree with the goal of publish acting as
pure compiler, and if it seems more appropriate not to pass the notice
through to the target html, then feel free to remove this notice from
the org-html-scripts definition, perhaps retaining it above the
definition as an as an elisp comment and/or as a note in the documentation.
One last note: users can attempt to fix this issue by disabling
:html-head-include-scripts, but doing so will provoke an error when a
reader's browser attempts to highlight links to source code literal
lines, so it is probably better to patch the script.
Anyway here is my patch, you can adapt it to your emacs init, or call it
from the command line as "emacs --batch -l publish".
I declare that this patch is in the public domain.
Enjoy.
;;; publish.el --- publish project with org publish -*- lexical-binding:
t; -*-
;; To use this from the shell:
;;
;; emacs --batch -l publish
(require 'org)
(require 'ox-publish)
(defconst public-domain-scripts
"
/* Any content added to the source document by the document
processor, including this script, are in the public domain */
function CodeHighlightOn(elem, id)
{
const target = document.getElementById(id);
if(null != target) {
target.classList.add(\"code-highlighted\");
}
}
function CodeHighlightOff(elem, id)
{
const target = document.getElementById(id);
if(null != target) {
target.classList.remove(\"code-highlighted\");
}
}
")
;; patch globally:
(setq org-html-scripts public-domain-scripts)
(org-publish-all)
;; or patch locally:
;;
;; (let ((org-html-scripts public-domain-scripts)) (org-publish-all))
--
Anthony Carrico
Re: `#+author:' stopped setting the author to empty string
Kaushal Modi writes: > At some point in the past month or so, I have noticed that on Org master, > #+author: does not set the author to empty in the exports. > > Simply example to reproduce: Thanks for the minimal example. > I looked through the commits on master in the past month, but I don't see > any author-specific change that would affect *all* the exporter backends. It bisects to b4e91b7e9 (New function: org-collect-keywords, 2020-04-26). I haven't done much digging, but I was able to restore the behavior with the change below, which may be a bad idea for other reasons. diff --git a/lisp/org.el b/lisp/org.el index 0e1e05239..a8db4c2bf 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -4501,7 +4501,6 @@ (defun org--collect-keywords-1 (keywords uniques files alist) (push (cons key value) alist) (setq keywords (remove key keywords)) (setq regexp (org-make-options-regexp keywords))) -((not (org-string-nw-p value)) nil) ((null entry) (push (list key value) alist)) (t (push value (cdr entry))) alist)))
Re: issue tracker?
Doesn’t Gogs have a nice issue tracker functionality? -- James Miller james.ryland.mil...@gmail.com
Re: issue tracker?
Anthony Carrico writes: > Does org-mode have an issue tracker, to keep track of which issues are > active, or is it just this mailing list? Just this mailing list. -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
issue tracker?
Does org-mode have an issue tracker, to keep track of which issues are active, or is it just this mailing list? -- Anthony Carrico
Re: Org-list: Add back fancy description list indentation
This just might be the functionality that makes me learn elisp. :) -- James Miller james.ryland.mil...@gmail.com
Re: Bug: Asterisk inside example is incorrectly parsed [9.3 (release_9.3 @ /usr/share/emacs/27.0.91/lisp/org/)]
You need to quote the asterisk with a comma: #+begin_example ,* I am not supposed to be a section #+end_example See (info "(Org) Literal Examples") -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: issue in orgmode manual
John Hendy writes: > I ran into this as well and did not see a response back from the list > yet. Emailed about just this issue last week. > > https://www.mail-archive.com/emacs-orgmode@gnu.org/msg127933.html > > John > > > On Sat, May 16, 2020 at 10:21 AM Max Mustermann > wrote: >> >> Hey, >> On https://orgmode.org/manual/LaTeX-Export.html#Tables-in-LaTeX-export, >> 13.10.5 -13.10.11 refer back to its parent 13.10 >> same with 13.9.6-13.9.11 and probably others. >> >> Sorry if this is already known or intended. >> >> Have a nice weekend. > > Yes, it has been reported a couple more times, but nothing has been done about it. My hunch is that Bastien takes care of orgmode.org, but with the current Covid-19 crisis, he is extremely busy and he may not be reading the list at all. -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
> As you noticed, using Org Element is a no-go, unfortunately. Parsing an > element is a O(N) operation by the number of elements before it in > a section. In particular, it is not bounded, and not mitigated by > a cache. For large documents, it is going to be unbearably slow, too. Ouch. I thought it is faster. What do you mean by "not mitigated by a cache"? The reason I would like to utilise org-element parser to make tracking modifications more robust. Using details of the syntax would make the code fragile if any modifications are made to syntax in future. Debugging bugs in modification functions is not easy, according to my experience. One possible way to avoid performance issues during modification is running parser in advance. For example, folding an element may as well add information about the element to its text properties. This will not degrade performance of folding since we are already parsing the element during folding (at least, in org-hide-drawer-toggle). The problem with parsing an element during folding is that we cannot easily detect changes like below without re-parsing. :PROPERTIES: :CREATED: [2020-05-18 Mon] :END: <- added line :ID: test :END: or even :PROPERTIES: :CREATED: [2020-05-18 Mon] :ID: test :END: <- delete this line :DRAWER: test :END: The re-parsing can be done via regexp, as you suggested, but I don't like this idea, because it will end up re-implementing org-element-*-parser. Would it be acceptable to run org-element-*-parser in after-change-functions? > If you use modification-hooks and al., you don't need to parse anything, > because you can store information as text properties. Therefore, once > the modification happens, you already know where you are (or, at least > where you were before the change). > The ideas I suggested about sensitive parts of elements are worth > exploring, IMO. Do you have any issue with them? If I understand correctly, it is not as easy. Consider the following example: :PROPERTIES: :CREATED: [2020-05-18 Mon] :ID: example :END: <... a lot of text, maybe containing other drawers ...> Nullam rutrum. Pellentesque dapibus suscipit ligula. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus. If the region gets deleted, the modification hooks from chars inside drawer will be called as (hook-function ). So, there is still a need to find the drawer somehow to mark it as about to be modified (modification hooks are ran before actual modification). The only difference between using modification hooks and before-change-functions is that modification hooks will trigger less frequently. Considering the performance of org-element-at-point, it is probably worth doing. Initially, I wanted to avoid it because setting a single before-change-functions hook sounded cleaner than setting modification-hooks, insert-behind-hooks, and insert-in-front-hooks. Moreover, these text properties would be copied by default if one uses buffer-substring. Then, the hooks will also trigger later in the yanked text, which may cause all kinds of bugs. > `org-element-at-point' is local, `org-element-parse-buffer' is global. > They are not equivalent, but is it an issue? It was mostly an annoyance, because they returned different results on the same element. Specifically, they returned different :post-blank and :end properties, which does not sound right. Best, Ihor Nicolas Goaziou writes: > Hello, > > Ihor Radchenko writes: > >> Apparently my previous email was again refused by your mail server (I >> tried to add patch as attachment this time). > > Ah. This is annoying, for you and for me. > >> The patch is in >> https://gist.github.com/yantar92/6447754415457927293acda43a7fcaef > > Thank you. > >>> I have finished a seemingly stable implementation of handling changes >>> inside drawer and block elements. For now, I did not bother with >>> 'modification-hooks and 'insert-in-font/behind-hooks, but simply used >>> before/after-change-functions. >>> >>> The basic idea is saving parsed org-elements before the modification >>> (with :begin and :end replaced by markers) and comparing them with the >>> versions of the same elements after the modification. >>> Any valid org element can be examined in such way by an arbitrary >>> function (see org-track-modification-elements) [1]. > > As you noticed, using Org Element is a no-go, unfortunately. Parsing an > element is a O(N) operation by the number of elements before it in > a section. In particular, it is not bounded, and not mitigated by > a cache. For large documents, it is going to be unbearably slow, too. > > I don't think the solution is to use combine-after-change-calls either, > because even a single call to `org-element-at-point' can be noticeable > in a very large section. Such low-level code should avoid using the > Element library altogether, except for the initial folding part, which > is interactive. > > If you use modification-hooks and al., you don't need to parse anything, > becaus
Re: issue in orgmode manual
I ran into this as well and did not see a response back from the list yet. Emailed about just this issue last week. https://www.mail-archive.com/emacs-orgmode@gnu.org/msg127933.html John On Sat, May 16, 2020 at 10:21 AM Max Mustermann wrote: > > Hey, > On https://orgmode.org/manual/LaTeX-Export.html#Tables-in-LaTeX-export, > 13.10.5 -13.10.11 refer back to its parent 13.10 > same with 13.9.6-13.9.11 and probably others. > > Sorry if this is already known or intended. > > Have a nice weekend.
Re: Org-list: Add back fancy description list indentation
"James R Miller" writes: > It just seems like a regression to me instead of a fix. Functionality > was removed instead of fixed. I am not sure about how helpful your message is. I am not opposed to the fancy indentation you want: if you want to fix it properly, you can give it a go. The code didn't disappear, it is still in a commit. Meanwhile, this broken part of indentation is "disabled". Regards,
Re: Bug: built-in macros not working anymore [9.3.6 (9.3.6-23-g01ee25-elpaplus @ c:/Users/mda/.emacs.d/elpa/org-plus-contrib-20200309/)]
Hello, "Dauer, Michael" writes: > According to my tests this is not fixed. Same use case as originally > reported still fails: Undefined Org macro: author; aborting > > I also use #OPTIONS: author:nil, which is necessary to prevent that the > export is concluded by an author line. > > Would you please verify the fix. Maybe I did something wrong by checking > out commit 965cdbfd4b3316cc9044854b0e5eb5cf69927ce6 I cannot reproduce the problem using master branch. Regards, -- Nicolas Goaziou
Re: "\_" sequences in indented lines of column view dynamic blocks
Hello, "Dauer, Michael" writes: > Why would the following break the export? I never said the following would break export. I said your initial proposal would, i.e. using ".". You changed it meanwhile. > #+BEGIN: columnview :indent t :id local > | ITEM| a | > |-+---| > | column view | 7 | > | ··item1 | 3 | > | item1.1 | 3 | > | ··item2 | 4 | > #+END > > U+2063 would be invisible. And the ASCII export could just substitute it > with Blank. As a rule of thumb, Org doesn't use non-ASCII characters for its syntax. This would break this rule. Regards, -- Nicolas Goaziou
Re: "\_" sequences in indented lines of column view dynamic blocks
Why would the following break the export? #+BEGIN: columnview :indent t :id local | ITEM| a | |-+---| | column view | 7 | | ··item1 | 3 | | item1.1 | 3 | | ··item2 | 4 | #+END U+2063 would be invisible. And the ASCII export could just substitute it with Blank. Am Mo., 11. Mai 2020 um 19:55 Uhr schrieb Nicolas Goaziou < m...@nicolasgoaziou.fr>: > Hello, > > "Dauer, Michael" writes: > > > It would be nice to have to have an option to just use other indentation > > characters like "." for ASCII or special blanks for other encoding. > > Do you mean in the Org document? That would break export. > > > And what about the second question? I'm looking for something like a > > minlevel argument. > > I didn't answer it, so I probably do not have a clue :) > > Regards, > > -- > Nicolas Goaziou >
Re: Bug: built-in macros not working anymore [9.3.6 (9.3.6-23-g01ee25-elpaplus @ c:/Users/mda/.emacs.d/elpa/org-plus-contrib-20200309/)]
According to my tests this is not fixed. Same use case as originally
reported still fails: Undefined Org macro: author; aborting
I also use #OPTIONS: author:nil, which is necessary to prevent that the
export is concluded by an author line.
Would you please verify the fix. Maybe I did something wrong by checking
out commit 965cdbfd4b3316cc9044854b0e5eb5cf69927ce6
thx
Am Mi., 11. März 2020 um 16:23 Uhr schrieb Nicolas Goaziou <
m...@nicolasgoaziou.fr>:
> Hello,
>
> "Dauer, Michael" writes:
>
> > worked at least with 9.1.x, but not anymore
> >
> > * test
> > dfgfas
> > {{{author}}}
> > dasfas
>
> Fixed. Thank you.
>
> Regards,
>
> --
> Nicolas Goaziou
>
Re: [patch suggestion] Mitigating the poor Emacs performance on huge org files: Do not use overlays for PROPERTY and LOGBOOK drawers
Hello, Ihor Radchenko writes: > Apparently my previous email was again refused by your mail server (I > tried to add patch as attachment this time). Ah. This is annoying, for you and for me. > The patch is in > https://gist.github.com/yantar92/6447754415457927293acda43a7fcaef Thank you. >> I have finished a seemingly stable implementation of handling changes >> inside drawer and block elements. For now, I did not bother with >> 'modification-hooks and 'insert-in-font/behind-hooks, but simply used >> before/after-change-functions. >> >> The basic idea is saving parsed org-elements before the modification >> (with :begin and :end replaced by markers) and comparing them with the >> versions of the same elements after the modification. >> Any valid org element can be examined in such way by an arbitrary >> function (see org-track-modification-elements) [1]. As you noticed, using Org Element is a no-go, unfortunately. Parsing an element is a O(N) operation by the number of elements before it in a section. In particular, it is not bounded, and not mitigated by a cache. For large documents, it is going to be unbearably slow, too. I don't think the solution is to use combine-after-change-calls either, because even a single call to `org-element-at-point' can be noticeable in a very large section. Such low-level code should avoid using the Element library altogether, except for the initial folding part, which is interactive. If you use modification-hooks and al., you don't need to parse anything, because you can store information as text properties. Therefore, once the modification happens, you already know where you are (or, at least where you were before the change). The ideas I suggested about sensitive parts of elements are worth exploring, IMO. Do you have any issue with them? >> For (2), I have introduced org--property-drawer-modified-re to override >> org-property-drawer-re in relevant *-change-function. This seems to work >> for property drawers. However, I am not sure if similar problem may >> happen in some border cases with ordinary drawers or blocks. I already specified what parts were "sensitive" in a previous message. >> 2. I have noticed that results of org-element-at-point and >> org-element-parse-buffer are not always consistent. `org-element-at-point' is local, `org-element-parse-buffer' is global. They are not equivalent, but is it an issue? Regards, -- Nicolas Goaziou
Re: `#+author:' stopped setting the author to empty string
Am 18.05.20 um 15:57 schrieb Kaushal Modi: > I looked through the commits on master in the past month, but I don't > see any author-specific change that would affect *all* the exporter > backends. > > Can anyone else reproduce this issue? Same observation here (org master from about a week ago, GNU emacs 26.3, ubuntu 18.4) I solved the problem by using #+author: \nbsp and forgot to report. Julius
Re: Org-list: Add back fancy description list indentation
It just seems like a regression to me instead of a fix. Functionality was removed instead of fixed. -- James Miller james.ryland.mil...@gmail.com
`#+author:' stopped setting the author to empty string
Hello, At some point in the past month or so, I have noticed that on Org master, #+author: does not set the author to empty in the exports. Simply example to reproduce: = #+author: Test = Run C-c C-e t A Expected output: = Table of Contents _ Test = Observed output: = Table of Contents _ Test = I looked through the commits on master in the past month, but I don't see any author-specific change that would affect *all* the exporter backends. Can anyone else reproduce this issue? -- Kaushal Modi
Re: Status of syntax specification
Hello, "Gerry Agbobada" writes: > I found on Worg a "draft" for org syntax description : > https://orgmode.org/worg/dev/org-syntax.html > > Do you think this paper marked as draft is good enough to use as > a source to make a parser ? It is "good enough", but possibly slightly inaccurate at some points. It would need proof reading, and comparing with "org-element.el", the actual implementation of the syntax. Formalization may be better better, too. > I think it'd be nice to try to finalize this ; but I don't know who to > contact to see how I can help > if I know almost nothing about standards and technical writing. Reading it and comparing with documentation might help. Regards, -- Nicolas Goaziou
Re: [Solved]: Bug: org-encrypt-entry fails [9.4 (nil @ /home/silipwn/.emacs.d/.local/straight/build/org-mode/)]
Hello, silipwn writes: > On removing the variable, it works fine. The GPG configuration directly > takes my mail address to get the key. The other issue was I also had > a revoked key with the same email, that > might have been causing an error, mentioned in the earlier mail. While trying to understand where the (setq org-crypt-key nil) from your config was coming from, I noticed the manual suggested to do so! I fixed this discrepancy between the manual and the implementation (aka a bug). You can now set again org-crypt-key to nil. The difference between "" and nil is the latter also ignores `epa-file-encrypt-to' if this happens to be set in the document. Regards, -- Nicolas Goaziou
Re: [PATCH] agenda: Consider FILETAGS for archive skipping
Kyle, could you please apply the patch to the org repository? Thank you George Bastien writes: > Hi George, > > George Sokolsky writes: > >> For avoidance of doubt - this is Kyle's patch, not mine (thank you >> Kyle!) > > Sorry for the confusion, I thought you were asking for permission to > commit the patch directly yourself. Kyle can of course apply it when > he wants. > >> Bastien, do you mean that this patch will be in the next weekly org >> build on melpa? > > If the patch gets applied soon, it will be available on the Org ELPA > package. I don't know about MELPA. > > Best,
Re: [PATCH] agenda: Consider FILETAGS for archive skipping
Hi George, George Sokolsky writes: > For avoidance of doubt - this is Kyle's patch, not mine (thank you > Kyle!) Sorry for the confusion, I thought you were asking for permission to commit the patch directly yourself. Kyle can of course apply it when he wants. > Bastien, do you mean that this patch will be in the next weekly org > build on melpa? If the patch gets applied soon, it will be available on the Org ELPA package. I don't know about MELPA. Best, -- Bastien
Capture Template Diary Entry: file+datetree+prompt use the prompted timestamp including the time when time is specified
Dear members of the org-mode mailing list,
a week ago I spent some time to set up a capture template to
directly write appointments to my calendar file (i.e. to write
diary entries). It looks as follows:
("d" "Diary entry" entry (file+datetree+prompt
"~/MPIK-Nextcloud/emacs/.org/kalender.org")
"* %i%?\n %T")
And it works as expected: When calling the capture template, I am prompted for a
date and I can also type a time, and on saving everything is stored at the
correct location in the datetree. Perfect. But in case I do not enter a time,
00:00 is inserted. This is unfortunate. Okay, I can replace "%T" in the template
with "%t", but then any specification of time is ignored.
Instead, I would love to mimic the behaviour of the function "org-time-stamp".
Calling it
prompts for a date, and if I do not specify a time, only the date is inserted.
In case I specify a time or a range (i.e. 10:00-12:00) the timestamp is
supplemented with this additional information.
The use-case is the following: Some of my appointments last a whole day, and
others start at a specified time and some of them last e.g. only two hours. To
capture all these cases, I would need a template expansion inserting the
timestamp as I entered it when prompted, i.e. if a specify a time, it includes
it and if not it does not. Of course, this should also be true for e.g.
(10:00-12:00).
I tried a lot to get the desired behaviour by testing variants of the following
combination of org-mode functions and variables.
%(org-insert-time-stamp (org-read-date nil t org-read-date-final-answer) t)
I was not able to produce what I wanted.
Does anyone have a workaround or an idea how I could implement the described and
wished behaviour? Thanks.
With best regards,
Nils
Re: [PATCH] agenda: Consider FILETAGS for archive skipping
For avoidance of doubt - this is Kyle's patch, not mine (thank you Kyle!) Bastien, do you mean that this patch will be in the next weekly org build on melpa? Thank you George Bastien writes: > Hi George, > > thanks for your patch! > > George Sokolsky writes: > >> I'm trying to add Bastien into recepients of this e-mail - or could >> anyone please help with commiting the below code into the org >> repository? > > Anyone with write access to the repository can apply it. > > If you plan to make regular contributions and do not need your patches > to be reviewed on the list anymore, we can grant you write access, but > there is no such need for occasional patches. > > Cheers,
Re: [PATCH] agenda: Consider FILETAGS for archive skipping
Hi George, thanks for your patch! George Sokolsky writes: > I'm trying to add Bastien into recepients of this e-mail - or could > anyone please help with commiting the below code into the org > repository? Anyone with write access to the repository can apply it. If you plan to make regular contributions and do not need your patches to be reviewed on the list anymore, we can grant you write access, but there is no such need for occasional patches. Cheers, -- Bastien
Re: [PATCH] agenda: Consider FILETAGS for archive skipping
Thank you very much Kyle for the patch you provided! I had to apply it manually on the latest org-20200518 (line numbers changed in this new version or me too lame) - the patch seem to fix the below problem and works just fine! IMHO using "#+FILETAGS: ARCHIVE" is one of legitimate ways of applying ARCHIVE tag to items in org. As such I'd love the below patch included into the official org distribution. I'm trying to add Bastien into recepients of this e-mail - or could anyone please help with commiting the below code into the org repository? Thank you, George Kyle Meyer writes: > George Sokolsky writes: > >> I have .org files with "#+FILETAGS: ARCHIVE" headers. >> >> I want items from these .org files to be hidden by default from results >> of "org-agenda" -> "s Search for keywords" by default. >> >> This is not the case, unfortunately. > [...] > > I'd guess that it's uncommon to try to set the ARCHIVE tag at the file > level, as file-level archiving is already dealt through > org-archive-location and friends. These standard files can optionally > be included with vA (or C-u M-x org-agenda-archives-mode). > >> *How the above could be done, please?* > > I don't see a built-in way to do it, though I think the patch below may > be sufficient to provide the behavior you want. It doesn't consider any > of the tag inheritance variables, but that's probably okay given that > those aren't considered for handling :ARCHIVE: subtrees either. > > -- >8 -- > Subject: [PATCH] agenda: Consider FILETAGS for archive skipping > > * lisp/org-agenda.el (org-agenda-skip): Consider skipping all entries > in a file if org-archive-tag is set via FILETAGS. > --- > lisp/org-agenda.el | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el > index 9c73d0d6c..8ed5e402d 100644 > --- a/lisp/org-agenda.el > +++ b/lisp/org-agenda.el > @@ -4082,8 +4082,10 @@ (defun org-agenda-skip () > (when (or > (save-excursion (goto-char p) (looking-at comment-start-skip)) > (and org-agenda-skip-archived-trees (not org-agenda-archives-mode) > - (get-text-property p :org-archived) > - (org-end-of-subtree t)) > + (or (and (get-text-property p :org-archived) > + (org-end-of-subtree t)) > + (and (member org-archive-tag org-file-tags) > + (goto-char (point-max) > (and org-agenda-skip-comment-trees > (get-text-property p :org-comment) > (org-end-of-subtree t))
Re: org-caldav-sync hanging
Garjola Dindi writes: > On Tue 12-May-2020 at 12:59:22 +02, "Loris Bennett" > wrote: >> Eric S Fraga writes: >> >>> On Tuesday, 12 May 2020 at 09:29, Loris Bennett wrote: The Nextcloud instance at work is version 15 and is accessible via the browser, but there was some outage recently and some server-side tweakage may also have occurred while things were being fixed. >>> >>> I don't know if this is related but a recent point release to nextcloud >>> caused problems with an OPTIONS directive that org-caldav-sync uses. A >>> subsequent bug fix has corrected this but may not have been incorporated >>> in your server yet. >>> >>> See https://github.com/nextcloud/server/issues/20624 >>> >>> The provider I use for calendar services had to manually patch their >>> instance of nextcloud to get it working again for org-caldav-sync. >> >> Thanks for the pointer, but the link seems to refer to a regression >> introduced between versions 18.0.3 and 18.0.4, whereas the server I am >> talking to is some version of version 15. >> >> My android phone is able to sync in both directions via DavX5, so the >> server is obviously not totally borked in terms of syncing. So some >> aspect of the org-caldav-sync seems to be hitting the problem. > > Hi, > > FYI, I found this issue when looking for a solution for the same problem: > https://github.com/dengste/org-caldav/issues/195 > > In my case, if I am patient enough, the sync completes after 30-50 minutes. Turns out there has been server-side borkage for a week now and which currently persists. I assume that when the IT elves responsible get their house back in order, everything will be fine again. Cheers, Loris -- This signature is currently under construction.
Re: Org-list: Add back fancy description list indentation
Hello, "James R Miller" writes: > Was there really not a way to keep fancy description list indentation > instead of removing it entirely? I don't know if there is a way, but the implementation did not work with nested lists. > I have almost a decade of org files > that use description lists, Note that the removal does not break existing documents. > and it really helps have the description > items called out from the description text. The Org manual contains many descriptions lists. For short descriptions, - XXX XXX XXX :: aaa a a For longer descriptions, - X XXX XXX :: Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. It doesn't look so bad, IMO. And it is very stable. > Is there a simple way to add this functionality back in? Perhaps as > some sort of variable like > `org-use-fancy-description-list-indentation` instead of throwing it > out entirely? It's not just about introducing a variable. It is about fixing indentation with description lists containing sub-lists. You can try, if you want to. It may be tricky though: at first glance, the previous implementation worked, but it actually didn't. Regards, -- Nicolas Goaziou
