Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
On 28/09/2023 19:31, Juan Manuel Macías wrote: I think I should insist on what I said in my previous message, with a copy/paste: The thing is that here it is not a question of whether something can be done in this way or in another better way. This is how a given package recommends doing it. If the user wants to use that specific package, she/he will have to follow these instructions. My reading of these instructions: users have 2 options, they either provide .xmpdata files directly or they ask LaTeX to generate it using filecontents* and take responsibility to remove the file when they change metadata. I do not see any words discouraging the former way, while there are warnings concerning pitfalls with the latter approach that still may be convenient in some cases. It's more. I am thinking, for example, of the case in which the user has to obtain a * tex file, not a PDF, because she/he is collaborating with more people who do not use Org, but do use that code in the * tex document. Perhaps I am wrong in my assumption that in particular case of PDF-X compliant documents, it is unlikely that it is just a single .tex document. If there are more files: graphics, custom packages, included .tex file then an additional separate .xmpdata file is not an issue.
[BUG] Return doesnt work when point is on org headlines after ellipsis [9.6.6 (release_9.6.6 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
From: Faust --text follows this line-- Hi, I use emacs 29.1 for macOS (sonoma) and it came with Org 9.6.6 and I think there’s a bug. To be sure that my config is not the reason I removed my own configuration completely to run Emacs out of the box; but the following bug occurred again: When point is on an org-headline after the ellipsis then return key doesn’t work, so point is stuck, its not possible to create a new line. This doesn’t happen on Emacs 28 on macOS sonoma, there is the normal behaviour since I use Emacs: with point after ellipsis the return key will set point to the beginning of a new line below the org headline (which remains collapsed). Thats it … hope this bug report was useful. I love Emacs!! Greetz from Stuttgart/Germany Arthur 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. Emacs : GNU Emacs 29.1 (build 1, aarch64-apple-darwin21.6.0, NS appkit-2113.60 Version 12.6.6 (Build 21G646)) of 2023-08-17 Package: Org mode version 9.6.6 (release_9.6.6 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)
Re: org-ctags-find-tag should not prompt inside org-open-at-point
Rudolf Adamkovič writes: > Joseph Turner writes: > >> (setopt org-ctags-open-link-functions nil) > > Oh, thank you! This regularly drives me crazy. You're welcome! > I added the following to my Emacs/Org configuration: > > #+BEGIN_SRC emacs-lisp :results none > (eval-after-load 'org-ctags > (setq org-ctags-open-link-functions nil)) > #+END_SRC Yes, eval-after-load makes sense. Joseph
Re: org-ctags-find-tag should not prompt inside org-open-at-point
Joseph Turner writes: > (setopt org-ctags-open-link-functions nil) Oh, thank you! This regularly drives me crazy. I added the following to my Emacs/Org configuration: #+BEGIN_SRC emacs-lisp :results none (eval-after-load 'org-ctags (setq org-ctags-open-link-functions nil)) #+END_SRC Rudy -- "I love deadlines. I love the whooshing noise they make as they go by." -- Douglas Adams, The Salmon of Doubt, 2002 Rudolf Adamkovič [he/him] Studenohorská 25 84103 Bratislava Slovakia
Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
Am Donnerstag, 28. September 2023, 12:07:41 CEST schrieb Max Nikulin:
> More I read about .xmpdata, more it looks similar to an ugly kludge from
> my point of view.
Exporting from orgmode to LaTeX needs a high level approach: don't do
complicated things, just use the appropriate LaTeX API.
Unfortunately adding XMP metadata is the largest construction site in the
LaTeX world: https://tug.org/TUGboat/tb43-3/tb135fischer-xmp.pdf
The LaTeX Project Team developed a new pdf management, see here: https://
ctan.org/pkg/pdfmanagement-testphase :
"The new PDF management code offers backend-independent interfaces to central
PDF dictionaries, tools to create annotations, form Xobjects, to embed files,
and to handle PDF standards."
The most important command is `\DocumentMetadata{}` and it needs to be placed
before `\ḑocumentclass{}`
The idea to have a LATEX_PRE_HEADER to insert `\DocumentMetadata{}` is exactly
what you need right now, if you export from orgmode to current LaTeX. With
`\DocumentMetadata{}` you can add most of the necessary xmp data -- and I
write most, because I'm using it on a daily basis, but haven't checked if
really everything is included yet.
--
Regards,
Alexander
signature.asc
Description: This is a digitally signed message part.
Re: Exporting elisp: and shell: links
Ihor Radchenko writes:
> Still, it would be nice to have _a_ variant compared to the current
> state of affairs.
Agreed. If the link has no description, we can do a great job on
exporting it. Half of the victory, right there!
Also, how about the following /simple/ idea for the description:
[[elisp:(server-start)][Launch Server]]
[[elisp:(server-start)][=M-x server-start RET=]]
src_elisp[:exports code]{(server-start)} (Launch Server)
src_elisp[:exports code]{(server-start)} (=M-x server-start RET=)
TL;DR We export the description, if any, in parentheses after the code.
Rudy
--
"One can begin to reason only when a clear picture has been formed in
the imagination."
-- Walter Warwick Sawyer, Mathematician's Delight, 1943
Rudolf Adamkovič [he/him]
Studenohorská 25
84103 Bratislava
Slovakia
Re: [BUG] Warning when creating preview
I forgot to say that now: "9.7-pre" GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.17.8) -- Sent with https://mailfence.com Secure and private email -- Sent with https://mailfence.com Secure and private email
Re: [BUG] Warning when creating preview
On Aug 28, 2023 at 11:00 AM, Ihor Radchenko wrote:Edgar Lux writes: > On Aug 27, 2023 at 7:29 PM, Ihor Radchenko wrote: >> I recommend https://github.com/Malabarba/elisp-bug-hunter to narrow down >> which part of the config is the culprit. > > We have a winner: Another winner? I am not getting the bug anymore ;; THIS SUCKS! ;; ;; Set soft line wrapping (only on screen, not adding ;; ;; newlines to files) ;; (remove-hook 'org-mode-hook #'turn-on-auto-fill) ;; (add-hook 'org-mode-hook ;; (lambda () ;; (turn-on-visual-line-mode) ;; ;; Visual indent ;; (org-indent-mode) ;; ;; Turn off hard wrapping ;; ;; (adding newlines to text) ;; (auto-fill-mode -1) ;; ;; Align tags from right to ;; ;; left to the width of the column ;; ;; (setq org-tags-column -60) ;; (setq org-tags-column ;; (- 3 fill-column ;; No more error ;; Set soft line wrapping (only on screen, not adding ;; newlines to files) (remove-hook 'org-mode-hook #'turn-on-auto-fill) (add-hook 'org-mode-hook #'turn-on-visual-line-mode) ;; Visual indent (add-hook 'org-mode-hook #'org-indent-mode) ;; Turn off hard wrapping ;; (adding newlines to text) (add-hook 'org-mode-hook (lambda () (auto-fill-mode -1))) ;; Align tags from right to ;; left to the width of the column ;; (setq org-tags-column -60) (add-hook 'org-mode-hook (lambda () (setq org-tags-column (- 3 fill-column -- Sent with https://mailfence.com Secure and private email
Re: Suggestions for Text-To-Speech (TTS) from Org sources?
espeak-ng likes to have speechdispatcher on a system and festival likes to have language-specific voices on it to use. fenrir which you didn't mention runs in user land and has no kernel dependencies. -- Jude "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Thu, 28 Sep 2023, Jens Lechtenboerger wrote: > Dear all, > > some time ago I asked for suggestions concerning Text-To-Speech > (TTS) from Org sources. Thank you to everyone who provided > suggestions! In case you are interested, you can listen to sample > results at [1]. > > Briefly, Emacspeak, espeak-ng, and festival are not good enough for > my purposes. Maybe I'm missing relevant backend options. IMHO, > Coqui-AI TTS [2] and Microsoft SpeechT5 [3] are far superior. > > Best wishes > Jens > > [1] https://gitlab.com/oer/emacs-reveal/-/wikis/Sample-TTS-results > [2] https://github.com/coqui-ai/TTS/ > [3] https://huggingface.co/microsoft/speecht5_tts > >
Re: Suggestions for Text-To-Speech (TTS) from Org sources?
Dear all, some time ago I asked for suggestions concerning Text-To-Speech (TTS) from Org sources. Thank you to everyone who provided suggestions! In case you are interested, you can listen to sample results at [1]. Briefly, Emacspeak, espeak-ng, and festival are not good enough for my purposes. Maybe I'm missing relevant backend options. IMHO, Coqui-AI TTS [2] and Microsoft SpeechT5 [3] are far superior. Best wishes Jens [1] https://gitlab.com/oer/emacs-reveal/-/wikis/Sample-TTS-results [2] https://github.com/coqui-ai/TTS/ [3] https://huggingface.co/microsoft/speecht5_tts
Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
Max Nikulin writes:
> LaTeX code may be inserted
> - before \DocumentMetadata
> - between \DocumentMetadata and \documentclass
> - between \documentclass and preamble added by Org
> - between Org preamble and \begin{document}
The first two cases can be solved perfectly with LaTeX_pre_header,
without having to complicate your life further.
> Since ordering is important [...]
Starting with \documentclass, the order is important in certain cases
and not so important in others. And, anyway, you can always use a hook
like \AtBegin... \AtEnd..., etc.
And if users want to have complete control over the preamble (that is,
everything before \begin{document}), they can always define a new class
(in Org terminology) or write a preamble or a sty file in a separate Org
document using org-babel and literary programming. In a job I'm doing
now my preamble has 1736 lines. Writing it with org-babel is quite
comfortable. In short, I think (IMHO) Org already has enough resources
for those situations.
> I consider \begin{filecontents*}{\jobname.xmpdata} as an acceptable
> (but perhaps fragile) hack for LaTeX-first document. During export of
> Org file, this file should be written directly with values from Org
> metadata.
I think I should insist on what I said in my previous message, with a
copy/paste:
The thing is that here it is not a question of whether something can be
done in this way or in another better way. This is how a given package
recommends doing it. If the user wants to use that specific package, she/he
will have to follow these instructions. It's more. I am thinking, for
example, of the case in which the user has to obtain a * tex file, not a
PDF, because she/he is collaborating with more people who do not use
Org, but do use that code in the * tex document.
Apart from that, since any code (except \usepackage) is allowed before
\documentclass, I think that the user should have the possibility (and
the freedom) to enter in their *tex documents whatever they want in that
place, including comments, luacode, shebangs, etc.
--
Juan Manuel Macías
https://juanmanuelmacias.com
https://lunotipia.juanmanuelmacias.com
https://gnutas.juanmanuelmacias.com
Re: [BUG] [PATCH] Add yank-media and DND handler [9.6.7 (9.6.7-g6eb773 @ /home/viz/lib/emacs/straight/build/org/)]
On 27/09/2023 15:29, Visuwesh wrote: Ihor Radchenko wrote: We can just say :safe nil (omit the keyword). Then, users will be >> prompted and can decide which directories are truly safe for them.> That would be quite annoying IMO. I say we let the user shoot> themselves in the foot. The patch implements 2 features: - attach to an Org file, - save to arbitrary directory. Second option is not specific to Org, so I would consider it in the context of Emacs core or an independent ELPA package. I am unsure if this is a bright idea, but it eliminates most of questions. Concerning security issues, there is demand like I wish to open Org files by using EWW. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58774#34 So a file from net may have arbitrary local variables. On 27/09/2023 15:33, Visuwesh wrote: Max Nikulin wrote: Does it mean that `org--dnd-local-file-handler' is unconditionally called for Org buffers? Current action is to open text files in the widow under cursor and it is what users may expect. They may be surprised if the file is attached instead. The common request I see when a file is dropped is to associate it somehow with the org-mode buffer. org-attach is the most natural way to do it. If the users like the old behaviour, they can remove the entry from the alist. I am unsure concerning opt-in vs. opt-out choice. I do not follow discussions e.g. on emacs help and on reddit, so I can not estimate if voice of users happy with opening file and discovered changed defaults would be louder.
Re: [patch] ox-latex.el: Add `LATEX_PRE_HEADER' keyword
On 27/09/2023 02:12, Juan Manuel Macías wrote:
Max Nikulin writes:
I remember recipes like "put \usepackage{cmap} immediately after
\documentclass" (nowadays this particular one should not be necessary).
So I would prefer to avoid keywords per each chunk of preamble code.
I think that this would not be the case. This is not just any part of
the preamble, but a fairly definite part. Broadly speaking, LaTeX_header
would take care of what is after \documenclass (the axis of a LaTeX
document); LaTeX_pre_header would do it of anything that may have come
before. And both provide a less constricted preamble for advanced use of
LaTeX. Frankly, I can't think of a simpler solution.
LaTeX code may be inserted
- before \DocumentMetadata
- between \DocumentMetadata and \documentclass
- between \documentclass and preamble added by Org
- between Org preamble and \begin{document}
Since ordering is important, I would prefer to assemble preamble from
predefined fragments (or replace particular ones) to putting code into
these (and probably more) slots.
\begin{filecontents*} from the original post is not convincing.
Are you not convinced by some instructions that are included in the
official documentation of a LaTeX package (pdfx)?
More I read about .xmpdata, more it looks similar to an ugly kludge from
my point of view. The following phrases are hardly consistent:
- "Including the metadata with the LATEX source is very convenient."
- "remember to remove the existing copy of \jobname.xmpdata file before
the next processing run".
(A side note: "overwrite" option of filecontents looks promising.)
So the goal is an XML document embedded into PDF. I admit, Org can not
provide it directly since e.g. PDF compliance level is responsibility of
a PDF engine.
However the intermediate .xmpdata file may be provided independently of
its .tex counterpart accordingly to docs. This file contains metadata
and in Org metadata are managed through keywords. Significant fraction
of metadata may be shared with HTML or MarkDown, so keywords should be
considered as primary data. Writing this file from Org (e.g. by a babel
source code block) should avoid issues with LaTeX input encodings
described in the docs. Thus generation of .xmpdata during exporting of
an .org file allows to keep metadata consistent.
Currently I do not see a way to get values of INFO argument of
org-export functions from source code blocks making access to metadata
tricky. This should be addressed somehow. I would consider specifying
metadata in a way similar to org-babel header arguments to allow more
fields than currently supported by Org. It should facilitate generation
of \DocumentMedata, .xmpdada, etc.
Ability to overwrite fragments of preamble should be supported, but only
as last resort. Specifying \DocumentMetadata or .xmpdata contents
literally should be avoided to prevent discrepancy with metadata keywords.
I consider \begin{filecontents*}{\jobname.xmpdata} as an acceptable (but
perhaps fragile) hack for LaTeX-first document. During export of Org
file, this file should be written directly with values from Org metadata.
