Re: (Feature Request) customise LaTeX-preview regex
On Sunday, 14 Jun 2020 at 21:53, TEC wrote:
> Hi All,
>
> Just a quick note: I'm yet to resolve this, so any further
> comments/help on this would be much appreciated :)
If you put the snippet in a math environment, it works with LaTeX
preview:
\(\ce{CO2}\)
Of course, this only applies to things that can belong in a maths
environment.
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.7-636-gaa32f6
Re: multiple EXPORT_LATEX_HEADER lines
On Saturday, 13 Jun 2020 at 17:02, Alan Schmitt wrote: > This is the crux of the issue: there does not seem to be any way to > generate a multi-line header. And this causes problems with LaTeX. Is the problem solvable in LaTeX? Does \makeatletter expect to be on a single line? As I said before, I've seldom played with @ variables or functions in LaTeX. However, I had the impression that LaTeX was quite robust with respect to whitespace & newlines. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.7-636-gaa32f6
[PATCH] Add markdown support to contrib/org-man export
Hey Org-mode enthusiasts,
Find attached a patch adding export of manual links for markdown.
I wanted to get links to man pages to work nicely for my blog
using ox-hugo, an org exporter based on markdown, built by
well-known org enthusiast Kaushal Modi.
Org snippet to demonstrate export to markdown feature:
--8<---cut here---start->8---
I sure love [[man:emacs][GNU Emacs]].
--8<---cut here---end--->8---
org-md-export-to-markdown before (link description missing, booh):
--8<---cut here---start->8---
I sure love http://man.he.net/?topic=emacs§ion=all.
--8<---cut here---end--->8---
Export to markdown after (pretty, valid markdown, yey):
--8<---cut here---start->8---
I sure love [GNU
Emacs](http://man.he.net/?topic=emacs§ion=all).
--8<---cut here---end--->8---
This is my first contribution (I welcome feedback regarding patch
formatting etc). No FSF papers due to contrib/.
Happy I can finally contribute /something/ back, and scratching
that itch feels nice.
Have a fantastic day.
--
Jb
>From c7c2fe978a134347a0b6c30667015c687803eb12 Mon Sep 17 00:00:00 2001
From: Jb DOYON
Date: Sun, 14 Jun 2020 21:19:20 +0100
Subject: [PATCH] contrib/ol-man.el: Add markdown support to org-man export
---
contrib/lisp/ol-man.el | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/lisp/ol-man.el b/contrib/lisp/ol-man.el
index 580556a..5cb7e01 100644
--- a/contrib/lisp/ol-man.el
+++ b/contrib/lisp/ol-man.el
@@ -68,6 +68,7 @@ PATH should be a topic that can be thrown at the man command."
((eq format 'latex) (format "\\href{%s}{%s}" path desc))
((eq format 'texinfo) (format "@uref{%s,%s}" path desc))
((eq format 'ascii) (format "%s (%s)" desc path))
+ ((eq format 'md) (format "[%s](%s)" desc path))
(t path
(provide 'ol-man)
--
2.20.1
Re: [PATCH] may we focus on readability?
Hi Nicolas, I think that the hint on testing is very correct, I'm afraid I changed the semantics of one of the original tests, and I found that there's other cl functions other than just cl-some, also cl-every, cl-notevery, and cl-notany. I'll have a closer look at this. and write some tests before changing the code. I also looked for the strange idiom used here, and these two are the only two locations I found. how do I run tests from the command line (I'm using make test) but then limited to one lisp file? or one specific test? ciao, Mario On 14/06/2020 14:32, Nicolas Goaziou wrote: […] Also, further nit: (not (cl-every ...)) will apply `not' only once. In any case, it would be better if refactoring happens while introducing unit tests *hint*. Regards,
Re: Bug: fontification error with #end_src in 9.3.7 [9.3.7 (9.3.7-dist @ /PATH/TO/org/install/emacs/site-lisp/org/)]
Thanks - I verified the fix. From: Kyle Meyer Sent: Saturday, June 13, 2020 3:21 PM To: John Ciolfi Cc: emacs-orgmode@gnu.org Subject: Re: Bug: fontification error with #end_src in 9.3.7 [9.3.7 (9.3.7-dist @ /PATH/TO/org/install/emacs/site-lisp/org/)] Kyle Meyer writes: > I'll try to take a closer look tomorrow. This should be fixed by ba6ca79af.
Re: tags-todo org-agenda-custom-command weirdness
Kyle Meyer writes:
> Stig Brautaset writes:
>
>> I'm seeing some weirdness with tags-todo vs tags custom agenda commands.
>> Below is the smallest case I've managed to narrow it down to. I would
>> *expect* that all the a1-4 commands return the same results, and that
>> the b1-4 return the same results. That is not what I'm seeing, however.
>>
>> (setq-default org-agenda-custom-commands
>> '(("a1" "A1" tags-todo "-PROJ/TODO")
>> ("a2" "A2" tags "-PROJ/TODO")
>> ("a3" "A3" ((tags-todo "-PROJ/TODO")))
>> ("a4" "A4" ((tags "-PROJ/TODO")))
>>
>> ("b1" "B1" tags-todo "-PROJ/DONE")
>> ("b2" "B2" tags "-PROJ/DONE")
>> ("b3" "B3" ((tags-todo "-PROJ/DONE")))
>> ("b4" "B4" ((tags "-PROJ/DONE")
>>
>
> I agree with your expectation that a1-4 should be the same. Why do you
> expect that b1-4 would be? Shouldn't tags-todo consider only none-DONE
> todo items, in the same spirit as m versus M? In other words, I'd
> expect b1 and b3 to be empty by definition.
I expected b1-4 to all yield the same result because I expect
`tags-todo` to search all TODO-items, not just TODO items where the
state is "TODO".
>> The effect of a1 & a2 appears identical to eachother, and a3 & a4 too,
>> but a1-2 and a3-4 differ (in that the former seems to include scheduled
>> items, but the latter does not.)
>
> It's helpful if you provide a minimal test file. I've tried to come up
> with one that I think should capture what you're describing.
Mea culpa, I should have done this.
>
> --8<---cut here---start->8---
> * TODO h1 :PROJ:
> * TODO h2
> * DONE h3 :PROJ:
> * DONE h4
> * TODO h5 :PROJ:
> SCHEDULED: <2020-06-14 Sun>
> * TODO h6
> SCHEDULED: <2020-06-14 Sun>
> * DONE h7 :PROJ:
> SCHEDULED: <2020-06-14 Sun>
> * DONE h8
> SCHEDULED: <2020-06-14 Sun>
> --8<---cut here---end--->8---
>
> With that, a1-4 all show:
>
> scratch:TODO h2
> scratch:TODO h6
>
> That doesn't match what you're seeing. I'm testing with 706970 checked
> out, the commit you reported in your follow-up message.
For me a2 and a4 returns the same, but a1 and a3 just returns TODO h2.
However, I can reproduce what you're seeing by setting this:
(setq org-agenda-todo-ignore-scheduled nil)
>> What I'm seeing for b1-4 is even weirder. Here I observe b1, b2 and b4
>> have identical behaviour[*], but b3 is the odd one out: while the other
>> three return a list of DONE non-project tasks, b3 doesn't find anything.
>>
>> [*] I suspect the reason b2 and b4 are identical is that I have no
>> scheduled DONE tasks.
>
> For b2 and b4, I see
>
> scratch:DONE h4
> scratch:DONE h8
>
> b1 and b3 are empty, which I think is expected given the tags-todo type.
Well, I disagree :-)
This behaviour of `tags-todo` seems inconsistent to me. If `todo` can
find DONE items, why shouldn't `tags-todo` do the same?
Stig
Re: Import Reusable org-babel snippet using #+SETUPFILE
Hi Salomon Turgman, I do this a lot and have had success using a combination of #+SETUPFILE to bring in names and configuration, and org-sbe to do initialization. I mix emacs vars and org names in my source headers with back quoting. The following example has a template file containing user/local information. This is brought into the example file, on load, through #:eval calling org-babel-lob-ingest and org-sbe, in addition, parameters are pulled in with #+SETUPFILE and the same template file name. The end result for this example is a running docker image with access to local paths and "remote" execution via tramp. More complex orchestration and actions in the template are certainly possible using org-sbe calls in the init elisp source blocks but hopefully, this shows the flavor of what can be done. In addition to avoiding code duplication, I have found this to be very effective when my group is all working from the same org file (via git) but everyone has their own template file with credentials, local paths, and org more preferences (ie showstars). Regards, Doug - TemplatingExample.org - #+SETUPFILE: Template-Loader.org * Init Code, run when file is opened #+name: Execute-On-Load #+begin_src elisp :results output ;; for this the container and image have the same name (setq *DockerName* "ContanerName") #+end_src * Run Contaner #+begin_src bash :results raw drawer :var DockerName=`,*DockerName* DockerHubUID=`,*DockerHubUID* containerName=`,*DockerContainer* LocalWorkPath=`,*LocalWorkPath* LocalDataPath=`,*LocalDataPath* docker run --rm -d \ -v $LocalWorkPath:/root/Workdir \ -v $LocalDataPath:/root/Data \ --name $DockerName $DockerHubUID/$DockerName bash -c "tail -f /dev/null" #+end_src * run IN contaner #+begin_src bash :results output :dir (concat "/docker:" `,*DockerName* ":/root/Workdir/") ls #+end_src # Local Variables: # eval: (org-babel-lob-ingest "Template-Loader.org") # eval: (org-sbe "Init-Template") # eval: (org-sbe "Execute-On-Load") # End: - Template-Loader.org - #+STARTUP: showstars #+PROPERTY: header-args :mkdirp yes #+name: Init-Template #+begin_src emacs-lisp :results none ;; This is called expecitly via org-sbe in the buffer that will uses the templating (setq *DockerHubUID* "MyUserName") (setq *LocalWorkPath* "/run/desktop/mnt/host/c/Users/.") (setq *LocalDataPath* "/run/desktop/mnt/host/d/devData/") ;; ingest + SBE can be used to bring in a hierarchy of templates (org-babel-lob-ingest "./GroupTools/GeneralORGTools.org") (org-sbe "GeneralORGTools.org") #+end_src
Re: [PATCH] may we focus on readability?
second thought about testing: if I did that, it would become longer than 15 lines, I would need refactoring quite a bit of stuff, and both things would require time, bureaucratic time, and programming time. I had a closer look at my changes, re-read it, and used it a bit, and I think this is o.k. see it yourself, when we have the agreement allowing you accept changes longer than 15 lines, I'll consider the needed refactoring and test-writing. ciao, Mario On 15/06/2020 09:49, Mario Frasca wrote: Hi Nicolas, I think that the hint on testing is very correct, I'm afraid I changed the semantics of one of the original tests, and I found that there's other cl functions other than just cl-some, also cl-every, cl-notevery, and cl-notany. I'll have a closer look at this. and write some tests before changing the code. I also looked for the strange idiom used here, and these two are the only two locations I found. how do I run tests from the command line (I'm using make test) but then limited to one lisp file? or one specific test? ciao, Mario On 14/06/2020 14:32, Nicolas Goaziou wrote: […] Also, further nit: (not (cl-every ...)) will apply `not' only once. In any case, it would be better if refactoring happens while introducing unit tests *hint*. Regards, >From 49f1cfbb80a3d5ffdbac4eea60bb3d45991c4423 Mon Sep 17 00:00:00 2001 From: mfrasca Date: Sun, 14 Jun 2020 10:52:41 -0500 Subject: [PATCH] lisp/org-plot.el: reducing complexity of test. * lisp/org-plot.el (org-plot/gnuplot): readability of test, looking for some non satisfying elements. I'm rewriting a complicated construction where there's an equality test on the length of the list of non matching elements, with a simpler cl-some invocation. The replacing code is self explanatory. --- lisp/org-plot.el | 34 ++ 1 file changed, 14 insertions(+), 20 deletions(-) diff --git a/lisp/org-plot.el b/lisp/org-plot.el index a23195d2a..bf81d3c37 100644 --- a/lisp/org-plot.el +++ b/lisp/org-plot.el @@ -309,26 +309,20 @@ line directly before or after the table." (`grid (let ((y-labels (org-plot/gnuplot-to-grid-data table data-file params))) (when y-labels (plist-put params :ylabels y-labels) - ;; Check for timestamp ind column. - (let ((ind (1- (plist-get params :ind - (when (and (>= ind 0) (eq '2d (plist-get params :plot-type))) - (if (= (length - (delq 0 (mapcar - (lambda (el) - (if (string-match org-ts-regexp3 el) 0 1)) - (mapcar (lambda (row) (nth ind row)) table - 0) - (plist-put params :timeind t) - ;; Check for text ind column. - (if (or (string= (plist-get params :with) "hist") - (> (length - (delq 0 (mapcar - (lambda (el) - (if (string-match org-table-number-regexp el) - 0 1)) - (mapcar (lambda (row) (nth ind row)) table - 0)) - (plist-put params :textind t) + ;; Check type of ind column (timestamp? text?) + (when (eq `2d (plist-get params :plot-type)) + (let* ((ind (1- (plist-get params :ind))) + (ind-column (mapcar (lambda (row) (nth ind row)) table))) + (cond ((< ind 0) nil) ; ind is implicit + ((cl-every (lambda (el) + (string-match org-ts-regexp3 el)) + ind-column) + (plist-put params :timeind t)) ; ind holds timestamps + ((or (string= (plist-get params :with) "hist") + (cl-notevery (lambda (el) +(string-match org-table-number-regexp el)) + ind-column)) + (plist-put params :textind t) ; ind holds text ;; Write script. (with-temp-buffer (if (plist-get params :script) ; user script -- 2.20.1
Re: tags-todo org-agenda-custom-command weirdness
Stig Brautaset writes: > For me a2 and a4 returns the same, but a1 and a3 just returns TODO h2. > However, I can reproduce what you're seeing by setting this: > > (setq org-agenda-todo-ignore-scheduled nil) So, provided you've configured org-agenda-todo-ignore-scheduled and org-agenda-tags-todo-honor-ignore-options away from their default values of nil, the a1-4 behavior you described is as advertised, correct? >> b1 and b3 are empty, which I think is expected given the tags-todo type. > > Well, I disagree :-) > > This behaviour of `tags-todo` seems inconsistent to me. If `todo` can > find DONE items, why shouldn't `tags-todo` do the same? Perhaps it should. The behavior has been that way for a long time, and the code makes it look very deliberate. That of course is not an argument that it should be that way, just one basis for expectations (and a reason to be wary of breaking workflows). And it looks like it was actually supposed to change to your preference in 2017. There was a report [0] that essentially boils down to what you're saying, I think. In response, 942b6267a (org-agenda: `tags-todo' command type includes DONE keywords, 2017-04-18) was applied, but then reverted for reasons not related to the intended change in behavior [1]. There was then a follow-up in 2fb129b5c (`org-scan-tags' retrieve all TODO keywords, not only not-done ones, 2017-08-17). As far as I can tell, that was supposed to achieve the behavior you're after but didn't. I don't have time to dig much at the moment, but quickly stepping through org-scan-tags, I think the issue is that the MATCHER argument still filters out done states. [0] https://orgmode.org/list/caf96xx0xxhpkjaxy0dqmoiy3rnt+duok4p1y71f1awyjanl...@mail.gmail.com/ [1] https://orgmode.org/list/874lt89fi2@free.fr/
