Re: oc-biblatex and biblatex substyles
Ah, now I sent two emails. I thought the first one got lost.
Sorry for the noise.
Rasmus
Rasmus writes:
> Hi there,
>
> Sorry for the slow reply.
>
> Nicolas Goaziou writes:
>
>> Hello,
>>
>> Rasmus writes:
>>
>>> I wonder if oc-biblatex should support loading biblatex-derived libraries,
>>> e.g. biblatex-chicago?
>>>
>>> There’s a quite a few of these libraries:
>>>
>>>$ tlmgr search --global "biblatex-" | wc -l
>>> 66
>>>
>>> (This is somewhat overestimating the true number of “biblatex-*”
>>> packages).
>>>
>>> These libraries are typically nie because they are (i) easier to configure
>>> than biblatex for a specific style and (ii) actually support some
>>> \usepackage keywords that can’t be used by biblatex (e.g. ibidtracker for
>>> biblatex-chicago).
>>>
>>> Thus, it might be able to at least support
>>>
>>> #+cite_export: biblatex-$SUBSTYLE
>>>
>>> E.g. #+cite_export: biblatex-chicago. But oc-biblatex would likely also
>>> have to be able to pickup biblatex-* packages in
>>> org-latex-(default-)packages-alist...
>>>
>>> So maybe it’s a can of worms?
>>
>> I don't know enough about BibLaTeX to answer that question. What does it
>> entail to "support loading biblatex-derived libraries" in practical
>> terms? I assume \usepackage{biblatex-chicago} instead of
>> \usepackage{biblatex}, with a different set of options and commands,
>> too.
>
> For the most part it should be drop in replacements. I don’t think any
> user commands are *removed* from a derived style. But options to the
> package could be added an user commands could be added.
>
>> It may be possible to define a new variable, e.g.,
>> ‘org-cite-biblatex-package‘, defaulting to ("bilatex" . nil). It would
>> contain entries like (SUBSTYLE . OPTIONS) and would be used to build the
>> proper \usepackage invocation.
>
> Maybe that is the best way to go about. Then at least we could support
> the main styles out there. I guess Chicago covers most of the social
> sciences? I guess the humanities use APA? I don’t know how different
> biblatex-apa is though.
>
> There are also obscure styles. E.g. a student once used biblatex-aer
> which is a derived style of biblatex-chicago that makes it look like a
> famous journal.
>
>
>> I also plan to allow custom commands in "oc-biblatex.el", so it could
>> also handle commands introduced by the substyles.
>>
>> How we would select substyle from the document is not clear, tho.
>
> If we want to support arbitrary styles somewhat I guess something like
> #+cite_export: biblatex-$SUBSTYLE would be ok. But it would not
> necessarily be full support.
>
>> Another possibility it to write, e.g., "oc-biblatex-chicago.el" and
>> define a new ‘biblatex-chicago’ export processor, re-using most
>> functions from "oc-biblatex.el". It would probably only be necessary to
>> re-define ‘org-cite-biblatex-export-citation’ and
>> ‘org-cite-biblatex-prepare-preamble’.
>
> I guess you (and Tom) is right that it would be better to make a derived
> style.
>
> Tom, did you already make a derived style? From the later emails it
> sounded like it, but I don’t see oc-biblatex-chicago.el in the main repo.
>
> Otherwise, I can have try to have a go at it over the coming weeks.
>
> Kind regards and terribly sorry again for missing the follow ups earlier,
> Rasmus
--
What will be next?
Re: oc-biblatex and biblatex substyles
Hi there,
Sorry for the slow reply.
Nicolas Goaziou writes:
> Hello,
>
> Rasmus writes:
>
>> I wonder if oc-biblatex should support loading biblatex-derived libraries,
>> e.g. biblatex-chicago?
>>
>> There’s a quite a few of these libraries:
>>
>>$ tlmgr search --global "biblatex-" | wc -l
>> 66
>>
>> (This is somewhat overestimating the true number of “biblatex-*”
>> packages).
>>
>> These libraries are typically nie because they are (i) easier to configure
>> than biblatex for a specific style and (ii) actually support some
>> \usepackage keywords that can’t be used by biblatex (e.g. ibidtracker for
>> biblatex-chicago).
>>
>> Thus, it might be able to at least support
>>
>> #+cite_export: biblatex-$SUBSTYLE
>>
>> E.g. #+cite_export: biblatex-chicago. But oc-biblatex would likely also
>> have to be able to pickup biblatex-* packages in
>> org-latex-(default-)packages-alist...
>>
>> So maybe it’s a can of worms?
>
> I don't know enough about BibLaTeX to answer that question. What does it
> entail to "support loading biblatex-derived libraries" in practical
> terms? I assume \usepackage{biblatex-chicago} instead of
> \usepackage{biblatex}, with a different set of options and commands,
> too.
For the most part it should be drop in replacements. I don’t think any
user commands are *removed* from a derived style. But options to the
package could be added an user commands could be added.
> It may be possible to define a new variable, e.g.,
> ‘org-cite-biblatex-package‘, defaulting to ("bilatex" . nil). It would
> contain entries like (SUBSTYLE . OPTIONS) and would be used to build the
> proper \usepackage invocation.
Maybe that is the best way to go about. Then at least we could support
the main styles out there. I guess Chicago covers most of the social
sciences? I guess the humanities use APA? I don’t know how different
biblatex-apa is though.
There are also obscure styles. E.g. a student once used biblatex-aer
which is a derived style of biblatex-chicago that makes it look like a
famous journal.
> I also plan to allow custom commands in "oc-biblatex.el", so it could
> also handle commands introduced by the substyles.
>
> How we would select substyle from the document is not clear, tho.
If we want to support arbitrary styles somewhat I guess something like
#+cite_export: biblatex-$SUBSTYLE would be ok. But it would not
necessarily be full support.
> Another possibility it to write, e.g., "oc-biblatex-chicago.el" and
> define a new ‘biblatex-chicago’ export processor, re-using most
> functions from "oc-biblatex.el". It would probably only be necessary to
> re-define ‘org-cite-biblatex-export-citation’ and
> ‘org-cite-biblatex-prepare-preamble’.
I guess you (and Tom) is right that it would be better to make a derived style.
Tom, did you already make a derived style? From the later emails it
sounded like it, but I don’t see oc-biblatex-chicago.el in the main repo.
Otherwise, I can have try to have a go at it over the coming weeks.
Kind regards and terribly sorry again for missing the follow ups earlier,
Rasmus
--
In theory, practice and theory are the same. In practice they are not
Re: oc-biblatex and biblatex substyles
Hi there,
Sorry for the slow reply.
Nicolas Goaziou writes:
> Hello,
>
> Rasmus writes:
>
>> I wonder if oc-biblatex should support loading biblatex-derived libraries,
>> e.g. biblatex-chicago?
>>
>> There’s a quite a few of these libraries:
>>
>>$ tlmgr search --global "biblatex-" | wc -l
>> 66
>>
>> (This is somewhat overestimating the true number of “biblatex-*”
>> packages).
>>
>> These libraries are typically nie because they are (i) easier to configure
>> than biblatex for a specific style and (ii) actually support some
>> \usepackage keywords that can’t be used by biblatex (e.g. ibidtracker for
>> biblatex-chicago).
>>
>> Thus, it might be able to at least support
>>
>> #+cite_export: biblatex-$SUBSTYLE
>>
>> E.g. #+cite_export: biblatex-chicago. But oc-biblatex would likely also
>> have to be able to pickup biblatex-* packages in
>> org-latex-(default-)packages-alist...
>>
>> So maybe it’s a can of worms?
>
> I don't know enough about BibLaTeX to answer that question. What does it
> entail to "support loading biblatex-derived libraries" in practical
> terms? I assume \usepackage{biblatex-chicago} instead of
> \usepackage{biblatex}, with a different set of options and commands,
> too.
While I haven’t looked through other styles, I would assume the user
commands (“\*cite*”) remain the same. Only The library differs. But
sometimes it may introduce new options to the package.
> It may be possible to define a new variable, e.g.,
> ‘org-cite-biblatex-package‘, defaulting to ("bilatex" . nil). It would
> contain entries like (SUBSTYLE . OPTIONS) and would be used to build the
> proper \usepackage invocation.
>
> I also plan to allow custom commands in "oc-biblatex.el", so it could
> also handle commands introduced by the substyles.
>
> How we would select substyle from the document is not clear, tho.
> Another possibility it to write, e.g., "oc-biblatex-chicago.el" and
> define a new ‘biblatex-chicago’ export processor, re-using most
> functions from "oc-biblatex.el". It would probably only be necessary to
> re-define ‘org-cite-biblatex-export-citation’ and
> ‘org-cite-biblatex-prepare-preamble’.
>
> WDYT?
Maybe that is a good way. But e.g. a student once preferred an even more
obscure style, biblatex-aer which builds on biblatex-chicago to make a
style similar to a specific journal. It could get old quickly...
OTOH, we could select some key derivatives to support.
Kind regards,
Rasmus
--
And I faced endless streams of vendor-approved Ikea furniture. . .
Re: [patch] fix ox-latex async export bug
Sébastien Miquel writes: > Rasmus Pank Roulund writes: >>> This is most likely due to native compilation which compiles the >>> unquoted lambda. Once compiled, it (presumably) fails to be passed to >>> the external emacs process. >> Ah, interesting. Is this a bug or a feature? > > I think the bug's with org-mode. As I explain elsewhere in the thread, > this lambda is to be treated as data, and written to a file to be > executed by the external emacs instance. It should always have been > quoted (naming it happens to work also). Thanks. That makes sense. I did wonder how those files worked (as the lambdas are gibberish) when I was debugging the problem. Rasmus -- Bang bang
Re: [patch] fix ox-latex async export bug
Timothy writes: > Hi Tim, > >> I’m wondering if this could be a problem when exporting to latex if the >>underlying latex process encounters errors and is waiting for user >> input before >>it can continue (which happens if there are problems in the tex >> source latex is >>trying to process)? >> >> It might be worth checking next time you encounter an error if you can >> run latex on the generated *.tex file and see if it waits for user >> input? > > If you look at the default value of `org-latex-pdf-process', it has the flag > `-interaction=nonstopmode' which should mean the process never pauses > and waits > for user input. Indeed. I run LaTeX in noninteractive mode. (And by now I rarely make mistakes... ;) Rasmus -- However beautiful the theory, one should occasionally look at the evidence
Re: oc-biblatex too aggressive in replacing styles
Nicolas Goaziou writes: > Hello, > > Rasmus writes: > >> However, I think it is currently too aggressive in overwriting styles. > > Ah? > >> Could it perhaps accept any style that is given in >> ‘org-cite-biblatex-options’ / ‘org-latex-packages-alist’ and only >> overwrite it if another style is explicitly specified in the file to be >> exported? > > Isn't it the case already? For me it is not. But maybe I used the latest release and not the latest git version. Let me recheck and get pack. >> Currently, the only way I have found that I can specify that I want to use >> biblatex-chicago is by issuing >> >> #+cite_export: biblatex chicago-authordate > > If you need chicago-authordate style globally, you can set > `org-cite-export-processors' instead, e.g., to > > ((t biblatex "chicago-authordate")) I see. I had missed that you could supply a third argument, but it seems to work perfectly! Thanks! (And sorry about the noise.) Maybe I will try to write a patch for the manual. Kind regards, Rasmus -- A clever person solves a problem. A wise person avoids it
Re: smart quotes and languages like en-gb
Nicolas Goaziou writes: > Hello, > > Rasmus writes: > >> I have noticed that smart quotes are not picked up for “long” languages, >> like “en-gb”, since smart quotes are defined for “short” languages, like >> “en”, in org-export-smart-quotes-alist. >> >> The attached patch is an attempt at remedying this. Not sure if it is the >> best fix, though... > > IMO, this is a bit of a kludge. > > "oc.el" parses language-region tags already, although it has not been > factored out as an independent function yet. See > `org-cite--get-note-rule'. Maybe moving this part to "org-macs.el" would > be a better solution. The patch is definitely dodgy. E.g. if I have rules for both en-gb and en the smart quote would depend on the order of ‘org-export-smart-quotes-alist’. So a better patch is needed, indeed. Thanks for the reference to the oc function. I will check it ASAP. Thanks, Rasmus -- I feel emotional landscapes they puzzle me
Re: [patch] fix ox-latex async export bug
Sébastien Miquel writes: > Hi, > > Nicolas Goaziou writes: >>> I don’t really understand why this bug happens to be honest. >> The patch is already an improvement, but the beast is still lurking, >> indeed. > This is most likely due to native compilation which compiles the > unquoted lambda. Once compiled, it (presumably) fails to be passed to > the external emacs process. Ah, interesting. Is this a bug or a feature? FWIW, I definitely use native compilation on my private laptop and almost certainly on my work (Windows) laptop as well. Thanks, Rasmus -- If you can mix business and politics wonderful things can happen!
Re: oc-biblatex too aggressive in replacing styles
"Bruce D'Arcus" writes: > On Sun, Nov 28, 2021 at 12:19 PM Bruce D'Arcus wrote: >> >> On Sun, Nov 28, 2021, 12:04 PM Rasmus wrote: >> > >>> However, I think it is currently too aggressive in overwriting styles. >>> >>> Could it perhaps accept any style that is given in >>> ‘org-cite-biblatex-options’ / ‘org-latex-packages-alist’ and only >>> overwrite it if another style is explicitly specified in the file to be >>> exported? >> >> I raised a similar question awhile back, and am not sure the best approach. > > Here's Nicolas' response to my query, which I agree with, and which is > consistent I think with what you are suggesting. > > https://lists.gnu.org/archive/html//emacs-orgmode/2021-10/msg00449.html > > Bruce Thanks a lot for pointing me to that thread! Rasmus
smart quotes and languages like en-gb
Hi, I have noticed that smart quotes are not picked up for “long” languages, like “en-gb”, since smart quotes are defined for “short” languages, like “en”, in org-export-smart-quotes-alist. The attached patch is an attempt at remedying this. Not sure if it is the best fix, though... Test file: #+language: en-gb "Foo" Thanks, Rasmus -- Dung makes an excellent fertilizer >From 44df143a60e035816bcf5a241631e48b9b0a487a Mon Sep 17 00:00:00 2001 From: Rasmus Pank Roulund Date: Sun, 28 Nov 2021 18:41:34 +0100 Subject: [PATCH] org-export-activate-smart-quotes: Support languages with hyphens. Get smart-quotes from "en" for "#+language: en-gb". --- lisp/ox.el | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lisp/ox.el b/lisp/ox.el index 98c9c1119..6f10112bb 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -5688,8 +5688,9 @@ Return the new string." (lambda (match) (or (plist-get (cdr (assq (pop quote-status) - (cdr (assoc (plist-get info :language) - org-export-smart-quotes-alist + (cdr (cl-assoc (plist-get info :language) + org-export-smart-quotes-alist + :test (lambda (lang k) (string-match-p k lang)) encoding) match)) s nil t))) -- 2.34.1
oc-biblatex and biblatex substyles
Hi, I wonder if oc-biblatex should support loading biblatex-derived libraries, e.g. biblatex-chicago? There’s a quite a few of these libraries: $ tlmgr search --global "biblatex-" | wc -l 66 (This is somewhat overestimating the true number of “biblatex-*” packages). These libraries are typically nie because they are (i) easier to configure than biblatex for a specific style and (ii) actually support some \usepackage keywords that can’t be used by biblatex (e.g. ibidtracker for biblatex-chicago). Thus, it might be able to at least support #+cite_export: biblatex-$SUBSTYLE E.g. #+cite_export: biblatex-chicago. But oc-biblatex would likely also have to be able to pickup biblatex-* packages in org-latex-(default-)packages-alist... So maybe it’s a can of worms? Rasmus -- Enough with the blah blah!
oc-biblatex too aggressive in replacing styles
Hi,
Thanks for providing ox-biblatex.
It works very well and has replaced my local hacks for LaTeX
bibliographies.
However, I think it is currently too aggressive in overwriting styles.
Could it perhaps accept any style that is given in
‘org-cite-biblatex-options’ / ‘org-latex-packages-alist’ and only
overwrite it if another style is explicitly specified in the file to be
exported?
A bit like how ox-koma-letter looks for in-buffer changed values.
Currently, the only way I have found that I can specify that I want to use
biblatex-chicago is by issuing
#+cite_export: biblatex chicago-authordate
But this is a bit blunt as it overrules ‘org-cite-export-processors’ and
thus biblatex is used for e.g. text export (of course I can replicate
org-cite-export-processors with a macro that looks at the current export
backend).
(If you want I am happy to try to work on this)
Thanks,
Rasmus
Example:
See [cite/t:@OrgCitations]
#+bibliography: lit.bib
# only way to "actuallyhicago:
#+cite_export: biblatex chicago-authordate
* settings :noexport:
#+begin_src emacs-lisp
(require 'oc-biblatex)
;; test 1: style is gobbled
;; (setq org-cite-biblatex-options "style=chicago-authordate,
maxcitenames=2")
;; test 2: style is gobbled
;; (setq org-latex-packages-alist '(("style=chicago-authordate,
maxcitenames=2" "biblatex")))
;; test 3: biblatex and biblatex-chicago are both loaded
;; (setq org-latex-packages-alist '(("authordate" "biblatex-chicago")))
#+end_src
--
9000!
[oc-csl] org-cite-csl-styles-dir and default-directory
Hi there,
Congrats on oc.el!
I have had a chance to try it a bit and it is really nice to work with!
One frustration with oc-csl.el is that is does not like relative dirs,
which I guess is fine overall as one would probably store styles
centrally, somewhere, similarly to LaTeX.
However, one niece that would seem useful is to simply dump something
relative to the org file (useful for e.g. a doc stored in git and compiled
via docker).
So it might be nice if oc-csl would look for style files in
default-directory / command-line-default-directory?
I haven’t been following the discussions closely so my apology if there’s
a reason for not doing this.
Thanks,
Rasmus
Example file
See [cite/t:@OrgCitations]
#+bibliography: lit.bib
#+cite_export: csl chicago-author-date.csl
* setup :noexport:
#+name: setup env
#+begin_src sh
wget
https://raw.githubusercontent.com/citation-style-language/styles/master/chicago-author-date.csl
cat >> lit.bib << EOF
@article{OrgCitations,
author={org, mode and Syntax, Citation and List, Mailing and
Effort, Time},
journal={Journal of Plain Text Formats},
title={Elegant Citations with Org-Mode},
year={2021},
month={7},
volume={42},
number={1},
pages={2-3}}
EOF
#+end_src
#+begin_src emacs-lisp
(require 'oc-csl)
#+end_src
Make ~oc-csl~ use current folder.
It would be nice not to have to specify this.
#+begin_src emacs-lisp
(setq org-cite-csl-styles-dir default-directory)
#+end_src
--
What will be next?
[patch] fix ox-latex async export bug
Hi there, When I try to export documents asynchronously with ox-latex, I always get a bug in the “org-export-processFOO” files. The last sexp is always something like this: (funcall '# "test.tex") where the “#” and “’” are mixed around. This happens even with a very simple ‘org-export-async-init-file’ just loading ELPA Org. This was previously reported here: https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00422.html Nicolas’ fix (replicated in this patch) seems to fix it. I don’t really understand why this bug happens to be honest. This happens both on my GNU/Linux system (Emacs v29) and my work Windows PC (Emacs v28 or v29) [all pre-releases, obviously]. Thanks, Rasmus -- If you can mix business and politics wonderful things can happen! >From be15ab50ef4cefc579f87766b21eaed7514379d1 Mon Sep 17 00:00:00 2001 From: Rasmus Pank Roulund Date: Sun, 28 Nov 2021 16:34:37 +0100 Subject: [PATCH] org-latex-export-to-pdf: Avoid using lambda function. Fix "invalid-read-syntax '#'" when exporting asynchronously with ox-latex. See also previous bug report: https://lists.gnu.org/archive/html/emacs-orgmode/2021-06/msg00422.html --- lisp/ox-latex.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el index 409d92164..8187119ec 100644 --- a/lisp/ox-latex.el +++ b/lisp/ox-latex.el @@ -3708,7 +3708,7 @@ Return PDF file's name." (let ((outfile (org-export-output-file-name ".tex" subtreep))) (org-export-to-file 'latex outfile async subtreep visible-only body-only ext-plist - (lambda (file) (org-latex-compile file) + #'org-latex-compile))) (defun org-latex-compile (texfile snippet) "Compile a TeX file. -- 2.34.1
Re: org-tempo insertion incoherence (lack of indentation) or misunderstanding
Hi Bruno, Bruno BEAUFILS writes: > Let us imagine this simple org file : > > #+NAME: first > #+begin_src org > > - an item > - subitem > > #+end_src > > If the cursor is at the last line and I want to insert an org block, > let's say an example, using org-tempo feature, I can type = followed by tabulation. > > In that case I get something like > > #+NAME: second > #+begin_src org > > - an item > - subitem > > #+begin_example > > #+end_example > > #+end_src > > However if I get indentation role (for instance in exports) well I do > not expect that but instead something like: > > #+NAME: third > #+begin_src org > > - an item > - subitem > > #+begin_example > > #+end_example > > #+end_src > > Are my expectations (and thus my use of indentation by org-mode > understandings) wrong or is it a bug? Whether the inserted block is indented depends on ‘org-get-indentation’ and thus the cursor’s position, at least in some cases. In particular, if | is the cursor, run org-get-indentation for these two examples to understand when you get indentation and when not: 1. - a | 2: - a | In 1. you are making a new block outside the list, in 2. it is part of the first item of the list. Both are valid. > In the same spirit if before trying that I type tabulation then = then tabulation again, nothing is inserted, aka org-tempo seems to work > only when cursor is at the beginning of line. > > Am I right? Is it a feature or a bug? You can have any amount of whitespace before expanding something a tempo snippet. You can’t have anything but whitespace before expanding a tempo snippet as a block must be the only thing on the line. (there does appear to be a bug in expanding when there’s something after the snippet: - a I expected that the example block would have been inserted /correctly/ > indented as in my third example above. > > > The only solution I found for getting things right is to type spaces > instead of tabulation to let my cursor go to the right column. > > Let us consider this snippet. > > #+NAME: fourth > #+begin_src org > > - an item > - subitem > H > #+end_src > > If the cursor is in the =H= position, then if I type = tabulation everything seems right and I get the same result as in > <>. > > Any help would appreciated. AFAICT everything is working as expected. Kind regards, Rasmus -- Even a three-legged dog has three good legs to lose
Re: Anyone doing any fancy customizations of source blocks?
John Kitchin writes: > Here is one approach: > > https://pank.eu/blog/pretty-babel-src-blocks.html There’s some work to generalize this here: https://github.com/integral-dw/org-menu-mode I have not had a chance to try it myself yet. That being said, the above approach still lives in my setup and doesn’t bother me too much even if it is hack :) Stay safe, Rasmus -- However beautiful the theory, one should occasionally look at the evidence
Re: [O] [patch] Check org-structure-template-alist
Aaron Ecay writes:
> Hi Rasmus,
>
> 2018ko maiatzak 27an, Rasmus-ek idatzi zuen:
>
> [...]
>
>> If there’s any better way to display the error
>
> org-display-warning?
That’s great. Thanks!
> [...]
>
>> + (mapconcat 'identity
>> + '("Please update the entries of `%s'."
>> +""
>> +"In Org 9.2 the format was changed from something akin to"
>> +" (\"s\" \"#+BEGIN_SRC ?\\n#+END_SRC\" "
>> +"to something akin to"
>> +"(\"s\" . \"src\")"
>> +"See (info \"(org)org-structure-template-alist\")"
>> +""
>> +"The following entries must be updated:"
>> +""
>> +"%s"
>> +"%s")
>> + "\n")
>
> You could use a multiline string literal. IMO itʼs less ugly (but
> still ugly...)
Same difference to me.
Rasmus
--
C is for Cookie
[O] [patch] Check org-structure-template-alist
Hi,
Here’s a patch that would check org-structure-template-alist for the "old"
format.
It just pops a user-error if the old format is detected (it checks if the
cdr of org-structure-template-alist entries is a list).
On my system, binding max-mini-window-height seems to have no effect. My
test window-total-height is 35.
(let ((max-mini-window-height 15))
(message (mapconcat 'number-to-string (number-sequence 1 15) "\n")))
If there’s any better way to display the error or check if
org-structure-template-alist is in the "old" format let me know.
Rasmus
--
Slowly unravels in a ball of yarn and the devil collects it
>From 7ae2fd392aaa5f76f65f4c88a0b1286167d6732a Mon Sep 17 00:00:00 2001
From: Rasmus <ras...@gmx.us>
Date: Sun, 27 May 2018 14:44:49 +0200
Subject: [PATCH] Check format of org-structure-template-alist
* org.el (org--check-org-structure-template-alist): New function
yielding user-error if using old org-structure-template-alist
format.
(org--insert-structure-template-mks):
* org-tempo.el (org-tempo-add-templates): Use new function
---
lisp/org-tempo.el | 2 ++
lisp/org.el | 36
2 files changed, 38 insertions(+)
diff --git a/lisp/org-tempo.el b/lisp/org-tempo.el
index b9a554ff7..a651c7b37 100644
--- a/lisp/org-tempo.el
+++ b/lisp/org-tempo.el
@@ -102,6 +102,8 @@ Tempo templates will be added."
Go through `org-structure-template-alist' and
`org-tempo-keywords-alist' and update tempo templates."
+ (mapc 'org--check-org-structure-template-alist '(org-structure-template-alist
+ org-tempo-keywords-alist))
(let ((keys (org-tempo--keys)))
;; Check for duplicated snippet keys and warn if any are found.
(when (> (length keys) (length (delete-dups keys)))
diff --git a/lisp/org.el b/lisp/org.el
index b05acd78a..c67e91489 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11727,6 +11727,41 @@ block can be inserted by pressing TAB after the string \"<KEY\"."
(string :tag "Template")))
:package-version '(Org . "9.2"))
+(defun org--check-org-structure-template-alist ( checklist)
+ "Check whether `org-structure-template-alist' is set up correctly.
+In particular, check if the Org 9.2 format is used as opposed to
+previous format.
+"
+ (let* ((elm (cl-remove-if-not (lambda (x) (listp (cdr x)))
+(or (eval checklist)
+org-structure-template-alist)))
+ (len (length elm))
+ (maxlen 3)
+ (resize-mini-windows t)
+ (message-truncate-lines nil)
+ (max-mini-window-height 15))
+(when elm
+ (user-error
+ (mapconcat 'identity
+ '("Please update the entries of `%s'."
+ ""
+ "In Org 9.2 the format was changed from something akin to"
+ " (\"s\" \"#+BEGIN_SRC ?\\n#+END_SRC\" "
+ "to something akin to"
+ "(\"s\" . \"src\")"
+ "See (info \"(org)org-structure-template-alist\")"
+ ""
+ "The following entries must be updated:"
+ ""
+ "%s"
+ "%s")
+ "\n")
+ (or checklist org-structure-template-alist)
+ (pp-to-string (cl-subseq elm 0 (min maxlen len)))
+ (if (> len maxlen)
+ (format "... And %s other entries" (- len maxlen))
+ "")
+
(defun org--insert-structure-template-mks ()
"Present `org-structure-template-alist' with `org-mks'.
@@ -11734,6 +11769,7 @@ Menus are added if keys require more than one keystroke. Tabs
are added to single key entries when more than one stroke is
needed. Keys longer than two characters are reduced to two
characters."
+ (org--check-org-structure-template-alist)
(let* (case-fold-search
(templates (append org-structure-template-alist
'(("\t" . "Press TAB, RET or SPC to write block name"
--
2.17.0
Re: [O] Localized org-mode
> is there something like localized/internationalized org? I.e. all > keywords, like :PROPERTIES: are translated to another language, > like :EIGENSCHAFTEN: (for German) so it looks more natural in a foreign > language. It is of a special importance for languages with non-latin > letters, where the mix of different languages might be > visually/esthetically disturbing and require switching of keyboard > layouts while writing. Technically it should be a simple 1-to-1 > substitution based on an org_keyword_vocabulary for a specific language. There’s a somewhat popular program called "microsoft excel" that I sometimes have the misfortune of being exposed to. It has played with the idea that you propose. Function names depends on the LOCALE. How do you find the mean of a vector, say? Well, it depends on the LOCALE of the system. My experience is that the result is not pleasant! Localization should at most (if at all) be supported via with overlays as others have pointed out, but it would be weird when inserting e.g. properties (C-c C-x p). Rasmus -- Need more coffee. . .
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Bastien <b...@gnu.org> writes: > Hi Rasmus, > > Rasmus <ras...@gmx.us> writes: > >> Do you think org-tempo should try to detect "old" versions of >> org-structure-template-alist and give a better error if it sees one? > > Yes, it definitely should detect old format and fix it. I don’t remember if I replied to this or not. In any case, it will not be able to "fix" an old template, as it can be much more complex than the new syntax. I would simply raise an error with a helpful text if the "old" format is detected. Rasmus -- m-mm-mmm- bacon!
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Hi, Aaron Ecay <aarone...@gmail.com> writes: > Hi Rasmus, > > 2018ko maiatzak 7an, Rasmus-ek idatzi zuen: > >> >> They’d already have the "old" behavior if it’s enabled by default in >> org.el. > > Indeed, my suggestion is not an alternative to keeping (what is now > called) org-tempo turned on by default indefinitely. It is an > alternative to turning org-tempo off suddenly. > >> Perhaps I’m too cruel or harsh after many years of dealing with the >> Emacs-way, but I do think that such as change is adequatly documented >> in ORG-NEWS and the manual. (Days after a new release there will also >> be a stackoverflow question for the Googlers). > > Here I am much more conservative than you: I think that puzzling users > so that they ask questions on stack overflow is an outcome that should > be avoided if possible. I also think experience shows that ORG-NEWS is > missed by a significant fraction of users. That is a nice thought, at least in theory. I guess my worry is about the "costs" of implementing such practices. Perhaps we could ask people if they want to have the ORG-NEWS file displayed when a new version of Org is installed. :) > Besides, I am a programmer not a writer so I believe in the power of > code over prose :P I am not a programmer, so perhaps therein lies the difference. >> Customize-changed would bring up the changes to >> org-structure-template-alist, which mentions Org Tempo. > > Interesting. I didnʼt know about that function. I just tried M-x > customize-changed RET Org 9.0 RET. That gives an error; it seems to > only work based on emacs versions and not package versions. Thatʼs > unfortunate, it would have been nice if people who install org from ELPA > could use the function to keep up with org changes independently from > their emacs version. (In fact, I just sent this as a feature request to > the emacs bug tracker, #31383) I did not know that. Thanks. Rasmus -- Dobbelt-A
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Hi, Bastien <b...@gnu.org> writes: >>> One remaining decision to make is: what is the future of org-tempo? I am >>> sympathetic to the idea that the best place for it eventually would be >>> org-contrib or GNU ELPA, and not org core. >> >> We don’t have make that decision now, do we? > > No. For now I'd like to get back to your original "trigger" and > continue to enhance the org-tempo code so that it allows to wrap > regions around templates. How would that work? A snippet is at the beginning of the line? Also, if I have delete-selection-mode on it might not make sense to try and "save" region when expanding a tempo snippet. Rasmus -- Evidence suggests Snowden used a powerful tool called monospaced fonts
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Aaron Ecay <aarone...@gmail.com> writes:
> AIUI the change was from a cons of (character, template string) to a
> cons of (string, template string). The relevant commit is b56df73.
That’s an irrelevant change as neither of those formats has been
published. The "old" format (9.1 and earlier) is a list of (key
template-string), e.g.
("s" "#+BEGIN_SRC ?
#+END_SRC")
The new is something like
("s" . "src")
Rasmus
--
I feel emotional landscapes they puzzle me
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Hi Aaron, Thanks for the reply. Aaron Ecay <aarone...@gmail.com> writes: > I wouldnʼt call it nagging. The user presses “<s[TAB]” expecting > something special to happen. The status quo is that nothing at all > happens. My proposal is to make something special happen. Itʼs > different than what the user expected, but it informs them of what has > changed and how to get the old behavior back if they want. They’d already have the "old" behavior if it’s enabled by default in org.el. Perhaps I’m too cruel or harsh after many years of dealing with the Emacs-way, but I do think that such as change is adequatly documented in ORG-NEWS and the manual. (Days after a new release there will also be a stackoverflow question for the Googlers). I sometimes open many new Emacs on any given day, sometimes loading my init.el sometimes not. I imagine the message would get old quickly. > Note that the only circumstance when the “nagging” happens is when a > user presses “<s[TAB]”, and it goes away when either they add > “(org-tempo-global-mode)” to their .emacs or learn a new habit of > pressing C-c C-, instead of <s[TAB] I’m perfectly happy with my (Emacs) habits :) > (We could make the warning appear only once per emacs session, if that > seems like a better balance.) Yes, that would be a must. >> There’s tools to mark thinks as obsolete in Emacs should we need to. > > There are tools to mark functions and variables obsolete when they are > used in elisp code. There is no way of warning a user about non-code > changes to the user experience, like (in this case) a changed key > binding. Customize-changed would bring up the changes to org-structure-template-alist, which mentions Org Tempo. ORG-NEWS as well. But now I’m going in circles. > We donʼt strictly have to. Obviously one approach to making the > decision is to wait and see whether org-tempo is widely adopted/used, > and remove it from core if not. But if we* can already decide on > principle that something like org-tempo belongs best in contrib or > ELPA, then we can communicate the relevant info all at once when 9.2 > is released, rather than for 9.2: “now add (require 'org-tempo) to > .emacs to keep using <s[TAB]” [...time passes, a new org release is > born...] “now you also have to install org-tempo from somewhere > else.” Perhaps. As I said, I like batteries included, but it’s not for me to decide. > *Here Iʼm using “we” loosely, I imagine it will mostly be up to you with > input from Nicolas and Bastien and perhaps others. I like the looser definition! Rasmus -- Dung makes an excellent fertilizer
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Carsten Dominik <domi...@uva.nl> writes: > On Sat, May 5, 2018 at 8:02 PM Rasmus <ras...@gmx.us> wrote: > >> Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: >> >> > Hello, >> > >> > Steve Downey <sdow...@gmail.com> writes: >> > >> >> Asking users to accept any breakage in the tool they use to get work >> done >> >> is a lot. Changes in UI in emacs are opt-in. >> >> >> >> Even if the change is the right thing to do. >> > >> > I think some of you (basically, anyone thinking we should enable "> > TAB" by default ;)) are missing the point. >> > >> > >> > The first important thing to understand is that, even if we enable >> > `org-tempo' by default, next Org release /will break/ for some of us. >> > >> > - It will break because `org-tempo' is only 99% backward-compatible. So >> > anyone having customizing templates is bound to change them. >> > >> > - It will break because there are 9 other incompatible changes between >> > 9.1 and 9.2. >> > >> > So, asking to load `org-tempo' by default just to avoid breaking users >> > set-up is a wrong argument. It will only "protect" those among us that >> > use "> > incompatible changes. IOW, updating Org from 9.1 to 9.2 will not be >> > smooth for everyone. No matter what `org-tempo' becomes. >> >> Nicolas, I have been wondering about something, reading all these posts, >> irrespective of whether tempo is loaded by default or not (I don’t care). >> >> Do you think org-tempo should try to detect "old" versions of >> org-structure-template-alist and give a better error if it sees one? I >> don’t know what the "best practice" is this case... >> > > Yes, it absolutely should. Thanks. I guess it would be enough to check if the elements of the alist are cons (newer Orgs) or lists (older orgs). A more "complex" procedure could look for at the content of the ca?dr, I guess, but I don’t know if that’s necessary. Rasmus -- I feel emotional landscapes they puzzle me
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Aaron Ecay <aarone...@gmail.com> writes: > Hi Rasmus, > > 2018ko maiatzak 5an, Rasmus-ek idatzi zuen: > >> Cool, I at least did not know that one. >> Can you a reproducible way to try it out? >> Without having to make my own templates etc. > > I havenʼt done anything with it myself. > > You can open up a blank .el file and test out some of emacsʼs built-in > templates. M-x srecode-minor-mode, and then “C-c / /” will prompt you for > the name of a template to insert. Entering file:major-mode at the > resulting prompt might be the most interesting one. Certain keys are > bound to common templates, examples are “C-c / f” for inserting a function > and “C-c / v” for a variable Srecode seems pretty neat, though it might only work in file buffers. Other than being shipped with Emacs, does it have any advantage over yas? Are there any plans to merge the two or make them more compatible? > Just as an aside, I have now also learned that emacs also includes > skeleton.el, which is yet a third template expansion library. Sigh. I think it was too restrictive. I think I also tried abbrev and found it not sufficient. Rasmus -- It was you, Jezebel, it was you
Re: [O] Moving from Jekyll to Orgmode
ST <smn...@gmail.com> writes: >> > 2. how can one create "prettified" links, i.e. /features/ instead >> > of /features.html ? Basically during the website generation for the file > >> > features.org a directory `features` needs to be created and the html >> > file placed into `features/index.html` ... Is there a tutorial on how to >> > do that? >> >> You make a wrapper around org-html-publish-to-html that creates folders >> and from filename and save file as index in the folder. The wrapper >> function is then used as the :publishing-function in >> org-publish-project-alist. >> >> Something like this (untested). >> >> (lambda (plist filename pub-dir) >> (let ((dir (make-directory (file-name-as-directory (file-name-base >> filename)) >> pub-dir))) >> (org-latex-publish-to-html plist filename dir) >> (rename-file (concat dir (file-name-base filename) ".html") >> (concat dir "index.html" >> >> >> You could also move around your source files before publishing via the >> :preparation-function. > > Thank you very much! Unfortunately I don't know lisp, so I have to learn > it first to understand your solution... but now I have something to > start with. I wish org html export will become a real static site > generator, like jekyll, hugo, etc.. I *think* that is what ox-publish is, but indeed, it’s a bit hairy to set up. Rasmus -- ⠠⠵
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Aaron Ecay <aarone...@gmail.com> writes: >> Expansion templates are a great thing, but this is only sugar for Org, >> which is totally usable without them. Besides, some facilities are >> providing it for us. This falls into (2). By design, I'm convinced we >> should not include them. I also wish that anyone involved in this thread >> can take a step back to see the whole picture. > > This is a red herring. The changes do not eliminate expansion template > code from org. They merely substitute (incompatibly) one expansion > template mechanism for a new one. > > FWIW, I do think the idea is worth exploring of getting rid of the (old > and new) template expansion code and using emacsʼs built-in SRecode > template facility. Like most of the CEDET stuff, it looks horridly > overengineered at a first glance. But it is also included with emacs by > default (unlike e.g. yasnippet which otherwise looks more pleasant to > program to me), and it would be (even more) responsive to the concerns > from emacs-devel that were quoted in your full message. To be specific, > this would entail (eventually) getting rid of the > org-structure-template-alist variable entirely, as well as the menu now > bound to C-c C-,; the former would be replaced by (AFAIUI) template > files that would be included with org and/or created by users for their > custom templates; the latter would use SRecodeʼs built-in template > selection instead. Cool, I at least did not know that one. Can you a reproducible way to try it out? Without having to make my own templates etc. Rasmus -- Not everything that goes around comes back around, you know
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > Hello, > > Steve Downey <sdow...@gmail.com> writes: > >> Asking users to accept any breakage in the tool they use to get work done >> is a lot. Changes in UI in emacs are opt-in. >> >> Even if the change is the right thing to do. > > I think some of you (basically, anyone thinking we should enable " TAB" by default ;)) are missing the point. > > > The first important thing to understand is that, even if we enable > `org-tempo' by default, next Org release /will break/ for some of us. > > - It will break because `org-tempo' is only 99% backward-compatible. So > anyone having customizing templates is bound to change them. > > - It will break because there are 9 other incompatible changes between > 9.1 and 9.2. > > So, asking to load `org-tempo' by default just to avoid breaking users > set-up is a wrong argument. It will only "protect" those among us that > use " incompatible changes. IOW, updating Org from 9.1 to 9.2 will not be > smooth for everyone. No matter what `org-tempo' becomes. Nicolas, I have been wondering about something, reading all these posts, irrespective of whether tempo is loaded by default or not (I don’t care). Do you think org-tempo should try to detect "old" versions of org-structure-template-alist and give a better error if it sees one? I don’t know what the "best practice" is this case... Thanks, Rasmus -- When in doubt, do it!
Re: [O] Moving from Jekyll to Orgmode
ST <smn...@gmail.com> writes: > Hello, > > I would like to rewrite my website using Orgmode (till now I used > Jekyll). It would be nice if you could help me with following questions: > > 1. could somebody, please, point me to a tutorial on how to create a > multilingual site? Like the orgmode.org with EN:FR:JA. Ideally it would > be if one would have page-aware language switch, i.e. if one is on the > page orgmode.org/fr/features.html and clicks JA he will be redirected to > orgmode.org/ja/features.html (and not .../ja/index.html as it is now)... I don’t know how to that. You can easily add language buttons to your documents via :html-preamble (see org-publish-project-alist). How to automatically move people to the right side based on their preferences is another thing. I know Django supports multilingual pages, so maybe their documentation discuss this issue on a more technical level. > 2. how can one create "prettified" links, i.e. /features/ instead > of /features.html ? Basically during the website generation for the file > features.org a directory `features` needs to be created and the html > file placed into `features/index.html` ... Is there a tutorial on how to > do that? You make a wrapper around org-html-publish-to-html that creates folders and from filename and save file as index in the folder. The wrapper function is then used as the :publishing-function in org-publish-project-alist. Something like this (untested). (lambda (plist filename pub-dir) (let ((dir (make-directory (file-name-as-directory (file-name-base filename)) pub-dir))) (org-latex-publish-to-html plist filename dir) (rename-file (concat dir (file-name-base filename) ".html") (concat dir "index.html" You could also move around your source files before publishing via the :preparation-function. > 3. is there a free modern "corporate" style theme for org-mode? Everything has classes so it’s easy to make a style that suits you. Just find the color and font combinations that you like. There’s an example of a technique I use here: https://gitlab.com/pages/org-mode Rasmus -- Look, it is what it is because it was what it was
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Tim Cross <theophil...@gmail.com> writes: > won't that conflict with the key binding for block editing mode? Isn’t that "C-’". Blocks are "C-c C-,". I used some program to scavenge for unused bindings in, I think, December last year and we discussed it on the list. I think the main contenders were "C-c C-." and "C-c C-," and the latter is a bit nicer on my keyboard layout... I might be have misunderstood something, if so I apologize. > Also, I think C-c , is possibly more in-line with other > template/expansion commands in other modes. Don’t know. Why? Rasmus -- Er du tosset for noge' lårt!
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Aaron Ecay <aarone...@gmail.com> writes: > Hi Rasmus, > > 2018ko maiatzak 2an, Rasmus Pank Roulund-ek idatzi zuen: >>> Finally, irrespective of which options are chosen, I think that org-tempo >>> would be better implemented in terms of a minor mode. This would allow >>> it to be autoloaded, turned on/off for different buffer(s) in an emacs >>> session, and avoid duplicating the logic for activating global minor >>> modes. Patch attached. >> >> I agree. > > OK, thatʼs good to know. Iʼve held off on any pushing of the patch to > master until everything is worked out. In the meantime, Iʼve put it in > a branch “org-tempo”. > > I also added a second commit to that branch which implements my vision > of the upgrade path (deprecation warnings, etc.) For convenience, that > patch is also attached to this email. I don’t like it, I’m afraid. It’s a bit nagging. There’s tools to mark thinks as obsolete in Emacs should we need to. > One remaining decision to make is: what is the future of org-tempo? I am > sympathetic to the idea that the best place for it eventually would be > org-contrib or GNU ELPA, and not org core. We don’t have make that decision now, do we? Rasmus -- This message is brought to you by the department of redundant departments
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Kevin Foley <kfole...@gmail.com> writes: > Bastien <b...@gnu.org> writes: > > I have to admit that Bastien's list describes my experience almost > perfectly. It look me a long time to figure out something that in the end > seemed very simple. At the time I wasn't familiar with the NEWS file and > it didn't come up in any of my online searches. It also didn't help that > site still documented the old behavior (and apparently still does > https://orgmode.org/manual/Easy-templates.html). AFAIK the maint manual is published online. Rasmus -- The right to be left alone is a human right
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Bastien <b...@gnu.org> writes: > Hi Tim, > > thanks for your thorough and balanced feedback. > > Tim Cross <theophil...@gmail.com> writes: > >> There is no solution which will make everyone happy. However, as a long >> term org user who hopes to continue using org for many more years, I >> tend to come down on the side of whatever will make org easier to >> maintain in the long term. > > For org-tempo, Rasmus wrote it so I'm inclined to listen quite > carefully at his opinion. Please don’t. I have not really made any policy decisions of sort. I only missed "<s" once it was cleaned away, and I only "improved/changed" "C-c C-," to better suit my taste. I am not a designer, I just type on my keyboard until it "stuff" works again... Anyhow, my general opinion on these matters is that I wouldn’t want to remove any batteries. I like included batteries... > ... > In fact, I'm inclined to ask the real question: if org-tempo is on by > default, who will have good reasons to turn it off and why? I certainly won’t be :) Rasmus -- However beautiful the theory, one should occasionally look at the evidence
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Aaron Ecay <aarone...@gmail.com> writes: > I would also question the decision to change the format of > org-structure-template-alist. That has caused some errors (in the sense > of calls to the elisp ‘error’ function) for me because a third > party-library (ox-reveal) still uses the old format. The change also > seems orthogonal to the switch from Finally, irrespective of which options are chosen, I think that org-tempo > would be better implemented in terms of a minor mode. This would allow > it to be autoloaded, turned on/off for different buffer(s) in an emacs > session, and avoid duplicating the logic for activating global minor > modes. Patch attached. I agree. Rasmus -- The right to be left alone is a human right
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > Hello, > > Rasmus <ras...@gmx.us> writes: > >> FWIW, I strongly disagree that Yasnippet is a suitable replacement. IMO >> it’s not at all intuitive. > > You must be kidding. Consider the following snippet: > ># key: # -- > >#+begin_src $1 >$0 >#+end_src > > In a buffer, "<s" and TAB lets me insert the language and possible > header arguments, then another TAB puts point within the block. Especially the tab behavior is what "gets me" with yasnippet. It seems erratic. Some package that I use used to auto-load it a few years back and it created a horrible mess with weird highlights and the tab key not working as expected. I have not tried it for many years, but last time I used it I had a distinct distaste for its behavior. The syntax looks nice. > No offense intended, but Yasnippet is more powerful and also more > versatile than what we offer, since we stick to "<" prefix for > historical reasons. Perhaps what we offer is also more simple. >> Why is using tempo NIH? > > Using Tempo is fine. But we're writing a template system on top of it, > which is a different beast. I am not sure I would raise it to a "template system". At most a "block insertion system". Rasmus -- To err is human. To screw up 10⁶ times per second, you need a computer
Re: [O] add blocks to org-structure-template-alist
Bastien <b...@gnu.org> writes:
> Hi Nicolas,
>
> Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
>
>> In master branch, the format has changed.
>
> With the new template mechanism, can we have rich templates like the
> one Charles quotes?
>
> (add-to-list 'org-structure-template-alist '("r" "#+begin_src rec :data?
> :type \n#+end_src" ""))
>
> allowing cursor positioning, etc?
>
> If yes, what pointer can we add to ORG-NEWS?
Not at the moment.
The particular example could be approximated with
("r" . "#+begin_src rec :data :type")
On the snippet expansion side, you can make whatever you want, see the
"<I" snippet.
It would require a different syntax to support more sophisticated blocks.
Rasmus
--
9000!
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Hi, Diego Zamboni <di...@zzamboni.org> writes: > Since a few weeks ago (around 9.1.10-11, maybe?) the “<s" expansion > seems a bit broken - if I try to use it in the middle of a file and > there is a block of the same type further down in the file, then only > the opening line of the block is inserted. So I’ve been using "C-c > C-," more, which seems to work fine. I just now realized (thanks to > Nicolas’ comment) that it works on regions, which is nice (I had been > using "org-babel-demarcate-block” - “C-c C-v d” for that). Would it be possible to send a reproducible bug-report, starting from "emacs -q"? Thanks, Rasmus -- May contains speling mistake
Re: [O] [POLL] Should Org tempo be enabled by default? (expand templates thru e.g. "<s[TAB]")
Hi, Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > We introduced a new expansion mechanism, recently bound to `C-c C-,'. > This mechanism is more in line with usual Org functions: it operates on > regions like, say, `org-insert-drawer'. It is an obvious default > expansion mechanism. > > If the big menu, we could however improve it with an "expert" UI, like > we already do for export and tags. Aside: At the moment key combinations are generated on the go (unless someone it was changed), so a full "expert-mode a la the export dispatcher" would likely not work. Of course, org-mks could be made nicer, as is obvious when compared to the export dispatcher. > Now, some users are used to "<s" constructs, and are not willing to > switch to that expansion mechanism. Fair enough. I first suggested to > use Yasnippets, which is powerful enough and easy to use. Some users > still didn't want to use that. Well. I suggested Tempo, but, admittedly, > out of the box, it is not really usable. Then Rasmus wrote Org Tempo. > > Even though Org Tempo is probably useful for a part of users, it is yet > another occurrence of NIH in Org mode. Instead of using already > available, and fitting, libraries for a task, we implement one. FWIW, I strongly disagree that Yasnippet is a suitable replacement. IMO it’s not at all intuitive. Why is using tempo NIH? > Also, it will probably prevent the default expansion mechanism to > receive feedback, and therefore, improvements (even though it is better > for basic uses) because users will not even notice the new mechanism if > the old one works out of the box. > IMO, Org Tempo should live outside of Org core, like many other > Org-related libraries. I disagree. > Some die-hard "<s" users might be annoyed if they > had to install an external library. So asking for a "(require > 'org-tempo)" was an acceptable compromise, until your disagreement. FWIW, I am indifferent to whether org-tempo is loaded by default or not as long as it’s included by default and documented in the manual. Rasmus -- May contains speling mistake
Re: [O] Release Org 9.2 soon ?
Bastien <b...@gnu.org> writes: > Hi Nicolas and all, > > Bastien <b...@gnu.org> writes: > >> I'm back from a few days off, I'll be able to make the 9.2 release >> at the end of next week. I've released 9.1.10 in the meantime. > > I'm now reading past emails and checking things for 9.2. > > Maybe we will need to release 9.1.12 before 9.2, as there are some > new bugfixes in maint. I am waiting for 9.1.12. Please consider making the release soon, as an upstream merge would have to be approved first. Thanks, Rasmus -- I hear there's rumors on the, uh, Internets. . .
Re: [O] How to keep footnotes hidden when creating a new footnote
Sharon Kimble <boudic...@skimble.plus.com> writes: > I'm writing a document that currently has over 500 footnotes, which is > then exported to latex and subsequently built into a PDF file. But every > time that I write a new footnote, all the other footnotes show as > visible, whereas previously they were hidden under their second-level > title. > > How can I get the 'old' footnotes to remain hidden, unopened and not > visible please? I’m not sure what the old way is, but maybe you’d prefer org-edit-footnote-reference for editing footnotes? Rasmus -- Tack, ni svenska vakttorn. Med plutonium tvingar vi dansken på knä!
Re: [O] Alternatives to inlinetasks? [was: Problems created by inlinetasks in agenda views]
Kaushal Modi <kaushal.m...@gmail.com> writes: > On Mon, Apr 23, 2018, 5:35 PM Eric Abrahamsen <e...@ericabrahamsen.net> > wrote: > >> >> Would there be any consideration for an inline syntax that looks more >> like a link? Personally, when I want inline TODOs, I want them because >> there's a particular chunk of text that I need to do something with. >> What about something that looks like: >> >> In 2005 there were approximately [[TODO: Verify this; SCHEDULED: >> ; :statistics:][4,500]] Confucius Institutes in operation >> worldwide. >> > > How would you distinguish between regular links and such inline TODO's when > the "link" portion is hidden? > > Would footnotes serve better? (I'm not a consumer of inline todos (yet?) so > consider this suggestion with a grain of salt :)) I’d also prefer that. I have often used inline tasks for long discussions. One downside would be that it would move the tast contents further away from the main contents it’s discussing. E.g. I have used it for discussions with co-authors and I think they’d maybe find footnotes confusing. For just me, footnotes TODOS would be great. Note, you can also have inline todos: [[TODO::Inline todo text]]. Rasmus -- Vote for proprietary math!
Re: [O] Release Org 9.2 soon ?
Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > Hello, > > Bastien <b...@gnu.org> writes: > >> yes, let's move forward. >> >> I'm back from a few days off, I'll be able to make the 9.2 release >> at the end of next week. I've released 9.1.10 in the meantime. > > Great. > > I suggest to release Org 9.1.11 by the beginning of the next week, and > merge in into Emacs. Hopefully, this will be the last update included in > Emacs 26. Fine by me, but we’d need to clear the merge with upstream beforehand. What is the best way to make a CHANGELOG from 9.1.9 to 9.1.11? Should I just copy the git log? Rasmus -- This message is brought to you by the department of redundant departments
Re: [O] Support showing stars as pretty bullets
Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > Hello, > > Alex Branham <alex.bran...@gmail.com> writes: > >> But then users of global-prettify-symbols-mode don't see the pretty >> symbols in org buffers without knowing about and activating >> org-pretty-mode. Anyway, the attached patch moves it to org-pretty.el. > > [...] > >> I've left it as a defvar since there's no way for us to know about what >> people want prettified where. Hopefully the default >> prettify-symbols-compose-p function does an OK job, but people will have >> to modify that if they customize org-pretty-alist anyway. > > I think there's a misunderstanding. To me, `prettify-symbols-mode' is > the plumbing. Org Pretty users should not have to care about it. > Likewise, when you use Org Bullets, you don't really care about how it > is done internally. > > As such, we know what people want prettified if we provide the > appropriate defcustom. > > BTW, the plumbing should be `compose-region', not > `prettify-symbols-mode'. IMO ‘prettify-symbols-mode’ is not pluming. It’s an Emacs-wide equivalent of "org-pretty-entities" (or at least the result when that variable is non-nil). IMO, the goal would be to offload more stuff into prettify-symbols-mode. Since this involves a "regexp" in a sense, compose-region might be better. In any case, the particular patch overwrites ‘prettify-symbols-alist’, meaning which symbols will be displayed will depend on whether users have their own pretty symbols loaded before the variable is being overwritten. Rasmus -- In theory, practice and theory are the same. In practice they are not
Re: [O] Bug: Usage of pmatrix yields error message dispite lack of error [9.1.9 (9.1.9-3-gb1a639-elpa @ /home/christoph/.emacs.d/elpa/org-20180402/)]
> Org-mode seems to support environment-based math formulas. However, when
> using pmatrix, the buffer *Org PDF LaTeX Output* always shows an
> error when exporting to PDF via LaTeX. This even happens for the
> simplest of matrices:
>
> \begin{pmatrix}
> 0
> \end{pmatrix}
>
> An org file with only these 3 lines of content is sufficient for
> reproducing the bug. Upon typing "C-c C-e l p", the error message "PDF
> file produced with errors." is shown in the mini buffer. The buffer *Org
> PDF LaTeX Output* shows this error message:
>
> ! Missing $ inserted.
>
> $
> l.31 \begin{pmatrix}
>
> (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/umsa.fd)
> (/usr/share/texlive/texmf-dist/tex/latex/amsfonts/umsb.fd)
> ! Missing $ inserted.
>
> $
> l.33 \end{pmatrix}
In your example they are missing. You could write
\(\begin{pmatrix}
0
\end{pmatrix}
\)
Or
#+ATTR_LATEX: :mode math :environment pmatrix
| 0 |
--
Nothing's wrong with an email that ends in a minor key
Re: [O] [Radio tables???]
Uwe Brauer <o...@mat.ucm.es> writes:
>>>> "Rasmus" == Rasmus <ras...@gmx.us> writes:
>
>> Hi Uwe,
>> Uwe Brauer <o...@mat.ucm.es> writes:
>
>>> Templates are another example of this philosophy. I still can't use the
>>> actual git master version of orgmode since the old templates have been
>>> removed and the new syntax is not really explained.
>
>> Please let me know what you are missing in terms of documentation.
>
>> For all of the annoyance of losing the old template system, the data
>> structure of the new system is surely simpler.
>
> Thanks, I will send my problems in the next days. Right now I am
> sticking to an old git version from July.
>
> I asked a while ago that I could not insert any template with the new
> system but nobody answered.
>
> Do I understand that correctly I have to rewrite my templates or can I
> use the old ones?
You can’t have very complicated templates (unless writing them in the
Tempo syntax).
Basically, you control the first line of the block.
So if you want "Rb" to expand to an src R :key val block you’d do something
like
(push ’("Rb" . "src R :key val") ’org-structure-template-alist)
Before the element would be something like
("R" . "#+begin_src R :key val\n?\n\#+end_src")
If you used to have "complicated" templates with e.g. headers, that’s not
possible ATM, but it could be added if there’s a need for it.
If you have a typical example of something you are missing, we could
either enrich the manual with how to add such a block directly with tempo.
Or we could perhaps find a way to define them.
Rasmus
--
Spil noget med Slayer!
Re: [O] [Radio tables???]
Nick Dokos <ndo...@gmail.com> writes: > Rasmus <ras...@gmx.us> writes: > >> Hi Uwe, >> >> Uwe Brauer <o...@mat.ucm.es> writes: >> >>> Templates are another example of this philosophy. I still can't use the >>> actual git master version of orgmode since the old templates have been >>> removed and the new syntax is not really explained. >> >> Please let me know what you are missing in terms of documentation. >> >> For all of the annoyance of losing the old template system, the data >> structure of the new system is surely simpler. >> >> Also let me know about any remaining features that you are missing. >> > > [apologies if this has been answered in the extensive earlier threads] > > IIUC, multi-letter abbrevs are not allowed. Is that because of tempo? > If it can be done, could we at least have two-letter abbrevs? I did > not use anything longer, but two-letter abbrevs were mnemonically > useful. There should not be such a limitation anymore, though. Strings were not supported initially as the keyboard interface to select blocks (C-c C-,) could not read more than one character. That limitation has been removed. Let me know if you find any other limitations. Rasmus -- And I faced endless streams of vendor-approved Ikea furniture. . .
Re: [O] git clone org mode
Vikas Rawal <vikasli...@agrarianresearch.org> writes: > Fellow orgers, > > The following two pages on worg both recommend using "git clone >g...@code.orgmode.org:bzg/org-mode.git” to clone the org repo. > > https://orgmode.org/worg/dev/index.html > <https://orgmode.org/worg/dev/index.html> > https://orgmode.org/worg/org-faq.html#keeping-current-with-Org-mode-development > <https://orgmode.org/worg/org-faq.html#keeping-current-with-Org-mode-development> > > When I tried this today, it asked me for a password. I was puzzled. I > then created an account on https://code.orgmode.org/ > <https://code.orgmode.org/>, added my ssh public key in the settings, > and was able to clone the repo without being bothered with the > password. > > If this is the expected method, may be the above two pages should mention > this. I guess you are right. The page should probably be a bit more detailed. You need the gig@ if you want to push. In that respect, gogs works more or less like popular site like GitLab or Github, I believe. An additional step to be able to push is to have your account "approved" for pushing to the centralized repo. Rasmus -- This message is brought to you by the department of redundant departments
Re: [O] [Radio tables???]
Hi Uwe, Uwe Brauer <o...@mat.ucm.es> writes: > Templates are another example of this philosophy. I still can't use the > actual git master version of orgmode since the old templates have been > removed and the new syntax is not really explained. Please let me know what you are missing in terms of documentation. For all of the annoyance of losing the old template system, the data structure of the new system is surely simpler. Also let me know about any remaining features that you are missing. Rasmus -- Warning: Everything saved will be lost
Re: [O] Clean up org-faces.el
Hi,
stardiviner <numbch...@gmail.com> writes:
> Add face for inline src: src_ruby{require 'library'}
>
> Here is my custom face: ...
Are you saying that we should display inline calls better?
Rasmus
--
Warning: Everything saved will be lost
Re: [O] Clean up org-faces.el
Daniele Nicolodi <dani...@grinta.net> writes: > On 08/04/2018 07:27, Rasmus wrote: >> I have been wanting to clean up org-faces.el for a couple of years. > > Only tangentially related: is there a way to have a different face for > tables content and tables structure (ie the grid)? The default blue > hurts my eyes :-) That’s a nice idea. At the moment it’s not possible as it’s the same face for table contents and table borders. It shouldn’t be too hard to add since cells are recognized by org-element. It would solve another of my issues. I typically display links in variable pitch, but when they then go into tables, it breaks the alignment. Rasmus -- Dobbelt-A
[O] Clean up org-faces.el
Hi, I have been wanting to clean up org-faces.el for a couple of years. 1. Font-lock keywords are copied over and the file is a mess to browse. 2. Some faces are basically hard-coded. It would be better to just inherit stuff and let the theme font lock dictate colors. 3. Things that must be fixed-pitch are not marked as such, making Org break with variable-pitch-mode out of the box. 4. Some faces probably could stand out a bit more. E.g. meta-lines may not need to use the same face as comments. I have tried to clean up the file (attached). It’s probably not something that should be merged until after v9.2, though. However, it would be useful to know what sort of ideas there are about faces. E.g. I know that faces are eventually to reflect the element type. Is there anything I should keep in mind? Also, is there showcase of /all/ faces that I can use to test against? Thanks, Rasmus -- Even a three-legged dog has three good legs to lose ;;; org-faces.el --- Face definitions -*- lexical-binding: t; -*- ;; Copyright (C) 2004-2018 Free Software Foundation, Inc. ;; Author: Carsten Dominik ;; Keywords: outlines, hypermedia, calendar, wp ;; Homepage: https://orgmode.org ;; ;; This file is part of GNU Emacs. ;; ;; GNU Emacs is free software: you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation, either version 3 of the License, or ;; (at your option) any later version. ;; GNU Emacs is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; You should have received a copy of the GNU General Public License ;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>. ; ;; ;;; Commentary: ;; This file contains the face definitions for Org. ;;; Code: ;;; Custom variables (defconst org-level-faces '(org-level-1 org-level-2 org-level-3 org-level-4 org-level-5 org-level-6 org-level-7 org-level-8)) (defcustom org-n-level-faces (length org-level-faces) "The number of different faces to be used for headlines. Org mode defines 8 different headline faces, so this can be at most 8. If it is less than 8, the level-1 face gets re-used for level N+1 etc." :type 'integer :group 'org-faces) (defcustom org-cycle-level-faces t "Non-nil means level styles cycle after level `org-n-level-faces'. Then so level org-n-level-faces+1 is styled like level 1. If nil, then all levels >=org-n-level-faces are styled like level org-n-level-faces" :group 'org-appearance :group 'org-faces :version "24.1" :type 'boolean) (defcustom org-agenda-deadline-faces '((1.0 . org-warning) (0.5 . org-upcoming-deadline) (0.0 . org-upcoming-distant-deadline)) "Faces for showing deadlines in the agenda. This is a list of cons cells. The cdr of each cell is a face to be used, and it can also just be like \\='(:foreground \"yellow\"). Each car is a fraction of the head-warning time that must have passed for this the face in the cdr to be used for display. The numbers must be given in descending order. The head-warning time is normally taken from `org-deadline-warning-days', but can also be specified in the deadline timestamp itself, like this: DEADLINE: <2007-08-13 Mon -8d> You may use d for days, w for weeks, m for months and y for years. Months and years will only be treated in an approximate fashion (30.4 days for a month and 365.24 days for a year)." :group 'org-faces :group 'org-agenda-daily/weekly :type '(repeat (cons (number :tag "Fraction of head-warning time passed") (sexp :tag "Face" (defcustom org-faces-easy-properties '((todo . :foreground) (tag . :foreground) (priority . :foreground)) "The property changes by easy faces. This is an alist, the keys show the area of application, the values can be `:foreground' or `:background'. A color string for special keywords will then be interpreted as either foreground or background color." :group 'org-faces :group 'org-todo :version "24.1" :type '(repeat (cons (choice (const todo) (const tag) (const priority)) (choice (const :foreground) (const :background) (defcustom org-todo-keyword-faces nil "Faces for specific TODO keywords. This is a list of cons cells, with TODO keywords in the car and faces in the cdr. The face can be a symbol, a color as a string (in which case the rest is inherited from the `org-todo' face), or a property list of attributes, like (:foreground \"blue\" :weight bold :underline t). If it is a color string, the variable `or
Re: [O] [ANN] OrgStruct is dead. Long live Orgalist.
Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > Hello, > > Eric S Fraga <esfli...@gmail.com> writes: > >> Not sure what kind of ECM you would like? I simply type in a line like >> this: >> >> 2. this is an item that has a lot of text, text that will eventually >> auto fill onto next line. > > I see. Here comes the 2018 release. Are there any plans to add this to either Org, Org contrib or ELPA? Thanks, Rasmus -- One thing that is clear: it's all down hill from here
Re: [O] [patch] Improved block insertion
Hi,
Thanks for the comments!
I have fixed up the patches.
> I don't think the old key-binding should be kept.
OK.
> Suggestion:
>
> (key (pcase (read-char-exclusive prompt)
> ((or ?\s ?\t ?\r) ?\t)
> (char char)))
Ha, actually I used pcase at first but then changed it to something more
simple. Are there any performance issues with pcase or can it be used
unconditionally?
>> +(let ((menu-choice (org--insert-structure-template-mks)))
>> + (if (equal (nth 0 menu-choice) "\t")
>> + (read-string "Structure type: ")
>> +(nth 1 menu-choice)
>
> (pcase (org--insert-structure-template-mks)
> (`("\t" . ,_) (read-string "Structure type: "))
> (`(,_ ,choice . ,_) choice))
Thanks, that’s nice.
Any worries about pushing the patches now?
Rasmus
--
I hear there's rumors on the, uh, Internets. . .
>From 06ab656f4250ee7a765550f353743056aed31c8d Mon Sep 17 00:00:00 2001
From: Rasmus <ras...@gmx.us>
Date: Sat, 7 Apr 2018 12:58:51 +0200
Subject: [PATCH 1/6] org-macs: Move org-mks from org-capture to org-macs
* lisp/org-capture.el (org-mks): Moved to org-macs.el.
* lisp/org-macs.el (org-mks): Added from org-capture.el.
The move is being done to accommodate the usage of org-mks in other
Org libraries.
---
lisp/org-capture.el | 88 -
lisp/org-macs.el| 87
2 files changed, 87 insertions(+), 88 deletions(-)
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index fd4706538..630166c21 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1479,94 +1479,6 @@ Use PREFIX as a prefix for the name of the indirect buffer."
(unless (org-kill-is-subtree-p tree)
(error "Template is not a valid Org entry or tree")))
-(defun org-mks (table title prompt specials)
- "Select a member of an alist with multiple keys.
-
-TABLE is the alist which should contain entries where the car is a string.
-There should be two types of entries.
-
-1. prefix descriptions like (\"a\" \"Description\")
- This indicates that `a' is a prefix key for multi-letter selection, and
- that there are entries following with keys like \"ab\", \"ax\"...
-
-2. Select-able members must have more than two elements, with the first
- being the string of keys that lead to selecting it, and the second a
- short description string of the item.
-
-The command will then make a temporary buffer listing all entries
-that can be selected with a single key, and all the single key
-prefixes. When you press the key for a single-letter entry, it is selected.
-When you press a prefix key, the commands (and maybe further prefixes)
-under this key will be shown and offered for selection.
-
-TITLE will be placed over the selection in the temporary buffer,
-PROMPT will be used when prompting for a key. SPECIAL is an
-alist with (\"key\" \"description\") entries. When one of these
-is selected, only the bare key is returned."
- (save-window-excursion
-(let ((inhibit-quit t)
- (buffer (org-switch-to-buffer-other-window "*Org Select*"))
- (prompt (or prompt "Select: "))
- current)
- (unwind-protect
- (catch 'exit
- (while t
- (erase-buffer)
- (insert title "\n\n")
- (let ((des-keys nil)
- (allowed-keys '("\C-g"))
- (cursor-type nil))
- ;; Populate allowed keys and descriptions keys
- ;; available with CURRENT selector.
- (let ((re (format "\\`%s\\(.\\)\\'"
- (if current (regexp-quote current) "")))
- (prefix (if current (concat current " ") "")))
- (dolist (entry table)
- (pcase entry
- ;; Description.
- (`(,(and key (pred (string-match re))) ,desc)
- (let ((k (match-string 1 key)))
- (push k des-keys)
- (push k allowed-keys)
- (insert prefix "[" k "]" "..." " " desc "..." "\n")))
- ;; Usable entry.
- (`(,(and key (pred (string-match re))) ,desc . ,_)
- (let ((k (match-string 1 key)))
- (insert prefix "[" k "]" " " desc "\n")
- (push k allowed-keys)))
- (_ nil
- ;; Insert special entries, if any.
- (when specials
- (insert "\
\n")
- (pcase-dolist (`(,key ,description) specials)
- (insert (format "[%s] %s\n" key description))
- (push key allowed-keys)))
- ;; Display UI and let user select an entry or
- ;; a sub-level prefix.
- (goto-char (point-min))
- (unless (pos-visible-in-window-p (point-max))
- (org-fit-window-to-buffer))
- (message prompt)
- (let ((pressed (char-to-strin
[O] [patch] Improved block insertion
Hi,
These patches improve the block insertion mechanisms using both the
keyboard binding and org-tempo.
I first sent these patches at Christmas, but did not have time to finish
them due to unexpected events.
On the Tempo side the cursor placement is a bit more clever. For an
"empty" source blocks, the cursor will be placed after "#+begin_src ".
For other blocks, the cursor is placed on the first line after the
"#+begin"-line. A better job is being done to detect changes. Also, long
keys arre supported!
I have added a menu system to ‘org-insert-structure-template’ based on
‘org-mks’ to accommodate long keys. It tries to make a menu of max two
keystrokes to insert a block. One can also insert a manually typed block
by clicking tab/space/ret in the top menu. An example of menu keys is
shown in the comments below.
Conflict resolution is somewhat brutal as the user is prevented from using
the system if keys are conflicting. E.g. if the following was my
org-structure-template-alist, ‘org-insert-structure-template’ would raise
an error.
(("c". "c1") ; "c[\r\t ]",
("co" . "c2") ; "co"
("com" . "c3") ; "cm"
("como" . "c4")) ; error as both "co" and "cm" are used
The alternative of dropping duplicates silently or with a warning is worse
IMO.
I have tried to make org-insert-structure-template respect indentation and
insert more space in patch 5.
Patch 6 changes the key binding of blocks to "C-c C-," as discussed in
December 2017. Let me know if this key is OK and if the old key should
still be kept.
Comments are appreciated as I’d hope to merge them ASAP.
Rasmus
--
Slaa Patienten ihjel, saa siger Feberen Pas
>From 06ab656f4250ee7a765550f353743056aed31c8d Mon Sep 17 00:00:00 2001
From: Rasmus <ras...@gmx.us>
Date: Sat, 7 Apr 2018 12:58:51 +0200
Subject: [PATCH 1/6] org-macs: Move org-mks from org-capture to org-macs
* lisp/org-capture.el (org-mks): Moved to org-macs.el.
* lisp/org-macs.el (org-mks): Added from org-capture.el.
The move is being done to accommodate the usage of org-mks in other
Org libraries.
---
lisp/org-capture.el | 88 -
lisp/org-macs.el| 87
2 files changed, 87 insertions(+), 88 deletions(-)
diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index fd4706538..630166c21 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1479,94 +1479,6 @@ Use PREFIX as a prefix for the name of the indirect buffer."
(unless (org-kill-is-subtree-p tree)
(error "Template is not a valid Org entry or tree")))
-(defun org-mks (table title prompt specials)
- "Select a member of an alist with multiple keys.
-
-TABLE is the alist which should contain entries where the car is a string.
-There should be two types of entries.
-
-1. prefix descriptions like (\"a\" \"Description\")
- This indicates that `a' is a prefix key for multi-letter selection, and
- that there are entries following with keys like \"ab\", \"ax\"...
-
-2. Select-able members must have more than two elements, with the first
- being the string of keys that lead to selecting it, and the second a
- short description string of the item.
-
-The command will then make a temporary buffer listing all entries
-that can be selected with a single key, and all the single key
-prefixes. When you press the key for a single-letter entry, it is selected.
-When you press a prefix key, the commands (and maybe further prefixes)
-under this key will be shown and offered for selection.
-
-TITLE will be placed over the selection in the temporary buffer,
-PROMPT will be used when prompting for a key. SPECIAL is an
-alist with (\"key\" \"description\") entries. When one of these
-is selected, only the bare key is returned."
- (save-window-excursion
-(let ((inhibit-quit t)
- (buffer (org-switch-to-buffer-other-window "*Org Select*"))
- (prompt (or prompt "Select: "))
- current)
- (unwind-protect
- (catch 'exit
- (while t
- (erase-buffer)
- (insert title "\n\n")
- (let ((des-keys nil)
- (allowed-keys '("\C-g"))
- (cursor-type nil))
- ;; Populate allowed keys and descriptions keys
- ;; available with CURRENT selector.
- (let ((re (format "\\`%s\\(.\\)\\'"
- (if current (regexp-quote current) "")))
- (prefix (if current (concat current " ") "")))
- (dolist (entry table)
- (pcase entry
- ;; Description.
- (`(,(and key (pred (string-match re))) ,desc)
- (let ((k (match-string 1 key)))
- (push k des-keys)
- (push k allowed-keys)
- (inse
Re: [O] Bug: Modifying org-latex-pdf-process doesn't modify the async export behaviour
Leo Vivier <leo.viv...@gmail.com> writes: > Hello, > > Thank you for pointing me in the right direction. I've created another > init file just for async-export, and not only have I got it to work, > but it's also quite a lot faster than it used to be. > > All that remains now is to find a way to re-write my function. My > knowledge of elisp if fairly limited, and I don't see how to > communicate with the background process other than by writing the > value of my toggle-variable to a file. I guess I could also make a > modularise async-init.el and control which module is loaded from the > main init.el. Would it be possible to use latexmk or rubber or one of the other "intelligent" LaTeX compilers? That /should/ automatically make the compilation as short as possible. Rasmus -- I almost cut my hair, it happened just the other day
Re: [O] Support showing stars as pretty bullets
Hi, Thanks for looking at this. I’ll definitely use this. Alex Branham <alex.bran...@gmail.com> writes: > + (setq-local prettify-symbols-alist org-prettify-alist) Hmm, wouldn’t this "break" the "normal" usage of prettify-symbols-mode? I guess it would be better to simply add symbols to prettify-symbols-alist (I believe ESS does that). Alternatively, perhaps org-prettify-alist could be locally bound in org-pretty-compose-p. Thanks, Rasmus -- Warning: Everything saved will be lost
Re: [O] Can’t include file with babel
Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > Hello, > > Rasmus <ras...@gmx.us> writes: > >> I am stitching together a number of documents to produce a report. >> >> I though I’d be clever and include subfile headings in the right order at >> the right place using babel. >> >> I do something like >> >> * Appendix to chapter N >> >> #+call: include-between(file="other-paper.org", first="appendix1", >> last="appendix3") :results value raw >> >> Producing >> >> #+RESULTS: >> >> #+include: "other-paper.org::*appendix1" :minlevel 2 >> #+include: "other-paper.org::*appendix2" :minlevel 2 >> >> #+include: "other-paper.org::*appendix3" :minlevel 2 >> >> This doesn’t work seem to work, I guess because #+include is expanded >> before anything else. > > Correct. > >> Should it be possible to include stuff like this using Babel or is it too >> circular? > > The latter. > > You can generate programmatically parts of the document with > `org-export-before-processing-hook'. That is what I suspected, and I’d probably agree. It’s no issue, really. (I also considered rearranging headings based on tags with a tree filter, but that is even more convoluted than the above approach). Thanks, Rasmus -- Sådan en god dansk lagereddike kan man slet ikke bruge mere
[O] Can’t include file with babel
Hi, I am stitching together a number of documents to produce a report. I though I’d be clever and include subfile headings in the right order at the right place using babel. I do something like * Appendix to chapter N #+call: include-between(file="other-paper.org", first="appendix1", last="appendix3") :results value raw Producing #+RESULTS: #+include: "other-paper.org::*appendix1" :minlevel 2 #+include: "other-paper.org::*appendix2" :minlevel 2 #+include: "other-paper.org::*appendix3" :minlevel 2 This doesn’t work seem to work, I guess because #+include is expanded before anything else. Should it be possible to include stuff like this using Babel or is it too circular? Thanks, Rasmus -- . . . It begins of course with The Internet. A Net of Peers
Re: [O] Prompt org-capture for buffer?
Lawrence Bottorff <borg...@gmail.com> writes:
> I've got this
>
> '(org-capture-templates
>(quote
> (("a" "Normal add" entry (file "~/org/notes.org")
> "* %(plainutc)\n%x%?"
>
> But it wants to put my captured things into ~/org/notes.org . Is there any
> way to have it prompt for which buffer to add to -- or even just put it in
> the active buffer?
You could either use "file+function" or "function" and write a function to
find location or file/buffer and location, respectively. See the
‘org-capture-templates’ docstring.
(file+function "path/to/file" function-finding-location)
A function to find the right location in the file
(function function-finding-location)
Most general way: write your own function which both visits
the file and moves point to the right location
Functions take no arguments and in the case of file+function, the function
is run from the file buffer.
Example:
(file+function "~/doc.org"
(lambda ()
(org-goto-local-search-headings
(ido-completing-read
"File note to: "
(org-element-map
(org-element-parse-buffer)
'headline
(lambda (hl)
(and (= (org-element-property :level hl) 1)
(org-element-property :title hl)
nil nil)
(forward-line 1))
:prepend t
:empty-lines-after 1)
Hope it helps,
Rasmus
--
. . . It begins of course with The Internet. A Net of Peers
Re: [O] [RFC] Could we get rid of Org specific "mark ring"
Kaushal Modi <kaushal.m...@gmail.com> writes: > On Tue, Jan 30, 2018, 12:07 AM Allen Li <vianchielfa...@gmail.com> wrote: > >> I was not aware Org had its own mark ring, and I see no use for it >> personally when Emacs's mark ring exists. >> > > Same here :) > > So also I wouldn't miss out if that feature is removed, C-u SPC works > great. I was also not aware of this and thus wouldn’t miss it, if removed. Rasmus -- You people at the NSA are becoming my new best friends!
Re: [O] Feature request: #+INCLUDE: with anchors
BTW: For your original request there’s a hack here that might work for you. AFAIR it works by updating the lines. http://endlessparentheses.com/updating-org-mode-include-statements-on-the-fly.html At one point I considered adding some sort of regexp delimiters, but I think including named objects is better in almost all cases. Rasmus -- Summon the Mothership!
Re: [O] do you need a separate LaTeX installation to export org mode files to pdf?
Christopher W Ryan <cr...@binghamton.edu> writes:
> I'm a longtime LaTeX user and a more recent org mode user. So I've always
> had LaTeX installed on any computer on which I was using org mode. I'd like
> to introduce org mode to a co-worker unfamiliar with the whole concept of
> plain text files, markup, and literate programming, etc. Would they need
> to install LaTeX too, or is org mode self-contained and able to export to
> pdf without LaTeX an friends installed?
You /could/ use latexonline. I think it even supports bibtex.
https://github.com/aslushnikov/latex-online
Here’s a minimal example.
* TODO headline
*bf* /emph/ etc.
| a |
#+begin_src emacs-lisp
(let ((str (mapconcat 'identity
'("tar -cj %f" "|"
"curl -L --post301 --post302 --post303 -F file=@-"
"\"https://latexonline.cc/data?command=%latex=%f\";
"> %b.pdf")
'" ")))
(setq org-latex-pdf-process (list str)))
#+end_src
How to include all document dependencies (e.g. images) in the tar file is
left as an exercise for the motivated reader. One could probably make a
"dumb" but effective solution by finding all instances of certain file
types in the project folder.
Needless to say, if you use this with real-life documents, you will
probably want to set up your own instance of latexonline.
Rasmus
--
There are known knowns; there are things we know that we know
Re: [O] [RFC] Moving "manual.org" into core
Bastien Guerry <b...@gnu.org> writes: > I'm all for editing manual.org instead of org.texi in the long run. > > Before moving manual.org into doc/, I'd suggest we agree on editing > variables like `fill-column' and the like: > > fill-column: 70 > org-list-description-max-indent: 5 > org-edit-src-content-indentation: ? > org-src-preserve-indentation: ? > > This is necessary so that contributors don't mess up accidentally with > the desired format. Could we use .dir-locals.el to ensure that the correct settings are loaded? As for their values, I have no strong preferences, but I’d prefer settings are either automatically loaded or that they are like the default settings so that one can just use "emacs -q". Rasmus -- Not everything that goes around comes back around, you know
Re: [O] Feature request: #+INCLUDE: with anchors
ed...@openmail.cc writes: > Hello, > > I have seen this syntax in markdown (one of the many versions): > > !listing > path/to/file.ext > start=ini_keyword end=end_keyword > > Here, ~file.ext~ is a source file, and both ~ini_keyword~ and > ~end_keyword~ are text strings in the text delimiting what should be > included (responsibility of the writer to make sure they are > unique). I think that having something like this in Org would be > nice. I am aware of the ~:lines~ option, but having something like > this would not require an update of the numeric reference every time > the referenced file changes. What would happen if one of the keywords aren’t unique? Something similar can already be done in Org. See this part of the manual: Inclusions may specify a file-link to extract an object matched by org-link-search (see Search options). To extract only the contents of the matched object, set :only-contents property to non-nil. This will omit any planning lines or property drawers. The ranges for :lines keyword are relative to the requested element. Some examples: #+INCLUDE: "./paper.org::#theory" :only-contents t Include the body of the heading with the custom id ‘theory’ #+INCLUDE: "./paper.org::mytable" Include named element. #+INCLUDE: "./paper.org::*conclusion" :lines 1-20 Include the first 20 lines of the headline named ‘conclusion’. Rasmus -- Tack, ni svenska vakttorn. Med plutonium tvingar vi dansken på knä!
Re: [O] Tab-completion no longer works?
Diego Zamboni <di...@zzamboni.org> writes: > Hi Martin, > > I discovered this only yesterday, when I started using org-mode from a git > checkout and the shortcuts stopped working. Turns out this functionality > now has to be enabled by loading the org-tempo library: > https://code.orgmode.org/bzg/org-mode/src/master/lisp/org-tempo.el. In > principle, you can reenable them just by adding (require 'org-tempo) in > your Emacs config. The first time I did this, I was getting an error which > seemed to be caused by the value of the org-structure-template-alist > variable. I hadn't modified it myself, but I went into its customize screen > and reset it to the default, and that fixed the problem. Note that ‘org-structure-template-alist’ will change again. There’s a patch posted on December 21 that I have got to finish. Rasmus -- The Kids call him Billy the Saint
[O] [patch] Snippet expansion
Hi,
The first patches adds string keys to snippet expansion. For tempo, this
is straight-forward.
For the interactive prompt there’s an org-mks interface. It limited to at
most two keys (this shouldn’t be much of a limitation TBH). So for
instance if the key is "prop" the interactive prompt will be "p", "pr",
"po" or "pp".
The second patch are various improvements for org-tempo, e.g. to put the
cursor at a better place. org-tempo now also do some checks wrt. new
structure templates.
The third patch is more experimental and tries to be more "clever" when
using the interactive interface, e.g. with newlines. The code is now a
lot more complicated, and I’m not sure it’s any more pleasant or
DWIMish...
Thanks,
Rasmus
--
Vote for Dick Taid in an election near you!
>From 369a79e2190726aed2aa5dbe71fe2e99d9a59b86 Mon Sep 17 00:00:00 2001
From: Rasmus <ras...@gmx.us>
Date: Thu, 21 Dec 2017 12:55:35 +0100
Subject: [PATCH 2/4] org-structure-template-alist: Use string keys
* lisp/org-tempo.el (org-tempo-keywords-alist):
(org-tempo-setup):
(org-tempo-add-templates): Use string keys
* lisp/org.el (org-structure-template-alist): Use string keys.
(org-insert-structure-template--mks):
(org-insert-structure-template--unique-keys): New functions for block selection.
(org-insert-structure-template): Use new block selection.
fix
---
lisp/org-tempo.el | 13
lisp/org.el | 98 +++
2 files changed, 85 insertions(+), 26 deletions(-)
diff --git a/lisp/org-tempo.el b/lisp/org-tempo.el
index 86e7b51eb..92a97c752 100644
--- a/lisp/org-tempo.el
+++ b/lisp/org-tempo.el
@@ -51,10 +51,10 @@
"Tempo tags for Org mode")
(defcustom org-tempo-keywords-alist
- '((?L . "latex")
-(?H . "html")
-(?A . "ascii")
-(?i . "index"))
+ '(("L" . "latex")
+("H" . "html")
+("A" . "ascii")
+("i" . "index"))
"Keyword completion elements.
Like `org-structure-template-alist' this alist of KEY characters
@@ -76,6 +76,7 @@ For example \"<l\" at the beginning of a line is expanded to
(org-tempo-add-templates)
(tempo-use-tag-list 'org-tempo-tags)
(setq-local tempo-match-finder "^ *\\(<[[:word:]]\\)\\="))
+ (setq-local tempo-match-finder "^ *\\(<[[:word:]]+\\)\\="))
(defun org-tempo-add-templates ()
"Update all Org Tempo templates.
@@ -102,7 +103,7 @@ Goes through `org-structure-template-alist' and
(defun org-tempo-add-block (entry)
"Add block entry from `org-structure-template-alist'."
- (let* ((key (format "<%c" (car entry)))
+ (let* ((key (format "<%s" (car entry)))
(name (cdr entry)))
(tempo-define-template (format "org-%s" (replace-regexp-in-string " " "-" name))
`(,(format "#+begin_%s " name) p '> n n
@@ -114,7 +115,7 @@ Goes through `org-structure-template-alist' and
(defun org-tempo-add-keyword (entry)
"Add keyword entry from `org-tempo-keywords-alist'."
- (let* ((key (format "<%c" (car entry)))
+ (let* ((key (format "<%s" (car entry)))
(name (cdr entry)))
(tempo-define-template (format "org-%s" (replace-regexp-in-string " " "-" name))
`(,(format "#+%s: " name) p '>)
diff --git a/lisp/org.el b/lisp/org.el
index e66e6d543..10e7682af 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -11876,16 +11876,16 @@ keywords relative to each registered export back-end."
"TITLE:" "TODO:" "TYP_TODO:" "SELECT_TAGS:" "EXCLUDE_TAGS:"))
(defcustom org-structure-template-alist
- '((?a . "export ascii")
-(?c . "center")
-(?C . "comment")
-(?e . "example")
-(?E . "export")
-(?h . "export html")
-(?l . "export latex")
-(?q . "quote")
-(?s . "src")
-(?v . "verse"))
+ '(("a" . "export ascii")
+("c" . "center")
+("C" . "comment")
+("e" . "example")
+("E" . "export")
+("h" . "export html")
+("l" . "export latex")
+("q" . "quote")
+("s" . "src")
+("v" . "verse"))
"Structure completion elements.
This is an alist of characters and values. When
`org-insert-structure-template' is called, an additional key is
@@ -11898,20 +11898,78 @@ corresponding structure is inserted, with \"#+BEGIN_\" and
(string :tag "Template")))
:package-
Re: [O] TIL about use of eval in user Org macros.. Documentation?
Kaushal Modi <kaushal.m...@gmail.com> writes:
> Hello,
>
> The commit message in this commit is golden:
> http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=3ac619c8ac9934a2a1368f3de8ffad951f900067
>
> Using that info, I came up with a "classified" version of n macro for
> markdown/HTML:
>
> #+MACRO: sec (eval (concat "" (number-to-string
> (org-macro--counter-increment $1 $2)) ""))
>
> Based on that I have two questions:
> 1. Can you please document the use of eval form in Org macro definitions
> in the Org manual(.org)? Its awesome wasn't evident to me until I read
> that commit message.
I guess it isn’t documented in the manual...
I agree, there could be a second example and the mention of using lisp or
at least a mention of the ‘org-export-global-macros’ docstring.
> 2. (Another question on canonical approach) What would be the recommended
> approach for an exporter backend to add new
> macros or override existing macros (like "n" macro to wrap the string with
> HTML class as an example)? Should it update
> org-macro-templates in org-export-before-processing-hook? or something
> similar?
Do you really need to overwrite an old macro? Couldn’t you define a new
macro? org-export-before-processing-hook is definitely the right hook,
cf. ‘org-export-as’.
(defun fooreplace (backend)
(when (eq backend 'mybackend)
(goto-char (point-min))
(while (search-forward-regexp "{{{foo\\((?\\)" nil t)
(replace-match "{{{myfoo\\1"))
(goto-char (point-max))
(insert "\n#+macro: myfoo mybar\n"
Rasmus
--
May contains speling mistake
Re: [O] Poll: new keybinding for org-insert-structure-template?
Eric Abrahamsen <e...@ericabrahamsen.net> writes:
> Eric Abrahamsen <e...@ericabrahamsen.net> writes:
>
>> Rasmus <ras...@gmx.us> writes:
>>
>>> Eric Abrahamsen <e...@ericabrahamsen.net> writes:
>>>
>>>> Eric Abrahamsen <e...@ericabrahamsen.net> writes:
>>>>
>>>>> Rasmus <ras...@gmx.us> writes:
>>>>>
>>>>>> Kaushal Modi <kaushal.m...@gmail.com> writes:
>>>>>>
>>>>>>> On Fri, Dec 15, 2017 at 6:23 AM Rasmus <ras...@gmx.us> wrote:
>>>>>>>
>>>>>>>> The only way it’s "bad" is in the sense it limits the flexibility of
>>>>>>>> snippets, like "<s". As you point out, if I add "<sr" as an "src R"
>>>>>>>> block
>>>>>>>> I can no longer have "<s" as plain "src" block.
>>>>>
>>>>> I don't see any way around that. Any system that allows string keys of
>>>>> arbitrary length is going to run into that problem.
>>>>
>>>> One possible fix, a bit arbitrary: in the default value, provide
>>>> as an artificial "stop key" in the sub-menus. So "s" starts the "source
>>>> code" sub-menu, and a after that simply inserts "#+begin_src", and
>>>> leaves point after that.
>>>
>>> Yeah, I tried to suggest that earlier (unless I didn’t say it), but I
>>> might not have expressed the idea in an understandable manner :)
>>
>> Maybe I missed it!
>>
>>> I think that would be the best approach, but there’s no infrastructure
>>> that I know of that does this ATM (but I haven’t had a lot of time lately,
>>> so my knowledge on this issue is limited!).
>>
>> Can't we do this with tempo? It will have to be "handmade", not
>> automatic, but:
>>
>> '(("s" "Source Code")
>> ("se" "Elisp" "src elisp")
>> ("sp" "Python" "src python")
>> ("TAB" "Empty" "src ")
>> ...etc
>> ("e" "Export Block")
>> ("eh" "HTML" "export html")
>> ("el" "LaTeX" "export latex")
>> ("TAB" "Empty" "export ")
>> ...etc
>> ("v" "Verbatim" "verbatim")
>> ("q" "Quote" "quote")
>> ("E" "Example" "example")
>> ...etc
>> )
>
> Ahem, should have actually tried that first:
>
> (org-mks
> '(("s" "Source Code")
>("se" "Elisp" "src elisp")
>("sp" "Python" "src python")
>("s\t" "Empty" "src ")
>("e" "Export Block")
>("eh" "HTML" "export html")
>("el" "LaTeX" "export latex")
>("s\t" "Empty" "export ")
>("v" "Verbatim" "verbatim")
>("q" "Quote" "quote")
>("E" "Example" "example"))
> "Insert Block" "Block: ")
>
> It's a bit ugly, but it works...
Great find; I didn’t realize we can use tab here!
I’ll try to build the mks list automatically. It will be a bit annoying,
as we’ll have to figure out valid keys for things like "prop".
Rasmus
--
Lasciate ogni speranza o voi che entrate: siete nella mani di'machellaio
Re: [O] master: org-complete-expand-structure-template gone?
Uwe Brauer <o...@mat.ucm.es> writes: > Hi > > I just pulled the actual master (the last time I did this was in July). > It seems that the function org-complete-expand-structure-template is > gone. > > Is this true? If so > > - what is the substitute. org-tempo.el and ‘org-insert-structure-template’. It’s still work in progress. > - what is the rationale to break backward compatibility? There’s a long thread about it. I don’t remember the main argument for removing it. > - couldn't there be a file announcing deleted or renamed functions. >I tried to search the logs but could not find any reference to >when I was deleted and why. It’s noted in ORG-NEWS: *** ~org-try-structure-completion~ Org Tempo may be used as a replacement. See details above. Rasmus -- In theory, practice and theory are the same. In practice they are not
Re: [O] ox-publish export subtree scopes?
Narendra Joshi <narendr...@gmail.com> writes:
> Kaushal Modi <kaushal.m...@gmail.com> writes:
>
>> On Tue, Dec 5, 2017 at 7:31 AM Rasmus <ras...@gmx.us> wrote:
>>
>> If you have any suggestions on how to improve ox-publish to
>> better suit
>> please share them.
>>
>>
>> Hello Rasmus,
>>
>> I'd like to make the ox-publish based exporting working for my
>> ox-hugo[1] package but so far have been unsuccessful.
>>
>> The main reason is that org-foo-publish-to-bar functions take only
>> plist, filename and pub-dir as args. I miss the ability to first pick
>> a subtree scope from the specific Org file and then export only that.
>> Is something like that already possible which I am missing?
>>
>> In addition, when given a file name, I need to auto-decide (i) if I
>> need to cycle through "valid" subtrees (see more about that below)
>> and export those subtrees,or (ii) export the whole Org file if #
>> +TITLE is present.
>>
>> So I ended up with org-hugo-export-wim-to-md[2] ("wim" stands for
>> What I Mean). Below is a snippet from its doc string:
>>
>> =
>> - If the current subtree has the \"EXPORT_FILE_NAME\" property,
>> export
>> that subtree.
>> - If the current subtree doesn't have that property, but one of its
>> parent subtrees has, then export from that subtree's scope.
>> - If none of the subtrees have that property (or if there are no Org
>> subtrees at all), but the Org #+TITLE keyword is present,
>> export the whole Org file as a post with that title (calls
>> `org-hugo-export-to-md' with its SUBTREEP argument set to nil).
>>
>> - If ALL-SUBTREES is non-nil, export all valid Hugo post subtrees
>> \(that have the \"EXPORT_FILE_NAME\" property) in the current file
>> to multiple Markdown posts.
>> - If ALL-SUBTREES is non-nil, and again if none of the subtrees have
>> that property (or if there are no Org subtrees), but the Org #
>> +TITLE
>> keyword is present, export the whole Org file.
>>
>> - If the file neither has valid Hugo post subtrees, nor has the
>> #+TITLE present, throw a user error. If NOERROR is non-nil, use
>> `message' to display the error message instead of signaling a user
>> error.
>> =
>>
>> And I use a Makefile[3] to find all Org files in the current directly
>> and call the above function, which then does the right thing as
>> explained in the conditions above.
>>
>> Is there any way to call org-publish to export either the entire file
>> or cycle through the file and export the subtrees matching a
>> predicate?
>>
>> [1]: https://github.com/kaushalmodi/ox-hugo
>> [2]: https://github.com/kaushalmodi/ox-hugo/blob/
>> 832a5d7424013f60b77354ec28613440afac0269/ox-hugo.el#L2424-L2448
>> [3]: https://github.com/kaushalmodi/ox-hugo/blob/master/Makefile
>> --
>>
>> Kaushal Modi
>
> I have faced something similar (or maybe not very similar) while using
> `org-publish' for my static blog. I wanted to wrap everything inside
> body in a container and a row (bootstrap classes). The functions
> provided do not let me do this conveniently. I can define `content',
> `preamble' and `postamble' but cannot wrap all three of them inside a
> `div' without overriding the whole export function.
For that you could use a filter, which may or may not be convinient.
(add-to-list
'org-export-filter-final-output-functions
(defun rasmus/div-body (body backend info)
(when (and (org-export-derived-backend-p backend 'html)
;; Add something to identify your project if using same
;; init.el for "normal" usage and publishing usage.
)
(replace-regexp-in-string
"" "\n"
(replace-regexp-in-string ""
"\n"
body)
Rasmus
--
Bang bang
Re: [O] Poll: new keybinding for org-insert-structure-template?
Eric Abrahamsen <e...@ericabrahamsen.net> writes: > Eric Abrahamsen <e...@ericabrahamsen.net> writes: > >> Rasmus <ras...@gmx.us> writes: >> >>> Kaushal Modi <kaushal.m...@gmail.com> writes: >>> >>>> On Fri, Dec 15, 2017 at 6:23 AM Rasmus <ras...@gmx.us> wrote: >>>> >>>>> The only way it’s "bad" is in the sense it limits the flexibility of >>>>> snippets, like "<s". As you point out, if I add "<sr" as an "src R" block >>>>> I can no longer have "<s" as plain "src" block. >> >> I don't see any way around that. Any system that allows string keys of >> arbitrary length is going to run into that problem. > > One possible fix, a bit arbitrary: in the default value, provide > as an artificial "stop key" in the sub-menus. So "s" starts the "source > code" sub-menu, and a after that simply inserts "#+begin_src", and > leaves point after that. Yeah, I tried to suggest that earlier (unless I didn’t say it), but I might not have expressed the idea in an understandable manner :) I think that would be the best approach, but there’s no infrastructure that I know of that does this ATM (but I haven’t had a lot of time lately, so my knowledge on this issue is limited!). Rasmus -- 9000!
Re: [O] run shell command after publishing project
Hi, Matt Price <mopto...@gmail.com> writes: > I'm setting up a new workflow using Kauhsal's ox-hugo. I keep all my > course materials in a few org files & publish to hugo-flavoured markdown. > My source materials live in one git repo, and my website in another. After > exporting any of my my courses to the local hugo directory, I'd like to run > a shell script that I'll keep in my org-files directory. Do you mean commit or publish instead of export? Otherwise you might have to keep track of whether you are exporting to buffer as a buffer still has a default-directory. It would be easier to publish. > That script > - cds to the website repo directory, commits changes to the website master > branch, - runs hugo, > - switches to the "public" directory of compiled html pages, which has a > worktree checked out to the gh-pages branch, > - commits changes there as well, and then > - pushes both branches to github. > > The script seems to work OK, and now I would like to run it every time I > export from the appropriate projects. Is there a good way for me to do > this? I guess a hook that only runs under certain conditions? That is a sane approach with github pages, indeed. I did something similar when I used github pages, but with ox-publish. My ‘:preparation-function’ was (defun project-prep-function () (interactive) (or (zerop (shell-command (format "cd %s && git checkout master" project-main-dir))) (error (format "error checking out master in %s" project-main-dir And my ‘:completion-function’ was as follows where ‘project-tmp-dir’ the ‘:publishing-directory’. (defun project-completion-function () (interactive) (let ((cd (format "cd %s && " project-main-dir))) (shell-command (concat cd "git commit -am \"auto-check-in\"")) (or (zerop (shell-command (concat cd "git checkout gh-pages"))) (error (format "error checking out gh-pages in %s" project-main-dir))) (or (zerop (shell-command (format "mv %s/*.html %s" project-tmp-dir project-main-dir))) (error "error moving files")) (or (zerop (shell-command (concat cd "git add *.html && git commit -am 'updated html'"))) (error "error adding html files")) (or (zerop (shell-command (concat cd "git push origin gh-pages"))) (warn "error pushing gh-pages")) (or (zerop (shell-command (concat cd "git checkout master"))) (error "error checking out master" > If I can get this to work, and then also auto export every time I commit > the org-files to master (maybe with a post-commit git hook of ~emacsclient > -e '(org-publish-project "course1"~ ?), then I will maybe be almost happy! If you use ox-publish you could auto-commit whenever you publish a project. But I guess you could also use a hook. I use this to publish: emacs --batch --no-init-file --load publish.el --funcall org-publish-all I do it via Gitlab CI, though, as I only want to keep track of source files. pages: script: - emacs --batch --no-init-file --load publish.el --funcall org-publish-all artifacts: paths: - public Rasmus -- Enough with the blah blah!
Re: [O] Restore old easy template feature (Re: function for inserting a block)
Matt Price <mopto...@gmail.com> writes: > On Wed, Nov 8, 2017 at 9:08 AM, Bastien Guerry <b...@gnu.org> wrote: > >> Hi Kaushal, >> >> Kaushal Modi <kaushal.m...@gmail.com> writes: >> >> > I am suggesting to have a minor mode that simply binds "<" to do the >> > template insertion (only when that is typed at BOL with optional >> > leading whitespace, or if a region is selected). >> >> I think this is a great suggestion and brings the best of both the new >> and the old system. >> >> I cannot test this myself until this week-end, but I'd happy too then. >> > > I guess I missed this ocnversation while I was busy wiht other stuff -- > the old easy templating has been removed? I am certainly very sorry to see > it go, esp. as I have found yasnippet to work only intermittently in > org-mode buffers (at least for me). I see Kaushal has added it back in > his config files, but if someone has a slightly less specialized solution > for restoring it I would love to see it. > > I see Nicolas's point that this functionality exists elsewhere, but maybe > someone can point to a ready-made replacement for those of us who rely on > <s, etc., as part of our daily workflow? (require ’org-tempo) At the moment you can only use one character after the "<" cf. ‘org-structure-template-alist’. Perhaps this will change in the future. Rasmus -- History is what should never happen again
Re: [O] "Minimal" LaTeX export
Hi, Would the body only export option in the export dispatcher work? (C-c C-e and then C-b)? Rasmus -- C is for Cookie
Re: [O] Poll: new keybinding for org-insert-structure-template?
Kaushal Modi <kaushal.m...@gmail.com> writes: > On Fri, Dec 15, 2017 at 6:23 AM Rasmus <ras...@gmx.us> wrote: > >> The only way it’s "bad" is in the sense it limits the flexibility of >> snippets, like "<s". As you point out, if I add "<sr" as an "src R" block >> I can no longer have "<s" as plain "src" block. > > > May be have "<ss" insert plain source block, "<ee", plain export block? I wouldn’t really like that. > I missed this in the original conversation, but in the cases where plain > source/export blocks are inserted, does the point move to where the > language/backend needs to be typed? When using Org Tempo an extra space is always inserted. It probably should only do it with blocks that support arguments, actually. ATM I don’t think spaces are inserted when using ‘org-insert-structure-template’, but I they’ll probably be consistent eventually. Rasmus -- To err is human. To screw up 10⁶ times per second, you need a computer
Re: [O] Poll: new keybinding for org-insert-structure-template?
Eric Abrahamsen <e...@ericabrahamsen.net> writes: > That's not so bad, is it? The only way it’s "bad" is in the sense it limits the flexibility of snippets, like "<s". As you point out, if I add "<sr" as an "src R" block I can no longer have "<s" as plain "src" block. Unless, the meaning of key in org-structure-template-alist is handled differently in the case of snippet expansion and insertion via org-insert-structure-template. Rasmus -- In theory, practice and theory are the same. In practice they are not
Re: [O] Poll: new keybinding for org-insert-structure-template?
Eric Abrahamsen <e...@ericabrahamsen.net> writes:
> Rasmus <ras...@gmx.us> writes:
>
>> Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
>>
>>> Hello,
>>>
>>> Rasmus <ras...@gmx.us> writes:
>>>
>>>> Nicolas, are there any public interfaces to make ox export like
>>>> interfaces?
>>>
>>> No, there isn't. However, Org provides `org-mks'.
>>
>> Good point. It isn’t quite as nice as the export dispatcher. Let’s wait
>> and see what Eric prefers.
>
> I don't have to own this! I don't have a strong feeling about it, and
> left to my own devices would just keep the single-character keys.
It’s pretty nice and quick with only one character.
> But I see why people would want more/longer keys, and better
> discoverability.
Discoverability is nice to have, but it’s a secondary issue.
> The main desires are:
>
> 1. String keys of arbitrary length.
> 2. Discoverability: either a window of choices pops up automatically, or
>you can do it with TAB, etc.
> 3. Ideally, you don't have to hit an extra key to finish.
>
> Given that, it seems to me that `org-mks' is just fine. It doesn't do as
> much as the export dispatcher, but I don't see that it needs to.
It doesn’t seem to offer a way to distinguish between a single "a" and
"ab".
(org-mks '(("a" "a.. templates")
("a" "export ascii" "")
("ab" "abstract" "")
("l" "latex" ""))
"Select a template"
"Template key: "
'(("q" "Abort")))
Perhaps the best way would be to automatically reserve upper case letters
for blocks with keys longer than one character, although that seems a bit
arbitrary.
(org-mks '(("A" "a.. templates")
("a" "export ascii" "")
("Ab" "abstract" "")
("l" "latex" ""))
"Select a template"
"Template key: "
'(("q" "Abort")))
Rasmus
--
And I faced endless streams of vendor-approved Ikea furniture. . .
Re: [O] Financial data into an org-mode table
You could use the various R libraries and convert it to an Org table via
ob-R.el.
#+begin_src R :colnames yes
library(quantmod)
x = getSymbols("YHOO",src="google", auto.assign=FALSE)
x[sprintf("%s/", Sys.Date()-7)]
#+end_src
Rasmus
--
Summon the Mothership!
Re: [O] Poll: new keybinding for org-insert-structure-template?
Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > Hello, > > Rasmus <ras...@gmx.us> writes: > >> Nicolas, are there any public interfaces to make ox export like >> interfaces? > > No, there isn't. However, Org provides `org-mks'. Good point. It isn’t quite as nice as the export dispatcher. Let’s wait and see what Eric prefers. Rasmus -- Send from my Emacs
Re: [O] Poll: new keybinding for org-insert-structure-template?
Hi, >> Let me know when you want me to do the change to strings. > > No time like the present! I don't think there's anything else remaining > to be done. One stumbling block is how to input key strings to org-insert-structure-template. Currently, it employs read-key which is really fast. The other easy alternative is completing-read with the keys. However, there you’d have to click RET at the end. The ideal interface for inputting the keys is something like the ox expert export UI. I looked at the code and it seems a bit complex. Nicolas, are there any public interfaces to make ox export like interfaces? Rasmus -- m-mm-mmm- bacon!
Re: [O] Poll: new keybinding for org-insert-structure-template?
Eric Abrahamsen <e...@ericabrahamsen.net> writes: > Hello all, > > Rasmus' org-tempo patch has landed, and it's time to make a few > adjustments to org-insert-structure-template: I think we're moving to > string keys in the template alist, rather than character keys, Let me know when you want me to do the change to strings. > and also > some people noted that the keybinding "C-c C-x w" is too close to "C-c > C-x C-w", which kills a whole subtree. Not a good command to run > accidentally! Two other things that might be nice to changer are - Perhaps there could be a space after at least "#+begin_src" so that it’s ready to insert :keys. - Perhaps there could be a newline between "#+begin_x" and "#+end_x". These things might already have been discussed in which case I missed them. > Given that the template system has been re-instated, are there any good > suggestions out there for a new keybinding for > `org-insert-structure-template'? This is the command that wraps existing > text in blocks. These aren’t too bad to typo on my keyboard: C-c C-. or C-c C-, C-c C-x s might make sense. It’s OKish to type on my keyboard layout, but no harder than C-c C-x C-w. free-keys.el can be used to identify combinations, although it isn’t bullet-proof. Rasmus -- However beautiful the theory, one should occasionally look at the evidence
Re: [O] [patch] structure snippet completions
"Berry, Charles" <ccbe...@ucsd.edu> writes: >> On Dec 8, 2017, at 1:20 PM, Rasmus <ras...@gmx.us> wrote: >> > >>> >>> A minor gotcha: if you `(require 'org-tempo)' after an org buffer has >>> been created you will need to (org-mode-restart) the buffer to enable >>> completions. I got stuck trying to add custom templates until I >>> realized this. >> >> It shouldn’t do that since this is near the bottom of org-tempo: >> >>(when (eq major-mode 'org-mode) (org-tempo-setup)) >> >> On my system it works in the first buffer where I require org-tempo, even >> without reloading. > > > Yes. It does that for me, too. But this only affects the buffer from which I > `(require 'org-tempo)'. I hadn’t thought of that, but that is rather annoying. Requiring Org Tempo now runs ‘org-tempo-setup’ on all active Org buffers (commit 3efb000739362). Thanks, Rasmus -- Hooray!
Re: [O] [patch] structure snippet completions
"numbch...@gmail.com" <numbch...@gmail.com> writes:
> error report when I `(require 'org-tempo)`
Because your org-structure-template-alist is mal-formatted:
("Q" "#+BEGIN_SRC
sql-mode ?\n\n#+END_SRC" "#+BEGIN_SRC sql-mode ?\n\n#+END_SRC")
Rasmus
--
The right to be left alone is a human right
Re: [O] [patch] structure snippet completions
"Berry, Charles" <ccbe...@ucsd.edu> writes: >> On Dec 7, 2017, at 3:37 PM, Rasmus <ras...@gmx.us> wrote: >> >> I have also pushed the code. "<s"-like snippet expansion should be >> enabled by requiring org-tempo. >> > > Thanks. I was in a deep funk without "<s" and friends. Feeling better now. I am happy that I am able to help you for once! >> Let me know about any issues. >> > > Maybe make `tempo-match-finder' be "^ *\\(<[[:word:]]+\\)" so it will > match things like "<la" when I want a latex align environment. Or let > the user customize it. At the moment snippets with more than one character isn’t supported. Note that the car of org-structure-template-alist elements is now a character. "Snippet-strings" (like "la") will be re-added soon cf. the email from Eric earlier on in this thread. > A minor gotcha: if you `(require 'org-tempo)' after an org buffer has > been created you will need to (org-mode-restart) the buffer to enable > completions. I got stuck trying to add custom templates until I > realized this. It shouldn’t do that since this is near the bottom of org-tempo: (when (eq major-mode 'org-mode) (org-tempo-setup)) On my system it works in the first buffer where I require org-tempo, even without reloading. Which version of Emacs are you using? Rasmus -- A clever person solves a problem. A wise person avoids it
Re: [O] [patch] structure snippet completions
Kaushal Modi <kaushal.m...@gmail.com> writes:
> On Thu, Dec 7, 2017 at 6:51 PM Rasmus <ras...@gmx.us> wrote:
>
>> Rasmus <ras...@gmx.us> writes:
>> One possible "bug" that I discovered is illustrated by the following
>> example.
>>
>> * foo
>> suggested indention
>> <s|
>>
>> When I tab at point ("|") extra indention will be stripped. I don’t
>> know if this is something that should be fixed.
>>
>
> That's does look like a bug. The preservation of indentation is especially
> useful if you want source block in nested lists.
>
> #+BEGIN_EXAMPLE
> Outside list
> #+END_EXAMPLE
>
> - list level 1
>
> #+BEGIN_EXAMPLE
> At level 1
> #+END_EXAMPLE
>
> - list level 2
>
> #+BEGIN_EXAMPLE
> At level 2
> #+END_EXAMPLE
In that example everything would work fine, though. For it not to work
you’d have alter your example to something like this:
#+BEGIN_EXAMPLE
Outside list
#+END_EXAMPLE
- list level 1
#+BEGIN_EXAMPLE
example with extra indention
#+END_EXAMPLE
Rasmus
--
Lasciate ogni speranza, voi che leggete questo.
Re: [O] [patch] structure snippet completions
Rasmus <ras...@gmx.us> writes:
> Hi,
>
> Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
>
>> It looks like a typo, but the two lines above are commented.
>
> Indeed. Thanks.
>
>> Also, would it make sense to add a few tests?
>
> I never feel very creative about tests but I have added some.
>
> I have also pushed the code. "<s"-like snippet expansion should be
> enabled by requiring org-tempo.
>
> Let me know about any issues.
One possible "bug" that I discovered is illustrated by the following
example.
* foo
suggested indention
<s|
When I tab at point ("|") extra indention will be stripped. I don’t
know if this is something that should be fixed.
Rasmus
--
I almost cut my hair, it happened just the other day
Re: [O] [patch] structure snippet completions
Hi, Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > It looks like a typo, but the two lines above are commented. Indeed. Thanks. > Also, would it make sense to add a few tests? I never feel very creative about tests but I have added some. I have also pushed the code. "<s"-like snippet expansion should be enabled by requiring org-tempo. Let me know about any issues. Rasmus -- Sådan en god dansk lagereddike kan man slet ikke bruge mere
Re: [O] 27.0.50;Missing requirement in org-gnus.el
Kaushal Modi <kaushal.m...@gmail.com> writes: > On Tue, Dec 5, 2017 at 7:17 AM Rasmus <ras...@gmx.us> wrote: > >> Should we prepare another v9.1 bugfix release for the next version of >> Emacs? >> > > > *Neki aur pooch pooch * > > It's an idiom in Hindi language which sort of translates[1] to "Why ask > before doing a good deed?". I tried to find something equivalent in English > but couldn't :) Thanks for the new proverb. I am not sure I would know how to pronounce it. To be honest, I am not sure what Bastien does to prepare a release. I have tried to document up-stream syncing bit. Rasmus -- Slowly unravels in a ball of yarn and the devil collects it
Re: [O] org to static site?
myg...@gmail.com writes: > On 12/01/2017 at 18:19 Adonay Felipe Nogueira writes: > >> The best approach for me is also to use something such as org-publish, >> and a simple static site server such as GNU Serveez. > > Have you used org-publish in earnest? I settled on the approach used in > https://github.com/myglc2/emacsite only after trying out org-publish > extensively. I needed source and generated content to sit together in > the working tree of complex multi-level reproducible research projects > and to be transparently revision controlled and hosted on the > organization's Github Entreprise server. I am happy that you found a method that works for you. As a contrasting point, I don’t see why you couldn’t do that with ox-publish.el in addition to maybe Make. Based on your description, I’d copy source files using org-publish-attachment to a publish dir and compiled files to the same dir via different projects in org-publish-project-alist. I don’t know how github works re CI, but with Gitlab you’d then mark the publish folder as an artifact folder that would be published. For each commit you’d then have a zip and a website with source and compiled data / code. If you have any suggestions on how to improve ox-publish to better suit please share them. > After studying both approaches I found the emacsite approach to work > better than org-publish. Just to be clear, emacsite does not require > GitHub. You can equally well serve the site from the development tree, > or you can publish by doing git push to non bare git repos hosted on web > servers. In this way emacsite effectively automates site publishing > using make and git which I found to be more reliable than org-publish. For publishing something to the web I’d personally use CI or just cp. You could use git using :publishing-function or maybe :publishing-directory if tramp somehow supports git. Rasmus -- Tack, ni svenska vakttorn. Med plutonium tvingar vi dansken på knä!
Re: [O] 27.0.50;Missing requirement in org-gnus.el
Nicolas Goaziou <m...@nicolasgoaziou.fr> writes: > Glenn Morris <r...@gnu.org> writes: > >> Speaking for the version in Emacs, apart from org-gnus the warnings are: >> >> In end of data: >> org-irc.el:255:1:Warning: the following functions are not known to be >> defined: >> erc-save-buffer-in-logs, erc-logging-enabled > > Fixed. Thank you. Should we prepare another v9.1 bugfix release for the next version of Emacs? Rasmus -- Evidence suggests Snowden used a powerful tool called monospaced fonts
Re: [O] [patch] structure snippet completions
Eric Abrahamsen <e...@ericabrahamsen.net> writes: > Rasmus <ras...@gmx.us> writes: > >> Hi, >> >> The attached patch adds expansions of "<s"-like snippets to Org v9.2. I >> would like to include this in the next version of Org in anticipation of >> the changes to the template system. > > Cool! We were talking about shifting the alist keys to strings, do we > want to do that all at once, in both places, or let this land first? I’m indifferent. If you make a shift to strings in the part of the code you know I can alter this code. >>> +(mapcar 'org-tempo-add-block org-structure-template-alist) >> >> #'org-tempo-add-block >> >>> +(mapcar 'org-tempo-add-keyword org-tempo-keywords-alist))) > > And `mapc'! Fair enough. Rasmus -- This space is left intentionally blank
Re: [O] [patch] structure snippet completions
Hi,
Thanks for the comments. I have attached a new version that addresses the
issues you raised.
I think Org Tempo should pretty much work as this point, but of course
additional testing would be great. And more cool key expansions of
course.
>> +@vindex org-tempo
>
> Is it worth mentioning the _variable_ `org-tempo'?
No.
> Also,
>
> @cindex Tempo
> @cindex Template expansion
> @cindex ... whatever ...
Good idea.
>> +@vindex org-tempo-keywords-alist
>
> Is
>
> @vindex org-structure-template-alist
>
> missing?
Perhaps. Added.
>> +@code{org-structure-template-alist} and @code{org-tempo-keywords-alist}.
>> For
>> +example, @code{org-tempo} makes @kbd{<} @kbd{s} @kbd{@key{TAB}}
>> expand to a
>
> For example, Org Tempo makes @kbd(< s @key{TAB}) expand to a code block.
That was taken from an old revision of the manual, but I am happy to use
the more clear form.
>> +@samp{src} code block. Enable it by customizing @code{org-modules} or add
>> +@code{(require 'org-tempo)} to your Emacs init file@footnote{For more
>> +information, please refer to the commentary section in
>> @code{org-tempo.el}}.
>
> ... @file{org-tempo.el}.}.
So much texinfo syntax...
>> +(user-error
>> + "Duplicated keys in `org-structure-template-alist' and
>> `org-tempo-keywords-alist'"))
>
> Is is an issue?
I guess if "<l" is defined to both make a export latex block and a latex
keyword it’s at least an issue, but I demoted it to a warning, which is
probably more appropriate.
>> +(defun org-tempo-add-keyword (entry)
>> + "Add keyword entry from `org-tempo-keywords-alist'."
>> + (let* ((key (format "<%c" (car entry)))
>> + (name (cdr entry)))
>> +(tempo-define-template (format "org-%s" (replace-regexp-in-string " "
>> "-" name))
>> + `(,(format "#+%s: " name) p '>)
>> + key
>> + (format "Insert a %s keyword" name)
>> + 'org-tempo-tags)))
>> +
>> +;;; Additional keywords
>> +
>> +(tempo-define-template "org-include"
>> + '("#+include: "
>> + (ignore-errors
>
> Why `ignore-errors'?
In case the file selection is quit. But I have re-done the include
keyword in a better way.
>> + ;; Simple test if `org-tempo-setup' has been run.
>> + ;; May not be the case if `org-tempo' was loaded
>> + ;; after Org.
>> + (unless (cl-member "<I" tempo-collection :key 'car :test 'equal)
>> +(org-tempo-setup))
>
> (unless (assoc "<I" tempos-collection) (org-tempo-setup))
>
> But wouldn't calling
>
> (org-tempo-setup)
>
> at top level in "org-tempo.el" solve the issue?
Good idea. I call it if we’re in an Org buffer. Perhaps people use Tempo
in other modes so it would be potentially disruptive to call it in other
modes.
Rasmus
--
You people at the NSA are becoming my new best friends!
>From d645c92381420203d42c0397269122de06ee76d9 Mon Sep 17 00:00:00 2001
From: Rasmus <ras...@gmx.us>
Date: Thu, 9 Nov 2017 16:47:13 +0100
Subject: [PATCH 1/2] org-tempo.el: New file for expansion of templates
* lisp/org-tempo.el: New file.
* doc/org.texi (Structure templates):
* lisp/org.el (org-modules): Add org-tempo.
---
doc/org.texi | 13 +
etc/ORG-NEWS | 4 +-
lisp/org-tempo.el | 164 ++
lisp/org.el | 1 +
4 files changed, 181 insertions(+), 1 deletion(-)
create mode 100644 lisp/org-tempo.el
diff --git a/doc/org.texi b/doc/org.texi
index 5becb0175..e6e6706cb 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -17396,6 +17396,19 @@ the key is @key{TAB}, the user is prompted to enter a type.
Available structure types are defined in @code{org-structure-template-alist},
see the docstring for adding or changing values.
+@cindex Tempo
+@cindex Template expansion
+@cindex template insertion
+@cindex insertion, of templates
+@vindex org-tempo-keywords-alist
+@vindex org-structure-template-alist
+Org Tempo expands snippets to structures defined in
+@c @code{org-structure-template-alist} and @code{org-tempo-keywords-alist}. For
+@c example, @code{org-tempo} expands @kbd{< s @key{TAB}} to a code block.
+Enable it by customizing @code{org-modules} or add @code{(require
+'org-tempo)} to your Emacs init file@footnote{For more information, please
+refer to the commentary section in @file{org-tempo.el}.}.
+
@multitable @columnfractions 0.2 0.8
@item @kbd{c} @tab @samp{#+BEGIN_CENTER}
@item @kbd{C} @tab @samp{#+BEGIN_COMMENT}
diff
[O] [patch] structure snippet completions
Hi,
The attached patch adds expansions of "<s"-like snippets to Org v9.2. I
would like to include this in the next version of Org in anticipation of
the changes to the template system.
In at least emacs-git it "just works" after requiring org-tempo.
Since it currently uses with-eval-after-load it would require Emacs 24.4,
but this could be changed to eval-after-load if necessary.
Thanks,
Rasmus
--
What will be next?
>From d5e3eacea38d3777f541f5abddebed04171650b6 Mon Sep 17 00:00:00 2001
From: Rasmus <ras...@gmx.us>
Date: Thu, 9 Nov 2017 16:47:13 +0100
Subject: [PATCH 1/2] org-tempo.el: New file for expansion of templates
* lisp/org-tempo.el: New file.
* doc/org.texi (Structure templates):
* etc/ORG-NEWS: Document new library.
* lisp/org.el (org-modules): Add org-tempo.
---
doc/org.texi | 9
etc/ORG-NEWS | 4 +-
lisp/org-tempo.el | 133 ++
lisp/org.el | 1 +
4 files changed, 146 insertions(+), 1 deletion(-)
create mode 100644 lisp/org-tempo.el
diff --git a/doc/org.texi b/doc/org.texi
index 5becb0175..17092ecbe 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -17396,6 +17396,15 @@ the key is @key{TAB}, the user is prompted to enter a type.
Available structure types are defined in @code{org-structure-template-alist},
see the docstring for adding or changing values.
+@vindex org-tempo
+@vindex org-tempo-keywords-alist
+@code{org-tempo} can be used to expand snippets to structures defined in
+@code{org-structure-template-alist} and @code{org-tempo-keywords-alist}. For
+example, @code{org-tempo} makes @kbd{<} @kbd{s} @kbd{@key{TAB}} expand to a
+@samp{src} code block. Enable it by customizing @code{org-modules} or add
+@code{(require 'org-tempo)} to your Emacs init file@footnote{For more
+information, please refer to the commentary section in @code{org-tempo.el}}.
+
@multitable @columnfractions 0.2 0.8
@item @kbd{c} @tab @samp{#+BEGIN_CENTER}
@item @kbd{C} @tab @samp{#+BEGIN_COMMENT}
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 66865ffe1..9d6c91ef3 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -72,6 +72,8 @@ document, use =shrink= value instead, or in addition to align:
#+END_EXAMPLE
** New features
+*** ~org-tempo~ may used for snippet expansion of structure template.
+See manual and commentary in ~org-tempo.el~ for details.
*** Exclude unnumbered headlines from table of contents
Set their =UNNUMBERED= property to the special =notoc= value. See
manual for details.
@@ -167,7 +169,7 @@ See docstring for details.
** Removed functions
*** ~org-try-structure-completion~
-
+=org-tempo= may be used as a replacement.
** Removed variables
*** org-babel-use-quick-and-dirty-noweb-expansion
diff --git a/lisp/org-tempo.el b/lisp/org-tempo.el
new file mode 100644
index 0..666954e1b
--- /dev/null
+++ b/lisp/org-tempo.el
@@ -0,0 +1,133 @@
+;;; org-tempo.el --- template expansion for org structures -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2017 Free Software Foundation, Inc.
+;;
+;; Author: Rasmus Pank Roulund
+;; Keywords: outlines, hypermedia, calendar, wp
+;; Homepage: http://orgmode.org
+;;
+;; This file is part of GNU Emacs.
+;;
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>.
+;;
+;;; Commentary:
+;;
+;; org-tempo reimplements completions of structure template before
+;; point like `org-try-structure-completion' in Org v9.1 and earlier.
+;; For example, strings like "<e" at the beginning of the line will be
+;; expanded to an example block.
+;;
+;; All blocks defined in `org-structure-template-alist' are added as
+;; org-tempo shortcuts, in addition to keywords defined in
+;; `org-tempo-keywords-alist'.
+;;
+;; `tempo' can also be used to define more sophisticated keywords
+;; completions. See the section "Additional keywords" below for
+;; additional details.
+;;
+;;; Code:
+
+(require 'tempo)
+(require 'cl-lib)
+
+(defvar org-tempo-tags nil
+ "Tempo tags for org-mode")
+
+(defcustom org-tempo-keywords-alist
+ '((?L . "latex")
+(?H . "html")
+(?A . "ascii")
+(?i . "index"))
+ "Keyword templates like `org-structure-template-alist'."
+ :group 'org-tempo
+ :type '(repeat
+ (cons (character :tag "Key")
+ (string :tag "Template")))
+ :packag
[O] [patch] structure snippet completions
Hi,
The attached patch adds expansions of "<s"-like snippets to Org v9.2. I
would like to include this in the next version of Org in anticipation of
the changes to the template system.
In at least emacs-git it "just works" after requiring org-tempo.
Since it currently uses with-eval-after-load it would require Emacs 24.4,
but this could be changed to eval-after-load if necessary.
Thanks,
Rasmus
--
What will be next?
>From d5e3eacea38d3777f541f5abddebed04171650b6 Mon Sep 17 00:00:00 2001
From: Rasmus <ras...@gmx.us>
Date: Thu, 9 Nov 2017 16:47:13 +0100
Subject: [PATCH 1/2] org-tempo.el: New file for expansion of templates
* lisp/org-tempo.el: New file.
* doc/org.texi (Structure templates):
* etc/ORG-NEWS: Document new library.
* lisp/org.el (org-modules): Add org-tempo.
---
doc/org.texi | 9
etc/ORG-NEWS | 4 +-
lisp/org-tempo.el | 133 ++
lisp/org.el | 1 +
4 files changed, 146 insertions(+), 1 deletion(-)
create mode 100644 lisp/org-tempo.el
diff --git a/doc/org.texi b/doc/org.texi
index 5becb0175..17092ecbe 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -17396,6 +17396,15 @@ the key is @key{TAB}, the user is prompted to enter a type.
Available structure types are defined in @code{org-structure-template-alist},
see the docstring for adding or changing values.
+@vindex org-tempo
+@vindex org-tempo-keywords-alist
+@code{org-tempo} can be used to expand snippets to structures defined in
+@code{org-structure-template-alist} and @code{org-tempo-keywords-alist}. For
+example, @code{org-tempo} makes @kbd{<} @kbd{s} @kbd{@key{TAB}} expand to a
+@samp{src} code block. Enable it by customizing @code{org-modules} or add
+@code{(require 'org-tempo)} to your Emacs init file@footnote{For more
+information, please refer to the commentary section in @code{org-tempo.el}}.
+
@multitable @columnfractions 0.2 0.8
@item @kbd{c} @tab @samp{#+BEGIN_CENTER}
@item @kbd{C} @tab @samp{#+BEGIN_COMMENT}
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 66865ffe1..9d6c91ef3 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -72,6 +72,8 @@ document, use =shrink= value instead, or in addition to align:
#+END_EXAMPLE
** New features
+*** ~org-tempo~ may used for snippet expansion of structure template.
+See manual and commentary in ~org-tempo.el~ for details.
*** Exclude unnumbered headlines from table of contents
Set their =UNNUMBERED= property to the special =notoc= value. See
manual for details.
@@ -167,7 +169,7 @@ See docstring for details.
** Removed functions
*** ~org-try-structure-completion~
-
+=org-tempo= may be used as a replacement.
** Removed variables
*** org-babel-use-quick-and-dirty-noweb-expansion
diff --git a/lisp/org-tempo.el b/lisp/org-tempo.el
new file mode 100644
index 0..666954e1b
--- /dev/null
+++ b/lisp/org-tempo.el
@@ -0,0 +1,133 @@
+;;; org-tempo.el --- template expansion for org structures -*- lexical-binding: t; -*-
+
+;; Copyright (C) 2017 Free Software Foundation, Inc.
+;;
+;; Author: Rasmus Pank Roulund
+;; Keywords: outlines, hypermedia, calendar, wp
+;; Homepage: http://orgmode.org
+;;
+;; This file is part of GNU Emacs.
+;;
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>.
+;;
+;;; Commentary:
+;;
+;; org-tempo reimplements completions of structure template before
+;; point like `org-try-structure-completion' in Org v9.1 and earlier.
+;; For example, strings like "<e" at the beginning of the line will be
+;; expanded to an example block.
+;;
+;; All blocks defined in `org-structure-template-alist' are added as
+;; org-tempo shortcuts, in addition to keywords defined in
+;; `org-tempo-keywords-alist'.
+;;
+;; `tempo' can also be used to define more sophisticated keywords
+;; completions. See the section "Additional keywords" below for
+;; additional details.
+;;
+;;; Code:
+
+(require 'tempo)
+(require 'cl-lib)
+
+(defvar org-tempo-tags nil
+ "Tempo tags for org-mode")
+
+(defcustom org-tempo-keywords-alist
+ '((?L . "latex")
+(?H . "html")
+(?A . "ascii")
+(?i . "index"))
+ "Keyword templates like `org-structure-template-alist'."
+ :group 'org-tempo
+ :type '(repeat
+ (cons (character :tag "Key")
+ (string :tag "Template")))
+ :packag
Re: [O] exporting "flattened" tagged subtrees
Michel Damiens <michel.dami...@gmail.com> writes: > Hello, > > I would like to export and org file in such a way that : > - only tagged subtrees are exported (for a specific tag) > - the tree structure is "flattened" > > for example a file example.org containing : > * heading 1 :tag: > ** subheading 1.1 > content 1.1 > ** subheading 1.2 :tag: > content 1.2 > *heading 2 > ** subheading 2.1 :tag: > content 2.1 > ** subheading 2.1.1 :tag: > ** subheading 2.1.2 :tag: > content 2.1.2 > ** subheading 2.2 > content 2.2 > > would be exported to the file example.org.org containing : > * heading 1 > * subheading 1.2 > content 1.2 > * subheading 2.1 > content 2.1 > * subheading 2.1.1 > * subheading 2.1.2 > content 2.1.2 > > (which in turn would be exported to latex, beamer or html for example) The first part you can archive with these tags: #+SELECT_TAGS:, #+EXCLUDE_TAGS: These lines provide settings for exporting files. For more details see Export settings . Flatting the file can be done by search and replace (while (search-forward-regexp "^*+ " nil t) (replace-match "* ")) Rasmus -- ツ
Re: [O] function for inserting a block
Hi Eric, > It incorporates Rasmus' org-tempo.el file, with modifications, and > Thomas' suggestion to re-instate `org-try-structure-completion', and, > erm, stardiviner's request to honor > `org-babel-uppercase-example-markers'. > > Remaining issues: > > 1. The "org-include" tempo template doesn't work, for reasons I don't >understand (I've never used tempo before). Nothing happens when I hit >. > 2. Now it seems like there should be completion when prompting for a >string key. Feature creep! But likely worthwhile feature creep. > 3. I've rather rashly renamed the relevant customization options >`org-structure-block-alist' (for blocks added via >`org-insert-structure-template') and `org-structure-keyword-alist' >(for keywords insertable via the tempo system). Perhaps this was a >bad idea. If it's not a bad idea, maybe >`org-insert-structure-template' should be renamed `org-insert-block' >or something like that. > 3. Docs need to be updated. I will have a look at org-tempo and try to figure out why it isn’t working. As it would probably warrant changes to ORG-NEWS and maybe the manual I will do it in a separate commit if people find it useful. Rasmus -- Hvor meget poesi tror De kommer ud af et glas isvand?
Re: [O] Bug: #+INCLUDE: :only-contents not recognized [9.1.2 (9.1.2-37-g3f8d67-elpa @ /home/data1/protected/.emacs.d/elpa/org-20171113/)]]
Jean Louis <bugs@gnu.support> writes: > I can see that if I use: > > #+INCLUDE: "~/Documents/Org/With-Ease.org" :only-contents t > > that the #+TITLE variable is then included in the > main file, and is concatenated to the main > title. I am exporting "visible only" and that is > happening. > > That is not expected. > > If I try to export with subtree from a section, I > do not get the #+TITLE of included file shown in > ASCII export. > > Do I need to do something to avoid the title being > exported wrongly? I am not sure there is a well specified meaning for :only-contents when you do not select an element. :only-content refers to the content of an element (try ‘org-element-at-point’ on a heading and check :contents-begin). Ways to archive what you want would be to select the right element or use :lines "2-" to skip the title, if it’s on line 1. Hope it helps. Rasmus -- Dung makes an excellent fertilizer
Re: [O] [PATCH] ox.el: Define subtitle macro
Jens Lechtenboerger <lech...@wi.uni-muenster.de> writes: > the attached patch adds a subtitle macro with documentation. AFAIK it’s already added to the backends where it makes sense. It’s not a basic keyword like "#+author". It should be documented under the relevant backends that support it. Rasmus -- Governments should be afraid of their people
Re: [O] org-mode in French
gmx <freds...@gmx.fr> writes:
> Hello,
> I've been using Org-mode for several months now, with pleasure.
> However, I would like the .tex files use some packages (babel,
> french...), a particular koma-script class (scrartcl), etc., which
> allow me to release a. pdf file with French typographical standards.
>
> How to do this?
For language support, you could do something like
(setq org-latex-packages-alist
'(("AUTO" "babel" nil ("pdflatex"))
("AUTO" "polyglossia" nil ("xelatex" "lualatex"
And use the "#+language: fr" keyword to set the document to French.
Rasmus
--
Hooray!
