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 31/08/2023 22:25, Csepp wrote:

There seems to be no easy way to tell it
to just treat it the same way it would treat an HTTP link and include it
verbatim.  There does seem to be a way to do some Elisp scripting, but
it's honestly really annoying to do this for every protocol type.

Please, just let users include URLs in their docs.


(info "(org) Adding Hyperlink Types")
https://orgmode.org/manual/Adding-Hyperlink-Types.html

(Side note: I would consider `org-export-derived-backend-p' instead of 
`pcase' with fixed symbols.)


So it is possible to have custom link types.

However I do not mind to have an easy way to delegate URI from :export 
function to the link transcoder of active export backend.


Current behavior with with treating link paths as fuzzy search targets 
is a kind of compromise. It allows internal search links to be shorter. 
One may have e.g. #+name: fig:something code blocks, so not every link 
looking as having some "scheme:" prefix should be treated as an external 
URI. As a result link types must be enabled explicitly.

Re: [PATCH] lisp/org-table.el: Allow named columns on lhs

[Gavin Downard]

Ihor Radchenko  writes:
> It has been over one month since the last message in this thread.
> Gavin, may I know if you are still interested to work on the patch?

Apologies for the lack of communication. I do plan on working on this
patch in the near future.

Re: Unclear where ob-spice.el is being maintained

[Bastien Guerry]

Ihor Radchenko  writes:

> Committed. Note that ob-spice was _not_ listed in the README.
> https://git.sr.ht/~bzg/org-contrib/commit/be51e9833b4f3393f4003c88131ba0a0a172c10d

Indeed!

> We may consider tagging a new release.

Yes, please go ahead as you see fit.

-- 
 Bastien Guerry

[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/)]

[Csepp]

I'm trying to include a tel: link in a curriculum vitae page that I want
to export to HTML.  Org-Mode fails during export because it thinks that
tel:+1234 is an internal link.  There seems to be no easy way to tell it
to just treat it the same way it would treat an HTTP link and include it
verbatim.  There does seem to be a way to do some Elisp scripting, but
it's honestly really annoying to do this for every protocol type.

Please, just let users include URLs in their docs.

Emacs  : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37, 
cairo version 1.16.0)
Package: Org mode version 9.6.7 (N/A @ 
/gnu/store/mg7223g8mw90lccp6mm5g6f3mpjk70si-emacs-org-9.6.7/share/emacs/site-lisp/org-9.6.7/)

Re: [BUG] Clocking with inlinetasks

[Ihor Radchenko]

Ypo  writes:

> When clock-in, if there is an inline task above the point, the clock is 
> set below the END of the inlinetask, instead of in the main headline.

I cannot reproduce on the latest main.

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

Re: [BUG] Clocking with inlinetasks

[Russell Adams]

On Wed, Aug 30, 2023 at 08:41:27PM +0200, Ypo wrote:
> When clock-in, if there is an inline task above the point, the clock is
> set below the END of the inlinetask, instead of in the main headline.

Thanks for the report.

I think currently that's the expected behavior, because the inline
task is considered the current heading.

--
Russell Adamsrlad...@adamsinfoserv.com
https://www.adamsinfoserv.com/

[BUG] Clocking with inlinetasks

[Ypo]

When clock-in, if there is an inline task above the point, the clock is 
set below the END of the inlinetask, instead of in the main headline.



Best regards

Re: [DISCUSSION] Re-design of inlinetasks

[Ypo]

Hi, Adams


In an org block:

- You can't use directly the org-mode keybinding.

- Visually, by default, it is different from the other headlines.

- When exporting, by default, it doesn't seem appropriate for reading.

- When inserting, by default, it is not as easy as inlinetasks are.


I will share a use example I proposed in gptel issues forum.  It seemed 
to me useful for inserting a chatgpt response with Properties, in the 
middle of the text:


https://github.com/karthink/gptel/issues/103#issuecomment-1685196575

*** OpenAI. (2023). /ChatGPT: I apologize for any confusion/ 
(Ago 20 version). In Conquest of Egypt

:PROPERTIES:
:GPTEL_MODEL: gpt-3.5-turbo
:GPTEL_TOPIC: Conquest of Egypt
:GPTEL_SYSTEM: I want you to act as a historian. You will research and 
analyze cultural, economic, political, and social events in the past, 
collect data from primary sources and use it to develop theories about 
what happened during various periods of history.

:END:
I apologize for any confusion, ...
*** END


Best regards

Re: Fallback fonts in LaTeX export for non latin scripts

[Juan Manuel Macías]

Ihor Radchenko writes:

> Juan Manuel Macías  writes:

>> The idea is to start from a defcustom that is an alist where each element
>> has the structure (script font). There would also be a default script +
>> font, for example ("latin" "Linux Libertine"). At the moment it would
>> only work for the default roman font, but it can be extended to default
>> sans serif, mono, etc.
>
> Are the fonts you have in mind shipped with LuaTeX distribution?

Yes, in fact the complete installation of TeX live includes a wide
catalog of free opentype fonts with good coverage for non-Latin scripts.
Added to that, more free (as in freedom) easily accessible fonts can be
recommended. Even many GNU/Linux distros already include them. In any
case, the fonts issue is the most delicate part. What default fonts to
add to the list? Here the user's taste or preferences would influence.
It must also be taken into account that if one has typographical
scruples, not all fonts match each other. For design purposes, I mean.
The Computer Modern, which is a modern style font (similar to the Didot
or Bodoni), does not usually pair well with (for example) a Garamond,
which is in the Renaissance style. That's why I think the best solution
would be to offer a basic defcustom, based on the purely utilitarian,
and let the user modify or extend it according to their taste,
preferences or convenience.

Another thing to keep in mind is the following. Offering basic
readability based on the unicode scripts means that we rely on scripts
and not languages. For example, the Cyrillic script covers several
languages, as you well know: Russian, Bulgarian, etc. The Latin script
is used for languages as diverse as English or Vietnamese. The choice of
font based on the script is a low-level LuaTeX functionality, that is,
it does not add features specific to each language, such as hyphenation
patterns. This means that long texts in (for example) Cyrillic or Greek
are not justified well because LaTeX does not know how hyphenate them:

https://i.imgur.com/PSja3x2.png

However, this may be sufficient for documents containing words or small
texts in non latin scripts, rather than long texts.

There is another possibility that I am working on in parallel: relying
on languages instead of scripts. This would add both readability and
support for each particular language. There could be two options for the
user: a basic one (the low level one, based on scripts: ensures
readability but the document may not look pretty) and an advanced one,
based on language support. Something like this occurred to me:

#+LaTeX_Header: % !enable-fonts-for ancientgreek russian:Old Standard
 arabic

This means: enable default fonts for ancient Greek and Arabic
(associated with Greek and Arabic scripts). For Russian, enable the Old
Standard font (included in TeX live). And in the case of Arabic, enable
'bidi' (bidirectional text). If the user added that line it would be
enough to do the magic. I hope :-)

>> The functionality would not be activated by default. When activated, it
>> also enables LuaTeX as the default LaTeX engine, and on each export a
>> list of non-latin scripts in the buffer is extracted. Perhaps with
>> some code like this, which checks for any non-latin characters:
>>
>> (let ((scripts))
>>   (save-excursion
>> (goto-char (point-min))
>> (while
>> (re-search-forward 
>> "\\([^\u-\u007F\u0080-\u00FF\u0100-\u017F]\\)" nil t)
>>   (let ((script (aref char-script-table
>>   (string-to-char (match-string 1)
>> (add-to-list 'scripts script)
>> (setq script-list scripts
>>   script-list)
>>
>> ?
>>
>> Once the list has been extracted, an ad hoc preamble would be formatted
>> assigning each script the chosen font.
>>
>> WDYT? Do you think this would be a viable path? I think that in a few
>> days I can offer something usable for discussion.
>
> Adding Timothy to CC. His WIP conditional preamble branch looks suitable
> to add the proposed functionality.

Great!

> What will happen if LuaTeX is not installed on the system?

Yes, there should be some kind of warning. Also it's not just LuaTeX,
but certain packages for fonts and multilingual support. The problem is
that the different versions of TeX live cooked in the distros 
usually name these packages differently. This is another added problem...
Arch or Gentoo offer a more vanilla TeX live.

> Also, just to double check, is LuaTeX fully compatible to LaTeX? That
> is, if we have an existing org file using LaTeX-specific commands and
> packages, will it work with LuaTeX?

Yes, it is fully compatible, except that LuaLaTeX does not need to load
the fontenc or inputenc packages. LuaTeX is intended to be the natural
replacement for pdfTeX. The latest edition of The LaTeX Companion is
already very focused on LuaTeX. And 90% of the new LaTeX packages that
are uploaded to CTAN only work in LuaLaTeX. One of the essential
advantages of LuaTeX is that TeX now 

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

[Jens Schmidt]

On 2023-08-31  10:08, Ihor Radchenko wrote:
> Jens Schmidt  writes:
> 
>>> Implemented in the next version of the patch, please check.
>>
>> Gentle ping ...
> 
> I was waiting for your comment on 
> https://list.orgmode.org/orgmode/874jklhqw2.fsf@localhost/

Ah, ok, sorry.  I will give that branch a second thought and comment
soon.

Re: Passing table to Ruby session

[Ihor Radchenko]

Ihor Radchenko  writes:

> On Org side, the best we might do is splitting the long command into
> multiline (if ruby REPL supports line continuation like \
> this or similar). Of course, it will be a workaround.

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=deb5ea0fc

There are still some issues with inf-ruby I cannot understand though.
When I tried to evaluate the src blocks multiple times, inf-ruby (AFAIU)
interprets some of the puts output as input for some reason, which is
bizarre and does not look like Org's fault.

May you please check if you can reproduce the same problem on your side?

Instructions:

1. Download the attached bug.org file
2. Clone the latest Org: git clone 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
3. cd org-mode
4. make repro REPRO_ARGS="-L /path/to/inf-ruby -l ob-ruby /path/to/bug.org"
5. Go to the second code block (the one with :session)
6. Evaluate it several times
7. At some point, you will see either empty result or an error.
   In the *ruby* buffer, you will see
   _org_babel_ruby_prompt (irb):481:in `': undefined method 
`_org_babel_ruby_prompt' for main:Object (NoMethodError)
from /usr/lib64/ruby/gems/3.1.0/gems/irb-1.4.1/exe/irb:11:in `'
from /usr/bin/irb:25:in `load'
from /usr/bin/irb:25:in `'
_org_babel_ruby_prompt



bug.org
Description: Lotus Organizer

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

Re: [DISCUSSION] Re-design of inlinetasks

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> And what about drawers? Don't they fit the idea of "detached" element?
>
> But drawers would not serve as a "detached section"... Although they are
> certainly very versatile. I usually use drawers to export as small
> "containers". And when I don't export them, they are very useful for
> temporarily saving all kinds of "things". In Spanish we have the term
> "cajón de sastre" (lit.: "a tailor drawer") to refer to something where
> you can store everything :-)

I am not sure here. It looks like having a new special block type

#+begin_inlinesection
...
#+end_inlinesection

would be sufficient. Given that we cannot nest inlinesections anyway.

Or special drawer
:inlinesection:
...
:end:

Although, drawers will be less powerful because, unlike special blocks,
you cannot have a different drawer type inside. For special blocks, a
different special block is perfectly fine.

I do not see any clear benefit of having a dedicated, separate markup
for inlinesection, apart from philosophical.

> As for the inlinetask (or whatever they may be called in the future),
> the fact that they are a kind of hybrid between a section (unrelated to
> the level hierarchy) and a drawer seems very interesting to me. Apart
> from the scenario of the anonymous sections that I mentioned before, I
> can think of a few more. For example, something like this:
>
> *** WORKING Complete this :noexport:
>   DEADLINE: <2023-08-27 dom>
> Content 
> *** END
>
> And the combination of org-store-link with org-transclusion can also be
> interesting.
>
> Or, for example this other example, which is not possible now, but with
> some modification in org-mime-org-subtree-htmlize I think it is:
>
> *** TODO Email this 
>   DEADLINE: <2023-08-27 dom>
>   :PROPERTIES:
>   :mail_to:  mail address
>   :mail_subject: mail subject
>   :END:
> Content
> *** END

We can get the same functionality if we allow arbitrary properties and
tags assigned to non-headline elements.

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

Re: Unclear where ob-spice.el is being maintained

[Ihor Radchenko]

Bastien Guerry  writes:

>> Bastien, it looks like we can now remove ob-spice from org-contrib.
>> Please, confirm.
>
> I do, thanks.

Committed. Note that ob-spice was _not_ listed in the README.
https://git.sr.ht/~bzg/org-contrib/commit/be51e9833b4f3393f4003c88131ba0a0a172c10d

We may consider tagging a new release.

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

> These days I'm working on some experimental code to try to provide Org
> with some sort of fallbacks fonts on LaTeX export. The functionality
> would (for now) be linked to LuaTeX + babel package, since XeTeX,
> although it has the ucharclasses package, is more limited.

Thanks! That would be a welcome addition.

> The idea is to start from a defcustom that is an alist where each element
> has the structure (script font). There would also be a default script +
> font, for example ("latin" "Linux Libertine"). At the moment it would
> only work for the default roman font, but it can be extended to default
> sans serif, mono, etc.

Are the fonts you have in mind shipped with LuaTeX distribution?

> The functionality would not be activated by default. When activated, it
> also enables LuaTeX as the default LaTeX engine, and on each export a
> list of non-latin scripts in the buffer is extracted. Perhaps with
> some code like this, which checks for any non-latin characters:
>
> (let ((scripts))
>   (save-excursion
> (goto-char (point-min))
> (while
> (re-search-forward "\\([^\u-\u007F\u0080-\u00FF\u0100-\u017F]\\)" 
> nil t)
>   (let ((script (aref char-script-table
>   (string-to-char (match-string 1)
> (add-to-list 'scripts script)
> (setq script-list scripts
>   script-list)
>
> ?
>
> Once the list has been extracted, an ad hoc preamble would be formatted
> assigning each script the chosen font.
>
> WDYT? Do you think this would be a viable path? I think that in a few
> days I can offer something usable for discussion.

Adding Timothy to CC. His WIP conditional preamble branch looks suitable
to add the proposed functionality.

What will happen if LuaTeX is not installed on the system?

Also, just to double check, is LuaTeX fully compatible to LaTeX? That
is, if we have an existing org file using LaTeX-specific commands and
packages, will it work with LuaTeX?

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

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

[Ihor Radchenko]

Jens Schmidt  writes:

>> Implemented in the next version of the patch, please check.
>
> Gentle ping ...

I was waiting for your comment on 
https://list.orgmode.org/orgmode/874jklhqw2.fsf@localhost/

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

Re: [PATCH] testing: Delete duplicate tests

[Ihor Radchenko]

Ilya Chernyshov  writes:

> Thank you! If a function that checks for duplicate tests is a welcome
> addition to org tests, I'll send is as a patch. What do you think?

It would be great. Thanks in advance!

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

Re: [PATCH] testing: Delete duplicate tests

[Ilya Chernyshov]

Ihor Radchenko  writes:

> I have re-introduced the new tests in place of the removed ones,
> according to my and Max's findings. On top of the patch.
>
> Applied, onto main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=fe85d61a9
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=173b5de0e

Thank you! If a function that checks for duplicate tests is a welcome
addition to org tests, I'll send is as a patch. What do you think?