Hi,
Kyle Meyer writes:
> Tim Cross writes:
>
>> one thing I think might help (maybe too late) would be to put the
>> entries for both electric-indent-mode and org-adapt-indentation so that
>> they are together in the release notes as they do interact with each
>> other and often people stop look
In this following peculiar setup, I wish to publish the macro value
{{{version}}} inside of the LaTeX source code export. That makes the
first page how I need it, as it displays logo and other matters. But I
cannot use macro replacements in src blocks, right?
That is why I have defined \def\versio
On Wednesday, 31 Mar 2021 at 12:40, Jean Louis wrote:
> But then the line with \def\version{ {{{version}}} } gets shown in
> HTML export, which is not what I want. How to resolve that?
Can you surround the line with @@latex: ... @@?
You might need to do @@latex:\def\version{@@ {{{version}}} @@lat
On Tuesday, 30 Mar 2021 at 17:44, Juan Manuel Macías wrote:
> However, *I would not recommend anyone to use LaTeX for writing*. A
> light markup language is more comfortable and efficient for me.
Totally agree! Although, over the years, I have written many papers in
LaTeX directly, in the past d
* Eric S Fraga [2021-03-31 13:06]:
> On Wednesday, 31 Mar 2021 at 12:40, Jean Louis wrote:
> > But then the line with \def\version{ {{{version}}} } gets shown in
> > HTML export, which is not what I want. How to resolve that?
>
> Can you surround the line with @@latex: ... @@?
>
> You might need
On Wednesday, 31 Mar 2021 at 13:29, Jean Louis wrote:
> By doing this:
>
> @@latex:\def\version{@@ {{{version}}} @@latex:}@@
>
> Then {{{version}}} will get expanded in the document, right? As I have
> hidden then only tags surrounding {{{version}}}.
Yes.
>> Also, a macro can itself use the @@ di
* Eric S Fraga [2021-03-31 13:46]:
> On Wednesday, 31 Mar 2021 at 13:29, Jean Louis wrote:
> > By doing this:
> >
> > @@latex:\def\version{@@ {{{version}}} @@latex:}@@
> >
> > Then {{{version}}} will get expanded in the document, right? As I have
> > hidden then only tags surrounding {{{version}}}
Jean Louis,
> Another issue related to this setup is that I would like:
>
> - for HTML export: title:t toc:t
>
> - for LaTeX PDF export: title:nil toc:nil
>
> Is there way to have options different for different exports?
sometimes "publishing" gives me easier control over options than
"exporti
> Another solution could be if a program in BEGIN_SRC block could
> generate Org inline, so that it gets processed after generation.
Or even an inline src block, e.g. src_elisp{...}, which checks the
/backend/ for export and outputs accordingly. Search the mailing list
as there have been examples
Hello,
Another little patch, this time a one-liner.
I think the commit description is pretty thorough, so give that a look.
TLDR; it makes `org-export-to-file' behave a bit more nicely.
--
Timothy
>From eb9d7c038dbb9e7a4b89edf61db83a31dda27170 Mon Sep 17 00:00:00 2001
From: TEC
Date: Wed, 31 M
Hello,
The latest in my visually-oriented (mostly) short patch series, adding
basic fontification to inline export snippets --- @@comment:these things@@.
I think fontification for stuff like this is nice because it visually
indicates to the user that they've written out an Org construct, and
hav
Hi All,
I anticipate that this change may be somewhat contentions because ox-md
explicitly follows only the original Markdown spec from 2003, however
I've thought this over and come to the conclusion that this change is
still in keeping with that, and beneficial.
Currently ox-md simply inherits
> "Eric" == Eric S Fraga writes:
Eric> On Tuesday, 30 Mar 2021 at 17:44, Juan Manuel Macías wrote:
>> However, *I would not recommend anyone to use LaTeX for
>> writing*. A light markup language is more comfortable and
>> efficient for me.
Eric> Totally agree! Although,
Markdown uses backticks to denote inline code which should get special
(typically monospace) formatting, org uses the tilde character.
Now I know that org is not markdown, is far more powerful than markdown,
and is not (mostly) the same use cases as markdown. But this one use case
*does* overlap.
Martin Steffen writes:
> [...] And last not least; if I ``compile'' the document (firing off latex,
> bibtex, or index or whatever), the compilation runs in the background.
> As far as I do that in org (exporting to pdf), it blocks emacs. Not
> that it's a huge delay even, at least for smaller do
Hi,
George> Aside from any official movement, I would like to add this to my own
files - is there a straightforward way to extend the org parser to do this?
Quick and Dirty: Bind key '`' to ~ in Emacs?
(I guess it is clear I haven't thought about the consequences.)
Cheers
Rasmus
autofrettage writes:
> Quick and Dirty: Bind key '`' to ~ in Emacs?
>
> (I guess it is clear I haven't thought about the consequences.)
You can add that just to the Org-mode map. That wouldn't be too bad,
there's always C-q.
--
Timothy
George Mauer writes:
is there a straightforward way to extend the org parser to do this?
I don't think so. It seems the emphasis markers are hard-coded
in various places.
From a quick look at the code, you'd have to customize
`org-emphasis-alist` and redefine `org-set-emph-re` and
`org-do-emp
George Mauer writes:
> I would like to submit that org consider adopting backticks as an alternate
> way of denoting inline code.
Just FYI, this is almost certainly not going to happen.
--
Timothy
> > I would like to submit that org consider adopting backticks as an alternate
> > way of denoting inline code.
>
> Just FYI, this is almost certainly not going to happen.
Perhaps as unlikely as Python adopts 'i' instead of 'j' in complex numbers? It
looks awful for all but electrical and electr
Thank you Kyle. I can see how using the latex environments the way I
did caused the table part to not be org-mode at all any more. I didn't
realize org behaved that way, and the workaround of using #+LATEX works
wonderfully.
Incidentally would not org-mode benefit from a bug tracker? Ordinar
* Greg Minshall [2021-03-31 14:33]:
> Jean Louis,
>
> > Another issue related to this setup is that I would like:
> >
> > - for HTML export: title:t toc:t
> >
> > - for LaTeX PDF export: title:nil toc:nil
> >
> > Is there way to have options different for different exports?
>
> sometimes "pub
The approach I've taken is to try and stop using Markdown altogether and
write everything in Org, exporting to Markdown for those destinations that
need it.
You could even use https://github.com/tecosaur/org-pandoc-import to
automatically convert/reconvert other formats as needed, and
https://gith
> On Mar 31, 2021, at 9:41 AM, Timothy wrote:
>
> I anticipate that this change may be somewhat contentions because ox-md
> explicitly follows only the original Markdown spec from 2003, however
> I've thought this over and come to the conclusion that this change is
> still in keeping with that
The point I'm making is that this is already the de-facto thing. People on
this email list do it, people in talking in irc and in forums do it. I
don't think it has so much to do with markdown documents as it does with
Slack, Discord, Teams, even google chat adopting that convention. All our
finger
George Mauer writes:
> - lists with dashes, org supports that just fine
or stars (not possible with org) or plus (in org).
> *bold text* with stars, again org already does this
Note that this does not match markdown: Markdown uses *emphasis* and **strong**.
> `backtick code`, org doesn't hand
"Dr. Arne Babenhauserheide" writes:
> George Mauer writes:
>> - lists with dashes, org supports that just fine
>
> or stars (not possible with org) or plus (in org).
>
>> *bold text* with stars, again org already does this
>
> Note that this does not match markdown: Markdown uses *emphasis* an
just personal opinion but i wouldn't want org's syntax to get more
heterogeneous and non-orthogonal/non-factored.
i could see room for an orthogonal/factored flexible syntax, like
"parsing risk" and "extensible syntax" threads on this ml. this would
be the one syntax to rule them all, /vaguely/ s
Grepping for src_ in *.el in the org distro shows 11 hits over 3 files:
ob-core.el, ob-exp.el, and org-element.el. That's where you can start
working if you want to copy those functions into your init files and modify
them for yourself, or you can see if maybe using function advice is
sufficient.
George and all,
whether it's the right thing to do or not, i don't know. but, i'm very
sympathetic to the urge. even when posting to the list, the reflex to
use back ticks is strong.
Greg
Jean Louis,
when publishing, one presents a data structure
~org-publish-project-alist~ that defines the back ends and options for
publishing actions. the options are here:
https://orgmode.org/manual/Publishing-options.html#Publishing-options
below is an example. as you can see, publis
Jean Louis,
another thing that i find helpful in understanding the tao of export: if
you haven't, look at the help string for the variable
~org-export-options-alist~: [C-h v org-export-options-alist].
cheers, Greg
On 2021-03-31, at 21:19, Timothy wrote:
> autofrettage writes:
>
>> Quick and Dirty: Bind key '`' to ~ in Emacs?
My first thought exactly. And I'd definitely use it - I need to use
Markdown more often than I'd like to (chat, wikis, (cloud-based) task
management system...).
>> (I guess it is
Tim,
Your concerns are well founded. Essentially any cosmetic extension
to the org table syntax will be an unmaintainable, bug ridden
nightmare and would be an eternal burden on any attempts to formalize
correct behavior. I have a draft of a grammar for a significant
portion of Org syntax (forth
On Wednesday, 31 Mar 2021 at 20:28, Martin Steffen wrote:
> And there is a final thing which (for me) seem to work better in
> latex-mode compared to org. That's jumping to the ``next error'' with
> some key stroke. That's important, LaTeX's own error output it quite
> poor, but jumping to error lo
35 matches
Mail list logo
