Re: Citations: non-page locators placed in front of citation

[M . ‘quintus’ Gülker]

Am Dienstag, dem 12. Oktober 2021 schrieb Nicolas Goaziou:
> I mapped both § and §§ to "section". Hopefully, the issue is now
> completely fixed.

Nearly :-). Thank you so much for your hard work so far! It is
incredible to see how this develops.

With »Org mode version 9.5 (release_9.5-104-g2b1fc6 @ 
/home/quintus/.emacs.d/org-mode/lisp/)«
now

Das ist ein Test [cite:@saenger2013gsr § 12 Rn. 488].

gives:

Saenger, Gesellschaftsrecht, 2. Aufl. (2013), §§ 12 Rn. 488

Positioning and choice of locator label is correct. The one thing left
is that it uses double §§ instead of a single §, that is, it treats the
citation as a plural one whereas it should be a singular one. The same
happens with

Das ist ein Test [cite:@saenger2013gsr section 12 Rn. 488].

Interestingly, the input

Das ist ein Test [cite:@saenger2013gsr § 12].

(which has no suffix) does export to

Saenger, Gesellschaftsrecht, 2. Aufl. (2013), § 12

with only one § sign. Then, a real multi-section citation like this:

Das ist ein Test [cite:@saenger2013gsr §§ 12 ff.].

instead yields a single §:

Saenger, Gesellschaftsrecht, 2. Aufl. (2013), § 12 ff.

This one however:

Das ist ein Test [cite:@saenger2013gsr §§ 12-14].

is correct again:

Saenger, Gesellschaftsrecht, 2. Aufl. (2013), §§ 12-14

This is a little confusing. Maybe an error on my part? Do I need to
signal singular and plural use more explicitely?

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: How to keep getting org updates

[Greg Minshall]

Lawrence,

in case it helps, my *straight.el* (not package.el) recipe looks like
this:

(org :type git :repo
 "https://git.savannah.gnu.org/git/emacs/org-mode.git; :local-repo "org"
 :depth full :pre-build (straight-recipes-org-elpa--build) :build (:not
 autoloads) :files (:defaults "lisp/*.el" ("etc/styles/"
 "etc/styles/*")))


cheers, Greg

Re: Inequalities in math blocks

[Nick Dokos]

Rudolf Adamkovič  writes:

> Max Nikulin  writes:
>
>> Though I am a bit surprised that Org did not replace characters to
>>   and  during export. Perhaps, it is possible to define a
>> filter. 
>
> That makes sense, and thank you for the explanation. Ignoring the dead
> link in the Org manual, I wonder how this bug can even exist in Org
> after 15+ years of development. Some people, including the author of
> TeX himself, write TeX without unnecessary whitespace. Strange! Either
> way, rearranging bullet points should never break math without any
> visual sign inside of Emacs. Thus, this represents a bug in Org. R+

No, it does not. Org mode just passes LaTeX directly to MathJax
without changing anything. If you want to blame somebody, you can
blame HTML for choosing < and > as its delimiters: see

   http://docs.mathjax.org/en/latest/input/tex/html.html#html-special-characters

-- 
Nick

Re: 9.5: coping with loss of ditaa.jar

[Nick Dokos]

Tim Cross  writes:

> Another alternative which I just found is the ditaa version on github,
> which has SVG support. See https://github.com/stathissideris/ditaa. If
> you click on the 'release' link on the right, there is the most recent
> release, which includes a link to a standalone ditaa.jar file.
>
> I've not tried this version, but suspect it will work fine (assuming
> they use semantic versioning, which indicates the API has not
> changed). 
>
>
>

Perfect! Thank you for pointing that out.

I downloaded that, installed java-11-openjdk from the Fedora repos and
tried the standard example:

--8<---cut here---start->8---
#+begin_src ditaa :file example.svg :results file drawer
++   +---++---+
|| --+ ditaa +--> |   |
|  Text  |   +---+|diagram|
|Document|   |!magic!||   |
| {d}|   |   ||   |
+---++   +---++---+
: ^
|   Lots of work  |
+-+
#+end_src

#+RESULTS:
:results:
[[file:example.svg]]
:end:
--8<---cut here---end--->8---

It worked perfectly on Fedora 34.

Thanks!
-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: Citations: non-page locators placed in front of citation

[Nicolas Goaziou]

M. ‘quintus’ Gülker  writes:

> Long story short: I do not think that it is a bug in locales-de-DE.xml,
> and I guess Pandoc proves my point here. Please map § to "section"
> instead of "paragraph" in org-cite, i.e., do it the way Pandoc does
> it.

I mapped both § and §§ to "section". Hopefully, the issue is now
completely fixed.

Regards,

How to keep getting org updates

[Galaxy Being]

This is in my init.el

...
(setq package-archives '(("ELPA"  . "http://tromey.com/elpa/;)
("gnu"   . "http://elpa.gnu.org/packages/;)
("melpa" . "https://melpa.org/packages/;)
("org"   . "https://orgmode.org/elpa/;)))
...

I'm guessing the last line is no more and should be removed? In any case,
not getting 9.5 when I do a package update.


-- 
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borg...@gmail.com

Re: Citations: non-page locators placed in front of citation

[M . ‘quintus’ Gülker]

Am Montag, dem 11. Oktober 2021 schrieb Bruce D'Arcus:
> Looks like § is currently mapped to the same as ¶: "paragraph", which
> is indeed incorrect.
>
> https://github.com/citation-style-language/locales/blob/0cc3885f6100e26ac6c6d103efa6f3d7195fd21b/locales-de-DE.xml#L210

This is interesting. Pandoc -- which I thought relies on these files? --
outputs the expected § sign. For

Das ist ein Test [@saenger2013gsr, § 12 Rn. 488].

it yields

Saenger, Gesellschaftsrecht, 2. Aufl. (2013), § 12 Rn. 488↩

which is what I would have expected. The issue appears to be in the way
§ is interpreted in the text input.

After reading the locales-de-DE.xml file, I suspect a case of lost in
translation. In German, when read out aloud, we spell the “§” character
as “paragraph”. This is evidently different from the English speaker,
who, as I have been told, would read it out as “section”. However, in
fact the German word “Paragraph” translates to “section” in English. The
unit below it is called “Absatz” in German -- in English, it would be
“paragraph”. That is:

| English   | German| German Short form |
|---+---+---|
| Section   | Paragraph | § |
| Paragraph | Absatz| Abs.  |

At least, when it comes to legal contexts. As it always is the case with
language, meaning can vary be context. If I talk about sections of a
novel, in German it would be “Abschnitt” rather than “Paragraph”. But
that’s not something one would cite. If I really would need to cite a
novel, I would cite it either by chapter or by page number (with line
number, if necessary).

There is no symbolic sign to my knowledge to denote the unit below § in
German. The locales-de-DE.xml files suggests ¶. That might actually be
valid in some discipline, but we do not use that in jurisprudence. I do
not see a problem with it; it can be left in. What needs to change is
the part of org that maps § to CSL's "paragraph". § needs to be mapped
to "section" instead.

Long story short: I do not think that it is a bug in locales-de-DE.xml,
and I guess Pandoc proves my point here. Please map § to "section"
instead of "paragraph" in org-cite, i.e., do it the way Pandoc does it.

  -quintus


-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Useful package? Compat.el

[Joost Kremers]

On Mon, Oct 11 2021, Timothy wrote:
> I think the way to do this would be as a “soft” dependency, i.e. not needed 
> for
> anyone running a recent version of Emacs, but needed if you want to use Org 
> with
> an old version of Emacs. Not sure how this would best be done, but if this 
> were
> to be useful, this is how I’d imagine it working.

IIUC you can simply specify a dependency on `compat` and the package itself will
make sure only the necessary compatibility functions are loaded given the Emacs
version it's running in. So if you're running Emacs 28, nothing is loaded; if
you're running Emacs 27, `compat-28.1` is loaded to ensure packages written for
Emacs 28 can still be used; if you're running Emacs 26, both `compat-27.1` and
`compat-28.1` are loaded, etc.

-- 
Joost Kremers
Life has its moments

Re: Citations: non-page locators placed in front of citation

[Bruce D'Arcus]

On Mon, Oct 11, 2021 at 1:57 PM M. ‘quintus’ Gülker
 wrote:

> As explained, the positioning is now correct. However, instead of the
> section § sign it now has two pilcrow signs ¶¶. It should be just one
> sign, and it should be a section sign rather than a pilcrow one.

Looks like § is currently mapped to the same as ¶: "paragraph", which
is indeed incorrect.

https://github.com/citation-style-language/locales/blob/0cc3885f6100e26ac6c6d103efa6f3d7195fd21b/locales-de-DE.xml#L210

Bruce

Re: Citations: non-page locators placed in front of citation

[M . ‘quintus’ Gülker]

Am Montag, dem 11. Oktober 2021 schrieb Nicolas Goaziou:
> Indeed. The "fix" I introduced was a mistake. I pushed a new fix.
> I think the initial issue is solved now. Could you confirm it?

Thank you so far -- we are getting closer. Now at »Org mode version 9.5
(release_9.5-102-gd0b557 @ /home/quintus/.emacs.d/org-mode/lisp/)«, the
/positioning/ is correct. What is still not correct is the character
used for the locator label. For me,

Das ist ein Test [cite:@saenger2013gsr § 12 Rn. 488].

now (regardless of a NSBP or normal space) exports to:

Saenger, Gesellschaftsrecht, 2. Aufl. (2013), ¶¶ 12 Rn. 488

As explained, the positioning is now correct. However, instead of the
section § sign it now has two pilcrow signs ¶¶. It should be just one
sign, and it should be a section sign rather than a pilcrow one.

  -quintus

-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: A minor suggestion about formatting citations

[Bruce D'Arcus]

On Mon, Oct 11, 2021 at 11:54 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > On Mon, Oct 11, 2021 at 10:28 AM John Kitchin  
> > wrote:
> >>
> >> you should probably trim each key, and re-add spaces where you want them 
> >> in the function that does these kinds of things.
> >
> > I realize that's an option, but something about that feels wrong to me.
> >
> > We're adding a single space as prefix, not because it's meaningful for
> > citation purposes (there actually is no prefix, though org-cite
> > interprets it as " "), but only so buffer formatting works correctly.
>
> I don't think that's totally true. The additional space makes sense
> typographically, in particular when some suffix is associated to the
> key.

Can you give an example of what you mean here? I can't think of one
off the top-of-my-head.

> > And then presumably code needs to be added to the export machinery to
> > strip those empty affixes?
>
> I think they are ignored already. I didn't check though.

I just checked, and believe you are correct.

> > Am not saying the latter goal isn't important; just seems like the
> > side effect isn't ideal.
> >
> >> Maybe that should even be controlled by a defcustom that allows 0-1 spaces.
> >
> > You mean in org-cite? I think that'd be my preference, unless there's
> > a better solution to this issue.
>
> Org Cite is unrelated to this. One could as well have inserted spaces
> manually, i.e., without calling `org-cite-insert' at all.

I know; but you changed the default behavior of org-cite-make-insert-processor.

The OP asked if there were any implications for this generally, and
I'm just saying "yes, there is."

You do have to trim the whitespace on either side of the key, since
the space is the delimiter. I guess it's not possible for the citation
parser to ignore the other whitespace?

> The functions responsible for swapping citations ought to cope with this 
> situation
> too.

So check if the content of an affix, for example, is " " (rather than
whether there's an affix), and adjust accordingly?

Bruce

Re: A minor suggestion about formatting citations

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> On Mon, Oct 11, 2021 at 10:28 AM John Kitchin  wrote:
>>
>> you should probably trim each key, and re-add spaces where you want them in 
>> the function that does these kinds of things.
>
> I realize that's an option, but something about that feels wrong to me.
>
> We're adding a single space as prefix, not because it's meaningful for
> citation purposes (there actually is no prefix, though org-cite
> interprets it as " "), but only so buffer formatting works correctly.

I don't think that's totally true. The additional space makes sense
typographically, in particular when some suffix is associated to the
key.

> And then presumably code needs to be added to the export machinery to
> strip those empty affixes?

I think they are ignored already. I didn't check though.

> Am not saying the latter goal isn't important; just seems like the
> side effect isn't ideal.
>
>> Maybe that should even be controlled by a defcustom that allows 0-1 spaces.
>
> You mean in org-cite? I think that'd be my preference, unless there's
> a better solution to this issue.

Org Cite is unrelated to this. One could as well have inserted spaces
manually, i.e., without calling `org-cite-insert' at all. The functions
responsible for swapping citations ought to cope with this situation
too.

Regards,
-- 
Nicolas Goaziou

Re: A minor suggestion about formatting citations

[Bruce D'Arcus]

On Mon, Oct 11, 2021 at 10:28 AM John Kitchin  wrote:
>
> you should probably trim each key, and re-add spaces where you want them in 
> the function that does these kinds of things.

I realize that's an option, but something about that feels wrong to me.

We're adding a single space as prefix, not because it's meaningful for
citation purposes (there actually is no prefix, though org-cite
interprets it as " "), but only so buffer formatting works correctly.

And then presumably code needs to be added to the export machinery to
strip those empty affixes?

Am not saying the latter goal isn't important; just seems like the
side effect isn't ideal.

> Maybe that should even be controlled by a defcustom that allows 0-1 spaces.

You mean in org-cite? I think that'd be my preference, unless there's
a better solution to this issue.

Bruce

Re: Useful package? Compat.el

[Timothy]

Hi Russel,

> Do you have any examples of where this could shorten code in Org?

I don’t have any examples on hand, but Org is already rolling some compat code
for old Emacs versions, and we’ve had issues where people have accidentally used
functions which are “too new” (but a few years old, and so nobody picked it up
till someone raised an issue). I can also personally recall times when I’ve had
to refactor code to make it uglier and more verbose to avoid using newer
functions. All of this is why I’m thinking this could be an interesting idea.

> I believe it’s a tall order to add a dependency, but if it eliminates
> large chunks of backward compatibility code then maybe that’s
> something to consider.

I think the way to do this would be as a “soft” dependency, i.e. not needed for
anyone running a recent version of Emacs, but needed if you want to use Org with
an old version of Emacs. Not sure how this would best be done, but if this were
to be useful, this is how I’d imagine it working.

All the best,
Timothy

Re: A minor suggestion about formatting citations

[John Kitchin]

you should probably trim each key, and re-add spaces where you want them in
the function that does these kinds of things. Maybe that should even be
controlled by a defcustom that allows 0-1 spaces.

John

---
Professor John Kitchin (he/him/his)
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu



On Mon, Oct 11, 2021 at 9:38 AM Bruce D'Arcus  wrote:

> On Mon, Oct 11, 2021 at 5:40 AM Nicolas Goaziou 
> wrote:
> >
> > Hello,
> >
> > Vikas Rawal  writes:
> >
> > > I find it works better for me if I insert spaces between multiple
> > > citations. For example: [cite: @john56; @john35; @bruce2021] rather
> > > than [cite:@john56;@john35;@bruce2021].
> > >
> > > The of advantage is that if I am citing many references in one place,
> > > and use fill-paragraph/auto-fill, they wrap nicely. As far as I can
> > > see, having spaces in between works just fine.
> > >
> > > If this does not break anything, should this be the recommended
> > > practice for the org-cite-insert-processors?
> >
> > Done, at least for insert processors relying on
> > `org-cite-make-insert-processor'. Thank you.
>
> There is one little issue I see.
>
> Org-ref, and in turn org-ref-cite, have functions, attached via keymap
> on the citation face, that allow one to shift the citation-references
> within a citation.
>
> I've borrowed some of that for oc-bibtex-actions as well.
>
> So if I insert a citation using org-cite-insert, I get this:
>
> [cite:@samers2002; @kohn2005]
>
> If I then shift the right one left, I get this, which seems less than
> ideal:
>
> [cite: @kohn2005;@samers2002;]
>
> WDYT?
>
> Bruce
>
>

Re: Useful package? Compat.el

[Russell Adams]

On Mon, Oct 11, 2021 at 06:36:50PM +0800, Timothy wrote:
> I’ve recently come across an interesting looking library available on ELPA,
> . I’m thinking in future this could allow us 
> to
> both use newer features and also support older versions of Emacs, e.g.
>
> Org 10.X is developed for Emacs 28.1 and newer, but supports Emacs 24.3 and
> newer with compat.el.

That's interesting, using a library to wrap new Emacs functionality
and implement a common replacement instead of custom work-arounds in
local code.

Do you have any examples of where this could shorten code in Org?

I believe it's a tall order to add a dependency, but if it eliminates
large chunks of backward compatibility code then maybe that's
something to consider.

Thanks.

--
Russell Adamsrlad...@adamsinfoserv.com

PGP Key ID: 0x1160DCB3   http://www.adamsinfoserv.com/

Fingerprint:1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: A minor suggestion about formatting citations

[Bruce D'Arcus]

On Mon, Oct 11, 2021 at 5:40 AM Nicolas Goaziou  wrote:
>
> Hello,
>
> Vikas Rawal  writes:
>
> > I find it works better for me if I insert spaces between multiple
> > citations. For example: [cite: @john56; @john35; @bruce2021] rather
> > than [cite:@john56;@john35;@bruce2021].
> >
> > The of advantage is that if I am citing many references in one place,
> > and use fill-paragraph/auto-fill, they wrap nicely. As far as I can
> > see, having spaces in between works just fine.
> >
> > If this does not break anything, should this be the recommended
> > practice for the org-cite-insert-processors?
>
> Done, at least for insert processors relying on
> `org-cite-make-insert-processor'. Thank you.

There is one little issue I see.

Org-ref, and in turn org-ref-cite, have functions, attached via keymap
on the citation face, that allow one to shift the citation-references
within a citation.

I've borrowed some of that for oc-bibtex-actions as well.

So if I insert a citation using org-cite-insert, I get this:

[cite:@samers2002; @kohn2005]

If I then shift the right one left, I get this, which seems less than ideal:

[cite: @kohn2005;@samers2002;]

WDYT?

Bruce

Useful package? Compat.el

[Timothy]

Hi,

I’ve recently come across an interesting looking library available on ELPA,
. I’m thinking in future this could allow us to
both use newer features and also support older versions of Emacs, e.g.

Org 10.X is developed for Emacs 28.1 and newer, but supports Emacs 24.3 and
newer with compat.el.

Just tossing this out as an idea :)

All the best,
Timothy

Re: 9.5: coping with loss of ditaa.jar

[Jarmo Hurri]

Greetings Tim.

Tim Cross  writes:

> I think you missed one obvious solution - donwload the jar file from
> the ditaa project homepage on sourceforge.

> Another alternative which I just found is the ditaa version on github,
> which has SVG support. See https://github.com/stathissideris/ditaa. If
> you click on the 'release' link on the right, there is the most recent
> release, which includes a link to a standalone ditaa.jar file.

Ok, so at least two different standalone versions seem to be available:

1. via "project page" on sourceforge; looking inside the downloaded zip,
   this seems to be version 0.9

2. via developer github page, version 0.11.

On the github page there is a discussion indicating that a clojure
version will _not_ be forthcoming after all. The author also states that
(s)he is no longer interested in maintaining ditaa:

https://github.com/stathissideris/ditaa/issues/69

> I don't think you need to be paranoid about downloading the jar file
> from the project homepage - either you trust the code or you don't. If
> you don't trust the code, then even compiling it yourself adds no
> additional protection.

Trying to avoid binaries from "weird" sources probably just adds a sense
of false security. Sometimes false security is the best you can get.

Have fun and stay safe,

Jarmo

Re: 9.5: coping with loss of ditaa.jar

[Jarmo Hurri]

Howdy.

"Thomas S. Dye"  writes:

>> 2. Use the program "ditaa" (not ditaa.jar) that comes with your
>>operating system. This _may_ work, but I have not been ableto
>> misuse
>>the settings in ob-ditaa widely enough yet to create aworking
>>solution.
>
> This worked for me on Ubuntu 20.04, if it is helpful.
>
> sudo apt-get install ditaa
>
> Then set org-ditaa-jar-path to "/usr/bin/ditaa".

I get an error:

Error: Invalid or corrupt jarfile /usr/bin/ditaa

What I also tried to do is to change org-babel-ditaa-java-cmd to "ditaa"
and modify other parameters such as org-ditaa-jar-option
accordingly. But no cigar so far.

Have fun and stay safe,

Jarmo

Re: 9.5: coping with loss of ditaa.jar

[Jarmo Hurri]

Colin Baxter   writes:

>> Jarmo Hurri  writes:
>
>
>> 3. Copy ditaa.jar from previous version of org. Works in the short
>> run, but I do not think we want to advocate this: "We took ditaa.jar
>> out of org, so you will want to download an earlier version of org to
>> make ditaa work."
>
> Not true. I use Org mode version 9.5 (release_9.5-91-gf5faff) with a
> previous org-mode ditaa.jar and have no issues.

Sorry for my confusing language: I meant "you need to download an
earlier version of org _and take ditaa.jar from it_ to make ditaa work."

So I agree: no issues with this approach, but I do not think this is
what we would like users to have to do.

Have fun and stay safe,

Jarmo

Re: A minor suggestion about formatting citations

[Nicolas Goaziou]

Hello,

Vikas Rawal  writes:

> I find it works better for me if I insert spaces between multiple
> citations. For example: [cite: @john56; @john35; @bruce2021] rather
> than [cite:@john56;@john35;@bruce2021].
>
> The of advantage is that if I am citing many references in one place,
> and use fill-paragraph/auto-fill, they wrap nicely. As far as I can
> see, having spaces in between works just fine.
>
> If this does not break anything, should this be the recommended
> practice for the org-cite-insert-processors?

Done, at least for insert processors relying on
`org-cite-make-insert-processor'. Thank you.

Regards,
-- 
Nicolas Goaziou

Re: Citations: non-page locators placed in front of citation

[Nicolas Goaziou]

Hello,

M. ‘quintus’ Gülker  writes:

> Now it’s getting wild.

Indeed. The "fix" I introduced was a mistake. I pushed a new fix.
I think the initial issue is solved now. Could you confirm it?

Thank you.

Regards,
-- 
Nicolas Goaziou

Re: Citations: non-page locators placed in front of citation

[Nicolas Goaziou]

Hello,

András Simonyi  writes:

> looks like an Org (oc-csl) side locator parsing problem to me, because
> using the alternative [cite:@saenger2013gsr para. 12 Rn. 488] form I
> seem to get the correct result. Can it be a regex matching problem
> with the paragraph symbols?

You're right. I thought I had solved the regexp part but I was wrong.
I pushed a new attempt to solve this.

Sorry for the noise.

Regards,
-- 
Nicolas Goaziou

Customization of IDs generation method

[Ypo]

How would the "New option org-id-ts-format" work?

I added to my init.el these lines with no result (sorry if I am 
commiting heresy):


(defcustom org-id-ts-format "%Y-%m-%d-T%H-%M-%S.%6N"
  "Timestamp format for IDs generated using `ts' `org-id-method'.
The format should be suitable to pass as an argument to 
`format-time-string'.

Defaults to ISO8601 timestamps without separators and without
timezone, local time and precision down to 1e-6 seconds."
  :type 'string
  :package-version '(Org . "9.5"))

The format still is ISO8601 with no separators.

Re: A minor suggestion about formatting citations

[Eric S Fraga]

On Monday, 11 Oct 2021 at 04:39, Vikas Rawal wrote:
> If this does not break anything, should this be the recommended
> practice for the org-cite-insert-processors?

+1

This would be good when using visual-line-mode as well.

thank you,
eric

-- 
: Eric S Fraga via Emacs 28.0.60, Org release_9.5-93-gd87250
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: org-beamer empty titles

[Eric S Fraga]

Hi Joseph,

apologies for earlier message: I hit wrong key by mistake so sent before
writing my reply!

On Sunday, 10 Oct 2021 at 21:30, Joseph Vidal-Rosset wrote:
> Le 10/10/2021 à 22:04, Eric S Fraga a écrit :
>> or, if getting desperate, resort to some LaTeX magic:
>>
>> * @@latex:}%@@
>
> Many thanks Eric, the magic LaTeX solution works (but why?).

A headline, say

* introduction

will get exported as

\begin{frame}{introduction}

so my magic incantation above gets exported as

\begin{frame}{}%}

Remember that a % is a comment character in latex.  Therefore, this is
an empty frame title.

> "Registering" means "Ctrl-x-s" i.e. saving a file: when I save the org
> file, the blank space disappears...

You must have something in the write-file-hooks that strips whitespace?

-- 
: Eric S Fraga via Emacs 28.0.60, Org release_9.5-93-gd87250
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: org-beamer empty titles

[Eric S Fraga]

Hi Joseph,

On Sunday, 10 Oct 2021 at 21:30, Joseph Vidal-Rosset wrote:
> Le 10/10/2021 à 22:04, Eric S Fraga a écrit :
>> On Sunday, 10 Oct 2021 at 17:44, Joseph Vidal-Rosset wrote:
>>> I reply to my question about org-bullets: the reply is no. Registering
>>> an empty title section delete the space and then the export frame does
>>> not work. :(
>>
>> I am not sure what you mean by "registering".  You can type "* "
>> directly to create an empty headline, can you not?
>>
>> In any case, you could try the following maybe:
>>
>> *   :sometag:
>>
>> or, if getting desperate, resort to some LaTeX magic:
>>
>> * @@latex:}%@@
>>
>> --
>> : Eric S Fraga via Emacs 28.0.60, Org release_9.5-93-gd87250
>> : Latest paper written in org: https://arxiv.org/abs/2106.05096
>>
>
> Many thanks Eric, the magic LaTeX solution works (but why?).
>
> "Registering" means "Ctrl-x-s" i.e. saving a file: when I save the org
> file, the blank space disappears...
>
> Best wishes,
>
> Jo.
>
>
>

-- 
: Eric S Fraga via Emacs 28.0.60, Org release_9.5-93-gd87250
: Latest paper written in org: https://arxiv.org/abs/2106.05096