Buggy footnote numbering

[Guillaume MULLER]

Hi again,

I hope this time I'm not mistaken.

When I compile the attached file into a PDF with org-beamer-export-to-pdf, I 
get a PDF file where the footnotes numbering are using numbers in the text and 
letters in the footer.

Am I doing something wrong? Is there a simple workaround?

Good night

--
Guillaume MULLER


BuggyFootnotes.org
Description: Lotus Organizer


OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Strange behavior => bug?

[Guillaume MULLER]

Hi,

Here is the simplest example I could write:

 main.org
* slide 1
2. [@2] Works
3. Also

#+INCLUDE:  "./doesnotwork.org"

 doesnotwork.org
** Lorem
9. [@9] \small ipsum
10. ipsum


- If I try to "org-beamer-export-to-pdf" "main.org", I get:
org-do-latex-and-related: Args out of range: 0, 1

- If I remove the \small on lines "9." it works.

- If I copy-paste the content of "doesnotwork.org" into "main.org" it works.

Is this behavior normal?

- I cannot manage to find nor the problem (but I'm a n00b in org mode) nor a 
workaround. I would be glad if someone could help.


Thanks in advance


Guillaume


OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug in org-insert-link?

[Guillaume MULLER]

EDIT:

The problem is still here, and I managed to find the actual problem.

The problem happens when I do the "C-C C-l file:" then select a file. The root cause is 
that the mini-buffer then lists all the files in the current directory, and when there are many, 
the mini-buffer becomes quite big. Thus, the current buffer gets its size reduced, and when the 
cursor was very low in the buffer frame/window(?), the cursor "magically" jumps to a new 
position, in the part of the buffer that remained visible.

It is now perfectly reproducible on my side.

On 12/4/23 16:24, Guillaume MULLER wrote:

Hi,

Sorry for coming back that late on this problem. The problem came back again 
today: Links get inserted into random places again.

I think I have (the beginning of) an idea where problem lies.

Context:
- I'm using (Doom)Emacs in emacs-client mode, and I'm putting my computer only 
on sleep at night, so Emacs (daemon) often runs for weeks
- I regularly do some updates/upgrades: `sh> doom upgrade` or `sh> doom sync 
-u` (from shell, outside DoomEmacs)
   - Sometimes it works, so I just continue using Emacs
   - But sometimes doing the updates/upgrades while DoomEmacs is running make 
it go berserk
   - In such cases, I start by running `M-x doom/reload` (from inside Emacs), 
and if org buffers are going berserk too, I also run `M-x org-reload`
   - If it still does not work (most of the time), I `pkill emacs` and start 
Emacs again from scratch

The last time the link insertion issue appeared, I had called `M-x org-reload` 
after a `M-x doom/reload` after a `sh> doom upgrade`.

Restarting Emacs solved it.

I tried calling `M-x org-reload` and inserting some link on the fresh new Emacs 
process, and it seems to work.

So the problem apparently comes when calling `M-x org-reload` (from inside Emacs) 
after calling `sh> doom upgrade` (from outside Emacs). (NOTE: I haven't been 
able to try if the problem appears when calling `M-x doom/upgrade` (from inside 
Emacs) yet, as my Emacs is the freshest possible for now).

My conclusion is that "the bug" probably comes from the fact that the "org-mode" being 
reloaded is a fresher version than the "org-mode" that was loaded when Emacs-client was started, 
several weeks ago.

Not sure if this issue should be pursued or if my franken-usage of Emacs is to 
be blamed :)

Cheers

On 10/9/23 16:40, Guillaume MULLER wrote:

Hi,

Thanks for the answer... I'll have a look at your links.

However, since I wrote the email, I've seen the behavior occur without changing 
(at least voluntarily) the cursor position in the Org buffer...

On 10/5/23 12:18, Ihor Radchenko wrote:

Guillaume MULLER  writes:


...
- Switch back to (Doom)Emacs ("window"/desktop)
- Click inside the Emacs "window" to give it focus
[Here is the problem: sometimes I forgot that I already started the 
org-insert-link]
- Call org-insert-link
- Paste the URL
- Validate the link creation

Then the link is inserted where I clicked last (to give focus to the Emacs 
"window").


By default, Emacs moves point to where you click. You can do the same
thing if you deliberately C-x o from the minibuffer. See 9.3 Editing in
the Minibuffer section of Emacs manual.
I see nothing wrong on the Org side.


Of course, the problem lies in my mistake of calling twice the org-insert-link 
method, but the behavior is very strange, and it took me some time to identify 
why my links were inserted at random places in my text.

However, wouldn't it be possible to prevent it from the beginning by forbidding 
me to call org-insert-link twice, i.e. making it a singleton/atomic function (I 
don't see a UseCase where this could be useful to be able to call it inside 
itself, but maybe I'm wrong)?


Check out 22.1 Mouse Commands for Editing section of Emacs manual.
`x-mouse-click-focus-ignore-position' might be something you want to
customize.







--
Guillaume MULLER
Associate Professor, PhD
Fayol Institute - ISI Department
 #426
☎ 04 77 42 02 71
 https://www.mines-stetienne.fr
留= Physical Address =
  Espace Fauriel
  29 Rue Pierre et Dominique Ponchardier
  42100 Saint-Étienne
 = Postal Address =
  École des Mines de Saint-Étienne
  158 cours Fauriel
  42100 Saint-Étienne


OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug in org-insert-link?

[Guillaume MULLER]

Hi,

Sorry for coming back that late on this problem. The problem came back again 
today: Links get inserted into random places again.

I think I have (the beginning of) an idea where problem lies.

Context:
- I'm using (Doom)Emacs in emacs-client mode, and I'm putting my computer only 
on sleep at night, so Emacs (daemon) often runs for weeks
- I regularly do some updates/upgrades: `sh> doom upgrade` or `sh> doom sync 
-u` (from shell, outside DoomEmacs)
  - Sometimes it works, so I just continue using Emacs
  - But sometimes doing the updates/upgrades while DoomEmacs is running make it 
go berserk
  - In such cases, I start by running `M-x doom/reload` (from inside Emacs), 
and if org buffers are going berserk too, I also run `M-x org-reload`
  - If it still does not work (most of the time), I `pkill emacs` and start 
Emacs again from scratch

The last time the link insertion issue appeared, I had called `M-x org-reload` 
after a `M-x doom/reload` after a `sh> doom upgrade`.

Restarting Emacs solved it.

I tried calling `M-x org-reload` and inserting some link on the fresh new Emacs 
process, and it seems to work.

So the problem apparently comes when calling `M-x org-reload` (from inside Emacs) 
after calling `sh> doom upgrade` (from outside Emacs). (NOTE: I haven't been 
able to try if the problem appears when calling `M-x doom/upgrade` (from inside 
Emacs) yet, as my Emacs is the freshest possible for now).

My conclusion is that "the bug" probably comes from the fact that the "org-mode" being 
reloaded is a fresher version than the "org-mode" that was loaded when Emacs-client was started, 
several weeks ago.

Not sure if this issue should be pursued or if my franken-usage of Emacs is to 
be blamed :)

Cheers

On 10/9/23 16:40, Guillaume MULLER wrote:

Hi,

Thanks for the answer... I'll have a look at your links.

However, since I wrote the email, I've seen the behavior occur without changing 
(at least voluntarily) the cursor position in the Org buffer...

On 10/5/23 12:18, Ihor Radchenko wrote:

Guillaume MULLER  writes:


...
- Switch back to (Doom)Emacs ("window"/desktop)
- Click inside the Emacs "window" to give it focus
[Here is the problem: sometimes I forgot that I already started the 
org-insert-link]
- Call org-insert-link
- Paste the URL
- Validate the link creation

Then the link is inserted where I clicked last (to give focus to the Emacs 
"window").


By default, Emacs moves point to where you click. You can do the same
thing if you deliberately C-x o from the minibuffer. See 9.3 Editing in
the Minibuffer section of Emacs manual.
I see nothing wrong on the Org side.


Of course, the problem lies in my mistake of calling twice the org-insert-link 
method, but the behavior is very strange, and it took me some time to identify 
why my links were inserted at random places in my text.

However, wouldn't it be possible to prevent it from the beginning by forbidding 
me to call org-insert-link twice, i.e. making it a singleton/atomic function (I 
don't see a UseCase where this could be useful to be able to call it inside 
itself, but maybe I'm wrong)?


Check out 22.1 Mouse Commands for Editing section of Emacs manual.
`x-mouse-click-focus-ignore-position' might be something you want to
customize.





--
Guillaume MULLER
Associate Professor, PhD
Fayol Institute - ISI Department
 #426
☎ 04 77 42 02 71
 https://www.mines-stetienne.fr
留= Physical Address =
  Espace Fauriel
  29 Rue Pierre et Dominique Ponchardier
  42100 Saint-Étienne
 = Postal Address =
  École des Mines de Saint-Étienne
  158 cours Fauriel
  42100 Saint-Étienne


OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug with "BEAMER_OPT: shrink" and links

[Guillaume MULLER]

Hi,

Thanks for the follow up.

I found a similar issue in Beamer's GitHub issue and added my comment:
https://github.com/josephwright/beamer/issues/100#issuecomment-1731863334

Unfortunately, thanks to your follow up I just realized this issue was closed, 
so I opened a brand new one:
https://github.com/josephwright/beamer/issues/863

Have a nice day :)

--
Guillaume MULLER


OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug in org-insert-link?

[Guillaume MULLER]

On 10/10/23 13:25, Ihor Radchenko wrote:

Guillaume MULLER  writes:


However, since I wrote the email, I've seen the behavior occur without changing 
(at least voluntarily) the cursor position in the Org buffer...


Clicking, by default, changes the cursor position.


I forgot to mention, I'm using a WindowManager (i3) configured with "focus follows 
mouse" behavior, so I usually (~99% of the time) do not click in the Emacs window 
when I come back to it, so the cursor should not have moved when I do the manipulations I 
was talking about.


--
Guillaume MULLER


OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: org beamer strange behaviour

[Guillaume MULLER]

On 10/9/23 17:09, Fraga, Eric wrote:

I haven't looked at your file but do consider running org-lint on the
file to see if it picks up anything.


Thanks! I didn't know about org-lint!!!

Running it, I got these "errors":
   221 low   Unknown source block language: 'latex'
   252 low   Unknown source block language: 'bibtex'
   268 low   Unknown source block language: 'latex'
   282 low   Unknown source block language: 'sh'
   329 low   Unknown source block language: 'bibtex'
   434 low   Unknown source block language: 'latex'

...which is very strange as I have the following lines in my config.org file:

  ;; sh code in org-mode!
  (setq org-babel-sh-command "bash")
  (org-babel-do-load-languages
   'org-babel-load-languages
   '((shell . t))) ; this line activates Bash

  ;; LaTeX code in org-mode!
  (org-babel-do-load-languages
   'org-babel-load-languages
   '((latex . t))) ; this line activates LaTeX


I also define lstlisting "keywords" for bibtex in the header (taken from some 
StackOverflow thread; removing it does not change anything):

#+BEAMER_HEADER: \def\BibTeX{Bib\TeX{}}
#+BEAMER_HEADER:\lstdefinelanguage{BibTeX}
#+BEAMER_HEADER: {keywords={%
#+BEAMER_HEADER:  
@article,@book,@collectedbook,@conference,@electronic,@ieeetranbstctl,%
#+BEAMER_HEADER:  
@inbook,@incollectedbook,@incollection,@injournal,@inproceedings,%
#+BEAMER_HEADER:  
@manual,@mastersthesis,@misc,@patent,@periodical,@phdthesis,@preamble,%
#+BEAMER_HEADER:  @proceedings,@standard,@string,@techreport,@unpublished%
#+BEAMER_HEADER:  },
#+BEAMER_HEADER:   comment=[l][\itshape]{@comment},
#+BEAMER_HEADER:   sensitive=false,
#+BEAMER_HEADER: }

And org is supposed to use lstlisting to render the blocks (also in my 
config.org):
(after! org
  (setq org-latex-src-block-backend 'listings) ;; not always the best choice, 
but prevent DoomEmacs to go Berzerck (ask file to save to everytime) when using 
lstlistings-specific commands in org/beamer files
  ;;(setq org-export-allow-bind-keywords 1) ;; allows binding of emacs/lisp 
vars directly in .org files VERY INSECURE!!!
)



--
Guillaume MULLER


OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

org beamer strange behaviour

[Guillaume MULLER]

Hi,

I'm writing a lot of my courses in Org with a final export to Beamer/PDF.

Recently, I tried to improve the slides for a course I gave last year. When I 
opened the org file, I got a very weird coloring, as if a section was not 
closed correctly. You can find the org file and a screenshot of the rendering 
here:
https://seafile.emse.fr/d/f689a4318aff4e12a72e/

What's VERY strange to me is that whatever (sub)sections of the org original 
file I extract and yank/paste in another org file, then everything is OK...

Any idea what could be wrong?

--
Guillaume MULLER


OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug in org-insert-link?

[Guillaume MULLER]

Hi,

Thanks for the answer... I'll have a look at your links.

However, since I wrote the email, I've seen the behavior occur without changing 
(at least voluntarily) the cursor position in the Org buffer...

On 10/5/23 12:18, Ihor Radchenko wrote:

Guillaume MULLER  writes:


...
- Switch back to (Doom)Emacs ("window"/desktop)
- Click inside the Emacs "window" to give it focus
[Here is the problem: sometimes I forgot that I already started the 
org-insert-link]
- Call org-insert-link
- Paste the URL
- Validate the link creation

Then the link is inserted where I clicked last (to give focus to the Emacs 
"window").


By default, Emacs moves point to where you click. You can do the same
thing if you deliberately C-x o from the minibuffer. See 9.3 Editing in
the Minibuffer section of Emacs manual.
I see nothing wrong on the Org side.


Of course, the problem lies in my mistake of calling twice the org-insert-link 
method, but the behavior is very strange, and it took me some time to identify 
why my links were inserted at random places in my text.

However, wouldn't it be possible to prevent it from the beginning by forbidding 
me to call org-insert-link twice, i.e. making it a singleton/atomic function (I 
don't see a UseCase where this could be useful to be able to call it inside 
itself, but maybe I'm wrong)?


Check out 22.1 Mouse Commands for Editing section of Emacs manual.
`x-mouse-click-focus-ignore-position' might be something you want to
customize.



--
Guillaume MULLER
Associate Professor, PhD
Fayol Institue - ISI Department
 #426
☎ 04 77 42 02 71
 https://www.mines-stetienne.fr
留= Physical Address =
  Espace Fauriel
  29 Rue Pierre et Dominique Ponchardier
  42100 Saint-Étienne
 = Postal Address =
  École des Mines de Saint-Étienne
  158 cours Fauriel
  42100 Saint-Étienne


OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug in org-insert-link?

[Guillaume MULLER]

Hi,

Here is a situation that I often end up in:

- Open a .org file
- Type some text
- Select it
- Call org-insert-link
- Switch to another windows/desktop to find my running firefox
- Copy a URL
- Switch back to (Doom)Emacs ("window"/desktop)
- Click inside the Emacs "window" to give it focus
[Here is the problem: sometimes I forgot that I already started the 
org-insert-link]
- Call org-insert-link
- Paste the URL
- Validate the link creation

Then the link is inserted where I clicked last (to give focus to the Emacs 
"window").

Of course, the problem lies in my mistake of calling twice the org-insert-link 
method, but the behavior is very strange, and it took me some time to identify 
why my links were inserted at random places in my text.

However, wouldn't it be possible to prevent it from the beginning by forbidding 
me to call org-insert-link twice, i.e. making it a singleton/atomic function (I 
don't see a UseCase where this could be useful to be able to call it inside 
itself, but maybe I'm wrong)?

Thanks


--
Guillaume MULLER


OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug with "BEAMER_OPT: shrink" and links

[Guillaume MULLER]

Hi,

Here is a small test.org file that uses shrink to reduce the size of the slides:

---

* Shrink + Link broken
:PROPERTIES:
:BEAMER_OPT: shrink=10
:END:
**  Block1 with links
+ Some text [[https://www.google.com][Link1]]
+ \small [[https://www.microsoft.com][Link2]]
+ A very long text before the link [[https://mail.google.com][Link3]] text text
** Block2 with links
+ Test [[https://www.yopmail.com][Link4]]
+ [[https://test.it][Link5]]


* Test2
:PROPERTIES:
:BEAMER_OPT: shrink=60
:END:
** Block1 with links
+ Some text [[https://www.google.com][Link1]]
+ \small [[https://www.microsoft.com][Link2]]
+ A very long text before the link [[https://mail.google.com][Link3]] text text
** Block2 with links
+ Test [[https://www.yopmail.com][Link4]]
+ [[https://test.it][Link5]]


---

If you run 'org-beamer-export-to-pdf' on this file, you'll get a PDF where the 
clickable area for the link is most of the time way out of the text for the 
link...

I've search the web, no mention of that.

Cheers

GM


OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

How to solve "Warning (emacs): Please update the LaTeX src-block-backend to listings"

[Guillaume MULLER]

Hi,

I'm trying to create a code block with some latex code to be interpreted 
inside. I only knew lstlistings until now. Page 
https://orgmode.org/manual/Source-blocks-in-LaTeX-export.html lists Engraved 
and Minted as possible backend. 
https://list.orgmode.org/87wnf1z1w8@gmail.com/T/ also lists verbatim.

So from what I understand, of the message "Warning (emacs): Please update the LaTeX 
src-block-backend to listings", is that the default backend is not lstlistings and 
that there is a variable somewhere that should be set to lstlistings.

However I cannot find any documentation on what variable and where to set it. Is the 
variable indeed called "src-block-backend". Is it set in global Emacs config? 
Locally in the org file?

I tried to eval (setq src-block-backend 'listings) and (setq org-latex-listings 
t) . But error is still there.


Any idea?

--
Guillaume MULLER
Associate Professor, PhD
Fayol Institue - ISI Department
 #426
☎ 04 77 42 02 71
 https://www.mines-stetienne.fr
留= Physical Address =
  Espace Fauriel
  29 Rue Pierre et Dominique Ponchardier
  42100 Saint-Étienne
 = Postal Address =
  École des Mines de Saint-Étienne
  158 cours Fauriel
  42100 Saint-Étienne


OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[BUG] org-element-cache Org parser error [9.7 (9.7-??-d6f3aed @ /home/guillaume.muller/.emacs.d/.local/straight/build-28.1/org/)]

[Guillaume MULLER]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


When I start DoomEmacs, I get this message:

---
Warning (org-element-cache): org-element--cache: Org parser error in 
packages.el::4667. Resetting.
 The error was: (error "rx ‘**’ range error")
 Backtrace:
nil
 Please report this to Org mode mailing list (M-x org-submit-bug-report). 
Disable showing Disable logging
Warning (org-element-cache): org-element--cache: Org parser error in 
packages.el::4667. Resetting.
---


Emacs  : GNU Emacs 28.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, 
cairo version 1.16.0)
 of 2022-05-31
Package: Org mode version 9.7 (9.7-??-d6f3aed @ 
/home/guillaume.muller/.emacs.d/.local/straight/build-28.1/org/)

current state:
==
(setq
 org-link-elisp-confirm-function nil
 org-directory "~/.doom.d/org/"
 org-cite-insert-processor 'citar
 org-after-refile-insert-hook '(save-buffer)
 org-indirect-buffer-display 'current-window
 org-roam-db-gc-threshold 2305843009213693951
 org-bibtex-headline-format-function #[257 "\300%1\236A\207" [:title] 3 "\n\n(fn 
ENTRY)"]
 org-roam-mode-hook '(turn-on-visual-line-mode)
 org-load-hook '(+org-init-org-directory-h +org-init-appearance-h 
+org-init-agenda-h
 +org-init-attachments-h +org-init-babel-h 
+org-init-babel-lazy-loader-h
 +org-init-capture-defaults-h +org-init-capture-frame-h 
+org-init-custom-links-h
 +org-init-export-h +org-init-habit-h +org-init-hacks-h 
+org-init-keybinds-h
 +org-init-popup-rules-h +org-init-smartparens-h 
+org-init-roam-h)
 org-startup-folded nil
 org-babel-after-execute-hook '(+org-redisplay-inline-images-in-babel-result-h)
 org-link-abbrev-alist '(("doomdir" . "/home/guillaume.muller/.doom.d/%s")
 ("emacsdir" . "/home/guillaume.muller/.emacs.d/%s")
 ("doom-repo" . 
"https://github.com/doomemacs/doomemacs/%s;)
 ("wolfram" . "https://wolframalpha.com/input/?i=%s;)
 ("wikipedia" . "https://en.wikipedia.org/wiki/%s;)
 ("duckduckgo" . "https://duckduckgo.com/?q=%s;)
 ("gmap" . "https://maps.google.com/maps?q=%s;)
 ("gimages" . "https://google.com/images?q=%s;)
 ("google" . "https://google.com/search?q=;)
 ("youtube" . "https://youtube.com/watch?v=%s;)
 ("github" . "https://github.com/%s;))
 org-agenda-files '("~/org")
 org-capture-templates '(("t" "Personal todo" entry (file+headline +org-capture-todo-file 
"Inbox")
  "* [ ] %?\n%i\n%a" :prepend t)
 ("n" "Personal notes" entry (file+headline 
+org-capture-notes-file "Inbox")
  "* %u %?\n%i\n%a" :prepend t)
 ("j" "Journal" entry (file+olp+datetree 
+org-capture-journal-file)
  "* %U %?\n%i\n%a" :prepend t)
 ("p" "Templates for projects")
 ("pt" "Project-local todo" entry
  (file+headline +org-capture-project-todo-file "Inbox") "* 
TODO %?\n%i\n%a"
  :prepend t)
 ("pn" "Project-local notes" entry
  (file+headline +org-capture-project-notes-file "Inbox") "* 
%U %?\n%i\n%a"
  :prepend t)
 ("pc" "Project-local changelog" entry
  (file+headline +org-capture-project-changelog-file 
"Unreleased")
  "* %U %?\n%i\n%a" :prepend t)
 ("o" "Centralized templates for projects")
 ("ot" "Project todo" entry 
#'+org-capture-central-project-todo-file
  "* TODO %?\n %i\n %a" :heading "Tasks" :prepend nil)
 ("on" "Project notes" entry 
#'+org-capture-central-project-notes-file
  "* %U %?\n %i\n %a" :heading "Notes" :prepend t)
 ("oc" "Project changelog" entry 
#'+org-capture-central-project-changelog-file
  "* %U %?\n %i\n %a" :heading "Changelog" :prepend t)
 )
 org-roam-node-display-template #("${doom-hierarchy:*} ${doom-type:12} 
${doom-tags:42}" 20 35 (face font-lock-keyword-face) 36 51 (face org-tag))
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-format-latex-options '(:foreground default :background default :scale 1.5 
:html-foreground "Black"
:html-background "Transparent" :html-scale 1.0 
:matchers
("begin" 

link to magnet URL in org-mode?

[Guillaume MULLER]

Hello,

I maintain a list of links in an org-file. I wanted to export it as HTML file 
for a colleague, but I got the following error:

  Unable to resolve link: "magnet:?xt=urn:..."

What would be the correct way of linking to a magnet link in an org-mode file ?

Thanks in advance

--
Guillaume MULLER


OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Problem with footnotes for sub-items in Beamer export

[Guillaume MULLER]

Hi all,

Sorry, I launched a private discussion with Eric.

As he found a solution (see below), I'm sharing it here for those interested.

THANKS Eric! I didn't know we could use  directly on the \footnote command!

On 1/6/23 18:59, Fraga, Eric wrote:

Ah, my bad: I didn't look at your full example.
This, for the second slide, works:

  + <4-> Level1.3@@beamer:\footnote<4->{@@Footnote@@beamer:}@@

Please post the list as well?



Untested but what happens if you put \onslide within the footnote itself?
--
: Eric S Fraga, with org release_9.6-190-g82cc6f in Emacs 30.0.50


--
Guillaume MULLER
Assistant Professor, PhD
ISI Department - Office #426
04 77 42 02 71
École des Mines de Saint-Étienne
Espace Fauriel
29 Rue Pierre et Dominique Ponchardier
42100 Saint-Étienne
www.mines-stetienne.fr


OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Problem with footnotes for sub-items in Beamer export

[Guillaume MULLER]

Hi,

Happy new year to everyone.

CONTEXT: I have an org file that I want to expert as a Beamer presentation. In 
this file, I make \items appear one after the other. For some (sub)items (2nd 
level itemize), I would like to add a footnote.

EXPECTATION: I would expect this footnote to appear at the same time as the 
item.

RESULTS:

Whatever I try, the footnote appears either at the same time as the parent item 
(1rst level itemize), i.e. way before it is useful, or at the end of the 
itemize (when it is not necessary anymore) :{

As can be seen in the attached MWE, I've tried many things :
- Using \pause vs. (\onslide) for the items
- org-style footnote vs. LaTeX \footnote
- Hacking by inserting LaTeX code (manual insertion of LaTeX \onslide 
out/in-side the \footnote)
- Putting the itemize inside Blocks or not (behavior with the various tweaks 
above is not the same!)
- Native Emacs org (9.5) or MELPA org (9.6)

Any help would be appreciated

Regards,

--
Guillaume MULLER
Assistant Professor, PhD
ISI Department - Office #426
04 77 42 02 71
École des Mines de Saint-Étienne
Espace Fauriel
29 Rue Pierre et Dominique Ponchardier
42100 Saint-Étienne
www.mines-stetienne.fr


BugFootnote.org
Description: Lotus Organizer


OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

org-beamer-export-to-pdf generates \\\relax everywhere which makes latexmk complain

[Guillaume MULLER]

Hi,

This morning, I upgraded from Emacs 27 to Emacs 28 and to latest DoomEmacs.

Now, when I compile an org-Beamer presentation I had previously written & which 
compiled perfectly, latexmk outputs an error:



! Misplaced \noalign.
\hline ->\noalign 
  {\ifnum 0=`}\fi \hrule \@height \arrayrulewidth \futurelet...

l.519 \end{frame}


When I go the l.519 in the .tex file, I can see that now 
org-beamer-export-to-pdf generates \\\relax everywhere instead of \\.

At least in tables, this seems to be erroneous as both latexmk & pdflatex complain and 
removing the \relax in the generated ".tex" file suffice to render them compilable 
again.

Is that a bug or is there something I missed?


Cheers,

 
Guillaume MULLER




OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

org-beamer improvement?

[Guillaume MULLER]

Hi again,

While writing my previous email, I just thought of another thing. As it is 
unrelated to the other one, I'm creating a second email...

The only thing I miss in org lies in org-beamer: it is the ability to use the 
star '*' in BEARMER_ACT, with something like:
* my block1
:PROPERTIES:
:BEAMER_ACT: *<1>
:BEAMER_ENV: block
:END:
 + my content1
* my block2
:PROPERTIES:
:BEAMER_ACT: *<2>
:BEAMER_ENV: block
:END:
 + my content2
which would make the 2nd block appear "in place" of the 1rst one.
I end up doing things like:
#+LATEX: \onlide*<1>{
* my block1
* @@l:@@
:PROPERTIES:
:BEAMER_ENV: ignoreheading
:END:
 + my content1
#+LATEX: }
#+LATEX: \onlide*<2>{
* my block2
* @@l:@@
:PROPERTIES:
:BEAMER_ENV: ignoreheading
:END:
 + my content2
#+LATEX: }
Its works but it makes my org files look very ugly :{

I know block do not natively accept *<1> notation, but it would be great if org would 
detect the * in BEAMER_ACT directive and translate that into some code similar to the one I 
generate manually (#+LATEX + onslide* + shadow "ignoreheading "closing block).

Any thoughts on this?

--
Guillaume MULLER



OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Opening of links

[Guillaume MULLER]

Hi,

Thanks for org, "the best tool in the world"! ;) (*)

I have a simple org file (Linux / Emacs 27.1 + Doom):

--
#+TITLE: Test pdf links

+ [[file:~/test.pdf][PDF 1]]
--

When I click on the link with mouse1, the document is opened in Calibre. When I 
use mouse3, the document is opened in Emacs. I get a similar behavior with 
org-attached PDF documents: using 'o' will open them in Calibre, 'O' in Emacs.

Such a behavior for mouse1/'o' raises 2 questions:

- My OS settings are configured so that PDFs are opened in Evince. I configured this with "xfce4-settings-manager 
> Default Applications" (which runs "xfce4-mime-settings" under the hood) and it can be verified with 
"xdg-open test.pdf" or by opening Thunar and clicking on "test.pdf".
  So, where in the world does org-mode/Emacs finds that it should use Calibre 
instead of Evince?

- Now, I would like to circumvent this global OS behavior, so that Emacs itself 
would be used specifically to open PDF links in files I open in Emacs. When I 
was using Vanilla Emacs, I was advised to use pdf-tools, and given a config 
that was working. I translated that into my DoomEmacs config.org as follows:
  (use-package! pdf-tools
:magic ("%PDF" . pdf-view-mode)
:config
  (pdf-tools-install :no-query)
)
  But apparently it does not override org's (default) behavior of opening PDF 
file with external tools.
  Is there

Sorry for these (probably very) basic questions, but I could not find anything 
relevant on the web (or I haven't found the correct keywords...). I would be 
very grateful of any help!

Have a nice Week end

--
Guillaume MULLER



OpenPGP_0xF3BCAD9F46F5FADC.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: org-meta-return / org-insert-heading does not insert new heading in middle of heading even id org-M-RET-may-split-line is set

[Guillaume MULLER]

Hi again,

> I am using Vanilla Emacs.
> Note that Doom is known for carelessly advising some Org functions and
> can sometimes break things. Such issues should be reported to Doom
> developers.

Thanks for your help & pointers.

Yes I agree, the problem must come from Doom's config (the commit version it 
uses seems 24k+ commits behind your HEAD!!). I reported the problem directly to 
them:
https://github.com/doomemacs/doomemacs/issues/6544

I did some more tests within Doom's config (see the issue for details) but 
couldn't find the proper way to get it running the latest org release (9.5.4).

Fortunately, I ended up with a working config. 

I'm not sure what did the trick, but if someone is looking for a solution, it's 
probably a mix of:
- disabling org in Doom's init.el and/or
- manually pulling & compiling the versions in 
~/.emacs.d/.local/straight/{repos,build-27.1}/org  and/or
- changing the :pin setup in ~/.emacs.d/modules/lang/org/packages.el to point 
to the latest commit.

FWIW, "list-packages" only shows the 9.3 builtin version of org, so my current 
working 9.5.4 org version seems to actually be loaded from the code previously 
installed by Doom and manually (re)compiled by me, even if org is disabled in 
init.el ...

This will probably break at next Doom sync/upgrade, but since it works, I won't 
touch it anymore :)

> What do you mean by "breaks too many other things in org"?

When calling some functions (e.g. org-meta-return or org-ctrl-c-ctrl-c in a 
code block or hitting C-x C-c to quit Emacs) I got errors like "function xxx is 
void" or "wrong arguments listp, xxx".

Have a nice day


Guillaume


OpenPGP_signature
Description: OpenPGP digital signature

Re: org-meta-return / org-insert-heading does not insert new heading in middle of heading even id org-M-RET-may-split-line is set

[Guillaume MULLER]

Hi again,

Thanks for your answer and sorry for the duplicate.

I would be glad to help find if/where is the bug.

> Note that '(default . t) is _not_ the correct value. It should be
 '((default . t)). Just in case.

Yes indeed. I had it right in my config. I made the mistake when I copied into 
the email.

> I tried to set org-M-RET-may-split-line to nil first followed by setting
> it to either t or '((default . t)). For both values, I am seeing
> 
> * heading number
> * <>one
> 
> which is expected behavior.

Are you using DoomEmacs or Vanilla Emacs?

More precisely, are you using org-mode "9.6-??-e9da29b6f" as I do? (This is the 
only version that gives me the strange behavior)

> Please, try to reproduce starting from emacs -Q (without Doom).
> See https://orgmode.org/manual/Feedback.html

I've tried several things, but it's not very clear to me how to get/test the 
specific version of org-mode that is comes with doom ("9.6-??-e9da29b6f").

What I tried:

- Getting an as-vanilla-as-possible DoomInstall, by removing my config.org and 
sync'ing Doom. I get the same "9.6-??-e9da29b6f" org version and erroneous 
behavior.

- Changing the version of org-mode used in Doom, by removing the directory and 
installing the one from MELPA (9.5.4). This gives me the correct behavior for 
org-meta-return, but it breaks too many other things in org to be usable.

- Using "vanilla" "emacs -Q" and running only org "9.6".

  1. I've tried to manually load the org-version that comes with Doom, by 
writing & executing "(add-to-list 'load-path 
"/home/user/.emacs.d/modules/lang/org/lisp/autoload") (load "org")" from 
scratch buffer, then running org-reload
   + but I get org-version 9.3
   + and I can't find a way to edit the "load-path" "variable" to remove the 
native path ("/usr/share/emacs/27.1/lisp/org") from the list (sorry newbie 
here...)

  2. I've tried to git clone the org-mode repo in /tmp, but don't see any 
tag/branch that would correspond to a "9.6" version of org.
  + I do see a commit matching e9da29b6f 
(e9da29b6fafe63abbc2774e9d485ac13d2811b65)
* I've tried to recover the code from this version "git checkout e9da29b6f 
."
* Compiled it (make)
* Opened emacs -Q
* Wrote and executed "(add-to-list 'load-path "/tmp/org-mode/lisp/") (load 
"org")" in the scratch buffer
* Ran M-x org-reload
+ But "M-x org-version" still returns "Org mode version 9.5.4", and it 
works as expected

If you have any more hints on how I could setup an environment where I could 
test just org-mode "9.6-??-e9da29b6f" on a raw/vanilla emacs, I vwould be glad 
to test that.


Thanks in advance

-- 
Guillaume MULLER



OpenPGP_signature
Description: OpenPGP digital signature

org-meta-return / org-insert-heading does not insert new heading in middle of heading even id org-M-RET-may-split-line is set

[Guillaume MULLER]

Hi,

I thought I already reported this bug, but I cannot find it anymore in the 
mailing list archives 
(https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=org-meta-return=Search%21=emacs-orgmode=20=normal=date%3Alate)
 nor in the accepted bugs (https://updates.orgmode.org/?sort-bugs-by=date#bugs) 
so I'm reporting it (again?). Please forgive me if I'm duplicating it, but FYI 
it is still present today.

I'm using DoomEmacs (latest), which uses "Org mode version 9.6 
(9.6-??-e9da29b6f)".

When the cursor is in the middle of a heading (<> denots the cursor):
* heading number<> one

Hiting Meta-Ret results in:
* heading number one
* <>

Whereas it should result in:
* heading number
* <>one

At least if org-M-RET-may-split-line is set correctly.

By default, on my config org-M-RET-may-split-line is set to 'nil', but changing 
to whatever ("Always" or (default . t)) results in the same behavior.

The documentation for org-meta-return points to org-insert-heading which says:
"If point is in the middle of a line, split it and create a new headline with 
the text in the current line after point (see org-M-RET-may-split-line on how 
to modify this behavior)."

So this is actually a bug.

Cheers, keep up the good work!

GM


OpenPGP_signature
Description: OpenPGP digital signature

Re: Change of behavior of org-meta-return in 9.6/DoomEmacs?

[Guillaume MULLER]

Hi again,

Thanks for your response.


If you do C-h f org-meta-return, do you see something like "This
function has .. advice: .." towards the end of that *Help* buffer?


After investigation, the bug is in org-insert-heading in org 9.6 (Latest Doom - 
upgraded today - uses exactly version: (9.6-??-971eb68)

The documentation says:
"If point is in the middle of a line, split it and create a new
headline with the text in the current line after point (see
org-M-RET-may-split-line on how to modify this behavior).  As
a special case, on a headline, splitting can only happen on the
title itself.  E.g., this excludes breaking stars or tags.

Whatever the value(s) I put in org-M-RET-may-split-line , org-insert-heading 
*always* creates a new line with a empty heading/item and leaves anything that 
was on the initial heading/item in-place.

If someone can confirm this finding, I would be happy to create the 
corresponding bug report.

Have a nice day

--
Guillaume MULLER - PhD
DataScientist
Saint-Étienne
org-insert-heading is an interactive and byte-compiled function
defined in org.el.

Signature
(org-insert-heading  ARG INVISIBLE-OK TOP)

Documentation
Insert a new heading or an item with the same depth at point.

If point is at the beginning of a heading, insert a new heading
or a new headline above the current one.  When at the beginning
of a regular line of text, turn it into a heading.

If point is in the middle of a line, split it and create a new
headline with the text in the current line after point (see
org-M-RET-may-split-line on how to modify this behavior).  As
a special case, on a headline, splitting can only happen on the
title itself.  E.g., this excludes breaking stars or tags.

With a C-u prefix, set org-insert-heading-respect-content to
a non-nil value for the duration of the command.  This forces the
insertion of a heading after the current subtree, independently
on the location of point.

With a C-u C-u prefix, insert the heading at the end of the tree
above the current heading.  For example, if point is within a
2nd-level heading, then it will insert a 2nd-level heading at
the end of the 1st-level parent subtree.

When INVISIBLE-OK is set, stop at invisible headlines when going
back.  This is important for non-interactive uses of the
command.

When optional argument TOP is non-nil, insert a level 1 heading,
unconditionally.

Key Bindings
This command is not in any keymaps.

References
References in org.el:
(defun org-insert-heading-after-current ...)   1 reference
(defun org-insert-heading-respect-content ...) 1 reference
(defun org-insert-todo-heading ...)1 reference
(defun org-insert-subheading ...)  1 reference
(defun org-meta-return ...)2 references

Find all references Functions used by org-insert-heading

Debugging
Enable edebug Enable tracing
Disassemble Forget

Source Code
;; Defined in ~/.emacs.doom.d/.local/straight/repos/org/lisp/org.el
(defun org-insert-heading ( arg invisible-ok top)
  "Insert a new heading or an item with the same depth at point.

If point is at the beginning of a heading, insert a new heading
or a new headline above the current one.  When at the beginning
of a regular line of text, turn it into a heading.

If point is in the middle of a line, split it and create a new
headline with the text in the current line after point (see
`org-M-RET-may-split-line' on how to modify this behavior).  As
a special case, on a headline, splitting can only happen on the
title itself.  E.g., this excludes breaking stars or tags.

With a `\\[universal-argument]' prefix, set \
`org-insert-heading-respect-content' to
a non-nil value for the duration of the command.  This forces the
insertion of a heading after the current subtree, independently
on the location of point.

With a `\\[universal-argument] \\[universal-argument]' prefix, \
insert the heading at the end of the tree
above the current heading.  For example, if point is within a
2nd-level heading, then it will insert a 2nd-level heading at
the end of the 1st-level parent subtree.

When INVISIBLE-OK is set, stop at invisible headlines when going
back.  This is important for non-interactive uses of the
command.

When optional argument TOP is non-nil, insert a level 1 heading,
unconditionally."
  (interactive "P")
  (let* ((blank? (org--blank-before-heading-p (equal arg '(16
 (level (org-current-level))
 (stars (make-string (if (and level (not top)) level 1) ?*)))
(cond
 ((or org-insert-heading-respect-content
  (member arg '((4) (16)))
  (and (not invisible-ok)
   (invisible-p (max (1- (point)) (point-min)
  ;; Position point at the location of insertion.  Make sure we
  ;; end up on a visible headline if INVISIBLE-OK is nil.
  (org-with-limited-levels
   (if (not level) (outline-next-heading) ;before first headline
 (org-back-to-heading invisible-ok)
 (whe

Change of behavior of org-meta-return in 9.6/DoomEmacs?

[Guillaume MULLER]

Hi,

I've been using org-mode for a few years now. Thanks for the tool, I love it! 
What I love most is that it really feels like built FOR the user, as every 
default behavior is the right one!

I recently switched from Vanilla Emacs (org 9.5.3) to DoomEmacs (org 9.6), 
because I'm tired of managing my 2000+ config.org with half-backed results.

I noticed that hitting Meta-Return in org in Doom does not behave as in Vanilla 
Emacs. If I have (with <> being the cursor):

* outline 1
** outline 2
  + no<>te1
  + note2

In Vanilla Emacs, hitting M-Ret (i.e. calling org-meta-return) resulted in:

* outline 1
** outline 2
  + no
  + <>te1
  + note2

In Doom Emacs, it results in:
* outline 1
** outline 2
  + note1
  + note2
** <>

As I use "keycast" package, I can see that, in both cases:
- M-Ret is org-meta-return
- C-Ret is +org/insert-item-below
but in the case of DoomEmacs, both result in the same behavior.

I tried many combinations of C/M/Ret, but I cannot reproduce the behavior of 
Vanilla/9.5.3 in Doom/9.6 . The only way I found to reach the same result as 
Vanilla Emacs in Doom Emacs (i.e. creating a new entry based on the remaining of 
the line) is to cut & paste line splits and creating new items/outlines 
manually, which is very painful.

How can I check if it is a change in org 9.6 or in DoomEmacs?

How can I get back org-meta-return acting in Doom/9.6 as in Vanilla/9.5.3?

Thanks in advance for your help


Guillaume


OpenPGP_signature
Description: OpenPGP digital signature

Re: #+include vs. resizing & centrering [SOLUTION]

[Guillaume MULLER]

Sorry, I finally found a solution by myself :)

Using a minipage instead of a scalebox tolerates the \begin{center} that is 
automatically inserted:

#+LATEX: \center \begin{minipage}[c]{.85\textwidth}
#+INCLUDE: ./test.dot src dot :file test.png
#+LATEX: \end{minipage}

However, if someone has a pure/clean org-mode solution, I would love to learn 
it :)

On 3/30/22 11:07, Guillaume MULLER wrote:
> Dear all,
> 
> Thanks for org-mode, it is so perfect :)
> 
> I'm currently fighting with a problem that I cannot find a solution to 
> (either on my own or with help on the web). If someone could help me, I would 
> be very thankful.
> 
> I have an org-mode file that "includes" ane xternally generated image, like 
> so:
> 
> #+INCLUDE: ./test.dot src dot :file test.png
> 
> The thing is the resulting image is too big. So I want to resize it.
> 
> I've tried several things that did not work:
> - add #+ATTR_LATEX: :width xxx before the #+INCLUDE
> - add :width xxx or :scale xxx on the #+INCLUDE line itself
> - ...
> 
> Thus I resolved to use plain LaTeX code with something like:
> #+LATEX: \center \scalebox{.85}{%
> #+INCLUDE: ./test.dot src dot :file test.png
> #+LATEX: }
> 
> Then the problem is that #+INCLUDE adds a \begin{center}\end{center} around 
> the image inclusion, and \scalebox{} does not like that, making the resulting 
> .tex file not compile ("perhaps missing \item").
> 
> Again, I've tried several unsuccessful things :
> - add #+ATTR_LATEX: :center nil before the #+INCLUDE
> - add :center nil on the #+INCLUDE line itself
> - ...
> 
> If anyone has an idea how a can solve the problem of resizing a #+INCLUDE'd 
> image, either in plain org or with a LaTeX "warkaround", I would be very 
> grateful.
> 
> Thanks !
>  
> Guillaume MULLER, PhD

-- 
Guillaume MULLER, PhD


OpenPGP_signature
Description: OpenPGP digital signature

#+include vs. resizing & centrering

[Guillaume MULLER]

Dear all,

Thanks for org-mode, it is so perfect :)

I'm currently fighting with a problem that I cannot find a solution to (either 
on my own or with help on the web). If someone could help me, I would be very 
thankful.

I have an org-mode file that "includes" ane xternally generated image, like so:

#+INCLUDE: ./test.dot src dot :file test.png

The thing is the resulting image is too big. So I want to resize it.

I've tried several things that did not work:
- add #+ATTR_LATEX: :width xxx before the #+INCLUDE
- add :width xxx or :scale xxx on the #+INCLUDE line itself
- ...

Thus I resolved to use plain LaTeX code with something like:
#+LATEX: \center \scalebox{.85}{%
#+INCLUDE: ./test.dot src dot :file test.png
#+LATEX: }

Then the problem is that #+INCLUDE adds a \begin{center}\end{center} around the 
image inclusion, and \scalebox{} does not like that, making the resulting .tex 
file not compile ("perhaps missing \item").

Again, I've tried several unsuccessful things :
- add #+ATTR_LATEX: :center nil before the #+INCLUDE
- add :center nil on the #+INCLUDE line itself
- ...

If anyone has an idea how a can solve the problem of resizing a #+INCLUDE'd 
image, either in plain org or with a LaTeX "warkaround", I would be very 
grateful.

Thanks !
 
Guillaume MULLER, PhD


OpenPGP_signature
Description: OpenPGP digital signature

Re: Rescaling #+INCLUDES / Not centering #+INCLUDE?

[Guillaume MULLER]

On 10/5/21 5:06 PM, Eric S Fraga wrote:
> A data point: your example works just fine in org 9.5.

Arg... Yes sorry, I mixed up my MCE with my tests to get rid of the scalebox.

You'll find attached the actual non working .org file with the \scalebox that 
conflicts with the  \begin{center} that is automatically inserted by #+INCLUDE


My (unsuccessful) approaches so far to find a solution:
1. remove the automatic \begin{center} inserted by #+INCLUDE
   => using :center nil in #+INCLUDE or in additional #+ATTR_LATEX added above 
#+INCLUDE does not work
2. remove the use of \scalebox by using a more "org-mode"'s way of doing things
   => using :width in #+INCLUDE or in additional #+ATTR_LATEX or even passing 
options to dot have no effect (see previously attached file) 

Thanks for any help

PS: Sorry for my other mistake: I thought MELPA had latest org-mode, but I've 
now switched to actual lastest org-mode using git clone. Same problem occurs.
-- 
Guillaume MULLER
Data Scientist, PhD
Télécom Saint-Étienne (office i119)
25 rue du Dr Remy Annino
-
Laboratoire Hubert Curien (office e002)
18 rue du Pr Benoît Lauras
-
42000 Saint-Étienne
FRANCE
#+STARTUP: showall indent beamer

#+LATEX_CLASS: beamer

* Test Slide

#+LATEX: \scalebox{.85\textwidth}{
#+INCLUDE: test.dot src dot :center nil :file test.png
#+LATEX: }


OpenPGP_signature
Description: OpenPGP digital signature

Rescaling #+INCLUDES / Not centering #+INCLUDE?

[Guillaume MULLER]

Hi,

I have Emacs 26.3 + Org mode 9.4.6.

I tried to recompile an org-beamer file I created a few moths ago (see 
equivalent MCE attached), but it did not succeed.

The thing is I was #+INCLUDing a .dot file (also attached for completeness, but 
it could be any .dot file). I was putting the result inside a scalebox:

@@latex: \center \scalebox{.85}{@@
#+INCLUDE: test.dot src dot :file test.png
@@latex:}@@

I don't know how it was translated in previous versions of org-mode but it 
compiled perfectly.

Now I get error "! LaTeX Error: Something's wrong--perhaps a missing \item." 
during LaTeX compilation.

It seems the problem comes from the fact that the included file is 
automatically \begin{center}ed, which conflicts with my scalebox, as seen in 
output .tex file:

\begin{frame}[label={sec:org0a44c10}]{Test Slide}
 \center \scalebox{.85}{
\begin{center}
\includegraphics[width=.9\linewidth]{./images/DesignPatterns/23_DesignPatterns.png}
\end{center}

}
\end{frame}

When I remove the \begin/end{center}, the .tex file compiles fine.

I've tried to add ":center false" in the #+INCLUDE instruction and in a 
#+ATTR_LATEX preceding the #+INCLUDE. With no success.

I cannot find anything about centering (or not) a #+INCLUDE results in the docs 
nor in the mailing list.

Maybe there is a way to rescale the output without the \scalebox too, but I 
couldn't find how. Whatever I put in the #+ATTR_LATEX before the #+INCLUDE or 
in the #+INCLUDE (:cmdline -Gsize for dot) does not seem to be taken into 
account.

So any help would be appreciated.

BTW, thanks for the magnificent tools. I use them everyday and I love them!

Regards,

-- 
Guillaume MULLER
Data Scientist, PhD
Télécom Saint-Étienne (office i119)
25 rue du Dr Remy Annino
-
Laboratoire Hubert Curien (office e002)
18 rue du Pr Benoît Lauras
-
42000 Saint-Étienne
FRANCE


test.dot
Description: application/msword-template
#+STARTUP: showall indent beamer

#+LATEX_CLASS: beamer

* Test Slide

#+ATTR_LATEX: :width .1\textwidth
#+ATTR_DOT: size="9,15"
#+INCLUDE: test.dot src dot results :cmdline -Tpng -Gsize=9,15 -Gdpi=100 :file 
test.png


OpenPGP_signature
Description: OpenPGP digital signature

On the protection of emails in the archives

[Guillaume MULLER]

Hi all,

I recently sent an email on this mailing list (see 
https://orgmode.org/list/b1e778c5-acbf-8a17-c9bf-dcb6693e9...@univ-st-etienne.fr/
 )

Since then, I'm receiving spams on the email address I used to send the message.

After some research, it seems that this email address only appears on 2 
websites, notably this orgmode.org mailing list archive.

Would it be possible to configure the archive to obfuscate / hide the email 
addresses inorder to protect its users?

According to what I understand, this list uses the "GNU mailman" software, 
which in turn uses "Pipermail" for the archive. From what I read in the docs 
(https://www.gnu.org/software/mailman/mailman-member/node40.html ), the default 
configuration should be that the email addresses are protected : "The HTML 
archives which are created by Pipermail (the archiving program which comes 
default with Mailman) contain only obscured addresses.". So is there a 
particular reason why this option has been disabled?

Thanks for your feedback

GM



OpenPGP_signature
Description: OpenPGP digital signature

Bug: [enhancement] "Insert Link" (C-c C-l) to propose completion (dired-listing?) of local files when link=local-file [9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/)]

[Guillaume MULLER]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Hi,

This is a simple enhancement proposition for C-c C-l (insert link): when
user starts the link with ./ or / or file: , it would be great if org-mode could
propose completions based on some local-files listing (dired?)

Thanks for the great job. Emacs + Org + Lsp = Paradise :)

Emacs  : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14)
 of 2020-03-26, modified by Debian
Package: Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @ 
/usr/share/emacs/26.3/lisp/org/)

-- 
Guillaume MULLER
Data Scientist, PhD
Télécom Saint-Étienne (office i119)
25 rue du Dr Remy Annino
-
Laboratoire Hubert Curien (office e002)
18 rue du Pr Benoît Lauras
-
42000 Saint-Étienne
FRANCE
Mobile : +33 (0)6 51 22 33 49



signature.asc
Description: OpenPGP digital signature

Wring case when using org-insert-structure-template

[Guillaume MULLER]

Hi,

Thanks for Org-mode. This is really THE software I needed! I LOVE everything 
about it! This is the only piece of software I know of that really designed by 
users for users, with users & efficiency in mind!

I'm using GNU Emacs 26.3, with built-in org 9.1.9.

When I try to automatically insert Structure Templates (e.g. by typing C-c C-, 
s), I get everything inserted in lowercase (e.g. #+begin_src).

In ALL the documentation pages I read, the snippets are written in uppercase 
(i.e. #+BEGIN_SRC, like in the main documentation for this feature: 
https://orgmode.org/org.html#Structure-Templates). I would myself prefer to 
have the templates inserted in uppercase, as it allows to clearly & visually 
differentiate between my main document text and the specific instructions for 
Org.

First question: why isn't the default as in the docs?

Second question: I couldn't find any configuration variable or function to 
change the default behaviour. Is there a way to do so?

Thanks!

-- 
Guillaume MULLER
Data Scientist, PhD
Télécom Saint-Étienne (office i119)
25 rue du Dr Remy Annino
-
Laboratoire Hubert Curien (office e002)
18 rue du Pr Benoît Lauras
-
42000 Saint-Étienne
FRANCE
Mobile : +33 (0)6 51 22 33 49



signature.asc
Description: OpenPGP digital signature