Re: How to keep getting org updates
What do you mean by 'inning' org to the ELPA repository?
What I've done was to remove the last line in my init.el for ...
orgmode.org/elpa, restarted, then tried through list-packages to D org --
which seemed to comply, but never removed org-20210920 from the elpa
directory. Not being gone, the old version kept reinstalling itself. So I
finally manually moved org-20210920 somewhere else. But then repeated
restarts never brought org-9.5 into the list-packages listing, despite
having gnu/elpa in my init.el. But I did manage to "trick" 9.5 in by
installing an org package with org, naturally, needed as a dependent. It
offered some other version, but the "other version" install window knew
about latest-greatest 9.5, which I chose, thereby "tricking" 9.5 to be
installed. Org-9.5 is now listed only as a dependency in list-packages, of
all things. I commented out my org-plus-contrib, not knowing how to proceed
with it. The install instructions on the main org page were not
very clear, to say the least.
On Tue, Oct 12, 2021 at 1:33 AM Tim Cross wrote:
>
> Galaxy Being writes:
>
> > 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.
>
> The 9.5 version is in GNU ELPA. However, if you have a version from
> orgmode.org or melpa, the version number is probably the release date
> e.g. 20211001 or example, and package.el will see that as a later
> version to 9.5 (because 20211001 is a larger number!).
>
> My suggestion would be to uninstall any version you have installed and
> then install the 9.5 version from ELPA. I would also remove the
> orgmode.org repository as you mention. It may also be worthwhile
> 'inning' org to the ELPA repository (which should mean package.el will
> only look at the ELPA repository when looking for updates (and not, for
> example, MELPA).
>
> If your running the emacs 28 pretest, it already includes 9.5
>
>
--
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borg...@gmail.com
Re: [PATCH] [BUG] Org 9.5: org-goto UI seems broken
Marco Wahl writes: > My feeling is that the "protection" is good intention but brings more > harm than good. I think it's not a good idea to enforce a certain > window setting. I guess the knowing user has an easier path to fine > tune the org-goto user interface when there is less "protection". I fully agree. That was the motivation behind removing dislpay-buffer-alist in 399481bad1. It is indeed not a good idea to overwrite user customisations. They can be deliberate. For example, see https://orgmode.org/list/87h7ij12t8.fsf@localhost Max Nikulin writes: > However current version of macro does not protect against > >(setq display-buffer-base-action >'((display-buffer-reuse-window display-buffer-pop-up-frame) > (reusable-frames . 0))) > > The example is taken from (info "(elisp) Choosing Window Options"). I > have no idea if such customization can be considered as shooting a foot. display-buffer-base-action, if customised by user, can later be fine-tuned using display-buffer-alist. If necessary, the user can easily add org-goto popup as an exception. At least, it is my understanding from reading docs. However, pop-up-frames and pop-up-windows are different beasts. They cannot be fine-tuned by the user to not affect org-goto. AFAIK, the only way for the user to overcome the problem would be advicing org-goto. > Summary: The org-goto interface today is somewhat broken. I vote for > taking the occasion and kicking out the macro org-no-popups entirely. > This way the org-goto interface is functional AFAICS. If problems occur > on that path we'll take care and action. > > Do you agree? My second version of the patch also fixes org-goto interface :) On the other hand, kicking org-no-popups macro completely may be an option. pop-up-windows and pop-up-frames are obsolete and should not be used anymore. Also, a compromise could be changing org-no-popups to just (let (pop-up-frames) ...) WDYT? Best, Ihor
Re: Expanding how the new cite syntax is used to include cross-references - thoughts?
On Tue, Oct 12, 2021 at 7:28 PM John Kitchin wrote: > > I am not sure it really fits the model of the exporters that are in org, > since it is basically just a pre-processing hook. [snip] > It also is (IMO) a part of org-ref since it uses the links that are defined > in org-ref. I see it as more an extension of org-mode than something that > needs to be in the core. For simple cross-references the built in internal > links are adequate I think. > > Anyway, it should be tested for a while to see if it is the right way to do > this. Maybe there are better ideas for it. Probably does take more testing and thought, but I guess I was thinking of something like an org-crossref-insert interactive function, that could make use of functions like org-ref-refproc-referenceables, to provide better out-of-box support for at least inserting cross-references. Perhaps like org-cite-insert, that could be configurable, so one could plug in a different such functions. I was toying with an idea like this earlier: https://gist.github.com/bdarcus/1cebcff17fca762a363f89138214848d Bruce
Re: Expanding how the new cite syntax is used to include cross-references - thoughts?
I am not sure it really fits the model of the exporters that are in org, since it is basically just a pre-processing hook. I don't think there are any exporters in org that rely on that, e.g. you can't just C-c C-e choose a backend and export with a pre-processing hook. It doesn't make sense to make a command that does that either I think, since you might want to use other pre-processing hooks too, e.g. I have one called natmove (inspired by the latex package) that moves superscript citations to the right hand side of punctuation, and in ox-ipynb I use pre-processing functions for removing solutions, and things like that. So some exports might use all three, and others only two, some just one, and others none. One solution for that is file-local variables I guess. It also is (IMO) a part of org-ref since it uses the links that are defined in org-ref. I see it as more an extension of org-mode than something that needs to be in the core. For simple cross-references the built in internal links are adequate I think. Anyway, it should be tested for a while to see if it is the right way to do this. Maybe there are better ideas for it. 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 Tue, Oct 12, 2021 at 5:58 PM Bruce D'Arcus wrote: > On Tue, Oct 12, 2021 at 5:16 PM John Kitchin > wrote: > > > > I think the existing link capability of org-mode is completely adequate > for cross-references. LaTeX exports are almost completely covered in > org-ref. I made a refproc ( > https://github.com/jkitchin/org-ref/blob/org-ref-3/org-ref-refproc.el) > that provides similar export behavior for other backends in a > pre-processing hook. It supports the concepts in autoref and cleveref by > replacing the org-links with an appropriate org syntax that then exports > natively. For example, if cref:name references a table, it would get > replaced by "Table [[name]]" in the buffer and then exported to the desired > backend. > > Nice work John; I'm glad you were able to sort it out. > > I haven't had a chance to play with it, but FYI I'm seeing a number of > compilation warnings (see below), which should be easy enough to fix. > > Any reason this, or something like it, shouldn't be added to org? > > Bruce > > org-ref-refproc.el:15:1: Warning: defcustom for > ‘org-ref-refproc-clever-prefixes’ fails to specify type > org-ref-refproc.el:15:1: Warning: defcustom for > ‘org-ref-refproc-clever-prefixes’ fails to specify type > > In org-ref-get-ref-links: > org-ref-refproc.el:47:54: Warning: reference to free variable > ‘org-ref-ref-types’ > > In org-ref-refproc-referenceables: > org-ref-refproc.el:113:60: Warning: reference to free variable > ‘org-ref-label-re’ > > In org-ref-refproc-cref-replacement: > org-ref-refproc.el:379:41: Warning: assignment to free variable > ‘prefix-data’ > org-ref-refproc.el:382:27: Warning: reference to free variable > ‘prefix-data’ > > In end of data: > org-ref-refproc.el:244:7: Warning: the function ‘org-ref-ref-jump-to’ is > not > known to be defined. >
Re: Expanding how the new cite syntax is used to include cross-references - thoughts?
On Tue, Oct 12, 2021 at 5:16 PM John Kitchin wrote: > > I think the existing link capability of org-mode is completely adequate for > cross-references. LaTeX exports are almost completely covered in org-ref. I > made a refproc > (https://github.com/jkitchin/org-ref/blob/org-ref-3/org-ref-refproc.el) that > provides similar export behavior for other backends in a pre-processing hook. > It supports the concepts in autoref and cleveref by replacing the org-links > with an appropriate org syntax that then exports natively. For example, if > cref:name references a table, it would get replaced by "Table [[name]]" in > the buffer and then exported to the desired backend. Nice work John; I'm glad you were able to sort it out. I haven't had a chance to play with it, but FYI I'm seeing a number of compilation warnings (see below), which should be easy enough to fix. Any reason this, or something like it, shouldn't be added to org? Bruce org-ref-refproc.el:15:1: Warning: defcustom for ‘org-ref-refproc-clever-prefixes’ fails to specify type org-ref-refproc.el:15:1: Warning: defcustom for ‘org-ref-refproc-clever-prefixes’ fails to specify type In org-ref-get-ref-links: org-ref-refproc.el:47:54: Warning: reference to free variable ‘org-ref-ref-types’ In org-ref-refproc-referenceables: org-ref-refproc.el:113:60: Warning: reference to free variable ‘org-ref-label-re’ In org-ref-refproc-cref-replacement: org-ref-refproc.el:379:41: Warning: assignment to free variable ‘prefix-data’ org-ref-refproc.el:382:27: Warning: reference to free variable ‘prefix-data’ In end of data: org-ref-refproc.el:244:7: Warning: the function ‘org-ref-ref-jump-to’ is not known to be defined.
Re: Expanding how the new cite syntax is used to include cross-references - thoughts?
I think the existing link capability of org-mode is completely adequate for cross-references. LaTeX exports are almost completely covered in org-ref. I made a refproc ( https://github.com/jkitchin/org-ref/blob/org-ref-3/org-ref-refproc.el) that provides similar export behavior for other backends in a pre-processing hook. It supports the concepts in autoref and cleveref by replacing the org-links with an appropriate org syntax that then exports natively. For example, if cref:name references a table, it would get replaced by "Table [[name]]" in the buffer and then exported to the desired backend. All of these are references to two tables named b1 and b2 - ref :: ref:b1 - autoref :: autoref:b1 - nameref :: nameref:b1 - pageref :: pageref:b1 - cref :: cref:b1 - cref, two :: cref:b1,b2 - Cref :: Cref:b1 - Cref, two :: Cref:b1,b2 and they are converted to this plain org syntax (which basically mirrors what would happen in a LaTeX export). - ref :: [[b1]] - autoref :: Tab. [[b1]] - nameref :: [[b1][this is a table b1.]] - pageref :: [[b1]] - cref :: Tab. [[b1]] - cref, two :: Tabs. [[b1]] and [[b2]] - Cref :: Tab. [[b1]] - Cref, two :: Tabs. [[b1]] and [[b2]] There are some options to control if the clever parts are abbreviated and/or capitalized. This should be part of org-ref on Melpa next week. 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 Sun, Oct 10, 2021 at 9:30 AM Bruce D'Arcus wrote: > Can we go back to this question of whether internal links are adequate > for cross-references, and if not, what's missing? > > On Fri, Aug 13, 2021 at 11:22 AM Eric S Fraga wrote: > > > > Hello John & co., > > > > I need to chime in when it comes to the UI: > > > > On Thursday, 12 Aug 2021 at 13:19, John Kitchin wrote: > > > I would say the UI that I like, have used for many years, and is the > > > default of org-ref is: > > > > > > 1. You type C-c ] to insert a citation > > > 2. You type C-u C-c ] to insert a cross-reference > > > 3. you type C-u C-u C-c ] to insert a new label. > > > > UI is a very personal thing. So long as there are 3 different functions > > that implement these actions, I would be happy... > > [snip] > > > In terms of the bigger picture, citations and cross-references, to me, > > are different things (one is external and the other usually internal, > > respectively) and I see no benefit in conflating them. I am also still > > not convinced that org links are not sufficient ... > > In reviewing and playing with this functionality a bit, it's clear to > me that internal links are intended to be cross-references, even if > they fall short for certain classes of users. > > Let's take a simple example of a figure, adapted from the manual: > > #+begin_example > #+CAPTION: This is the caption. > #+NAME: fig:SED-HR4049 > [[./img/a.jpg]] > > Here's a cross-reference to Figure [[fig:SED-HR4049]]. > #+end_example > > This internal link seems to produce consistent and correct output > across latex, html, and odt. > > The "fig" prefix is meaningful to ref in latex to enable it to type > that cross-reference. I'm unsure how typing in the odt context works, > but it does. > > The only downside is one has to manually, per the example, insert the > prefix (here "Figure ") in text (though this is a small price to pay > in my view). > > If one wants to use cleveref or autoref instead, as is now possible > with a recent commit, those packages handle that automatically. But of > course, this only works in latex, so you lose the consistency across > the backends. > > Also, you then need to be able to specify different variants locally > (for example, cref vs Cref), which is not possible currently. > > So I'm unclear: is that added functionality and complexity really > needed? Is there something else I'm missing? > > A separate, possibly more important (?), matter is UI and supporting > functionality. > > I think it would be nice to have better UI support for inserting these > references. > > To John's point, could we add interactive functions to insert labels > and cross-references (say as customizable functions?), using the > existing internal link support, and iterate that support over time? > > Bruce >
Re: [PATCH] [BUG] Org 9.5: org-goto UI seems broken
Hi Max and all! > On 08/10/2021 17:22, Marco Wahl wrote: >> Max Nikulin writes: >>> On 05/10/2021 23:32, Ihor Radchenko wrote: Max Nikulin writes: I tried come up with the reason why org-no-popup was used in the initial implementation. I think, the reason is avoiding situation like what you may see after running (let ((pop-up-frames t)) (funcall-interactively #'org-goto)) So, removing the macro completely is not a good idea. I have updated the patch that should work without dropping the macro. See the attached. >> >> Please note the documentation of variable `pop-up-windows'. >> >> This variable is provided mainly for backward compatibility and >> should not be used in new code. >> >> The same holds for `pop-up-frames'. >> >> The drop of the macro looks like a good idea to me. Can someone please >> describe the price for dropping macro `org-no-popups'? >> >> @Ihor I do not understand what "situation" you mean. > > Marco, have you tried > (setq pop-up-frames t) > with first version of patch? It shows help in a new separate frame. > Unsure if it is expected behavior even with such customization. > > However current version of macro does not protect against > > (setq display-buffer-base-action > '((display-buffer-reuse-window display-buffer-pop-up-frame) > (reusable-frames . 0))) > > The example is taken from (info "(elisp) Choosing Window Options"). I > have no idea if such customization can be considered as shooting a foot. TBH I don't fully understand that display-buffer stuff. I experimented a little with regards to org-goto. AFAICT org-goto does a good job without macro org-no-popups. IIUC the use of macro org-no-popups in org-goto shall "protect" the org-goto user interface in some sense. You already mentioned that. My feeling is that the "protection" is good intention but brings more harm than good. I think it's not a good idea to enforce a certain window setting. I guess the knowing user has an easier path to fine tune the org-goto user interface when there is less "protection". > http://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=399481bad10845a77f210c9320ff1efee9a312c8 > that caused the current problem changed namely `pop-up-windows' Thanks for the link! AFAICT the change in org-macs.el should not be in that commit since it has nothing to do with org links -- which are the actual concern of that commit. And indeed the change in org-macs.el of that commit broke the org-goto interface some. Summary: The org-goto interface today is somewhat broken. I vote for taking the occasion and kicking out the macro org-no-popups entirely. This way the org-goto interface is functional AFAICS. If problems occur on that path we'll take care and action. Do you agree? Regards, -- Marco
bug#51167: 29.0.50; org-indent-line broken
Andreas Röhler writes: > With following stuff in org-mode buffer: > > * bla > asd > > M-x org-indent-line RET on second line has no effect. Org 9.5 changed the default value of org-adapt-indentation from t to nil, as that seemed to be what a lot of users expect[1], so org-indent-line should not indent the second line in Emacs 28 onward unless configured otherwise: - setting org-adapt-indentation back to t will make Org indent by inserting whitespace; - alternatively, enabling org-indent-mode will make Org "soft-indent" with text properties. [1] Org 9.4 made RET and C-j obey electric-indent-mode like they do in most other major modes. Since org-adapt-indentation was t by default, this led to many dismayed reports on emacs-orgmode that "RET now messes up indentation", indicating that these users did not expect their prose to be indented.
Re: org-beamer empty titles
Le 12/10/2021 à 17:01, Eric S Fraga a écrit : > Ihor, thank you for this. > > Jo, what actual version of org are you using? I'm using a fairly recent > version (as of last week) so maybe what you want to do is possible now > but was not earlier? > > -- > : 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 > Maybe. I'm using presently Prelude Emacs and in elpa I have org-20210920/ What can I do? All the best, Jo.
Re: Citations: non-page locators placed in front of citation
Am Dienstag, dem 12. Oktober 2021 schrieb András Simonyi: > No, it's citeproc-el which is supposed to determine whether the passed > locator string represents single vs multiple references, using § vs §§ > shouldn't make a difference, because they simply signal that the label > is "section". I see. This explains why it makes no difference whether I use "section" or "§". Trying to find this out from the subsequent text alone sounds ambitious to me, though. There could be difficult edge cases I imagine. > Apparently, citeproc-el's classifier algorithm doesn't > handle some of your examples correctly -- could you open an issue > about this on the project page? Thanks in advance! Done: https://github.com/andras-simonyi/citeproc-el/issues/58 -quintus -- Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite Passau, Deutschland | kont...@guelker.eu| O<
Re: org-beamer empty titles
Le 12/10/2021 à 13:51, Eric S Fraga a écrit : > On Tuesday, 12 Oct 2021 at 08:05, Joseph Vidal-Rosset wrote: >> More seriously, the best solution for me would be to allow saving a file >> with a space just after ** without deleting this space... I do not know >> which code provokes this deletion. > > Maybe have a look at your write-file-hooks and write-file-functions > variables to see if there is some invocation that strips whitespace? The file.el of which this function depends is to big and too complicated for me. > > You may wish to use the whitespace package (for a little time) to see > when a space at the end of headline disappears. The whitespace package > is part of Emacs. > > -- > : 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 > This problem was also described here: https://emacs.stackexchange.com/questions/54970/preserving-the-space-immediately-after-an-org-heading-when-deleting-trailing-whi But no solution was given. All the best, Jo.
Re: org-beamer empty titles
Ihor, thank you for this. Jo, what actual version of org are you using? I'm using a fairly recent version (as of last week) so maybe what you want to do is possible now but was not earlier? -- : 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: [PATCH] [BUG] Org 9.5: org-goto UI seems broken
On 08/10/2021 17:22, Marco Wahl wrote: Max Nikulin writes: On 05/10/2021 23:32, Ihor Radchenko wrote: Max Nikulin writes: I tried come up with the reason why org-no-popup was used in the initial implementation. I think, the reason is avoiding situation like what you may see after running (let ((pop-up-frames t)) (funcall-interactively #'org-goto)) So, removing the macro completely is not a good idea. I have updated the patch that should work without dropping the macro. See the attached. Please note the documentation of variable `pop-up-windows'. This variable is provided mainly for backward compatibility and should not be used in new code. The same holds for `pop-up-frames'. The drop of the macro looks like a good idea to me. Can someone please describe the price for dropping macro `org-no-popups'? @Ihor I do not understand what "situation" you mean. Marco, have you tried (setq pop-up-frames t) with first version of patch? It shows help in a new separate frame. Unsure if it is expected behavior even with such customization. However current version of macro does not protect against (setq display-buffer-base-action '((display-buffer-reuse-window display-buffer-pop-up-frame) (reusable-frames . 0))) The example is taken from (info "(elisp) Choosing Window Options"). I have no idea if such customization can be considered as shooting a foot. P.S. http://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=399481bad10845a77f210c9320ff1efee9a312c8 that caused the current problem changed namely `pop-up-windows' Joshua mentioned `display-buffer-overriding-action'.
Re: org-beamer empty titles
Eric S Fraga writes: > I don't understand. Maybe somebody else on the list can test this? A blind shot: something to do with https://orgmode.org/list/87tumvdno3@gmail.com Hope it helps. Best, Ihor
Re: org-beamer empty titles
On Tuesday, 12 Oct 2021 at 13:58, Joseph Vidal-Rosset wrote:
> I get this :
>
> \begin{frame}[label={sec:org89e57ca}]{:emptytitle:}
I don't understand. Maybe somebody else on the list can test this?
--
: 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
Le 12/10/2021 à 13:51, Eric S Fraga a écrit :
> On Tuesday, 12 Oct 2021 at 08:05, Joseph Vidal-Rosset wrote:
>> I just tried what you suggested to me. The result is always the same: I
>> get the following title:
>> :emptytitle:
>> but this title is not empty, contradiction. :)
>
> This is very strange. What does the LaTeX code generated look like for
> this case? In my case, I get:
>
> \begin{frame}[label={sec:org4b25942}]{}
> some text for the slide
> \end{frame}
I get this :
\begin{frame}[label={sec:org89e57ca}]{:emptytitle:}
\begin{block}{test}
test
\end{block}
\end{frame}
>> More seriously, the best solution for me would be to allow saving a file
>> with a space just after ** without deleting this space... I do not know
>> which code provokes this deletion.
>
> Maybe have a look at your write-file-hooks and write-file-functions
> variables to see if there is some invocation that strips whitespace?
>
> You may wish to use the whitespace package (for a little time) to see
> when a space at the end of headline disappears. The whitespace package
> is part of Emacs.
Thanks ! I am going to see this point, very soon.
All the best,
Jo.
Re: org-beamer empty titles
On Tuesday, 12 Oct 2021 at 08:05, Joseph Vidal-Rosset wrote:
> I just tried what you suggested to me. The result is always the same: I
> get the following title:
> :emptytitle:
> but this title is not empty, contradiction. :)
This is very strange. What does the LaTeX code generated look like for
this case? In my case, I get:
\begin{frame}[label={sec:org4b25942}]{}
some text for the slide
\end{frame}
> More seriously, the best solution for me would be to allow saving a file
> with a space just after ** without deleting this space... I do not know
> which code provokes this deletion.
Maybe have a look at your write-file-hooks and write-file-functions
variables to see if there is some invocation that strips whitespace?
You may wish to use the whitespace package (for a little time) to see
when a space at the end of headline disappears. The whitespace package
is part of Emacs.
--
: 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: Inequalities in math blocks
On 12/10/2021 08:11, Nick Dokos wrote: 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, I am sorry, but I do not see your point. Do you know any reason why Org properly escapes "<>&" in text but transparently passes them to HTML inside LaTeX fragment? Does escaping them everywhere lead to problems? From the referenced document (I posted this link on 2021-10-03): you need to be careful that your mathematics doesn’t look like HTML tags to the browser, which parses the page before MathJax gets to see it. ... you can use the HTML entities , and to encode these characters so that the browser will not interpret them, but MathJax will. I fail to see any reason to blame HTML. Any text markup language requires some easily typed special characters. Org has one set of them, HTML another one. Export backend should just respect delimeters of the target format. I understand expectations and thus complains of Rudolf. In my opinion he has reasons to be disappointed (and maybe even angry to some degree). It looks like a bug in Org that should be fixed. Workarounds exist but Org should be more reliable.
Re: Citations: non-page locators placed in front of citation
Dear All, On Tue, 12 Oct 2021 at 07:43, M. ‘quintus’ Gülker wrote: > Das ist ein Test [cite:@saenger2013gsr § 12 Rn. 488]. > > gives: > > Saenger, Gesellschaftsrecht, 2. Aufl. (2013), §§ 12 Rn. 488 [...] > This is a little confusing. Maybe an error on my part? Do I need to > signal singular and plural use more explicitely? No, it's citeproc-el which is supposed to determine whether the passed locator string represents single vs multiple references, using § vs §§ shouldn't make a difference, because they simply signal that the label is "section". Apparently, citeproc-el's classifier algorithm doesn't handle some of your examples correctly -- could you open an issue about this on the project page? Thanks in advance! best wishes, András
Re: org-beamer empty titles
Le 12/10/2021 à 09:47, Eric S Fraga a écrit : > Jo, > > I am curious to know why the second proposed solution, i.e. putting a > tag on the headline with no actual headline text, didn't work for > you. It might be that you need to have > > #+options: tags:nil > > It worked for me and, at least to me, seems cleaner as you could then > have headlines like this: > > ** :emptytitle: > > which are more clear in terms of intent. Like I said, just curious. > > -- > : 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 > I just tried what you suggested to me. The result is always the same: I get the following title: :emptytitle: but this title is not empty, contradiction. :) More seriously, the best solution for me would be to allow saving a file with a space just after ** without deleting this space... I do not know which code provokes this deletion. Best wishes, Jo.
Re: org-beamer empty titles
Jo, I am curious to know why the second proposed solution, i.e. putting a tag on the headline with no actual headline text, didn't work for you. It might be that you need to have #+options: tags:nil It worked for me and, at least to me, seems cleaner as you could then have headlines like this: ** :emptytitle: which are more clear in terms of intent. Like I said, just curious. -- : 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
Le 10/10/2021 à 23:30, Joseph Vidal-Rosset a écrit : > > > 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?). Just a word to thank again Eric Fraga for this solution and to describe the way I have taken: I have added to one of my personal configuration files the following code: (global-set-key (kbd "C-c m") (lambda () (interactive) (insert "@@latex:}%@@"))) And after each double star for beamer frame, after adding the relevant space, I type C-c m to insert @@latex:}%@@ when I do not want a title for this frame, which is the most frequent case. I hope it will help people who meet the same problem. Best wishes, Jo.
Re: How to keep getting org updates
Galaxy Being writes:
> 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.
The 9.5 version is in GNU ELPA. However, if you have a version from
orgmode.org or melpa, the version number is probably the release date
e.g. 20211001 or example, and package.el will see that as a later
version to 9.5 (because 20211001 is a larger number!).
My suggestion would be to uninstall any version you have installed and
then install the 9.5 version from ELPA. I would also remove the
orgmode.org repository as you mention. It may also be worthwhile
'inning' org to the ELPA repository (which should mean package.el will
only look at the ELPA repository when looking for updates (and not, for
example, MELPA).
If your running the emacs 28 pretest, it already includes 9.5
