Re: Is there a size limit to org files?

[Max Nikulin]

On 08/09/2023 23:52, Ihor Radchenko wrote:

Carlo Tambuatco writes:


I noticed that an org file I was using for my capture templates was getting
quite large
and that my capture templates that were pasting TODO entries in that file
were starting to exhibit
strange behavior. Mostly just getting stuck at a mysterious "clipboard
pasted to level 2 subtree"
message, then it would just hang there until I hit ctrl g.


That could be a bug, but it is impossible to fix it without knowing more
details.


Looks like a follow-up of
https://list.orgmode.org/CAJb92ExdvB7FMkSnmZAFTs4AuSZHBp5Rj4bK-4EWAGAbAGgC=g...@mail.gmail.com/
Carlo Tambuatco. [BUG] Org-9.6.x org templates hang on 'clipboard pasted 
as level 2 subtree'... Mon, 3 Apr 2023 15:53:22 -0400


Certainly a way to reproduce the issue or detailed enough stack traces 
are required.


Have you tried to run `org-lint'?

I have seen a couple of times emacs consuming 100% CPU and not reacting 
to C-g, but in that cases I was not ready to debug these issues. Almost 
certainly it was unrelated to capture a clipboard, more likely 
incremental search or a wrong key while calling it.

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

[Max Nikulin]

On 09/09/2023 00:25, Tom Alexander wrote:

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
```


The following does not address your particular question, it is just a 
warning. Be careful with "::" since the following is recognized as a 
description list item.


- =foo :: bar=

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

[Juan Manuel Macías]

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.

--
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

>From 52f17bc841241562a52e91159cb1531dbe5684e1 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Fri, 8 Sep 2023 19:33:25 +0200
Subject: [PATCH] ox-latex.el: Fixes and improvements in
 `org-latex-language-alist'.

* (org-latex-language-alist): Fix a language code (`de-de') removed
when `org-latex-babel-language-alist' and
`org-latex-polyglossia-language-alist' were merged.  To allow language
codes that can have a similar translation in `babel' or `polyglossia'
now in each element of `org-latex-language-alist' car can also be a
list of language codes.  New admitted properties: `:babel-ini-alt',
`:script' and `:script-tag'.  Add language code for ancient Greek.
Fix Afrikaans (was previously removed).  New languages: Chinese
Simplified and Traditional.  Correction of some typos, errors and
inaccuracies.

* (org-latex-guess-babel-language): Some necessary modifications.

* (org-latex-guess-polyglossia-language): Some necessary modifications.
---
 lisp/ox-latex.el | 208 +++
 1 file changed, 118 insertions(+), 90 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 241ef603a..d6790ea27 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -177,94 +177,102 @@
 ;;; Internal Variables
 
 (defconst org-latex-language-alist
-  '(("am" :babel-ini-only "amharic" :polyglossia "amharic" :lang-name "Amharic")
-("ar" :babel "arabic" :polyglossia "arabic" :lang-name "Arabic")
-("ast" :babel-ini-only "asturian" :polyglossia "asturian" :lang-name "Asturian")
-("bg"  :babel "bulgarian" :polyglossia "bulgarian" :lang-name "Bulgarian")
-("bn"  :babel-ini-only "bengali" :polyglossia "bengali" :lang-name "Bengali")
-("bo"  :babel-ini-only "tibetan" :polyglossia "tibetan" :lang-name "Tibetan")
-("br"  :babel "breton" :polyglossia "breton" :lang-name "Breton")
-("ca"  :babel "catalan" :polyglossia "catalan" :lang-name "Catalan")
-("cop"  :babel-ini-only "coptic" :polyglossia "coptic" :lang-name "Coptic")
-("cs"  :babel "czech" :polyglossia "czech" :lang-name "Czech")
-("cy"  :babel "welsh" :polyglossia "welsh" :lang-name "Welsh")
-("da"  :babel "danish" :polyglossia "danish" :lang-name "Danish")
-("de"  :babel "ngerman" :polyglossia "german" :polyglossia-variant "german" :lang-name "German")
-("de-at"  :babel "naustrian" :polyglossia "german" :polyglossia-variant "austrian" :lang-name "German")
-("dsb"  :babel "lsorbian" :polyglossia "sorbian" :polyglossia-variant "lower" :lang-name "Lower Sorbian")
-("dv"  :babel-ini-only "divehi" :polyglossia "divehi" :lang-name "Divehi")
-("el"  :babel "greek" :polyglossia "greek" :lang-name "Greek")
-("el-polyton"  :babel "polutonikogreek" :polyglossia "greek" :polyglossia-variant "polytonic" :lang-name "Polytonic Greek")
-("en"  :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
-("en-au"  :babel "australian" :polyglossia "english" :polyglossia-variant "australian" :lang-name "English")
-("en-gb"  :babel "british" :polyglossia "english" :polyglossia-variant "uk" :lang-name "English")
-("en-nz"  :babel "newzealand" :polyglossia "english" :polyglossia-variant "newzealand" :lang-name "English")
-("en-us"  :babel "american" :polyglossia "english" :polyglossia-variant "usmax" :lang-name "English")
-("eo"  :babel "esperanto" :polyglossia "esperanto" :lang-name "Esperanto")
-("es"  :babel "spanish" :polyglossia "spanish" :lang-name "Spanish")
-("es-mx"  :babel "spanishmx" :polyglossia "spanish" :polyglossia-variant "mexican" :lang-name "Spanish")
-("et"  :babel "estonian" :polyglossia "estonian" :lang-name "Estonian")
-("eu"  :babel "basque" :polyglossia "basque" :lang-name "Basque")
-("fa"  :babel "farsi" :polyglossia "farsi" :lang-name "Farsi")
-("fi"  :babel "finnish" :polyglossia "finnish" :lang-name "Finnish")
-("fr"  :babel "french" :polyglossia "french" :lang-name "French")
-("fr-ca"  :babel "canadien" :polyglossia "french" :polyglossia-variant "canadian" :lang-name "French")
-("fur"  :babel "friulan" :polyglossia "friulan" :lang-name "Friulian")
-("ga"  :babel "irish" :polyglossia "irish" :lang-name "Irish")
-("gd"  :babel "scottish" :polyglossia "scottish" :lang-name "Scottish Gaelic")
-("gl"  :babel "galician" 

Re: Is there a size limit to org files?

[Ihor Radchenko]

Marcin Borkowski  writes:

> Another one, it seems, is clocking in when the entry already has a lot
> of clock entries.  I have a headline with 8000+ clock entries and
> starting another one takes about half a second.

Yup. The list parser is not incremental (for historic reasons), so every
time you change a list, it is re-parsed from scratch.

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

Re: Is there a size limit to org files?

[Marcin Borkowski]

On 2023-09-08, at 19:37, Ihor Radchenko  wrote:

> Marcin Borkowski  writes:
>
>> It's a /very/ long shot, but I noticed that editing large tables (1000+
>> lines) can become pretty slow.  Apart from that, I have Org files with
>> tens of thousands lines and they work pretty well.
>
> Expected. The current code re-inserts the whole table every time you
> need to re-align it. You can guess how such approach scales.

Agreed, just wanted to point out one possible reason for slowness.

Another one, it seems, is clocking in when the entry already has a lot
of clock entries.  I have a headline with 8000+ clock entries and
starting another one takes about half a second.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: Is there a size limit to org files?

[Ihor Radchenko]

Marcin Borkowski  writes:

> It's a /very/ long shot, but I noticed that editing large tables (1000+
> lines) can become pretty slow.  Apart from that, I have Org files with
> tens of thousands lines and they work pretty well.

Expected. The current code re-inserts the whole table every time you
need to re-align it. You can guess how such approach scales.

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

Re: Is there a size limit to org files?

[Marcin Borkowski]

On 2023-09-08, at 18:26, Carlo Tambuatco  wrote:

> I noticed that an org file I was using for my capture templates was getting
> quite large
> and that my capture templates that were pasting TODO entries in that file
> were starting to exhibit
> strange behavior. Mostly just getting stuck at a mysterious "clipboard
> pasted to level 2 subtree"
> message, then it would just hang there until I hit ctrl g.
>
> Since this file was getting quite big and unwieldy, > 5000 lines, I decided
> to split it up, so that
> the various entries under their headers would be split up into different
> files. I basically just
> put each header into its own separate file, and updated my
> org-capture-templates accordingly.
>
> Since then, no strange behavior, no stalling and hanging for no apparent
> reason.
>
> So, I was wondering if there is hardcoded somewhere in org some kind of
> size limit to the
> files it has to deal with, or is this some limitation arising naturally
> from the size of
> the clipboard? I'm not sure how org handles large files when considering
> how to paste
> entries from capture templates.

It's a /very/ long shot, but I noticed that editing large tables (1000+
lines) can become pretty slow.  Apart from that, I have Org files with
tens of thousands lines and they work pretty well.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Description list with " :: " in the tag.

[Tom Alexander]

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
```

Which parses to:
```
(org-data
 (:standard-properties
  [1 1 1 23 23 0 nil org-data nil nil nil 3 23 nil # nil nil 
nil]
  :path nil :CATEGORY nil)
 (section
  (:standard-properties
   [1 1 1 23 23 0 nil first-section nil nil nil 1 23 nil # 
nil nil #0])
  (plain-list
   (:standard-properties
[1 1 1 23 23 0 nil top-comment nil nil nil nil nil nil # 
nil
   ((1 0 "- " nil nil "=foo :: bar=" 23))
   #1]
:type descriptive)
   (item
(:standard-properties
 [1 1 19 23 23 0
(:tag)
item nil nil nil nil nil nil # nil
((1 0 "- " nil nil "=foo :: bar=" 23))
#2]
 :bullet "- " :checkbox nil :counter nil :pre-blank 0 :tag
 ((verbatim
   (:standard-properties
[3 nil nil nil 15 0 nil nil nil nil nil nil nil nil # 
nil nil #3]
:value "foo :: bar"
(paragraph
 (:standard-properties
  [19 19 19 23 23 0 nil nil nil nil nil nil nil nil # nil 
nil #3])
 #("baz\n" 0 4
   (:parent #4)))
```

It seems that "TAG-TEXT" is not just text but it can include objects and those 
objects can include the substring " :: ".

[1] https://orgmode.org/worg/org-syntax.html#Items

--
Tom Alexander

Re: Is there a size limit to org files?

[Ihor Radchenko]

Carlo Tambuatco  writes:

> You might want to look into what changed between org 9.5.5 and 9.6, because
> that is when this strange behavior started (for me anyway)...

Unfortunately, such information is not helpful. A lot have changed.

If you observe the problem in future, I encourage you to follow the
steps described in https://orgmode.org/manual/Feedback.html#Feedback, so
that we can identify and fix the bug.

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

Re: Is there a size limit to org files?

[Carlo Tambuatco]

You might want to look into what changed between org 9.5.5 and 9.6, because
that is when this strange behavior started (for me anyway). I've been
hanging onto
9.5.5 for as long as I could until I upgraded to emacs 29. Then the above
mentioned
strange behavior resumed. My fix for it was to split up my large org files
into
smaller files, and so far no strange behavior.



On Fri, Sep 8, 2023 at 12:51 PM Ihor Radchenko  wrote:

> Carlo Tambuatco  writes:
>
> > I noticed that an org file I was using for my capture templates was
> getting
> > quite large
> > and that my capture templates that were pasting TODO entries in that file
> > were starting to exhibit
> > strange behavior. Mostly just getting stuck at a mysterious "clipboard
> > pasted to level 2 subtree"
> > message, then it would just hang there until I hit ctrl g.
>
> That could be a bug, but it is impossible to fix it without knowing more
> details.
>
> > Since this file was getting quite big and unwieldy, > 5000 lines, I
> > decided ...
>
> I am using 100x (yes, 100 times) larger org file right now. With 500k
> lines.
>
>
> > So, I was wondering if there is hardcoded somewhere in org some kind of
> > size limit to the
> > files it has to deal with, or is this some limitation arising naturally
> > from the size of
> > the clipboard? I'm not sure how org handles large files when considering
> > how to paste
> > entries from capture templates.
>
> There is no size limit on Org files. Although certain operations may
> become slower when the file size reaches tens of megabytes.
>
> Clipboard should normally not be a problem either.
>
> If you can interrupt with C-g, there might be some infinite loop
> somewhere in the code.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Is there a size limit to org files?

[Ihor Radchenko]

Carlo Tambuatco  writes:

> I noticed that an org file I was using for my capture templates was getting
> quite large
> and that my capture templates that were pasting TODO entries in that file
> were starting to exhibit
> strange behavior. Mostly just getting stuck at a mysterious "clipboard
> pasted to level 2 subtree"
> message, then it would just hang there until I hit ctrl g.

That could be a bug, but it is impossible to fix it without knowing more
details.

> Since this file was getting quite big and unwieldy, > 5000 lines, I
> decided ...

I am using 100x (yes, 100 times) larger org file right now. With 500k lines.


> So, I was wondering if there is hardcoded somewhere in org some kind of
> size limit to the
> files it has to deal with, or is this some limitation arising naturally
> from the size of
> the clipboard? I'm not sure how org handles large files when considering
> how to paste
> entries from capture templates.

There is no size limit on Org files. Although certain operations may
become slower when the file size reaches tens of megabytes.

Clipboard should normally not be a problem either.

If you can interrupt with C-g, there might be some infinite loop
somewhere in the code.

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

Is there a size limit to org files?

[Carlo Tambuatco]

I noticed that an org file I was using for my capture templates was getting
quite large
and that my capture templates that were pasting TODO entries in that file
were starting to exhibit
strange behavior. Mostly just getting stuck at a mysterious "clipboard
pasted to level 2 subtree"
message, then it would just hang there until I hit ctrl g.

Since this file was getting quite big and unwieldy, > 5000 lines, I decided
to split it up, so that
the various entries under their headers would be split up into different
files. I basically just
put each header into its own separate file, and updated my
org-capture-templates accordingly.

Since then, no strange behavior, no stalling and hanging for no apparent
reason.

So, I was wondering if there is hardcoded somewhere in org some kind of
size limit to the
files it has to deal with, or is this some limitation arising naturally
from the size of
the clipboard? I'm not sure how org handles large files when considering
how to paste
entries from capture templates.

Re: ox-latex language handling in Org-9.5 vs 9.6

[Juan Manuel Macías]

Max Nikulin writes:

> I am still unsure that de and de-de should be mapped to different
> babel language configurations.

I think that for practical purposes de and de-de should be treated the
same in both babel and polyglossia. In the new fixed version of
org-babel-language-alist I thought it would be useful to support a list
of languages codes as car for each element, in addition to a simple
string. In such a way:

(("de" "de-de") :babel "ngerman" :babel-ini-alt "german" :polyglossia "german" 
:polyglossia-variant "german" :lang-name "German" :script "latin" :script-tag 
"latn")

I've had to make some small modifications to
org-latex-guess-babel/polyglossia-language, to get that to work.

:babel-ini-alt refers to an alternative name that is used only if
\babelprovide is present. I'm also adding the :script and :script-tag
properties for each language.

I have done something similar with the case of Chinese Simplified (a new
language that I have added):

(("zh" "zh-cn")  :babel-ini-only "chinese" :polyglossia "chinese" :lang-name 
"Chinese Simplified" :script "hans" :script-tag "hans")

Between today and tomorrow I will try to send the patch. I saw that
org-latex-language-alist had a few typos as well, some inherited from
the previous lists that were merged.

-- 
Juan Manuel Macías 

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

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

[Eduardo Suarez-Santana]

On Fri, Sep 08, 2023 at 12:38:07PM +, Ihor Radchenko wrote:
> Did you consider :kill-buffer property in `org-capture-templates'?
> 
>  :kill-bufferIf the target file was not yet visited by a buffer when
>  capture was invoked, kill the buffer again after capture
>  is finalized.
> 
> 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.

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

[Ihor Radchenko]

Eduardo Suarez-Santana  writes:

>> May you explain a bit more about the problem you are trying to solve?
>> Isn't the temporary capture buffer killed after capture already?
>> Or do you refer to the org buffer where the capture is recorded?
>
> Sorry about that. I refer to the org buffer where the capture is recorded. I
> meant:
>
> "This would be useful to avoid having to kill the target buffer manually."
>
> I like to keep the target buffer open after the capture is finalized so I can
> review the changes later, but sometimes I'd rather prefer to kill it because I
> already assume that the changes are correct. This helps to keep the buffer 
> list
> clean.

Did you consider :kill-buffer property in `org-capture-templates'?

 :kill-bufferIf the target file was not yet visited by a buffer when
 capture was invoked, kill the buffer again after capture
 is finalized.

Or do you mean that you sometimes want to kill the target org buffer and
sometimes not?

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

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

[Eduardo Suarez-Santana]

On Fri, Sep 08, 2023 at 12:10:23PM +, Ihor Radchenko wrote:
> Eduardo Suarez  writes:
> 
> > The function org-capture-finalize allows an argument to 'jump-to-capture'. I
> > think it may be a good idea to add a new argument to 'kill-buffer' after the
> > capture is finalized. This would be useful to avoid having to kill the 
> > capture
> > buffer manually. I assume that if ':kill-buffer' is intended as the default
> > behavior, then it would be better to set it in the capture template.
> 
> May you explain a bit more about the problem you are trying to solve?
> Isn't the temporary capture buffer killed after capture already?
> Or do you refer to the org buffer where the capture is recorded?

Sorry about that. I refer to the org buffer where the capture is recorded. I
meant:

"This would be useful to avoid having to kill the target buffer manually."

I like to keep the target buffer open after the capture is finalized so I can
review the changes later, but sometimes I'd rather prefer to kill it because I
already assume that the changes are correct. This helps to keep the buffer list
clean.

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

[Ihor Radchenko]

Eduardo Suarez  writes:

> The function org-capture-finalize allows an argument to 'jump-to-capture'. I
> think it may be a good idea to add a new argument to 'kill-buffer' after the
> capture is finalized. This would be useful to avoid having to kill the capture
> buffer manually. I assume that if ':kill-buffer' is intended as the default
> behavior, then it would be better to set it in the capture template.

May you explain a bit more about the problem you are trying to solve?
Isn't the temporary capture buffer killed after capture already?
Or do you refer to the org buffer where the capture is recorded?

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

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

[Eduardo Suarez]

This is a feature request.

The function org-capture-finalize allows an argument to 'jump-to-capture'. I
think it may be a good idea to add a new argument to 'kill-buffer' after the
capture is finalized. This would be useful to avoid having to kill the capture
buffer manually. I assume that if ':kill-buffer' is intended as the default
behavior, then it would be better to set it in the capture template.

I mean something like 'C-u C-u C-c C-c'.

I can't think now of a better way to do it. Any idea is welcome.

Thanks for your work.

Re: ox-latex language handling in Org-9.5 vs 9.6

[Max Nikulin]

On 07/09/2023 21:49, Max Nikulin wrote:

On 07/09/2023 21:19, Juan Manuel Macías wrote:

I think I can introduce some fixes to org-latex-language-alist to
restore the removed language codes


I have no idea why in

393f2f5ae 2012-06-14 12:57:35 +0200 Nicolas Goaziou: org-e-latex: Set 
Babel language according to LANGUAGE keyword


https://list.orgmode.org/871umay444@med.uni-goettingen.de/
Andreas Leha  Re: new (LaTeX) 
exporter and date formatting. Wed, 23 May 2012 23:33:31 +0200


contains a table that is likely a source for Nicolas' commit:


this list of LaTeX-babel supported languages from
http://www.tug.org/texlive/Contents/live/texmf-dist/doc/generic/babel/babel.pdf:




| LaTeX babel  | lang symbol |
|--+-|



| austrian | de-at   |



| german   | de  |
| germanb  | de  |



| ngerman  | de-de   |


Contemporary babel.pdf contains another table (1.13 ini files)

de-1901German
de-1996German
de-AT-1901 Austrian German
de-AT-1996 Austrian German
de-AT  Austrian German
de-CH-1901 Swiss High German
de-CH-1996 Swiss High German
de-CH  Swiss High German

I am still unsure that de and de-de should be mapped to different babel 
language configurations.

Re: [PATCH] Add tests for ob-haskell (GHCi)

[Bruno Barbier]

Ihor Radchenko  writes:

> Bruno Barbier  writes:
>
>> From 86a5443948fc84a6a412ccf49d0c537608f465a7 Mon Sep 17 00:00:00 2001
>> From: Bruno BARBIER 
>> Date: Fri, 18 Nov 2022 20:14:20 +0100
>> Subject: [PATCH 1/7] ob-haskell: Add tests for GHCi
>> ...
>
> Thanks!
> Applied, onto main.
> I also added a missing defvar declaration for
> `inferior-haskell-root-dir'.

Thanks Ihor!

Re: [PATCH] Add tests for ob-haskell (GHCi)

[Ihor Radchenko]

Bruno Barbier  writes:

> From 86a5443948fc84a6a412ccf49d0c537608f465a7 Mon Sep 17 00:00:00 2001
> From: Bruno BARBIER 
> Date: Fri, 18 Nov 2022 20:14:20 +0100
> Subject: [PATCH 1/7] ob-haskell: Add tests for GHCi
> ...

Thanks!
Applied, onto main.
I also added a missing defvar declaration for
`inferior-haskell-root-dir'.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=91c52e2ab
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5bffb9a1e
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d6dd92d44
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=b85217217
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=924c2dd83
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=36a786f7f
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=3674e4024
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=eed3ac9f7

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

Re: Help me contribute to org

[Ihor Radchenko]

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 .
Support Org development at ,
or support my work at 

Re: [BUG] Consider supporting C-x 4 and C-x 5 and C-x t in org-open-at-point [9.6.6 (release_9.6.6 @ /usr/share/emacs/30.0.50/lisp/org/)]

[Ihor Radchenko]

Max Nikulin  writes:

> On 07/09/2023 17:54, Ihor Radchenko wrote:
>> I think that it will be acceptable to add new bindings like
>> C-x 4 C-c C-o and C-x 5 C-c C-o that will open a link in other window or
>> frame, if possible. Patches welcome!
>
> Is it possible to make such bindings local to Org?

Simply (org-defkey org-mode-map (kbd "C-x 4 C-c C-o") #'org-open-at-point)
will do. Except that we will need to bind a different command there (to
honor the C-x 4 convention).

> C-c C-x b `org-tree-to-indirect-buffer'
>
> is specific to Org. It may still have same options: frame, tab in 
> addition to current "other window" (and *same* window as well).

I have nothing against adding this command variants.

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

Re: Fallback fonts in LaTeX export for non latin scripts

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> I am not sure if I like "russian*" idea. May you explain a bit more
>> about how onchar works? What if language characters are intersecting,
>> and not using exactly the same char sets?
>
> Basically, it's like I said above. According to the Babel Manual:
>
> #+begin_quote
> onchar= ids | fonts | letters
>
> This option is much like an ‘event’ called when a character belonging to
> the script of this locale is found (as its name implies, it acts on
> characters, not on spaces). There are currently two ‘actions’, which can
> be used at the same time (separated by a space): with ids the \language
> and the \localeid are set to the values of this locale; with fonts, the
> fonts are changed to those of this locale (as set with \babelfont).
> Characters can be added or modified with \babelcharproperty.
>
> [...] Option letters restricts the ‘actions’ to letters, in the TEX
> sense (i. e., with catcode 11). Digits and punctuation are then
> considered part of current locale (as set by a selector). This option is
> useful when the main script is non-Latin and there is a secondary one
> whose script is Latin.
> #+end_quote

Thanks for the explanation!
Then, language* it is. I have no better idea.

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