Bug: PDF Export of Link fails [9.4.6 (9.4.6-gab9f2a @ /gnu/store/2pny4z6mbi2aybgzzxz0yrzkds7hbpmq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/)]
Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See https://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org mailing list. Using the following text I get failing pdf export: The link is not recognized correctly but ends after the comma and the markup persists in the PDF. /Diesen Text habe ich leicht abgewandelt schon am Montag per E-Mail ans [[https://km-bw.de/,Lde/startseite/service/kontakt][Kultusministerium BW]] geschickt. Da hatten wir noch 2 Wochen./ Best wishes, Arne Emacs : GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0) Package: Org mode version 9.4.6 (9.4.6-gab9f2a @ /gnu/store/2pny4z6mbi2aybgzzxz0yrzkds7hbpmq-emacs-org-9.4.6/share/emacs/site-lisp/org-9.4.6/) -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: [PATCH] Re: New source block results option for attaching file to node
That's starting to sound pretty good. It might make sense to fix up inserted "file:" links that are under the attachment directory to be "attachment:" style links by default anyway, no? Then just being able to set the working directory to the attachment directory easily would get the rest of the way there. So I suppose that would then mean having the :dir header accept the symbol `attach' or something like that? I'll play around and see what that looks like. On Thu, Sep 2, 2021 at 8:09 PM Ihor Radchenko wrote: > Greg Minshall writes: > > > i can imagine wanting to have input files and > > output files in separate directories. (for ease in "make clean", if for > > no other conceptual reason.) (but, probably i don't understand.) > > Makes sense. Currently, there is :dir header arg to set working > directory (aka input files directory). Maybe we can introduce something > like :results-dir header arg to set the output directory? It's value can > be a directory path or symbol 'attach. > > `:results file :results-dir 'attach` will be equivalent of > `:results file attach` in the patch proposed by Ryan Scott. > > WDYT? > > Best, > Ihor >
Re: [PATCH] Re: New source block results option for attaching file to node
Greg Minshall writes: > i can imagine wanting to have input files and > output files in separate directories. (for ease in "make clean", if for > no other conceptual reason.) (but, probably i don't understand.) Makes sense. Currently, there is :dir header arg to set working directory (aka input files directory). Maybe we can introduce something like :results-dir header arg to set the output directory? It's value can be a directory path or symbol 'attach. `:results file :results-dir 'attach` will be equivalent of `:results file attach` in the patch proposed by Ryan Scott. WDYT? Best, Ihor
Re: [BUG] [BUG] inconsistent behavior when reading multiple tags [9.4.6 (9.4.6-g366444 @ /home/n/.emacs.d/straight/build/org/)]
Timothy writes: Hi NoWayman, Thanks for your suggestion. At a glance it looks reasonable to me, but would you be able to explain the default value you’ve set? It isn’t obvious to me how you arrived at `"[ \t]*[^[:alnum:]_@#%][ \t]*"'. Also, do you think a one-size-fits-all solution is a good fit here? I don’t do much with tags personally, so I’m probably not the best person to judge. (defconst org-tag-crm-separator “[ ]*[^[:alnum:]_@#%][ ]*” “Regexp used to determine `crm-separator’ when reading multiple tags.”) All the best, Timothy I was aiming for the inverse of `org-tag-re' which is: "[[:alnum:]_@#%]+" The idea being we treat any character which is not a valid tag character as the crm separator.
Re: Greater than, less than bug in emacs-lisp source block
John Kitchin writes: > I think this issue is described in > https://emacs.stackexchange.com/questions/50216/org-mode-code-block-parentheses-mismatch. > There are also some > solutions there. I wasn't able to get that to work in my Emacs. I did something simpler though, that seems to work for me: #+begin_src emacs-lisp (defmacro gt (n1 n2) `(> ,n1 ,n2)) (defmacro gte (n1 n2) `(>= ,n1 ,n2)) (defmacro lt (n1 n2) `(< ,n1 ,n2)) (defmacro lte (n1 n2) `(<= ,n1 ,n2)) ;; example usage (dolist (s templist) (while (lt (length s) l) (setq s (concat s " "))) (push (concat "[ " s " ]") kwdlist)) #+end_src
Re: Greater than, less than bug in emacs-lisp source block
I think this issue is described in https://emacs.stackexchange.com/questions/50216/org-mode-code-block-parentheses-mismatch. There are also some solutions there. John --- Professor John Kitchin (he/him/his) Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu On Thu, Sep 2, 2021 at 2:10 PM Charles Millar wrote: > Set up: > GNU Emacs 28.0.50 (build 344, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, > cairo version 1.16.0) of 2020-12-31 > Org mode version 9.4.6 (release_9.4.6-637-gd70f28 @ > /usr/local/share/org-mode/lisp/) > > The following code will evaluate > > #+begin_src emacs-lisp > (defun Foo () > (if (= 2 4) bar)) > #+end_src > > #+RESULTS: > : Foo > and the opening and closing parentheses match. > > If a greater than is inserted instead of equals, thus > > #+begin_src emacs-lisp > (defun Foo () > (if (> 2 4) bar)) > #+end_src > > it apparently evaluates, however, the closing parenthesis immediately > following the "4" is paired with the opening paren before "if" and not > the opening paren immediately before the ">" > > A "less than" results with stranger parenthesis matching - the closing > paren after the "4" matches no others; the closing paren immediately > after "bar" matches the opening paren before "if" > > Charlie Millar > > > >
Greater than, less than bug in emacs-lisp source block
Set up: GNU Emacs 28.0.50 (build 344, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.16.0) of 2020-12-31 Org mode version 9.4.6 (release_9.4.6-637-gd70f28 @ /usr/local/share/org-mode/lisp/) The following code will evaluate #+begin_src emacs-lisp (defun Foo () (if (= 2 4) bar)) #+end_src #+RESULTS: : Foo and the opening and closing parentheses match. If a greater than is inserted instead of equals, thus #+begin_src emacs-lisp (defun Foo () (if (> 2 4) bar)) #+end_src it apparently evaluates, however, the closing parenthesis immediately following the "4" is paired with the opening paren before "if" and not the opening paren immediately before the ">" A "less than" results with stranger parenthesis matching - the closing paren after the "4" matches no others; the closing paren immediately after "bar" matches the opening paren before "if" Charlie Millar
Re: [PATCH] Re: New source block results option for attaching file to node
Ryan, et al., i'm not entirely following the discussion, as i don't use "attaching". but, fwiw, if i did, i can imagine wanting to have input files and output files in separate directories. (for ease in "make clean", if for no other conceptual reason.) (but, probably i don't understand.) cheers, Greg
Re: Support for tabularray in LaTeX export
This is perfect. Thank you, Juan Manuel.
Vikas
On Thu, 2 Sept 2021 at 14:06, Juan Manuel Macías
wrote:
> Hi Vikas,
>
> You can define a modified version of `org-latex--org-table',
> adding a new LaTeX attribute `:options'. Something like this:
>
> #+begin_src emacs-lisp
> (defun my/org-latex--org-table (table contents info)
> "Return appropriate LaTeX code for an Org table.
>
> TABLE is the table type element to transcode. CONTENTS is its
> contents, as a string. INFO is a plist used as a communication
> channel.
>
> This function assumes TABLE has `org' as its `:type' property and
> `table' as its `:mode' attribute."
> (let* ((attr (org-export-read-attribute :attr_latex table))
> (alignment (org-latex--align-string table info))
> (opt (org-export-read-attribute :attr_latex table :options))
> (table-env (or (plist-get attr :environment)
> (plist-get info :latex-default-table-environment)))
> (width
> (let ((w (plist-get attr :width)))
> (cond ((not w) "")
> ((member table-env '("tabular" "longtable")) "")
> ((member table-env '("tabu" "longtabu"))
>(format (if (plist-get attr :spread) " spread %s "
> " to %s ")
>w))
> (t (format "{%s}" w)
> (caption (org-latex--caption/label-string table info))
> (above? (org-latex--caption-above-p table info)))
> (cond
> ((member table-env '("longtable" "longtabu"))
> (let ((fontsize (let ((font (plist-get attr :font)))
> (and font (concat font "\n")
> (concat (and fontsize (concat "{" fontsize))
> (format "\\begin{%s}%s{%s}\n" table-env width alignment)
> (and above?
> (org-string-nw-p caption)
> (concat caption "\n"))
> contents
> (and (not above?)
> (org-string-nw-p caption)
> (concat caption "\n"))
> (format "\\end{%s}" table-env)
> (and fontsize "}"
> (t
> (let ((output (format "\\begin{%s}%s%s{%s}\n%s\\end{%s}"
> table-env
> (if opt opt "")
> width
> alignment
> contents
> table-env)))
> (org-latex--decorate-table output attr caption above? info))
>
> (advice-add 'org-latex--org-table :override #'my/org-latex--org-table)
> #+end_src
>
> and then:
>
> #+ATTR_LATEX: :environment longtblr
> #+ATTR_LATEX: :align
> #+ATTR_LATEX: :booktabs t
> #+ATTR_LaTeX: :options []
>
> Best regards,
>
> Juan Manuel
>
> Vikas Rawal writes:
>
> > tabularray (CTAN: Package tabularray) provides longtblr environment
> > that is called as
> >
> > ---
> > \begin{longtblr}[various-table-options]{column and row specifications}
> >
> > \end{longtblr}
> > ---
> >
> > Adding something like the following to orgmode tables makes them
> > export nicely as longtblr
> >
> > ---
> > #+ATTR_LATEX: :environment longtblr
> > #+ATTR_LATEX: :align width=0.8\textwidth,colspec={lX[2,r]X[3,r]X
> > [r,bg=gray9]}
> > #+ATTR_LATEX: :booktabs t
> > ---
> >
> > Everything seems to work very well with orgmode except that I cannot
> > figure out how to pass [various table options] from orgmode. These
> > table options include, most importantly, table notes.
> >
> > I normally use threeparttable for table notes, but longtblr does not
> > seem to work with threeparttable and has its own syntax for table
> > notes.
> >
> > Any advice on how to pass [table-options] to longtblr environment?
> >
> > Vikas
> >
>
Re: Support for tabularray in LaTeX export
Hi Vikas,
You can define a modified version of `org-latex--org-table',
adding a new LaTeX attribute `:options'. Something like this:
#+begin_src emacs-lisp
(defun my/org-latex--org-table (table contents info)
"Return appropriate LaTeX code for an Org table.
TABLE is the table type element to transcode. CONTENTS is its
contents, as a string. INFO is a plist used as a communication
channel.
This function assumes TABLE has `org' as its `:type' property and
`table' as its `:mode' attribute."
(let* ((attr (org-export-read-attribute :attr_latex table))
(alignment (org-latex--align-string table info))
(opt (org-export-read-attribute :attr_latex table :options))
(table-env (or (plist-get attr :environment)
(plist-get info :latex-default-table-environment)))
(width
(let ((w (plist-get attr :width)))
(cond ((not w) "")
((member table-env '("tabular" "longtable")) "")
((member table-env '("tabu" "longtabu"))
(format (if (plist-get attr :spread) " spread %s "
" to %s ")
w))
(t (format "{%s}" w)
(caption (org-latex--caption/label-string table info))
(above? (org-latex--caption-above-p table info)))
(cond
((member table-env '("longtable" "longtabu"))
(let ((fontsize (let ((font (plist-get attr :font)))
(and font (concat font "\n")
(concat (and fontsize (concat "{" fontsize))
(format "\\begin{%s}%s{%s}\n" table-env width alignment)
(and above?
(org-string-nw-p caption)
(concat caption "\n"))
contents
(and (not above?)
(org-string-nw-p caption)
(concat caption "\n"))
(format "\\end{%s}" table-env)
(and fontsize "}"
(t
(let ((output (format "\\begin{%s}%s%s{%s}\n%s\\end{%s}"
table-env
(if opt opt "")
width
alignment
contents
table-env)))
(org-latex--decorate-table output attr caption above? info))
(advice-add 'org-latex--org-table :override #'my/org-latex--org-table)
#+end_src
and then:
#+ATTR_LATEX: :environment longtblr
#+ATTR_LATEX: :align
#+ATTR_LATEX: :booktabs t
#+ATTR_LaTeX: :options []
Best regards,
Juan Manuel
Vikas Rawal writes:
> tabularray (CTAN: Package tabularray) provides longtblr environment
> that is called as
>
> ---
> \begin{longtblr}[various-table-options]{column and row specifications}
>
> \end{longtblr}
> ---
>
> Adding something like the following to orgmode tables makes them
> export nicely as longtblr
>
> ---
> #+ATTR_LATEX: :environment longtblr
> #+ATTR_LATEX: :align width=0.8\textwidth,colspec={lX[2,r]X[3,r]X
> [r,bg=gray9]}
> #+ATTR_LATEX: :booktabs t
> ---
>
> Everything seems to work very well with orgmode except that I cannot
> figure out how to pass [various table options] from orgmode. These
> table options include, most importantly, table notes.
>
> I normally use threeparttable for table notes, but longtblr does not
> seem to work with threeparttable and has its own syntax for table
> notes.
>
> Any advice on how to pass [table-options] to longtblr environment?
>
> Vikas
>
Re: [PATCH] Fix bug assuming canonical duration units in org-agenda-format-items
> >> I think a proper fix would be to change `org-duration-from-minutes' so
> >> it removes any unknown unit from what is provided from fmt or
> >> `org-duration-format', and defaults to (special . h:mm) if nothing is
> >> left.
> >>
> >> WDYT?
> >>
> > Perhaps. I don't understand `org-duration-from-minutes` well enough to
> > change it.
>
> You don't really need to understand it. I suggest using a filter as the
> very first step of the function.
>
> > I guess the stripping of unknown units from fmt or
> > `org-duration-format` would then have to compare either against
> > `org-duration-units` or `org-duration-canonical-units` depending on
> > the canonical argument.
>
> Exactly.
>
>
> Regards,
> --
> Nicolas Goaziou
Included is a patch for the filtering (I assumed cl-intersection was
reasonable to use since cl-lib is a requirement).
However, I do not think this is enough, since it can cause quite
unexpected results when canonical is used without specifying the
format, Hence, I do think the previous patch should also be applied.
For my case, org-duration-format is (("m") ("w") ("d") (special . h:mm)).
This call to org-duration-from-minutes (like in org-agenda-format-item):
(org-duration-from-minutes MINUTES nil t)
will then result in a full format amounting to (("d")), (since
"special" is not part of the canonical units), which is hardly what is
expected for the agenda.
Best,
Anders Johansson
[PATCH] Ensure valid duration format in org-duration-from-minutes
Filter out any elements of the duration format that is not in
org-duration-units or org-duration-canonical-units.
---
lisp/org-duration.el | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/lisp/org-duration.el b/lisp/org-duration.el
index e627d0936..eb4b6075f 100644
--- a/lisp/org-duration.el
+++ b/lisp/org-duration.el
@@ -314,13 +314,19 @@ (defun org-duration-from-minutes (minutes
fmt canonical)
"Return duration string for a given number of MINUTES.
Format duration according to `org-duration-format' or FMT, when
-non-nil.
+non-nil. Invalid units in the duration format are discarded.
When optional argument CANONICAL is non-nil, ignore
`org-duration-units' and use standard time units value.
Raise an error if expected format is unknown."
- (pcase (or fmt org-duration-format)
+ (pcase (cl-intersection
+ (or fmt org-duration-format)
+ (if canonical
+ org-duration-canonical-units
+org-duration-units)
+ :key #'car
+ :test #'equal)
(`h:mm
(format "%d:%02d" (/ minutes 60) (mod minutes 60)))
(`h:mm:ss
--
2.33.0
[PATCH] Re: New source block results option for attaching file to node
Updated patch; fixed typos and wrapped the commit message to 72 characters Thinking about the input files issue some more, I wonder if an attach keyword wouldn't better function as setting the working directory to the node's attachment directory and then fixing up any inserted link to use "attachment:" if it's relative to that. I've been working with this for a bit in my own workflow and it's been useful, but I'll see about maybe experimenting with some other approaches as well. Moving the referenced file to the attachment directory never felt completely right to me. On Wed, Sep 1, 2021 at 1:01 PM Ryan Scott wrote: > I hadn't thought about input directories much as my usage of > graphviz/gnuplots is through [essentially] DSLs that I made for them, so > the blocks are actually elisp. > Perhaps a convenient way of setting the working directory to the > attachment directory per-block makes sense? > > My own personal coding style doesn't include a hard line limit, so it just > wasn't on my mind. > > I'll get my patch updated and submitted shortly. Thanks for the help! > > On Wed, Sep 1, 2021 at 7:44 AM Ihor Radchenko wrote: > >> Ryan Scott writes: >> >> The patch looks fine for me except a typo: >> >> > + by the source block to the nodes attachmen directory (as >> ^attachment >> >> > org-attach-dir is a function for me (latest org pulled using >> straight.el) >> > org/lisp/org-attach.el:327. >> >> Timothy probably does not have (require 'org-attach) in his personal >> config. However, it should not be an issue for your patch with the >> autoload you added. >> >> > The primary use case is src blocks that generate files, in my case >> usually >> > gnuplot or graphviz, and return a file path. With a collection of org >> files >> > in a directory, organization can get messy, and creating an >> organizational >> > scheme essentially recreates the attachment directory design. >> >> I am also using attach directories for gnuplot output. Your approach is >> fine, but what about input directory? I find it a bit awkward to store >> input files alongside with the main .org file, while keeping the output >> images as attachments. >> >> I personally prefer to set the working dir for gnuplot like >> >> #+begin_src gnuplot :dir (org-attach-dir) >> >> With my approach, both the input and output files are going to be in the >> attach dir. >> >> I even go as far as making attach dir my default directory of all the >> code blocks. >> >> Though your patch may be useful when input directory is read-only or >> even remote. >> >> > Another approach would be to instead only modify org to have hooks (or >> any >> > other callback mechanism really) that are run on link insertion and have >> > access to the result-params for the block. The rest of this could then >> be a >> > separate package easily enough. Would that be a better approach as it >> would >> > allow the org core to not be so tightly coupled to org-attach? >> >> org-attach is in the Org core. It should not be a problem supporting >> org-attach in org babel. >> >> > I'm using magit; I just don't normally restrain myself to the line >> length. >> > I'll make sure to do that for submitted patches here. >> >> You may find flycheck-mode useful to hint things like line length. >> >> > In terms of this mailing list and overall contribution process, how >> best to >> > remedy things for the patch? Just modify it and reply with the modified >> > patch as an attachment? >> >> Yep. Just submit the updated patch. Preferably, also add [PATCH] at the >> beginning of the message topic. Then, the patch will also be shown in >> updates.orgmode.org >> >> Best, >> Ihor >> > 0001-ob-core-Added-option-for-attaching-file-from-babel-s.patch Description: Binary data
[PATCH] Re: [BUG] Creating sparse tree with regexp property matches
Attached is a patch with improvement to documentation regarding regular
expressions.
Best,
Daniel Fleischer
>From d3d1dcbc5f62ea111e7bcd1741114cae6b1280c5 Mon Sep 17 00:00:00 2001
From: Daniel Fleischer
Date: Tue, 31 Aug 2021 20:01:47 +0300
Subject: [PATCH] org-manual: added section about regular expressions
Telling users it's based on Elisp regular expressions, linking to its
info node and putting some links to this new node in places where regexp
are presented.
Signed-off-by: Daniel Fleischer
---
doc/org-manual.org | 80 --
1 file changed, 49 insertions(+), 31 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 10e0baa28..02eaa10f2 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -916,16 +916,16 @@ ** Sparse Trees
#+kindex: C-c / /
#+findex: org-occur
#+vindex: org-remove-highlights-with-change
- Prompts for a regexp and shows a sparse tree with all matches. If
- the match is in a headline, the headline is made visible. If the
- match is in the body of an entry, headline and body are made
- visible. In order to provide minimal context, also the full
- hierarchy of headlines above the match is shown, as well as the
- headline following the match. Each match is also highlighted; the
- highlights disappear when the buffer is changed by an editing
- command, or by pressing {{{kbd(C-c C-c)}}}[fn:8]. When called with
- a {{{kbd(C-u)}}} prefix argument, previous highlights are kept, so
- several calls to this command can be stacked.
+ Prompts for a regexp (see [[*Regular Expressions]]) and shows a sparse
+ tree with all matches. If the match is in a headline, the headline
+ is made visible. If the match is in the body of an entry, headline
+ and body are made visible. In order to provide minimal context,
+ also the full hierarchy of headlines above the match is shown, as
+ well as the headline following the match. Each match is also
+ highlighted; the highlights disappear when the buffer is changed by
+ an editing command, or by pressing {{{kbd(C-c C-c)}}}[fn:8]. When
+ called with a {{{kbd(C-u)}}} prefix argument, previous highlights
+ are kept, so several calls to this command can be stacked.
- {{{kbd(M-g n)}}} or {{{kbd(M-g M-n)}}} (~next-error~) ::
@@ -3663,10 +3663,10 @@ ** Search Options in File Links
- =/REGEXP/= ::
- Do a regular expression search for {{{var(REGEXP)}}}. This uses the
- Emacs command ~occur~ to list all matches in a separate window. If
- the target file is in Org mode, ~org-occur~ is used to create
- a sparse tree with the matches.
+ Do a regular expression search for {{{var(REGEXP)}}} (see [[*Regular
+ Expressions]]). This uses the Emacs command ~occur~ to list all
+ matches in a separate window. If the target file is in Org mode,
+ ~org-occur~ is used to create a sparse tree with the matches.
As a degenerate case, a file link with an empty file name can be used
to search the current file. For example, =[[file:::find me]]= does
@@ -4978,8 +4978,9 @@ ** Tag Hierarchy
Furthermore, the members of a group tag can also be regular
expressions, creating the possibility of a more dynamic and rule-based
-tag structure. The regular expressions in the group must be specified
-within curly brackets. Here is an expanded example:
+tag structure (see [[*Regular Expressions]]). The regular expressions in
+the group must be specified within curly brackets. Here is an
+expanded example:
#+begin_example
,#+TAGS: [ Vision : {V@.+} ]
@@ -5321,7 +5322,7 @@ ** Property Searches
tree is created with all entries that define this property with the
given value. If you enclose the value in curly braces, it is
interpreted as a regular expression and matched against the property
- values.
+ values (see [[*Regular Expressions]]).
** Property Inheritance
:PROPERTIES:
@@ -8913,8 +8914,9 @@ *** Matching tags and properties
#+cindex: regular expressions, with tags search
Instead of a tag, you may also specify a regular expression enclosed
-in curly braces. For example, =work+{^boss.*}= matches headlines that
-contain the tag =:work:= and any tag /starting/ with =boss=.
+in curly braces (see [[*Regular Expressions]]). For example,
+=work+{^boss.*}= matches headlines that contain the tag =:work:= and
+any tag /starting/ with =boss=.
#+cindex: group tags, as regular expressions
Group tags (see [[*Tag Hierarchy]]) are expanded as regular expressions.
@@ -8954,7 +8956,7 @@ *** Matching tags and properties
#+begin_example
+work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<2
- +With={Sarah|Denny}+SCHEDULED>="<2008-10-11>"
+ +With={Sarah\|Denny}+SCHEDULED>="<2008-10-11>"
#+end_example
#+texinfo: @noindent
@@ -8984,7 +8986,7 @@ *** Matching tags and properties
not =boss=, which also have a priority value =A=, a =Coffee= property
with the value =unlimited=, an =EFFORT= property that is numerically
smaller than 2, a
