Re: Bug: Repeating tasks no longer appearing on future dates in the agenda [9.3.6 (9.3.6-17-g389288-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20200224/)]
Hi Gustavo, Gustavo Barros writes: > As of recently, repeating tasks are no longer showing up in the agenda > for future dates. Below a minimal example of the issue: Just confirming this issue, to make sure we don't forget it. -- Bastien
Re: org-store-link and help for a key
> Such behavior exists for ages, at least since 8.2.10 till current master. I can reproduce this. The reason of error is simple: help buffers for key combinations where not considered when writing help: link type. Current code does not even store the link to such help buffers correctly - when the key sequence has more than a single key only the first key will be stored (tested in k k help buffer). The code to open help: link type also does not know that help: link can point to anything other than function or variable. I can see two solutions: 1. Avoid storing links to help buffers describing key sequences. Show error when trying to store such link instead 2. Write proper handlers for storing and following links to help buffers other than just function/variable help (in addition to key sequence help buffers, org-store/follow-link also fails to work with describe-face buffers at least) To do this, one need to change org-link--open-help and org-store-link (see "(eq major-mode 'help-mode)" line). Patches are welcome. P.S. Would it be cleaner to have separate :store link properties for standard link types instead of hard-coding them into org-store-link? Best, Ihor Maxim Nikulin writes: > Either I missed something obvious or org-store-link from a help page for > a keystroke works incorrectly > > Let's try to save a link to the *keystroke* help for e.g. org-insert-link: > > 1. Open help page with =C-h k C-c C-l= > 2. Switch to the help buffer =C-x o= > 3. Store link =M-x org-store-link RET= > 4. Switch back to the org file =C-x o= > 5. Insert link =C-c C-l RET RET= > > I get =[[help:C-c]]= and an error if I try to follow the link with =C-c C-o= > > user-error: Unknown function or variable: C-c > > If I ask a help page for the *function* > > 1b, =C-h f org-insert-link RET= > > I get the working link =[[help:org-inser-link]]=. I expect the similar > result for the keystroke help link or maybe something special that leads > to the description of the current keystroke binding. > > Such behavior exists for ages, at least since 8.2.10 till current master.
Re: Release 9.3.8
Bastien writes: > Kévin Le Gouguec writes: > >> Bastien writes: >> - During the development of 9.4, AFAICT, while the "Version:" comment in org.el sayd "9.4-dev", the org-version variable matched the latest tag, i.e. 9.3.x. I therefore couldn't figure out a way to check for 9.4 programmatically. >>> >>> ... because 9.4 is not yet released - or am I missing something? >> >> See Emacs's master branch for a counter-example: even though 28.1 is not >> out yet, emacs-version says "28.0.50", so one can determine that they're >> running on the master branch. > > Well, yes, but I find that confusing: "I'm using the 28.0.50 version, > which looks like an officially released version, while it's not." Can't you inspect the return value of org-git-version? (Though in my view, distinguishing based on the functionality present with things like fboundp, which you mention below, is typically a better approach, if possible.)
[PATCH] Add %L (the link content *not* as a full link) to Capture expansions
Hello, In an attempt at automating a part of my workflow, I found that org-capture's %l didn't quite fit what I needed. Normally, org-store-link does the right thing, but for some capture tasks, I want to custom generate the description, so %l doesn't work. I've attached a patch that adds %L, a version that doesn't add the link brackets. Thanks, Sam Flint -- Samuel W. Flint 4096R/FA13D704 (F50D 862B 4F65 5943 A8C2 EF0E 86C9 3E7A FA13 D704) diff --git i/lisp/org-capture.el w/lisp/org-capture.el index 2cc1ce394..e638eabfa 100644 --- i/lisp/org-capture.el +++ w/lisp/org-capture.el @@ -308,6 +308,7 @@ be replaced with content and expanded: %a Annotation, normally the link created with `org-store-link'. %A Like %a, but prompt for the description part. %l Like %a, but only insert the literal link. + %L Like %l, but no brackets (the link content itself). %c Current kill ring head. %x Content of the X clipboard. %k Title of currently clocked task. @@ -1574,6 +1575,9 @@ The template may still contain \"%?\" for cursor positioning." (v-l (if (and v-a (string-match l-re v-a)) (replace-match "[[\\1]]" nil nil v-a) v-a)) + (v-L (if (or v-a (string-match l-re v-a)) + (replace-match "\\1" nil nil v-a) + v-a)) (v-n user-full-name) (v-k (if (marker-buffer org-clock-marker) (org-no-properties org-clock-heading) @@ -1626,7 +1630,7 @@ The template may still contain \"%?\" for cursor positioning." ;; Mark %() embedded elisp for later evaluation. (org-capture-expand-embedded-elisp 'mark) ;; Expand non-interactive templates. - (let ((regexp "%\\(:[-A-Za-z]+\\|<\\([^>\n]+\\)>\\|[aAcfFikKlntTuUx]\\)")) + (let ((regexp "%\\(:[-A-Za-z]+\\|<\\([^>\n]+\\)>\\|[aAcfFikKlLntTuUx]\\)")) (save-excursion (while (re-search-forward regexp nil t) ;; `org-capture-escaped-%' may modify buffer and cripple @@ -1663,6 +1667,7 @@ The template may still contain \"%?\" for cursor positioning." (?k v-k) (?K v-K) (?l v-l) + (?L v-L) (?n v-n) (?t v-t) (?T v-T)
Re: idea for capture anywhere in x
as some have mentioned keystrokes, i just wanted to point out htat the
idea here is select with mouse and run using mouse, with no keyboard
at all. firefox org-capture does this for me. in case there was any
confusion.
On 9/9/20, Russell Adams wrote:
> On Mon, Sep 07, 2020 at 10:05:38PM -0700, Samuel Wales wrote:
>> well for a non-emacs application, i want to select text and capture
>> using wm menu.
>
> I routinely capture programming and UNIX history. I select text (X11
> clipboard), and then I have a skel/abbrev to insert it into Emacs. I
> type "pexa" and it creates an example source block and pastes
> the clipboard into it with proper indentation. "pexa" stands for
> "paste example".
>
> This is *so* fast compared to creating a new source block (C-c C-, e),
> then entering it (C-c C-'), pasting (C-y), and then exiting (C-c C-').
>
> ;; Org mode skeletons instead of yasnippet
> (define-skeleton rla-paste-example
> "Insert an Org-mode example source block and paste the clipboard into it."
> nil
> "#+BEGIN_EXAMPLE\n"
> ;; indent to match the src block
> (concat " " (replace-regexp-in-string "\n" "\n "
> (replace-regexp-in-string "\n$" "" (current-kill 0 "\n"
> "#+END_EXAMPLE\n"
> "\n"
> -)
>
> (define-abbrev-table 'org-mode-abbrev-table '(("pexa" "" rla-paste-example
> 0)))
>
> Mind you this is in the current buffer I'm typing in. If I wanted to
> add from the CLI, I'd use a capture template with a predefined
> location and make sure it includes the clipboard in expansion.
>
> As some of the other replies have shown, triggering capture externally
> isn't too hard. You'll just need to figure out the WM hook.
>
> --
> Russell Adamsrlad...@adamsinfoserv.com
>
> PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/
>
> Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
>
>
--
The Kafka Pandemic
Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html
Re: [PATCH] Omit file description when :file-desc has nil value
Kyle Meyer writes: > I also don't find the current behavior particularly intuitive. (I'm > also not really a babel user, so my opinion probably shouldn't count for > much.) If we were adding it today, I think what you describe would be > better, but, as you mention, breakage also now also weighs against > making a change here. > > In any case, I'd suggest raising the discussion on the list after the > 9.4 release. Ok, I'll follow up on this then. >>> Right, to reflect the current behavior established as a result of the >>> above thread, I think that should be reworded to distinguish between an >>> absent :file-desc header and one with no argument. Sorry for not >>> catching that when reviewing your initial patch. >> >> No worries, and I agree the documentation should be updated. I'm happy >> to provide the patch myself, but I'd like to talk through whether the >> current implementation is the correct one before I do. > > Thanks. To avoid any confusion coming from this description making it > into the 9.4 release, I've updated it in 4b2123fb7. Thanks for fixing that Kyle. Matt
Re: [PATCH] babel latex headers and image generation commands
Bastien writes:
> Prefer
>
> * lisp/ob-latex.el (org-babel-latex-preamble): New option for LaTeX
> preamble customization.
>
> "New option" is quite standard, an "option" being a customizable
> variable. In this case, "New option" would probably be enough, given
> the name of the option is quite self-explanatory. Also, some find it
> pedantic, but "LaTeX" is the correct spelling in a changelog I guess.
Fixed in new patch (attached).
> The first line of the docstring should contain a sentence, so you'd
> need to have a new paragraph after "runtime to the LaTeX preamble."
Also fixed. Making the first line a full sentence means that some lines
are a little longer than 80 characters. Is this acceptable?
> What for users who don't have inkscape?
This is just a default, but I could use a dvisvgm command as the default
instead? Either way, converting a PDF to SVG will require an executable
outside Emacs, but I guess dvisvgm is more likely to be installed for
people using a texlive installation. My personal preference for inkscape
is because it should handle all PDF inputs, whereas there are some cases
where dvisvgm may fail (see
https://github.com/mgieseki/dvisvgm/issues/139) due to changes in
ghostscript. Still, dvisvgm generally does a very good job with PDF
inputs. Let me know your thoughts, I'd be happy to set the default to a
dvisvgm command instead.
Matt
>From 1ff86f2267b653dff225837ccf13ebf417f7ed03 Mon Sep 17 00:00:00 2001
From: Matt Huszagh
Date: Fri, 28 Aug 2020 22:26:05 -0700
Subject: [PATCH] ob-latex.el: Make latex to svg compilation very customizable
* lisp/ob-latex.el (org-babel-latex-preamble): New option for LaTeX
preamble customization.
(org-babel-latex-begin-env): New option for LaTeX document environment
begin customization.
(org-babel-latex-end-env): New option for LaTeX document environment
end customization.
(org-babel-latex-pdf-svg-process): New option for converting a pdf to
svg.
(org-babel-execute:latex): Add specific case for svg generation from
LaTeX block.
---
lisp/ob-latex.el | 59 +---
1 file changed, 56 insertions(+), 3 deletions(-)
diff --git a/lisp/ob-latex.el b/lisp/ob-latex.el
index 4b343dd14..6a4f7a6ba 100644
--- a/lisp/ob-latex.el
+++ b/lisp/ob-latex.el
@@ -66,7 +66,46 @@
"LaTeX-specific header arguments.")
(defcustom org-babel-latex-htlatex "htlatex"
- "The htlatex command to enable conversion of latex to SVG or HTML."
+ "The htlatex command to enable conversion of LaTeX to SVG or HTML."
+ :group 'org-babel
+ :type 'string)
+
+(defcustom org-babel-latex-preamble
+ (lambda (_)
+"\\documentclass[preview]{standalone}
+\\def\\pgfsysdriver{pgfsys-tex4ht.def}
+")
+ "Closure which evaluates at runtime to the LaTeX preamble.
+
+It takes 1 argument which is the parameters of the source block."
+ :group 'org-babel
+ :type 'function)
+
+(defcustom org-babel-latex-begin-env
+ (lambda (_)
+"\\begin{document}")
+ "Closure which evaluates at runtime to the begin part of the document environment.
+
+It takes 1 argument which is the parameters of the source block.
+This allows adding additional code that will be ignored when
+exporting the literal LaTeX source."
+ :group 'org-babel
+ :type 'function)
+
+(defcustom org-babel-latex-end-env
+ (lambda (_)
+"\\end{document}")
+ "Closure which evaluates at runtime to the end part of the document environment.
+
+It takes 1 argument which is the parameters of the source block.
+This allows adding additional code that will be ignored when
+exporting the literal LaTeX source."
+ :group 'org-babel
+ :type 'function)
+
+(defcustom org-babel-latex-pdf-svg-process
+ "inkscape --pdf-poppler %f -T -l -o %O"
+ "Command used to convert a PDF file to an SVG file when executing a latex source block."
:group 'org-babel
:type 'string)
@@ -114,12 +153,26 @@ This function is called by `org-babel-execute-src-block'."
(mapconcat #'identity headers "\n"
(org-create-formula-image
body out-file org-format-latex-options in-buffer)))
+ ((string= "svg" extension)
+ (with-temp-file tex-file
+ (insert (concat (funcall org-babel-latex-preamble params)
+ (mapconcat #'identity headers "\n")
+ (funcall org-babel-latex-begin-env params)
+ body
+ (funcall org-babel-latex-end-env params
+ (let ((tmp-pdf (org-babel-latex-tex-to-pdf tex-file)))
+ (let* ((log-buf (get-buffer-create "*Org Babel LaTeX Output*"))
+ (err-msg "org babel latex failed")
+ (img-out (org-compile-file
+ tmp-pdf
+ (list org-babel-latex-pdf-svg-process)
+ extension err-msg log-buf)))
+(shell-command (format "mv %s %s" img-out out-file)
((string-suffix-p ".tikz" out-file)
(when (file-exists-p out-file) (delete-file out-file))
(with-temp-file out-file
Re: babel default header args as functions
Hi Matt, Looking good here. Thanks! Tom On Wed, Sep 9, 2020 at 12:06 PM Matt Huszagh wrote: > > Tom Gillespie writes: > > > [...] I have a number of use > > cases that I can imagine would benefit greatly from being able to > > define a :header-args: :header (lambda () "yay!") property as a > > closure (and actually I assumed that it would just work that way if I > > tried to do it, clearly not though). I can't tell for sure if the > > patch enables this behavior though or whether I would still get a > > Wrong type argument error. > > This should work. Do you have reason for believing it might not? With the patch applied this is working on my end. * test header :PROPERTIES: :header-args:bash: :tangle (lambda () "./from-header.sh") :END: #+begin_src bash :shebang "#!/usr/bin/env bash" echo yes #+end_src > > [...] Looking > > at the patch it seems that it preserves the behavior of performing the > > evaluation of the closures at the source block, but I'm not 100% sure. > > I'm not sure I completely understand what you mean here. However, the > closures are evaluated when point is at the source block, during the > source block evaluation, not when the default headers are declared. This > allows the closures to use context-dependent functionality (e.g. you can > call `org-element-at-point' inside the closure and retrieve whatever > information you want). Does this address your concern? Please clarify if > I've missed your point. Yep, you've got it. > > If the default header closures are being evaluated before checking > > whether they have been superseded by the headers on a block then that > > is incorrect and they should not be evaluated until it is clear that > > they are the value of the header for that block and have not been > > superseded. > > I've fixed my patch (attached) so that now closures are only evaluated > when they are used as part of the final set of headers. Great.
Re: babel default header args as functions
Bastien writes: > Also, if we integrate the change, `eval-default-headers' would be > better named `org-babel-eval-default-headers'. I've changed the function name to `org-babel-eval-headers'. The reason for dropping "default" is that this function is now used as part of `org-babel-merge-params' on all headers, not just defaults in order to avoid evaluating closures until we know they are needed. See https://lists.gnu.org/archive/html/emacs-orgmode/2020-09/msg00464.html for the new patch and more info. Matt
Re: babel default header args as functions
Tom Gillespie writes: > [...] I have a number of use > cases that I can imagine would benefit greatly from being able to > define a :header-args: :header (lambda () "yay!") property as a > closure (and actually I assumed that it would just work that way if I > tried to do it, clearly not though). I can't tell for sure if the > patch enables this behavior though or whether I would still get a > Wrong type argument error. This should work. Do you have reason for believing it might not? For example, set: (setq org-babel-default-header-args:bash `((:var . (lambda () "a='yay'" Then in file.org: #+begin_src bash :results output echo $a #+end_src Executing this will yield: #+RESULTS: : yay > [...] Looking > at the patch it seems that it preserves the behavior of performing the > evaluation of the closures at the source block, but I'm not 100% sure. I'm not sure I completely understand what you mean here. However, the closures are evaluated when point is at the source block, during the source block evaluation, not when the default headers are declared. This allows the closures to use context-dependent functionality (e.g. you can call `org-element-at-point' inside the closure and retrieve whatever information you want). Does this address your concern? Please clarify if I've missed your point. > If the default header closures are being evaluated before checking > whether they have been superseded by the headers on a block then that > is incorrect and they should not be evaluated until it is clear that > they are the value of the header for that block and have not been > superseded. I've fixed my patch (attached) so that now closures are only evaluated when they are used as part of the final set of headers. >From 4a461a90ec4f3c5f9634b687a6685ea3ba74f168 Mon Sep 17 00:00:00 2001 From: Matt Huszagh Date: Fri, 28 Aug 2020 11:05:59 -0700 Subject: [PATCH] ob-core.el: Add ability to use closures as default header arguments * lisp/ob-core.el (org-babel-default-header-args): Document ability to use closures. (org-babel-eval-headers): New function to generate header arguments, which adds the ability to evaluate closures during source block execution or export. (org-babel-merge-params): Only evaluate closures when we have our final list of headers. --- lisp/ob-core.el | 60 - 1 file changed, 55 insertions(+), 5 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 578622232..bef34d7c0 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -473,7 +473,35 @@ For the format of SAFE-LIST, see `org-babel-safe-header-args'." (defvar org-babel-default-header-args '((:session . "none") (:results . "replace") (:exports . "code") (:cache . "no") (:noweb . "no") (:hlines . "no") (:tangle . "no")) - "Default arguments to use when evaluating a source block.") + "Default arguments to use when evaluating a source block. + +This is a list in which each element is an alist. Each key +corresponds to a header argument, and each value to that header's +value. The value can either be a string or a closure that +evaluates to a string. The closure is evaluated when the source +block is being evaluated (e.g. during execution or export), with +point at the source block. It is not possible to use an +arbitrary function symbol (e.g. 'some-func), since org uses +lexical binding. To achieve the same functionality, call the +function within a closure (e.g. (lambda () (some-func))). + +To understand how closures can be used as default header +arguments, imagine you'd like to set the file name output of a +latex source block to a sha1 of its contents. We could achieve +this with: + +(defun org-src-sha () + (let ((elem (org-element-at-point))) +(concat (sha1 (org-element-property :value elem)) \".svg\"))) + +(setq org-babel-default-header-args:latex + `((:results . \"file link replace\") +(:file . (lambda () (org-src-sha) + +Because the closure is evaluated with point at the source block, +the call to `org-element-at-point' above will always retrieve +information about the current source block.") + (put 'org-babel-default-header-args 'safe-local-variable (org-babel-header-args-safe-fn org-babel-safe-header-args)) @@ -584,6 +612,19 @@ the outer-most code block.") (defvar *this*) +(defun org-babel-eval-headers (headers) + "Compute header list set with HEADERS. + +Evaluate all header arguments set to functions prior to returning +the list of header arguments." + (let ((lst nil)) +(dolist (elem headers) + (if (and (cdr elem) + (functionp (cdr elem))) + (push `(,(car elem) . ,(funcall (cdr elem))) lst) +(push elem lst))) +lst)) + (defun org-babel-get-src-block-info ( light datum) "Extract information from a source block or inline source block. @@ -2704,12 +2745,21 @@ parameters when merging lists." results-exclusive-groups results
Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]
Bastien writes: No Wayman writes: Well, back to square one -- the "fix" breaks setting the end time of an existing schedule timestamp for me with. I reverted it as 771c66f79. Unfortunate, but I see the same breakage with the patch. I stepped through trying to set and end time of an existing schedule timestamp and I think the problem may be in `org-read-date-analyze'. The sections commented: ;; Check if a time range is given as a duration ;; Check if there is a time range Might be where the problem is. Not 100% on why yet as I don't have deep knowledge of how this function is supposed to work and it is a little opaque. I'll keep researching and see if I can come up with anything.
Re: [PATCH] org-element: Hide parsers boilerplate into plist-creating macros
Hello, Bastien writes: > akater writes: > >> We replace some repetetive code with macro calls org-prog-plist and >> org-let*-prog-plist. > > IIUC this is a refactoring, it does not add or remove functionalities? > > I'll let Nicolas decide on this, of course. FWIW, I'm not convinced there's a significant advantage in doing this refactoring. Arguably, the code is not more readable. It will not make it faster either. There is room for refactoring in Org (for the record, org-agenda.el has not switched to lexical binding yet), but I don't think org-element.el has bitrotten so much that it deserves some. Regards, -- Nicolas Goaziou
org-store-link and help for a key
Either I missed something obvious or org-store-link from a help page for a keystroke works incorrectly Let's try to save a link to the *keystroke* help for e.g. org-insert-link: 1. Open help page with =C-h k C-c C-l= 2. Switch to the help buffer =C-x o= 3. Store link =M-x org-store-link RET= 4. Switch back to the org file =C-x o= 5. Insert link =C-c C-l RET RET= I get =[[help:C-c]]= and an error if I try to follow the link with =C-c C-o= user-error: Unknown function or variable: C-c If I ask a help page for the *function* 1b, =C-h f org-insert-link RET= I get the working link =[[help:org-inser-link]]=. I expect the similar result for the keystroke help link or maybe something special that leads to the description of the current keystroke binding. Such behavior exists for ages, at least since 8.2.10 till current master.
Re: [PATCH] Org-mode publish avoids inserting licensed content into target documents.
On 9/5/20 4:03 AM, Bastien wrote: ... I applied your change on the master branch as 471054136, thanks for this. And thank you Bastien! -- Anthony Carrico
Re: Adaptive Org faces in headings?
Hi Timothy, TEC writes: > From memory, Doom actually has a number of rather nice Org patches that > it hoards :P IIRC simply to avoid the effort of going through the patch > process, and have more flexibility (using Doom convenience macros, etc.). > > See > https://github.com/hlissner/doom-macs/blob/develop/modules/lang/org/config.el > for nice features like lazy loading babel language support. > > There are a number of contributors, but if you look at the blame > (https://github.com/hlissner/doom-emacs/blame/develop/modules/lang/org/config.el) > you can see that it looks like everyone other than Henrik (hlissner) has > only made what we'd call TINYCHANGEs. We do encourage early upstream contributions exactly because of this issue: when downstream (or distinct) projects accumulate changes made with no clear copyright assignment, we cannot integrate these changes upstream, because of these copyright uncertainty. -- Bastien
how to remove automatically an intermediate odt-File
I have set org-odt-preferred-output-format to docx, which works fine. How can I have the intermediate odt-file removed automatically after the docx-file is created? Many thanks in advance for any answer Rainer -- Prof. Dr. Rainer Thiel Institut für Altertumswissenschaften 07737 Jena, Germany (EU) r.th...@uni-jena.de
Re: variable-pitch-mode misaligns org-mode heading tags
Hi Eric, Eric S Fraga writes: > Also support for org-indent-mode: having the text align nicely with the > heading (as it does with monospace typefaces) would be more visually > pleasing. > > But I have a feeling that the calculations required for this and the > above may be significant and arguably not worth it? Indeed. > Org, especially > with respect to (large) tables, is already quite slow unfortunately. Fortunately, the reasons why tables might be slow are distinct from the reasons why org-indent might be slow. But yes, space-based alignment is a welcome improvement as long as it does not make Org slower. -- Bastien
Re: [PATCH] org-element: Hide parsers boilerplate into plist-creating macros
akater writes: > Bastien writes: > >> IIUC this is a refactoring, it does not add or remove functionalities? > > Yes, just a refactoring. In any case, let's discuss this for after 9.4. Thanks, -- Bastien
Re: Agenda view: On this day
Dear Klaus, I am not aware of code that does that. Carsten On Wed, Sep 9, 2020 at 3:55 PM Klaus Thoben wrote: > Carsten Dominik writes: > > > On Wed, Sep 9, 2020 at 3:06 PM Eric S Fraga wrote: > > > >> On Wednesday, 9 Sep 2020 at 14:35, Klaus Thoben wrote: > >> > Does such a function exist already? Or can somebody help me out with > >> > some Lisp code for that? > >> > >> The org agenda viewer will display timestamped events from all files > >> listed in org-agenda-files. Set the latter and invoke the agenda > >> (org-agenda, which is bound to C-c a for me) and select "a". You can > >> then view any particular day you may wish. > >> > > > > To make this work for a number of files, Org has to be told which files > to > > look at. The variable org-agenda-files can be customized to be a list of > > all such files. > > > > - Carsten > > > > > >> > >> -- > >> : Eric S Fraga via Emacs 28.0.50, Org release_9.3.7-725-g7bc18e > >> > >> > Hi and thanks, > the things you wrote I did already, maybe I didn't make myself clear > enough. What I envision is an extension to the > birthday/diary/anniversary function > > This I already have: > > > Monday 27 July 2020 W31 > > Birthday: Matthew Daniels (36th) > > Birthday: Annie Rose (76th) > > What I'd also like to see: > > > Tuesday 28 July 2020 W31 > > Birthday: Matthew Daniels (32th) > > Birthday: Annie Rose (67th) > > This day in 2015: 0:05 lastfm: Under Pressure (Queen And David Bowie) > > This day in 2015: 7:51 lastfm: Radio Ga Ga > > > This day in 2016: 13:36 SMS from Katwarn: KATWARN - DWD: > UNWETTERWARNUNG > > This day in 2016: 14:44 SMS from Katwarn: KATWARN - DWD: > UNWETTERWARNUNG > > This day in 2019: 13:18 Photo K50_2685.JPG > > This day in 2019: 13:19 Photo K50_2686.JPG > > Klaus > > > >
Re: [PATCH] org-element: Hide parsers boilerplate into plist-creating macros
Bastien writes: > IIUC this is a refactoring, it does not add or remove functionalities? Yes, just a refactoring. A typo crept into comments and help pages, so here's an update. signature.asc Description: PGP signature >From 0636f032b3c7e60221c28aeea91cce58376561dd Mon Sep 17 00:00:00 2001 From: akater Date: Thu, 16 Apr 2020 02:25:59 + Subject: [PATCH] org-element: Hide parsers boilerplate into plist-creating macros * lisp/org-element.el (org-prog-plist, org-let*-prog-plists) (org-let*-prog-plist): New macros. Build plists without boilerplate. (org-fold, org-dekeyword): New functions. Dependencies for the above. * lisp/org-element.el (org-element-center-block-parser) (org-element-drawer-parser, org-element-dynamic-block-parser) (org-element-footnote-definition-parser) (org-element-plain-list-parser, org-element-property-drawer-parser) (org-element-quote-block-parser, org-element-section-parser) (org-element-special-block-parser, org-element-babel-call-parser) (org-element-clock-parser, org-element-comment-parser) (org-element-comment-block-parser, org-element-diary-sexp-parser) (org-element-example-block-parser, org-element-export-block-parser) (org-element-fixed-width-parser, org-element-horizontal-rule-parser) (org-element-keyword-parser, org-element-latex-environment-parser) (org-element-node-property-parser, org-element-paragraph-parser) (org-element-planning-parser, org-element-src-block-parser) (org-element-table-parser, org-element-table-row-parser) (org-element-verse-block-parser, org-element-entity-parser) (org-element-footnote-reference-parser, org-element-inline-babel-call-parser) (org-element-inline-src-block-parser, org-element-latex-fragment-parser) (org-element-link-parser): Use org-prog-plist to build plist (org-element-headline-parser, org-element-inlinetask-parser) (org-element-item-parser, org-element-timestamp-parser): Use org-let*-prog-plist to build plist (org-element-radio-target-parser, org-element-statistics-cookie-parser) (org-element-subscript-parser, org-element-superscript-parser) (org-element-table-cell-parser, org-element-target-parser) (org-element-underline-parser, org-element-verbatim-parser): Use just #'list to build plist (org-element-comment-block-parser): Fix a typo in docstring. --- lisp/org-element.el | 2584 +++ lisp/org-macs.el| 259 + 2 files changed, 1421 insertions(+), 1422 deletions(-) diff --git a/lisp/org-element.el b/lisp/org-element.el index a693cb68d..e40f881b9 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -691,29 +691,26 @@ Assume point is at the beginning of the block." (re-search-forward "^[ \t]*#\\+END_CENTER[ \t]*$" limit t))) ;; Incomplete block: parse it as a paragraph. (org-element-paragraph-parser limit affiliated) - (let ((block-end-line (match-beginning 0))) - (let* ((begin (car affiliated)) - (post-affiliated (point)) + (list 'center-block + (nconc + (org-prog-plist + block-end-line (match-beginning 0) + :begin (car affiliated) + :post-affiliated (point) ;; Empty blocks have no contents. - (contents-begin (progn (forward-line) + :contents-begin (progn (forward-line) (and (< (point) block-end-line) - (point - (contents-end (and contents-begin block-end-line)) - (pos-before-blank (progn (goto-char block-end-line) - (forward-line) - (point))) - (end (save-excursion + (point))) + :contents-end (and contents-begin block-end-line) + pos-before-blank (progn (goto-char block-end-line) + (forward-line) + (point)) + :end (save-excursion (skip-chars-forward " \r\t\n" limit) - (if (eobp) (point) (line-beginning-position) - (list 'center-block - (nconc - (list :begin begin - :end end - :contents-begin contents-begin - :contents-end contents-end - :post-blank (count-lines pos-before-blank end) - :post-affiliated post-affiliated) - (cdr affiliated + (if (eobp) (point) + (line-beginning-position))) + :post-blank (count-lines pos-before-blank end)) + (cdr affiliated)) (defun org-element-center-block-interpreter (_ contents) "Interpret a center-block element as Org syntax. @@ -740,32 +737,28 @@ Assume point is at beginning of drawer." (if (not (save-excursion (re-search-forward "^[ \t]*:END:[ \t]*$" limit t))) ;; Incomplete drawer: parse it as a paragraph. (org-element-paragraph-parser limit affiliated) - (save-excursion - (let* ((drawer-end-line (match-beginning 0)) - (name (progn (looking-at org-drawer-regexp) - (match-string-no-properties 1))) - (begin (car affiliated)) - (post-affiliated (point)) - ;; Empty drawers have no contents. - (contents-begin (progn (forward-line) - (and (< (point) drawer-end-line) - (point
Re: [feature request] A new cookie type [!] showing the last note taken
Hello, Ihor Radchenko writes: > You are right. I missed that \\ is also a newline for LaTeX export. It is a line break in any export back-end. > Another possibility is re-purposing counter definition from ordered > lists. Currently the "\\[@[0-9]+\\]" is used to force item number in > ordered lists: > > 1. item > 5. [@5] another item > 6. next item > > However, it is unused it unordered lists. We might define a note as a > unnumbered list item with [@note]: > > - [@note] This is note That's a reasonable syntax extension, maybe too English-centered. Maybe a more abstract [@!] would be better. > In addition, all the list items in :LOGBOOK: drawer may be considered > notes (to avoid a need to change the current format of the > automatically added notes). Notes are not necessary stuffed into a LOGBOOK drawer, or even into a drawer at all. Besides, LOGBOOK is a common word, and it is not unreasonable to think some user could have used it for other purposes. Old notes are going to be incompatible (as in ignored by any tool processing notes, not invalid markup) with the new ones. I don't think there's a way to eschew it. It doesn't seem to be a big deal, however, as you don't lose anything by keeping notes in old syntax around. Regards, -- Nicolas Goaziou
Re: Agenda view: On this day
Carsten Dominik writes: > On Wed, Sep 9, 2020 at 3:06 PM Eric S Fraga wrote: > >> On Wednesday, 9 Sep 2020 at 14:35, Klaus Thoben wrote: >> > Does such a function exist already? Or can somebody help me out with >> > some Lisp code for that? >> >> The org agenda viewer will display timestamped events from all files >> listed in org-agenda-files. Set the latter and invoke the agenda >> (org-agenda, which is bound to C-c a for me) and select "a". You can >> then view any particular day you may wish. >> > > To make this work for a number of files, Org has to be told which files to > look at. The variable org-agenda-files can be customized to be a list of > all such files. > > - Carsten > > >> >> -- >> : Eric S Fraga via Emacs 28.0.50, Org release_9.3.7-725-g7bc18e >> >> Hi and thanks, the things you wrote I did already, maybe I didn't make myself clear enough. What I envision is an extension to the birthday/diary/anniversary function This I already have: > Monday 27 July 2020 W31 > Birthday: Matthew Daniels (36th) > Birthday: Annie Rose (76th) What I'd also like to see: > Tuesday 28 July 2020 W31 > Birthday: Matthew Daniels (32th) > Birthday: Annie Rose (67th) > This day in 2015: 0:05 lastfm: Under Pressure (Queen And David Bowie) > This day in 2015: 7:51 lastfm: Radio Ga Ga > This day in 2016: 13:36 SMS from Katwarn: KATWARN - DWD: UNWETTERWARNUNG > This day in 2016: 14:44 SMS from Katwarn: KATWARN - DWD: UNWETTERWARNUNG > This day in 2019: 13:18 Photo K50_2685.JPG > This day in 2019: 13:19 Photo K50_2686.JPG Klaus
Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]
Kyle Meyer writes: > With Org's master (f17d301e1), the second one hangs for me with Emacs > 26.3. Quickly stepping through org-babel-python--send-string, it > appears to get stuck in the accept-process-output call. > > Using an Emacs built from master, there's no hang on my end either. If > you'd find it useful, I can try to bisect that to a specific Emacs > commit tomorrow. > > The Emacs 26.3 hang goes away after installing your patch that restores > the use of a marker. Thanks Kyle and Nowayman for checking the patch. I was able to reproduce the problem on emacs-26.3 (but not 27.1). I'll be more diligent testing on those versions in future. I pushed an updated version of my patch to master in 939cf16bc. It solves the problem for me on emacs-26.3. No need to bisect Emacs (but thanks for offering!). But do let me know if you encounter any more problems with this. Best, Jack
Re: Agenda view: On this day
On Wed, Sep 9, 2020 at 3:06 PM Eric S Fraga wrote: > On Wednesday, 9 Sep 2020 at 14:35, Klaus Thoben wrote: > > Does such a function exist already? Or can somebody help me out with > > some Lisp code for that? > > The org agenda viewer will display timestamped events from all files > listed in org-agenda-files. Set the latter and invoke the agenda > (org-agenda, which is bound to C-c a for me) and select "a". You can > then view any particular day you may wish. > To make this work for a number of files, Org has to be told which files to look at. The variable org-agenda-files can be customized to be a list of all such files. - Carsten > > -- > : Eric S Fraga via Emacs 28.0.50, Org release_9.3.7-725-g7bc18e > >
Re: Agenda view: On this day
On Wednesday, 9 Sep 2020 at 14:35, Klaus Thoben wrote: > Does such a function exist already? Or can somebody help me out with > some Lisp code for that? The org agenda viewer will display timestamped events from all files listed in org-agenda-files. Set the latter and invoke the agenda (org-agenda, which is bound to C-c a for me) and select "a". You can then view any particular day you may wish. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.7-725-g7bc18e
Agenda view: On this day
Hi everyone, long time orgmode user, but never really did use the Agenda. Now, having used Memacs quite a bit, I thought it would be handy to have an agenda view that shows significant events related to the selected day from all org files. Does such a function exist already? Or can somebody help me out with some Lisp code for that? Thanks in advance, Klaus
Re: [feature request] org-at-timestamp-p should accept multiple parameters
Thanks. I understand now. I think to generate a patch in this case it's too much hustle, for a minor benefit. -- Adam On Wed, 9 Sep 2020 at 09:13, Bastien wrote: > Hi Adam, > > Adam Faryna writes: > > > Ok, maybe I misunderstood the purpose of this function. I wanted to > > use it to check if the timestamp is active or inactive and I tried to > > get it by using (org-at-timestamp-p 'inactive) while pointing at the > > timestamp. But actually when I call it on any timestamp like > > [2020-09-04 Fri], <2020-09-04 Fri> I always get nil. So either it's a > > bug, or I miss something. > > (org-at-timestamp-p) returns t on an active timestamp. > > (org-at-timestamp-p 'inactive) returns t on any timestamp, including > inactive ones. > > If you think the docstring could be enhanced, can you share a patch? > > See https://orgmode.org/worg/org-contribute.html on how to contribute. > > Thanks, > > -- > Bastien >
Re: variable-pitch-mode misaligns org-mode heading tags
On Wednesday, 9 Sep 2020 at 10:44, Bastien wrote: > Thanks for reporting this. Actually yes, we should consider handling > variable-pitch-mode more pleasantly, with space-aligned tags and also > tables that still display with fixed-width. Also support for org-indent-mode: having the text align nicely with the heading (as it does with monospace typefaces) would be more visually pleasing. But I have a feeling that the calculations required for this and the above may be significant and arguably not worth it? Org, especially with respect to (large) tables, is already quite slow unfortunately. Just my 2¢. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.7-725-g7bc18e
Re: [PATCH] org-add-planning-info: respect caller's given time [9.3.7 (release_9.3.7-716-g3d4876 @ /home/n/.emacs.d/straight/build/org/)]
No Wayman writes: > Bastien writes: > >> Hi No Wayman, >> >> I pushed 4f49ebb6d, a small variant of your initial patch, >> which pass the test fine by checking whether the variables >> are bound outside or not, ignoring them if not. >> >> Thanks again for the fix! > > Sounds good to me! Thanks, Bastien. Well, back to square one -- the "fix" breaks setting the end time of an existing schedule timestamp for me with. I reverted it as 771c66f79. -- Bastien
Re: Bug: Off-by-one when archiving to top level date [9.3.6 (9.3.6-17-g389288-elpa @ /home/charlestam/.emacs.d/elpa/org-20200224/)]
Hi Charles, sorry for the late feedback. Charles Tam writes: > I am archiving subtrees of my main Orgmode document to a top-level > datetree in a secondary file. When I do so, I expect something like > the following: > > * 2020 > *** 2020-02 February (org-odd-levels-only t) > * 2020-02-27 Thursday > *** Archived Item > > But instead I get > > * 2020 > *** 2020-02 February > * 2020-02-27 Thursday > * Archived Item > > The archived item ends up as a sibling of the targeted date, instead > of a child. This seems incorrect. What command or keybinding do you use when archiving? Can you provide a minimal step-by-step recipe to reproduce this bug with emacs -q ? Thanks, -- Bastien
Re: Bug: inserting capture template [9.3.7 (release_9.3.7-705-gea9463 @ /home/nick/elisp/org-mode/lisp/)]
Hi Nick, thanks for reporting this, I committed a fix for this (f5573e6a0). Best, -- Bastien
Re: Adaptive Org faces in headings?
Bastien writes: > (In general, it would be good if downstream enhancements like these > could be shared upstream, we are generally quite grateful for help!) >From memory, Doom actually has a number of rather nice Org patches that it hoards :P IIRC simply to avoid the effort of going through the patch process, and have more flexibility (using Doom convenience macros, etc.). See https://github.com/hlissner/doom-macs/blob/develop/modules/lang/org/config.el for nice features like lazy loading babel language support. There are a number of contributors, but if you look at the blame (https://github.com/hlissner/doom-emacs/blame/develop/modules/lang/org/config.el) you can see that it looks like everyone other than Henrik (hlissner) has only made what we'd call TINYCHANGEs. -- Timothy.
Re: Adaptive Org faces in headings?
Hi Protesilaos, Protesilaos Stavrou writes: > Diego Zamboni [2020-09-05, 23:39 +0200]: > >> I had seen the same in my setup. I recently started using Doom Emacs >> (https://github.com/hlissner/doom-emacs/) and was pleasantly surprised >> to discover that todo and tag faces scale according to the headline in >> which they are. I don't know precisely how this is done, but there are >> some hints here, you might use it as a starting point: >> https://github.com/hlissner/doom-emacs/blob/develop/modules/lang/org/config.el#L146-L175 > > I noticed that the doom-themes have some extra code to fontify Org.[0] > It also has some opinionated extras that do not belong to the issue I > raised. I am curious whether this was ever shared/discussed on this > mailing list. I can't remember any such discussion. (In general, it would be good if downstream enhancements like these could be shared upstream, we are generally quite grateful for help!) In any case, thanks for reporting this issue, I confirm we should work on it for a future release. Patches welcome, -- Bastien
Re: [PATCH] org-element: Hide parsers boilerplate into plist-creating macros
Hi Akater, akater writes: > We replace some repetetive code with macro calls org-prog-plist and > org-let*-prog-plist. IIUC this is a refactoring, it does not add or remove functionalities? I'll let Nicolas decide on this, of course. -- Bastien
Re: variable-pitch-mode misaligns org-mode heading tags
Hi Protesilaos, Protesilaos Stavrou writes: > 1. Run 'emacs -Q' > 2. Open a new Org file 'C-x C-f /tmp/test.org' > 3. Insert the following contents: > > * TODO this is a test :tag: > * TODO here is another test :tag: > > The tags should align to the right with the standard monospaced font. Thanks for reporting this. Actually yes, we should consider handling variable-pitch-mode more pleasantly, with space-aligned tags and also tables that still display with fixed-width. Patch(es) welcome for 9.5! Thanks, -- Bastien
Re: idea for capture anywhere in x
On Mon, Sep 07, 2020 at 10:05:38PM -0700, Samuel Wales wrote:
> well for a non-emacs application, i want to select text and capture
> using wm menu.
I routinely capture programming and UNIX history. I select text (X11
clipboard), and then I have a skel/abbrev to insert it into Emacs. I
type "pexa" and it creates an example source block and pastes
the clipboard into it with proper indentation. "pexa" stands for
"paste example".
This is *so* fast compared to creating a new source block (C-c C-, e),
then entering it (C-c C-'), pasting (C-y), and then exiting (C-c C-').
;; Org mode skeletons instead of yasnippet
(define-skeleton rla-paste-example
"Insert an Org-mode example source block and paste the clipboard into it." nil
"#+BEGIN_EXAMPLE\n"
;; indent to match the src block
(concat " " (replace-regexp-in-string "\n" "\n " (replace-regexp-in-string
"\n$" "" (current-kill 0 "\n"
"#+END_EXAMPLE\n"
"\n"
-)
(define-abbrev-table 'org-mode-abbrev-table '(("pexa" "" rla-paste-example 0)))
Mind you this is in the current buffer I'm typing in. If I wanted to
add from the CLI, I'd use a capture template with a predefined
location and make sure it includes the clipboard in expansion.
As some of the other replies have shown, triggering capture externally
isn't too hard. You'll just need to figure out the WM hook.
--
Russell Adamsrlad...@adamsinfoserv.com
PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/
Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: Bug: Exporting internal link to special latex block [9.3.7 (9.3.7-14-gb2b587-elpa @ /home/lobo/.emacs.d/elpa/org-20200720/)]
Bastien writes: > I tested the patch and it fixes the problem just fine, I applied > it in master as b79fef1da. PS: Also marking this as fixed now. -- Bastien
Re: Bug: Exporting internal link to special latex block [9.3.7 (9.3.7-14-gb2b587-elpa @ /home/lobo/.emacs.d/elpa/org-20200720/)]
Hi Nicolas and Marco, I tested the patch and it fixes the problem just fine, I applied it in master as b79fef1da. Thanks a lot for this! -- Bastien
Re: Release 9.3.8
Hi Kévin, Kévin Le Gouguec writes: > Bastien writes: > >>> - Will Emacs's maintenance branch (emacs-27) be updated with Org 9.3.8, >>> so that Emacs 27.2 includes all bugfixes for 9.3? (If so, I can open >>> a new report on Debbugs to track this, as suggested by Stefan K.) >> >> Yes, thanks. > > ACK; see bug#43268! Thanks! >>> - During the development of 9.4, AFAICT, while the "Version:" comment in >>> org.el sayd "9.4-dev", the org-version variable matched the latest >>> tag, i.e. 9.3.x. >>> >>> I therefore couldn't figure out a way to check for 9.4 >>> programmatically. >> >> ... because 9.4 is not yet released - or am I missing something? > > See Emacs's master branch for a counter-example: even though 28.1 is not > out yet, emacs-version says "28.0.50", so one can determine that they're > running on the master branch. Well, yes, but I find that confusing: "I'm using the 28.0.50 version, which looks like an officially released version, while it's not." > It's clearly not a big deal; cf. below. > >> On what commit would I add the "release_x.(y+1)-rc" on master, since >> master is always moving forward? > > If a new major release is immediately merged to the maint branch, it > would be enough to have a followup empty commit on master, and tag that. > > I'm not suggesting to do that though; I don't find empty commits very > elegant. Me neither. > That's fair. My "use-case" was to conditionally swap RET and C-j for > Org<9.4, to palliate the lack of electric-indent-mode. It's far from a > critical problem, and there are other ways for me to solve this (rely on > fboundp, run "make ORGVERSION=9.4"…). OK - let's see if others have similar needs, and maybe we can think about this again. (Also, Kyle has more git-fu that me, so he may be in a better position to decide on this.) Thanks, -- Bastien
Re: [feature request] org-at-timestamp-p should accept multiple parameters
Hi Adam, Adam Faryna writes: > Ok, maybe I misunderstood the purpose of this function. I wanted to > use it to check if the timestamp is active or inactive and I tried to > get it by using (org-at-timestamp-p 'inactive) while pointing at the > timestamp. But actually when I call it on any timestamp like > [2020-09-04 Fri], <2020-09-04 Fri> I always get nil. So either it's a > bug, or I miss something. (org-at-timestamp-p) returns t on an active timestamp. (org-at-timestamp-p 'inactive) returns t on any timestamp, including inactive ones. If you think the docstring could be enhanced, can you share a patch? See https://orgmode.org/worg/org-contribute.html on how to contribute. Thanks, -- Bastien
Re: [PATCH] Re: Re: Re: org-forward-heading-same-level and the invisible-ok argument
D writes: > I fully understand, though I do believe that this change is beneficial > to the way org-forward-heading-same-level works overall, in a "principle > of least astonishment" sort of way. Yes, that's why I allowed this exception, but still, I think it's best to leave the FIXME for future generations. -- Bastien
Re: Bug: [PATCH] org-datetree-insert-line doesn't honor headline spacing customization [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]
Hello Vasilij, Vasilij Schneidermann writes: >> Thanks for the patch. I tried it and these two tests fail: >> >>FAILED test-org-datetree/find-date-create >>FAILED test-org-datetree/find-iso-week-create >> >> Perhaps you can check the value of `org-blank-before-new-entry' and >> insert a blank line only if needed? > > I've looked at the tests and concluded that your proposed approach is better > and updated the patch accordingly. thanks for the updated patch, I added a changelog entry and applied it as 5082e436a in master. Best, -- Bastien
Re: [PATCH] Re: Re: Re: org-forward-heading-same-level and the invisible-ok argument
Ihor Radchenko writes: >> I applied a small variant of it as a700fadd7, thanks. >> >> (See also the comment I added with f17d301e1, which basically means >> that such changes are made as exceptions.) > > For record, the old behaviour did not only affect a single external > package. For example, https://github.com/TonCherAmi/org-starless was > also affected. Good to know, thanks! -- Bastien
Re: Babel: parse error when output contains opening bracket
Hi Ian, ian martins writes: > Of course there's never a problem in fixing things. I'm curious how > you did it. Will look when I have a chance. Here it is: https://code.orgmode.org/bzg/org-mode/commit/989f50a53 Sorry I forgot to mention the commit in the ack message. PS: As I said, it was quite simple ;) -- Bastien
Re: org-format-outline-path fonts sizes in the minibuffer
Hi Carsten, Carsten Dominik writes: > yes, keeping the color would be good, this can make reading these > strings much easier. That's what is done, as of 7a12e1499, just committed in master. Thanks for insisting on this! -- Bastien
