Re: [O] How to handle an inline multiline noweb reference
On Fri, Nov 30, 2018 at 11:25 AM Marcin Borkowski wrote: > On 2018-11-28, at 03:08, Grant Rettke wrote: > > On Tue, Nov 27, 2018 at 3:57 AM Marcin Borkowski wrote: > >> but it's fairly complicated. Any better ideas? > > > > What is the part that you think is too complicated? > > I hoped that I could somehow skip the "manually replace newlines with > spaces" step. Thank you for explaining!
Re: [O] suppress ++ markup in orgmode?
On 11/21/18, Nicolas Goaziou wrote: > You can use a zero-width space, like +++. that trick does not work on ===.
[O] set :var to string inline code
Hi,
I have recutils data base and from that I want to use inline source code
to generate a list of names, addresses, etc. for instance the following
inline code when exported in latex
src_sh[:results raw :results replace :exports results :eval yes]{recsel
-t InterestedParties -e "IPName='Charles Millar'" -P IPPrintName Millar.rec}
src_sh[:results raw :results replace :exports results :eval yes]{recsel
-t InterestedParties -e "IPName='Charles Millar'" -P IPAddress1 Millar.rec}
src_sh[:results raw :results replace :exports results :eval yes]{recsel
-t InterestedParties -e "IPName='Charles Millar'" -P IPPAddress2 Millar.rec}
will give
Charles Millar
123 XYZ Street
Apt 678
However, there are (as there should be) many records in the database and
rather than set each and every IPName= to a specific field I want to use
something like the following
#+name: iponeshell
#+begin_src sh :results raw :exports results
iponeassign="Charles Millar"
echo "$iponeassign"
#+end_src
#+RESULTS: iponeshell
Charles Millar
src_sh[:results raw :results replace :var IPOne='iponeshell' :eval
yes]{recsel -t InterestedParties -e "IPName=IPOne" -P IPPrintName
Millar.rec}
src_sh[:results raw :results replace :var IPOne='iponeshell' :eval
yes]{recsel -t InterestedParties -e "IPName=IPOne" -P IPAddress1
Millar.rec}
src_sh[:results raw :results replace :var IPOne='iponeshell' :eval
yes]{recsel -t InterestedParties -e "IPName=IPOne" -P IPAddress2
Millar.rec}
The above example evaluates, but there is no output. I have tried
:exports results as well as diggernet variations of dounle and sing
quotes, at both where I define var and at the expression selection
within recsel.
I believe that this is bash issue so I have also tries to use $ with the
:var and recsel selection expression.
Any help would be gretly appreciated.
Charlie Millar
src_sh[:results raw :results replace :var IPOne=iponeshell :exports
results :eval yes]{recsel -t InterestedParties -e "IPName='Charles
Millar'" -P IPPrintName StreichertCatherine.rec}
I am
[O] org-envolve.el
Hello, I've implemented a new file to contrib/lisp. It's called org-envolve.el, this file implements functions to help to format in org-mode from ASCII. For instance, you have a bash source that you are copying in your buffer, later you can call org-envolve-tags to add #+BEGIN_SRC bash in the beginning and #+END_SRC in the end. I use this feature all weeks in the year. But the file provides functions to envolve numbered list, or check list. I can't make git push at this moment davidam@libresoft:~/git/org-mode/contrib/lisp$ git push origin master Counting objects: 27, done. Delta compression using up to 4 threads. Compressing objects: 100% (27/27), done. Writing objects: 100% (27/27), 4.26 KiB | 0 bytes/s, done. Total 27 (delta 17), reused 0 (delta 0) Username for 'https://code.orgmode.org': davidam Password for 'https://davi...@code.orgmode.org': error: RPC failed; HTTP 403 curl 22 GnuTLS recv error (-110): The TLS connection was non-properly terminated. fatal: The remote end hung up unexpectedly fatal: The remote end hung up unexpectedly Everything up-to-date But this software is released with a gpl licencese. Thanks in advance. -- https://cienciabasura.wordpress.com/ http://libremanuals.net/ org-envolve.el Description: application/emacs-lisp
Re: [O] Feature request: simplify usage of special blocks (for beamer)
> (when (looking-at "[ \t]*#\\+BEGIN_\\S-+[ \t]+\\(\\S-+\\)") Sorry, it obviously should have been \\(.+\\) at the end. One thing the core parser could do is to put the remaining of the opening line of a special block into an :args or similar property of the special block element, leaving it otherwise unparsed. This is in the same spirit than what it already do for the affiliated attrs_X element. It's not a lot of help but it would at least spare backends from having to parse the remaining of the opening line as I did. They would still have to parse :args exactly as they now parse :attrs_X, but there are helper functions for that task. The idea is that stuff that is very specific to a backend X would be in :attrs_X, but stuff that is related to what makes the block semantically special could be in :args. Nevertheless special blocks will probably be backend specific in most cases.
Re: [O] Feature request: simplify usage of special blocks (for beamer)
> > 1. Allow for special blocks to take an :options argument. > > Although I agree that this would be nice, I imagine the difficulty would be > that it would be difficult to cater for multiple backends. It's not really difficult, more on the trivial side. For example, as an end user I already can install a filter like: (defun my-special-block-parse-filter (tree backend symbol) (when (org-export-derived-backend-p backend 'latex) (org-element-map tree 'special-block (lambda (element) (save-excursion (goto-char (org-element-property :begin element)) (when (looking-at "[ \t]*#\\+BEGIN_\\S-+[ \t]+\\(\\S-+\\)") (let ((options (format ":options [%s]" (match-string-no-properties 1 (org-element-put-property element :attr_latex (list options) And then write: #+BEGIN_definition Special Block A block mostly left uninterpreted by core org for the sake of backends #+END_definition This is as devoid of boilerplate as possible. Notice the filter only applies to latex derived backends and won't take effect if there is an #+ATTR_LATEX clause before the block (this because it's considered part of the element the regexp won't match it). Obviously this can be implemented in a cleaner way by changing org-latex-special-block in ox-latex.el. Again, the change would be trivial. > > 2. Mention the possibility of using special blocks to represent beamer > > blocks, be it in the manual or in the tutorial. > > Given that beamer inherits everything that the LaTeX exporter supports, is > the special blocks section in the LaTeX exporter documentation not already > enough? Not much users seem to be aware of the ablity of using special blocks for beamer. No example, answer, tutorial out there even mentioned the possibility. Given its convenience, I would say the beamer export section should explicitly suggest the alternative. Best regards -- Carlos
Re: [O] Feature request: simplify usage of special blocks (for beamer)
On Saturday, 1 Dec 2018 at 13:24, Carlos Pita wrote: > Now, there are special blocks [1] also, and it's a pity they are not [...] > So my request would be: > > 1. Allow for special blocks to take an :options argument. Although I agree that this would be nice, I imagine the difficulty would be that it would be difficult to cater for multiple backends. > 2. Mention the possibility of using special blocks to represent beamer > blocks, be it in the manual or in the tutorial. Given that beamer inherits everything that the LaTeX exporter supports, is the special blocks section in the LaTeX exporter documentation not already enough? -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.14-1035-gfeb442
[O] Feature request: simplify usage of special blocks (for beamer)
Hi all! The standard mapping from org structures to beamer structures introduces boilerplate: 1. At the bare minimum a properties drawer. 2. Then there is the tag. 3. But above all the need to add an ignoreheading subsection (with its drawer and everything) to introduce a little text between, say, two definition blocks. Now, there are special blocks [1] also, and it's a pity they are not suggested for beamer blocks nor in the org manual nor in the org beamer tutorial. IMO they are a better fit for simple beamer blocks. They don't nest, so org headings still have a purpose here for complex layouts, but they close naturally without the need of ignoreheading-like tricks, and this covers most cases of practical importance. Now, that it's great but the way they take their options is more clunky than it could be. You need to add a #+ATTR_LATEX: options:... line above, burying the block title into syntactical noise. It would be nice it they took their options directly instead, as src blocks do. For example: #+BEGIN_definition :options [I'm the definiendum] I'm the definition #+END_definition So my request would be: 1. Allow for special blocks to take an :options argument. 2. Mention the possibility of using special blocks to represent beamer blocks, be it in the manual or in the tutorial. Best regards -- Carlos [1] https://orgmode.org/manual/Special-blocks-in-LaTeX-export.html
