Re: [BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3mpjk70si-emacs-org-9.6.7/share/emacs/site-lisp/org-9.6.7/)]

[Max Nikulin]

On 05/09/2023 16:42, Ihor Radchenko wrote:

Max Nikulin writes:


  From my point of view it will be more sane behavior. However it may
require update of 3rd party ox backends.


Yes. The main problem is that I fail to understand the motivation behind
the current behaviour. git logs reveal that the code is there from the
initial version of the library.


Just a guess, likely unrelated to actual decision. For links like 
"lisp:" or "shell:" keeping link type does not have much sense (however 
stripping it is questionable as well).


From my point of view, e.g.  should be exported 
as plain text (identity "a") rather than an (invalid due to 
not escaped quotes inside href) link (identity 
"a").


I still believe that fallback export should preserve link type. Code 
links should define their export functions.

Re: Description list with " :: " in the tag.

[Max Nikulin]

On 09/09/2023 16:06, Ihor Radchenko wrote:

Everything after the bullet and before the last " :: " is considered as
tag. Everything after the last " :: " is description.


I have not realized that besides

  - 

that is parsed as 'b">' description, another surprise is

  - or :: 

where description is 'd">' and the link is truncated.

Re: Feature request: Allow export to convert broken links to plain text

[Ryan C. Thompson]

On 1/13/19 5:34 PM, Berry, Charles wrote:

Looks like your original idea to revise `org-export-data' might be best.

IIUC, you need to add the link text to the SIGNAL-DATA in each of the places 
where `org-export-resolve-*-link' functions call `signal', then modify 
`org-export-data' to ignore the addition for `mark' and add it back for your 
new `mark-with-text' option.

HTH,

Chuck


Years later, I became annoyed enough by this to attempt to fix it again. 
Unfortunately, I looked into changing all the functions that signal 
org-link-broken, and not all of them can be modified in the way you 
described, at least not easily. Instead, I came up with a fairly clean 
alternative solution: define a new link type "maybe" using 
org-link-set-parameters with an :export function that pulls out the real 
link transcoder from the backend and calls it, but then implements my 
desired behavior if that transcoder throws an error. This allows you to 
prefix any link's path with "maybe:" to have it magically become plain 
text if it can't be resolved during export. Here's the implementation:



(org-link-set-parameters
 "maybe"
 :follow
 (lambda (path prefix)
   (condition-case err
   (org-link-open-from-string (format "[[%s]]" path))
 (error (message "Failed to open maybe link %S" path
 ;; This must be a lambda so it is self-contained
 :export
 (lambda (path desc backend  info)
   (when (symbolp backend)
 (setq backend (org-export-get-backend backend)))
   ;; Generate the non-maybe version of the link, and call the
   ;; backend's appropriate transcoder on it, but catch any error
   ;; thrown and just replace the link with its text instead.
   (let* ((real-link
   (with-temp-buffer
     (save-excursion (insert "[[" path "][" desc "]]"))
     (org-element-link-parser)))
  (real-link-transcoder (cdr (assoc 'link 
(org-export-get-all-transcoders backend)

 (condition-case err
 (funcall real-link-transcoder real-link desc info)
   (error
    (message "Skipping error during maybe link transcoding: %S" err)
    (or desc path))


Using the above code, the following org file can be successfully 
exported to HTML, with the broken/invalid links converted to just plain 
text.



* First heading
:PROPERTIES:
:CUSTOM_ID: heading1
:END:
- [[maybe:maybe:maybe:https://google.com][Maybe google]]
- [[maybe:#heading1][Link to first heading]]
- [[maybe:#heading2][Link to second heading]]
- [[maybe:#heading3][Link to third(?) heading]]
- [[maybe:blarg:notalink][This is an invalid link]]
* Second heading
:PROPERTIES:
:CUSTOM_ID: heading2
:END:


So, this isn't an ideal solution, since it requires me to prefix any 
potential offending links with "maybe:". But it's good enough for me.



Regards,

Ryan

Re: #2 [[bbb:OrgMeetup]] on Wed, Sep 13, 19:00 UTC+3

[Esteban Ordóñez]

 
> The last meetup [1] turned out quite successful. Let's continue.
> 
> [1] https://list.orgmode.org/877cq38gdt.fsf@localhost/ (meetup notes)

Thanks a lot for the notes, Ihor!  I hope that I do not miss the next
meetup.

Re: [patch] Fixes and improvements in org-latex-language-alist

[Juan Manuel Macías]

Ihor Radchenko writes:

> I am thinking about something like
>
> (let ((de-plist '(...)))
>  `(...
>("de" ,@de-plist)
>("de-de" ,@de-plist)
>...))
>
> This is copy-paste-proof and does not require breaking changes in the
> value structure.

I like the idea because it avoids errors, but I don't know if
it's worth it, there being only two cases (at the moment). This other
possibility occurred to me, just to make it easier to read and not have
to navigate to the list of variables:

(let* ((basic-code)
   (shared-plist (lambda ( plist)
 (setq basic-code plist
  `(...
("de" ,(funcall shared-plist :babel "ngerman" :babel-ini-alt "german" 
:polyglossia "german" :polyglossia-variant "german" :lang-name "German" :script 
"latin" :script-tag "latn"))
("de-de" ,@basic-code)
...
("zh" ,(funcall shared-plist :babel-ini-only "chinese" :polyglossia 
"chinese" :lang-name "Chinese Simplified" :script "hans" :script-tag "hans"))
("zh-cn" ,@basic-code)))

Likewise, there being two cases (even in the case of Chinese you could
perfectly omit zh-cn, because it is a new language and there is no
danger of regression), I would say that it is not worth complicating the
code so much.

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

[BUG] org-export-with-broken-links not respected for (org-icalendar-combine-agenda-files t) [9.6.9 ( @ /home/jorge/.config/emacs/elpa/org-9.6.9/)]

[Jorge P. de Morais Neto]

Hi.  I am on Gentoo.  I wrote the following Elisp function:

--8<---cut here---start->8---
(defun J-org-icalendar-agenda-no-babel ( async)
  "Invoke `org-icalendar-combine-agenda-files' without babel, maybe ASYNC.

Also, make broken Org links just get marked as such in the
output, instead of stopping the export with an error."
  (interactive "P")
  (let (org-export-use-babel
(org-export-with-broken-links 'mark))
  (org-icalendar-combine-agenda-files async)))
--8<---cut here---end--->8---

When I invoke (J-org-icalendar-agenda-no-babel t), the async export
errors out.  I determined that the inferior Emacs process does not see
the let-binding (org-export-with-broken-links 'mark).  Is this intended
behavior?

For now I have worked around this by writing

(setopt org-export-with-broken-links 'mark)

At the end of the file named by `org-export-async-init-file`.

Regards!

Emacs  : GNU Emacs 29.1.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, 
cairo version 1.17.8)
 of 2023-09-03
Package: Org mode version 9.6.9 ( @ /home/jorge/.config/emacs/elpa/org-9.6.9/)
-- 
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Free Software Supporter: https://www.fsf.org/free-software-supporter
- If an email of mine arrives at your spam box, please notify me.
- Many people hate injustice but few check the facts; this causes more
  injustice.  Ask me about 

Re: Suggestions for Text-To-Speech (TTS) from Org sources?

[briangpowell]

I've turned OrgMode files into audio desktops

It was pretty simple

Just find the code that reveals what an icon is when you hover over it &
pipe it to some text-to-speech engine & then on to usual routes

On Sat, Sep 9, 2023 at 2:06 PM Jens Lechtenboerger <
lech...@wi.uni-muenster.de> wrote:

> Dear all,
>
> does someone here produce audio via Text-To-Speech (TTS) from Org
> sources?  I plan to do that in the context of emacs-reveal to
> generate voice-over for reveal.js presentations, with open questions
> [1] concerning my initial, experimental approach.
>
> Currently, I like the default model of Coqui-AI TTS [2] and
> Microsoft SpeechT5 [3] best.  Any suggestions for free and open TTS
> implementations that produce even better results?  Other models of
> Coqui-AI?  The solution should work without GPU support, which seems
> to rule out Suno Bark [4].
>
> The above models do not pronounce numbers/digits, and they fail to
> pronounce most acronyms.  In a preprocessing step I could replace
> those.  I use preprocessing anyways to get rid of Org markup that
> might confuse the language models.  Anyone here who did that
> already?  Maybe gruut [5] in conjunction with SSML [6] handling?
>
> Any other suggestions?
>
> Best wishes
> Jens
>
> [1] https://gitlab.com/oer/emacs-reveal/-/issues/20
> [2] https://github.com/coqui-ai/TTS/
> [3] https://huggingface.co/microsoft/speecht5_tts
> [4] https://github.com/suno-ai/bark
> [5] https://github.com/rhasspy/gruut
> [6] https://www.w3.org/TR/speech-synthesis11/
>
>

Org mode version 9.7-pre (9.7-pre-n/a-g2030c1 @ /home/n/.emacs.d/elpaca/builds/org/); org--get-expected-indentation: useless cond clause

[No Wayman]

When compiling Org, I get the following warning:

In org--get-expected-indentation:
org.el:19192:8: Warning: Useless clause following default ‘cond’ 
clause


I looked at the source and confirmed it is not a false positive.
The following code is unreachable due to the (t ...) cond clause 
before it:


 ;; Finally, no indentation is needed, fall back to 0.
 (t (current-indentation))

Package: Org mode version 9.7-pre (9.7-pre-n/a-g2030c1 @ 
/home/n/.emacs.d/elpaca/builds/org/)

Suggestions for Text-To-Speech (TTS) from Org sources?

[Jens Lechtenboerger]

Dear all,

does someone here produce audio via Text-To-Speech (TTS) from Org
sources?  I plan to do that in the context of emacs-reveal to
generate voice-over for reveal.js presentations, with open questions
[1] concerning my initial, experimental approach.

Currently, I like the default model of Coqui-AI TTS [2] and
Microsoft SpeechT5 [3] best.  Any suggestions for free and open TTS
implementations that produce even better results?  Other models of
Coqui-AI?  The solution should work without GPU support, which seems
to rule out Suno Bark [4].

The above models do not pronounce numbers/digits, and they fail to
pronounce most acronyms.  In a preprocessing step I could replace
those.  I use preprocessing anyways to get rid of Org markup that
might confuse the language models.  Anyone here who did that
already?  Maybe gruut [5] in conjunction with SSML [6] handling?

Any other suggestions?

Best wishes
Jens

[1] https://gitlab.com/oer/emacs-reveal/-/issues/20
[2] https://github.com/coqui-ai/TTS/
[3] https://huggingface.co/microsoft/speecht5_tts
[4] https://github.com/suno-ai/bark
[5] https://github.com/rhasspy/gruut
[6] https://www.w3.org/TR/speech-synthesis11/

Re: Feature request: kill-buffer for org-capture-finalize

[Eduardo Suarez]

On Sat, Sep 09, 2023 at 09:18:27AM +, Ihor Radchenko wrote:
> For personal use-case, you can utilize
> `org-capture-after-finalize-hook', checking `current-prefix-arg' and
> killing the target org buffer according to the prefix argument passed.
> Then, for example, you can make C-u C-u C-c C-c unconditionally kill the
> target org buffer.

I have tried something simple like

 (defun my-org-capture-kill-buffer ()
   (when (equal current-prefix-arg '(16))
 (kill-buffer)))

as an after-finalize hook. It seems to recognize the 'current-prefix-arg'
variable.

However,

1. it looks to me that org-capture-finalize jumps to the captured item if there
are any number greater than zero of preffix arguments,

2. the code above tries to kill the buffer I was working before invoking the
capture process.

Any hint?

Re: Help me contribute to org

[emacs]

Hello everyone and thank you yantar for the response,

I did just that:
I have added a Polish translation for everything that I could find and 
corrected one existing one.

I have also attached the diff file to this message.

Is that alright?

--- Original Message ---
On Friday, September 8th, 2023 at 07:53, Ihor Radchenko 'yantar92 at 
posteo.net'  wrote:
> em...@supporter.mailer.me writes:
> 

> > I would like to contribute to org-mode but I have no experience with git. I 
> > would like to start with something small - adding translations for my 
> > language.
> > 

> > Could somebody please guide?
> 

> 

> The easiest way would be:
> 

> 1. Download Org mode source code from command line:
> 

> git clone https://git.savannah.gnu.org/cgit/emacs/org-mode.git
> 

> This will create "org-mode" folder in the place you run the above
> command.
> 

> 2. Open one of the Org files in the downloaded folder.
> For example org-mode/lisp/ox.el has `org-export-dictionary' variable
> - you can search for the variable in the file simply using isearch:
> C-s org-export-dictionary
> 

> 3. Edit the file as needed, adding translations. You simply can follow
> by example when adding new translations.
> 

> 4. M-x vc-diff 
> 

> This will open a buffer with you edits converted into "diff".
> 

> 5. C-x C-w in the diff buffer and save it to a file like
> "my-edits.diff".
> 

> 6. Drop an email to this mailing list, explaining what you did and
> attaching the "diff" file.
> 

> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at https://orgmode.org/.
> 

> Support Org development at https://liberapay.com/org-mode,
> 

> or support my work at https://liberapay.com/yantar92diff --git a/lisp/ox.el b/lisp/ox.el
index f8ccd2a9f..38643c077 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -6215,7 +6215,7 @@ them."
  ("ja" :default "次ページに続く")
  ("nl" :default "Vervolg op volgende pagina")
  ("nn" :default "Held fram på neste side")
- ("pl" :default "Kontynuacja na następnej stronie")
+ ("pl" :default "Ciąg dalszy na następnej stronie")
  ("pt" :default "Continua na página seguinte")
  ("pt_BR" :html "Continua na prxima pgina" :ascii "Continua na proxima pagina" :default "Continua na próxima página")
  ("ro" :default "Continuare pe pagina următoare")
@@ -6229,6 +6229,7 @@ them."
  ("fa" :default "ساخته شده")
  ("nl" :default "Gemaakt op")  ;; must be followed by a date or date+time
  ("nn" :default "Oppretta")
+ ("pl" :default "Wygenerowano o") ; must be followed by a date or date+time
  ("pt_BR" :default "Criado em")
  ("ro" :default "Creat")
  ("sl" :default "Ustvarjeno")
@@ -6278,6 +6279,7 @@ them."
  ("no" :default "Ligning")
  ("nb" :default "Ligning")
  ("nn" :default "Likning")
+ ("pl" :default "Równanie" :ascii "Rownanie")
  ("pt_BR" :html "Equao" :default "Equação" :ascii "Equacao")
  ("ro" :default "Ecuația")
  ("ru" :html ""
@@ -6301,6 +6303,7 @@ them."
  ("no" :default "Illustrasjon")
  ("nb" :default "Illustrasjon")
  ("nn" :default "Illustrasjon")
+ ("pl" :default "Obrazek") ; alternativly "Rysunek"
  ("pt_BR" :default "Figura")
  ("ro" :default "Imaginea")
  ("ru" :html "" :utf-8 "Рисунок")
@@ -6323,6 +6326,7 @@ them."
  ("no" :default "Illustrasjon %d")
  ("nb" :default "Illustrasjon %d")
  ("nn" :default "Illustrasjon %d")
+ ("pl" :default "Obrazek %d") ; alternativly "Rysunek %d"
  ("pt_BR" :default "Figura %d:")
  ("ro" :default "Imaginea %d:")
  ("ru" :html ". %d.:" :utf-8 "Рис. %d.:")
@@ -6375,6 +6379,7 @@ them."
  ("nn" :default "Programliste")
  ("no" :default "Dataprogrammer")
  ("nb" :default "Dataprogrammer")
+ ("pl" :default "Indeks") ; probably too vague but better than nothing
  ("pt_BR" :html "ndice de Listagens" :default "Índice de Listagens" :ascii "Indice de Listagens")
  ("ru" :html " "
   :utf-8 "Список распечаток")
@@ -6398,6 +6403,7 @@ them."
  ("no" :default "Tabeller")
  ("nb" :default "Tabeller")
  ("nn" :default "Tabeller")
+ ("pl" :default "Indeks tabel")
  ("pt_BR" :html "ndice de Tabelas" :default "Índice de Tabelas" :ascii "Indice de Tabelas")
  ("ro" :default "Tabele")
  ("ru" :html " "
@@ -6421,6 +6427,7 @@ them."
  ("nn" :default "Program")
  ("no" :default "Dataprogram")
  ("nb" :default "Dataprogram")
+ ("pl" :default "Indeks")
  ("pt_BR" :default "Listagem")
  ("ro" :default "Lista")
  ("ru" :html ""
@@ -6445,6 +6452,7 @@ them."
  ("no" :default "Dataprogram %d")
  ("nb" :default "Dataprogram %d")
  ("ro" :default "Lista %d")
+ ("pl" :default "Indeks %d:")
  ("pt_BR" :default "Listagem %d:")
  ("ru" :html " %d.:"
   :utf-8 "Распечатка %d.:")
@@ -6462,6 +6470,7 @@ them."
  ("it" :default "Riferimenti")
  ("nl" 

Re: [patch] Fixes and improvements in org-latex-language-alist

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> I am not sure if making a breaking change to public constant is the best
>> approach.
>> What about simply adding an extra entry:
>> ("de" )
>> ("de-de" )
>> ?
>
> At first I had done it with extra entries, but I was wondering if there
> wasn't a more "economical" way... If you don't mind having extra entries
> with identical plists, then I do it that way. After all, there are only
> two cases (Chinese and German).

I am thinking about something like

(let ((de-plist '(...)))
 `(...
   ("de" ,@de-plist)
   ("de-de" ,@de-plist)
   ...))

This is copy-paste-proof and does not require breaking changes in the
value structure.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [patch] Fixes and improvements in org-latex-language-alist

[Juan Manuel Macías]

Ihor Radchenko writes:

>> I don't know if it's a valid path to allow the car of each element to
>> also be a list of languages codes, but I couldn't think of a better
>> solution for the "de"/"de-de" cases. A similar case is in Chinese
>> Simplified (new language added), where the possible language codes are
>> zh and zh-cn, if I'm not wrong.
>
> I am not sure if making a breaking change to public constant is the best
> approach.
> What about simply adding an extra entry:
> ("de" )
> ("de-de" )
> ?

At first I had done it with extra entries, but I was wondering if there
wasn't a more "economical" way... If you don't mind having extra entries
with identical plists, then I do it that way. After all, there are only
two cases (Chinese and German).

-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Re: Feature request: kill-buffer for org-capture-finalize

[Ihor Radchenko]

Eduardo Suarez-Santana  writes:

>> Or do you mean that you sometimes want to kill the target org buffer and
>> sometimes not?
>
> Yes, I mean that I sometimes want to kill the target org buffer and sometimes
> not. I don't want to kill the target buffer as the default behavior of my
> capture template.

I see what you want.
I am not sure if it is something commonly needed.

Unless more people are interested, I do not find this feature as useful
for inclusion to Org mode.

For personal use-case, you can utilize
`org-capture-after-finalize-hook', checking `current-prefix-arg' and
killing the target org buffer according to the prefix argument passed.
Then, for example, you can make C-u C-u C-c C-c unconditionally kill the
target org buffer.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6)

[Ihor Radchenko]

Juan Manuel Macías  writes:

> I think that with this patch the possible regressions are removed. I
> took the opportunity to add some improvements (the :babel-ini-alt,
> :script and :script-tag properties) and correct some errors and typos.
>
> I don't know if it's a valid path to allow the car of each element to
> also be a list of languages codes, but I couldn't think of a better
> solution for the "de"/"de-de" cases. A similar case is in Chinese
> Simplified (new language added), where the possible language codes are
> zh and zh-cn, if I'm not wrong.

I am not sure if making a breaking change to public constant is the best
approach.
What about simply adding an extra entry:
("de" )
("de-de" )
?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Description list with " :: " in the tag.

[Ihor Radchenko]

"Tom Alexander"  writes:

> Emacs version: 29.1
> Org-mode version: 163bafb43dcc2bc94a2c7ccaa77d3d1dd488f1af
>
> Found a conflict between the documentation and the parser behavior. The 
> org-mode documentation[1] for description list items says that TAG '[...] 
> does not contain the substring " :: "'
>
> Using this sample document, I have created a plain list item with a tag that 
> contains that substring by wrapping it in a verbatim block:
> ```
> - =foo :: bar= :: baz
> ```
>(item
> ...
> ((1 0 "- " nil nil "=foo :: bar=" 23))
> ...
> It seems that "TAG-TEXT" is not just text but it can include objects and 
> those objects can include the substring " :: ".

It is simpler.
Everything after the bullet and before the last " :: " is considered as
tag. Everything after the last " :: " is description.
Then, tag and description are parsed, allowing objects inside.

org-syntax document is inaccurate here - it says that the _first_ " :: "
is used as tag:description delimiter, not the _last_.

I do not see any benefit changing the current parser. So, we probably
need to update org-syntax document instead.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Ihor Radchenko]

Guillaume MULLER  writes:

> - Would be great to be able to set this parameter per org buffer/file, e.g. 
> with a #+ (#+OPTIONS?) command. Indeed, using the defaults is OK most of the 
> time for most of the users. I only need this trick when I want to force 
> lstlistings, and I only need to force lstlistings when I want to insert a 
> LaTeX inside a src block (it might be possible with other backends, but I 
> don't know how to do it with the other backends, and I can look for 
> documentations as I don't know which is the default backend)

The default backend is verbatim.
You can already set the backend on per-file basis using file-local
variables or #+BIND keywords.

We might add a dedicated Org keyword like #+LATEX_SRC_BLOCK_BACKEND though.

> - It would be great to add this "trick" (on how to change the backend) in the 
> Docs (e.g. the page I cited in my previous email)

> - In the docs, it would also be great to tell what is the default backend (as 
> I thought it was lstlisting and it is clearly not + the message I cited made 
> me think it has changed recently)

Already done in on the development branch. orgmode.org will update the
manual after the next minor release.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a144b2355

> - Finally, when the error is raised, (Doom)Emacs goes definitively berzerck: 
> every time I try to save the/any buffer with C-x C-s "save-buffer", it asks 
> for the name to save to and for a confirmation for overwriting the selected 
> file when I select the same filename as the one that was initially opened. So 
> there might be something that is not restored correctly after the error is 
> rasied?

What do you mean by error? What you described is a warning, not an
error. And it should have 0 effect except displaying a buffer with that warning.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at