Re: Fallback fonts in LaTeX export for non latin scripts

[Juan Manuel Macías]

Ihor Radchenko writes:

> Juan Manuel Macías  writes:
>
>>> #+language: ancientgreek russian arabic
>>
>> Of course, this syntax would be the most appropriate and consistent
>> within Org. The problem is LaTeX, specifically babel, and that certain
>> inconsistencies would be created with the rest of the backends. At first
>> some pitfalls come to mind:
>>
>> - The keyword #+language accepts for now only language codes (es, en,
>>   el, ar, ru, etc.). Consistency with other backends should
>>   be maintained in this regard: ancientgreek is not a valid language
>>   code, but a name that only babel understands. If we put something
>>   like (a valid language code):
>>
>>   #+language: el-polyton
>>
>>   this could be translated in babel as polutonikogreek (in the classic
>>   syntax, that is, the languages that are loaded in the options of
>>   \usepackage[options]{babel}), or, in the new syntax, ancientgreek and
>>   polytonicgreek, which are actually two different languages: the first
>>   is ancient polytonic Greek and the second modern polytonic Greek. To
>>   add more confusion to the matter, in classical babel syntax
>>   greek.ancient and greek.polytonic are also supported. But neither of
>>   these things can be deduced by simply putting el-polyton, unless
>>   breaking the consistency with the other backends.
>
> I am now working on unifying Org translation system as discussed in
> https://orgmode.org/list/87o7iw8yem@bzg.fr
> As a part of the effort, I plan to introduce a new constant that will
> unify language abbreviations across Org and also associate them with
> more human-readable names.
>
> (defconst org-language-abbrevs
>   '(("am".  "Amharic")
> ("ar" . "Arabic")
> ("ast" . "Asturian")
> ("bg" . "Bulgarian")
> ("bn" . "Bengali")
> ...))
>
> The idea is to allow
>
> #+language: Austrian German, Greek
> as a valid specifier, in addition to
>
> #+language: de-at, el
>
> Then, across Org, we will make use of the standardized language
> abbreviations.

Great! I think it's great news. Yes, I agree with what you say below. I
think Org should move towards a multilingual support that is 100% native
to Org. That is, Org had its own "selectlanguage" mechanism, to be able
to delimit text segments in other languages and have control over them,
both within Org and when exporting to the different backends. That
scenario seems very desirable to me, and I would like to contribute my
help to the best of my ability (and time).

In LaTeX, as I mentioned, things are complicated. There is Babel and
Polyglossia, and there is LuaTeX and XeTeX. In addition, there is also
pdfTeX, which is still the default engine and (to be honest) is the
engine used by a high percentage of LaTeX users. Although perhaps things
will change soon to the detriment of LuaTeX. Both babel and polyglossia
could be supported, but that means more work, more code, and more
complications. And we are not sure that polyglossia is no longer
maintained. After all, babel is the official LaTeX package for language
support, and polyglossia appeared at a time when babel had no support
for the new unicode engines. Now Babel supports all of that and is much
more powerful, but its interface has also grown in complexity. There is
the problem of the double syntax for loading languages: the old one,
which loads traditional ldf files, and the modern one (\babelprovide),
which loads languages using ini files. It is more powerful, with more
options, but has added more verbosity to babel. I have taken advantage
of \babelprovide, specifically its onchar=id fonts property, to
automatically apply fonts to non-Latin scripts.

>> I like this idea, but with the exception that in the two examples you
>> give the user is declaring two fonts for both languages. In my example
>> there was also Arabic, where the default font for the Arabic script is
>> used.
>
> My idea was that
>
> #+language: ancientgreek russian arabic
>
> implies "use default font for arabic", unless #+latex_font is specified.

This seems the most consistent to me for Org, but, as I mentioned in the
other email, I have some concerns. Currently, what we are talking about
is simply font support for non-Latin languages. If it is allowed, in the
current state of things, that #+language can accept a list of language
names, we can give the user a wrong perception of reality. That is:
multilingual support that does not exist as such. It is more like font
support for non-Latin languages. And only in LaTeX, and specifically in
LuaLaTeX. Furthermore, the user could mix languages that in Babel are
loaded through ldf and others through ini files. For example, something
like this:

#+language: spanish, english, french, russian

in Babel it would be:

\usepackage[english,french,spanish]{babel}

and here we need babelprovide for the font (and load Russian via ini
file):

\babelprovide[onchar=id fonts, import]{russian}
\babelfont[russian]{rm}[options]{somefont}

Org would have to discern which 

[BUG] kill-whole-line on folded subtrees [9.6.8 (release_9.6.8-3-g21171d @ /home/w/usr/emacs/0/29/0/lisp/org/)]

[Sebastian Miele]

In an emacs -Q, create an Org buffer with the following contents:

--8<---cut here---start->8---
* AB
** C
--8<---cut here---end--->8---

Fold the subtree under the heading AB, so that only a single line is
displayed (ending in "...").  With point between A and B, hit
C-S- (kill-whole-line).

Expected: The whole _visible_ line, i.e., the entire contents of the
buffer is erased.  Actual behavior: The line with heading C remains.

Contrast this with the same experiment, except that the point is at the
beginning of the line containing AB when hitting C-S-.  Then
the expected behavior happens.  According to the source of
kill-whole-line, the intended effect indeed is to kill a whole _visible_
line.

The following patch to the Emacs sources fixes the issue:

diff --git a/lisp/simple.el b/lisp/simple.el
index abd587245fe..44221f3fc24 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -6649,9 +6649,7 @@ kill-whole-line
 (unless (bobp) (backward-char))
 (point
(t
-(save-excursion
-  (kill-region (point) (progn (forward-visible-line 0) (point
-(kill-region (point)
+ (kill-region (save-excursion (forward-visible-line 0) (point))
  (progn (forward-visible-line arg) (point))
 
 (defun forward-visible-line (arg)

The reason for the issue probably is: Without the patch, the killing
happens in two stages.  The first kill-region kills from the beginning
of the line until after the A.  That kills the leading *.  That probably
somehow triggers Org visibility changes.  With the patch applied the
whole killing happens in one stage, probably without causing an
intermediate change of visibility.

I first reported this to bug-gnu-em...@gnu.org (see
https://debbugs.gnu.org/65734).  However, Eli asks:

> I'm not sure I understand why this is deemed a problem in Emacs.
> Shouldn't Org redefine C-S- if the default binding doesn't
> suit what happens in Org buffers?  Did you discuss this with Org
> developers?

Emacs  : GNU Emacs 29.1.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, 
cairo version 1.17.8)
 of 2023-09-04
Package: Org mode version 9.6.8 (release_9.6.8-3-g21171d @ 
/home/w/usr/emacs/0/29/0/lisp/org/)

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3

[Max Nikulin]

On 01/09/2023 16:04, Ihor Radchenko wrote:

And introduce [[::fig:something]] to allow explicit internal links.


I would consider an explicit link type for internal links, e.g. org: or 
o: to allow search links in angle brackets  or 
.

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3

[Max Nikulin]

On 02/09/2023 14:26, Ihor Radchenko wrote:

With my proposal, it would become

(link :type "sec" :path "spielbeispiel" ...)

However, "sec" link type will still not be listed in the output
`org-link-types' (not registered).

Then, ox.el and other link processing code, when encountering a link
type that is not registered, will fall back to searching "fuzzy" link.

So, export, and following the link should not be affected.


I do not see which way it may help in the reported case of complications 
with URI schemes not enabled by default. What is the purpose of parser 
changes if links can not be exported or opened?


I am unsure if any "PREFIX:" should be recognized as a link type, but 
there is another possibility on this way: allow users to mark some 
prefixes as search links, not link types.


Taking into account requests to enable more URI schemes by default, 
requiring to explicitly disable some prefixes may be acceptable 
compromise. It may be necessary even if fixed set of link types is 
allowed by default instead of arbitrary prefix.


Changes of behavior disturbs a part of users, but strictly adhering 
backward compatibility means inconvenience for others.

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 03/09/2023 14:53, Ihor Radchenko wrote:

Max Nikulin writes:

I missed this feature, but anyway it does not work as expected.

(org-link-set-parameters "tel")

...

\href{321}{call}

"tel:" is missed.


I have realized that it is possible to take advantage of current behavior:

  (org-link-set-parameters
   "browse"
   :follow
   (lambda (url arg) (browse-url url arg)))

so [[browse:tel:+321][call]] with *any* protocol is properly exported 
and opened. The only inconvenience is that the "browse:" type must be 
added when a link is inserted or stripped down to copy a URL.



(path (org-latex--protect-text
(pcase type
  ((or "http" "https" "ftp" "mailto" "doi")
   (concat type ":" raw-path))
  ("file"
   (org-export-file-uri raw-path))
  (_
   raw-path

is fishy.


I do not like that lists of types in ox backends are not the same as in 
ol.el:


(dolist (scheme '("ftp" "http" "https" "mailto" "news"))
  (org-link-set-parameters scheme


We may simply use (org-element-property :raw-link link) and leave
special handling to "file" links only.

Does it make sense?


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



Actually I had in mind more flexible delegation. :export functions
should be able to alter URI, attributes and to provide description if it
is missed, but did not care if '' or '\href{}{}' should
be used.


I'd call that :filter rather than :export :)


It is an option, the only disadvantage is that `org-link-properties' can 
not set an export filter directly.



Have nothing against it, though it is not 100% relevant to this
particular report.


If there were an `org-link-properties' field to export link as a parsed 
element, not just path and description then it would be easier to define 
backend agnostic export function for a non-standard link type.



Easy way to add protocol/scheme should include :follow with `browse-url'
as well.


Sorry, but I do not understand what you are referring to.
May you elaborate?


My reading of the bug report subject is that it should be easy to define 
a link type for a protocol not supported by Org mode out of the box. 
Minimal features are export and follow using a handler configured 
desktop-wide or Emacs-wide.

Re: [BUG] tangle breaks fortran modules [9.7-pre (release_9.6.7-581-gd38ca5)]

[Paul Stansell]

>
> I opened the latest Org git repo, ran make repro, opened the file,
> clicked on "tangle" link, moved to the linked source code, and executed
> it. It worked.
>
> So, I am unable to reproduce the problem on my system.
>

Hello Ihor,

Thanks for investigating.  Can you please post your tangled file named
circle.f90.

Mine looks like this

program main
MODULE Circle
  implicit None
  public :: area
contains
  function area(r)
  implicit none
  real, intent(in) :: r
  real :: area
  area = 3.14159 * r**2
  return
  end function area
END MODULE Circle
end program main

which is broken because org/babel has added the first and last lines.

Thanks,

Paul

Re: Completion mechanism for headlines when creating a link between 2 Org files?

[Ihor Radchenko]

alain.coch...@unistra.fr writes:

>C-c C-l (org-insert-link)
>
>[...]
>
>Completion support
>
>  Completion with TAB helps you to insert valid link prefixes
>  like ‘http’ or ‘ftp’, including the prefixes defined
>  through link abbreviations (see Link Abbreviations). If you
>  press RET after inserting only the prefix, Org offers
>  specific completion support for some link types.
>
> but, after I complete for a given file, I cannot find a way to further
> complete for a specific (sub)headline.  Is there a way that I missed,
> even after searching the Internet a bit?

You would need to extend the default file: link completion function -
`org-link-complete-file'.

You can override it with any custom function:

(org-link-set-parameters "file" :complete #'your-custom-completion-function)

> If not, I am making it a feature request.  Indeed it would be great,
> especially if one does not really remember where, in a (known) file,
> the headline is, nor --even more importantly-- what its name exactly
> is.
>
> (In my naive view, as the completion mechanism already exists for
> internal files, it should be easy to extend it for external files...)

It is, although even more common request is simply inserting a link to a
heading in _a_ file (not known).

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

>> #+language: ancientgreek russian arabic
>
> Of course, this syntax would be the most appropriate and consistent
> within Org. The problem is LaTeX, specifically babel, and that certain
> inconsistencies would be created with the rest of the backends. At first
> some pitfalls come to mind:
>
> - The keyword #+language accepts for now only language codes (es, en,
>   el, ar, ru, etc.). Consistency with other backends should
>   be maintained in this regard: ancientgreek is not a valid language
>   code, but a name that only babel understands. If we put something
>   like (a valid language code):
>
>   #+language: el-polyton
>
>   this could be translated in babel as polutonikogreek (in the classic
>   syntax, that is, the languages that are loaded in the options of
>   \usepackage[options]{babel}), or, in the new syntax, ancientgreek and
>   polytonicgreek, which are actually two different languages: the first
>   is ancient polytonic Greek and the second modern polytonic Greek. To
>   add more confusion to the matter, in classical babel syntax
>   greek.ancient and greek.polytonic are also supported. But neither of
>   these things can be deduced by simply putting el-polyton, unless
>   breaking the consistency with the other backends.

I am now working on unifying Org translation system as discussed in
https://orgmode.org/list/87o7iw8yem@bzg.fr
As a part of the effort, I plan to introduce a new constant that will
unify language abbreviations across Org and also associate them with
more human-readable names.

(defconst org-language-abbrevs
  '(("am".  "Amharic")
("ar" . "Arabic")
("ast" . "Asturian")
("bg" . "Bulgarian")
("bn" . "Bengali")
...))

The idea is to allow
#+language: Austrian German, Greek
as a valid specifier, in addition to
#+language: de-at, el

Then, across Org, we will make use of the standardized language
abbreviations.

> - Added to this is that Babel has two ways to load languages: the
>   classic syntax and the \babelprovide command, which is the one we are
>   interested in here for languages with non-Latin scripts, because the
>   onchar=ids fonts property must be added here. And what happens if the
>   user has already defined several languages with babel, using the
>   current procedure: \usepackage[french, english, AUTO]{babel}?

For LaTeX specifically, `org-latex-language-alist', will be re-used to
map whatever is allowed in #+language keyword to its name in
babel/polyglossia.

Does it make sense?

> Therefore, the least complicated thing, in my opinion, is to leave the
> syntax of the keyword #+language as it is. It is not necessary for the
> user to explicitly define secondary non-latin languages. The idea is
> that Org is responsible for generating the necessary babel code by
> simply giving a command like enable font for X language. What we are
> talking about here is ensuring readability using a series of fonts that
> LaTeX does not load by default, not even LuaLaTeX. And, after all, Org
> is monolingual: it does not have multilingual support at the moment;
> that is, there is nothing in Org to switch languages in the middle of
> the document. What happens is that here we take advantage of the
> functionality that Babel has to automatically apply a font for a
> non-Latin language/script, also loading its properties (hyphen rules,
> captions, etc.).
>
> A new keyword #+latex_language could be created, which would understand
> the babel names, but I think it is unnecessary and would add more
> complexity. As I said before, defining the necessary fonts would be
> enough, since my idea in this is a basic practicality to ensure the
> readability of the documents. And anyone looking for more advanced
> functions would have to enter LaTeX code explicitly.

I think that we should move towards multi-language support.
Such support would practically simplify WORG and orgmode.org translation
process, and may also be used as a basis to allow translating the
Org manual.

My rough idea is to allow specifying language as affiliated
keyword and, in future, allow selective export to certain target
language.

Multi-language documents are another potential target to support.

>> #+latex_font[ancientgreek]: "Linux Libertine O" Scale=MatchLowercase
>>
>> #+latex_font[russian]: "FreeSerif" Numbers=Lowercase,Color=blue
>
> I like this idea, but with the exception that in the two examples you
> give the user is declaring two fonts for both languages. In my example
> there was also Arabic, where the default font for the Arabic script is
> used.

My idea was that

#+language: ancientgreek russian arabic

implies "use default font for arabic", unless #+latex_font is specified.

> #+latex_font[arabic]: "FreeSerif" Numbers=Lowercase,Color=blue
>
> This last syntax would also be valid to modify the main default fonts:
>
> #+latex_font[main]: "FreeSerif" Numbers=Lowercase
> #+latex_font[sans]: "some font"
> #+latex_font[mono]: "some font"
> 

Re: [BUG] tangle breaks fortran modules [9.7-pre (release_9.6.7-581-gd38ca5)]

[Ihor Radchenko]

Paul Stansell  writes:

> The attached file is an example of how tangle wraps the Fortran module in
>
>   program main
>   end program main
>
> which prevents the code from compiling.
>
> There are more instructions on how to reproduce the bug in the attached
> bug.org file.

I opened the latest Org git repo, ran make repro, opened the file,
clicked on "tangle" link, moved to the linked source code, and executed
it. It worked.

So, I am unable to reproduce the problem on my system.

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

Re: Org mode version 9.7-pre (9.7-pre-n/a-g63e8ca @ /home/n/.emacs.d/elpaca/builds/org/); [PATCH] ob-lilypond.el: fix docstring typos

[Ihor Radchenko]

No Wayman  writes:

> See attached.
>
> From 9b21849b9b7d9f36f57241e80d005535f07b788c Mon Sep 17 00:00:00 2001
> From: Nicholas Vollmer 
> Date: Sun, 3 Sep 2023 15:41:51 -0400
> Subject: [PATCH] ob-lilypond.el: Fix docstring typos

Thanks!
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f6fc385ed

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

Re: Org mode version 9.7-pre (9.7-pre-n/a-g63e8ca @ /home/n/.emacs.d/elpaca/builds/org/); [PATCH] refactor org-babel-lilypond-compile-lilyfile

[Ihor Radchenko]

No Wayman  writes:

> Ihor Radchenko  writes:
>
>>> - Removes the optional TEST parameter, which is unused and 
>>> better 
>>>   served through debugging tools.  
>>
>> This is technically a breaking change. So, we (1) need to 
>> mention it in
>> ORG-NEWS; (2) may consider (file-name  _) function 
>> definition
>> to be 100% sure that no existing code will be broken.
>
> I've added the NEWS entry and updated the signature to ignore the 
> second, optional parameter.
> See attached.

Thanks!

> +*** ~org-babel-lilypond-compile-lilyfile~ ignores optional second argument
> +
> +The =TEST= parameter is better served by Emacs debugging tools.

It looks like ob-lilypond/ly-compile-lilyfile test is relying on this
optional second argument. So, after applying your patch, make test is
failing.

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

Completion mechanism for headlines when creating a link between 2 Org files?

[Alain . Cochard]

Hello.  For internal links, the manual states that

   To insert a link targeting a headline, in-buffer completion can be
   used.  Just type a star followed by a few optional letters into the
   buffer and press ‘M-’.  All headlines in the current buffer
   are offered as completions."

Is there a similar mechanism for links from one Org file to a headline
of another Org file?  In the 'Handling Links' section of the manual:

   C-c C-l (org-insert-link)

   [...]

   Completion support

   Completion with TAB helps you to insert valid link prefixes
   like ‘http’ or ‘ftp’, including the prefixes defined
   through link abbreviations (see Link Abbreviations). If you
   press RET after inserting only the prefix, Org offers
   specific completion support for some link types.

but, after I complete for a given file, I cannot find a way to further
complete for a specific (sub)headline.  Is there a way that I missed,
even after searching the Internet a bit?

If not, I am making it a feature request.  Indeed it would be great,
especially if one does not really remember where, in a (known) file,
the headline is, nor --even more importantly-- what its name exactly
is.

(In my naive view, as the completion mechanism already exists for
internal files, it should be easy to extend it for external files...)

Regards