Re: Missing changes

[Po Lu]

Kyle Meyer  writes:

> Those commits are on Emacs's master branch.  We're up to date with the
> emacs-29 branch, but I've yet to port any of the Emacs's master-specific
> Org changes to Org's main branch.  I started working on it last weekend,
> so it should happen soon-ish.  In any case, all the currently unported
> master-specific changes would of course be ported to Org's main before
> we start syncing that to Emacs's master.
>
> You can find all of these commits listed at
>
>   https://git.kyleam.com/orgmode-backport-notes/tree/orgmode-backports.org
>
> It's not in your list above, but there's also your 9082b4e6ee2 (Make
> binaries distributed with Emacs work on Android, 2023-01-24).  That, by
> the way, will need to be adjusted to stay compatible with previous Emacs
> versions that don't have a ctags-program-name variable defined.

OK, thanks.  As an aside, which versions of Emacs does Org presently
support?

Re: Missing changes

[Kyle Meyer]

Po Lu writes:

> These changes made to lisp/org within the Emacs repository are absent
> from orgmode.git:
>
> * | 73b24a41412..: Po Lu 2023-08-23 Make org-mouse compatible with touch 
> screen event emulation
> * | 4f714dc0813..: Po Lu 2023-08-20 Support desktop notifications on Android
> * | 5856ea5e4e8..: Po Lu 2023-08-17 Introduce support for Desktop 
> Notifications on Haiku
>
> Would anyone care to see to it that they are transferred into the Org
> repository?

Those commits are on Emacs's master branch.  We're up to date with the
emacs-29 branch, but I've yet to port any of the Emacs's master-specific
Org changes to Org's main branch.  I started working on it last weekend,
so it should happen soon-ish.  In any case, all the currently unported
master-specific changes would of course be ported to Org's main before
we start syncing that to Emacs's master.

You can find all of these commits listed at

  https://git.kyleam.com/orgmode-backport-notes/tree/orgmode-backports.org

It's not in your list above, but there's also your 9082b4e6ee2 (Make
binaries distributed with Emacs work on Android, 2023-01-24).  That, by
the way, will need to be adjusted to stay compatible with previous Emacs
versions that don't have a ctags-program-name variable defined.

Missing changes

[Po Lu]

These changes made to lisp/org within the Emacs repository are absent
from orgmode.git:

* | 73b24a41412..: Po Lu 2023-08-23 Make org-mouse compatible with touch screen 
event emulation
* | 4f714dc0813..: Po Lu 2023-08-20 Support desktop notifications on Android
* | 5856ea5e4e8..: Po Lu 2023-08-17 Introduce support for Desktop Notifications 
on Haiku

Would anyone care to see to it that they are transferred into the Org
repository?

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

[Juan Manuel Macías]

Max Nikulin writes:

> I consider the following as an issue rather close to the discussion in 
> the thread
> Juan Manuel Macías. Fallback fonts in LaTeX export for non latin 
> scripts. Wed, 30 Aug 2023 08:25:53 +.
> https://list.orgmode.org/878r9t7x7y@posteo.net
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042450
> elpa-org: #+LANGUAGE: de-de is not working in LaTeX export. Debian Bug 
> report logs
>
> I am unsure if the change was intentional.

I seem to remember that when I made org-latex-language-alist I made some
corrections to a few language codes. I was guided by page 19 of the
Babel manual and by

https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes

In both lists the language code for German is simply "de". Of course,
I'm no expert on the subject, so if I'm wrong in this case, I should
revert the change. I understand that de-de is German of Germany (="de"?); on
org-latex-language-alist exists de-at (Austrian German). The babel ini
file for german babel/locale/de/babel-de.ini has this id:

[identification]
charset = utf8
version = 1.3
date = 2020-06-30
name.local = Deutsch
name.english = German
name.babel = german
name.polyglossia = german
tag.bcp47 = de
language.tag.bcp47 = de
tag.bcp47.likely = de-Latn-DE
tag.opentype = DEU
script.name = Latin
script.tag.bcp47 = Latn
script.tag.opentype = latn
level = 1
encodings = T1 OT1 LY1
derivate = no

and babel-de-AT.ini:

[identification]
charset = utf8
version = 1.3
date = 2020-06-30
name.local = Deutsch
name.english = German
name.babel = austrian german-austria german-at
name.polyglossia = german
tag.bcp47 = de-AT
language.tag.bcp47 = de
tag.opentype = DEU
region.local = Österreich
region.english = Austria
region.tag.bcp47 = AT
script.name = Latin
script.tag.bcp47 = Latn
script.tag.opentype = latn
polyglossia.variant = austrian
polyglossia.spelling = new
level = 1
encodings = T1 OT1 LY1
derivate = no

ini files use german and german-at, but in classic babel nomenclature
(ldf files) we have ngerman and naustrian.

Maybe it should be corrected like this:

("de-de"  :babel "ngerman" :polyglossia "german" :polyglossia-variant "german" 
:lang-name "German")
("de"  :babel-ini-only "german" :polyglossia "german" :polyglossia-variant 
"german" :lang-name "German")

The case of de-at is more problematic because a single language code
serves for naustrian (ldf) and (ini:) austrian, german-at and
german-austria. Some new property, something like :babel-ini-alt, would
have to be introduced . There are other similar cases on the list, such
as el-polyton, which points to polutonikogreek (ldf). In general, except
in cases where only the ini file exists, I used the ldf nomenclature for
backward compatibility.

In any case, these dances of language names between some places and
others make the list of language names that Ihor is working on
increasingly necessary. 


-- 
Juan Manuel Macías

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

Tips on reproducing and bisecting bugs

[Rens Oliemans]

Hi all,

Thanks for creating and maintaining Org mode, it's great. I tried helping out 
recently by
confirming and bisecting a reported bug
(https://list.orgmode.org/camjkazz6srdoxv6rhmdm97enhysntodtctcznn1zbquk3gh...@mail.gmail.com/),
but am not sure if what I did was actually useful, and if so, how to do this 
more
efficiently.

I have the orgmode repo cloned, and build orgmode with `make && make vanilla`. 
When
bisecting, I manually navigate to and load the required init.el and reproduce 
the bug per
commit. It seems that parameters passed to `make vanilla` are not passed to 
emacs. Is this
how you would do it, or do you have tips to improve this workflow? 
Additionally, how could
I do this for different emacs versions?

If it wasn't all that useful, what can I do to improve this? I have a little 
bit of lisp
knowledge, but no experience with the orgmode source code (yet).

--
Thanks and best,
Rens

Re: Possible File Saving Bug with [/]?

[Samuel Wales]

lock file?  in 27 (info "(emacs) Interlocking") strangely does not
mention .# but it could be the concept in question.


On 9/6/23, Ihor Radchenko  wrote:
> Summer Emacs  writes:
>
>> I have a .org file which is just a list of Emacs commands I like to keep
>> handy to refer to (navigation, selection, commands in some modes etc…) One
>> of these had help about the [/] command for a header for a list. However,
>> because I had [/] and no numbers in it (it was just an example to show me
>> how to do it if I forgot), it kept saving a backup copy of that file
>> anytime that I saved it, and kept that backup “alive” to track. The name
>> of the regular file is emacshelp.org, and the file it kept creating in my
>> directory was .#emacshelp.org#  ->
>> summer@summer.localhost.randomnumberhere:randomportnumberhere
>
> Thanks for the report!
> Unfortunately, it is not clear to me what exactly is going on from your
> description.
> May you please provide more detailed instructions how to trigger the
> observed behavior? See https://orgmode.org/manual/Feedback.html#Feedback
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [MAINTENANCE] On how much we can expose internals into defcustom

[Leo Butler]

On Tue, Sep 05 2023, Ihor Radchenko  wrote:

> CCing Bastien, as he might want to intervene.
>
> Leo Butler  writes:
>
>>> +(defcustom org-babel-maxima-command-arguments
>>> +  "--very-quiet"
>>
>>> +(defcustom org-babel-maxima-batch/load
>>> +  "batchload"
>>> +
>>> +(defcustom org-babel-maxima-graphic-file-format-string
>>> +  "(set_plot_option ('[gnuplot_term, png]), set_plot_option 
> ('[gnuplot_out_file, %S]))$"
>>> +
>>> +(defcustom org-babel-maxima-default-epilogue
>>> +  "gnuplot_close ()$"
>
>>> IMHO, in their current state, if a user mindlessly customizes these
>>> options without knowing how ob-maxima internals work, ob-maxima may
>>> simply be broken.
>>
>> I think there is a fine line between being too rigid but working within
>> a limited scope (as ob-maxima is now), or providing enough customizable
>> options to let users do what they want. I would prefer the latter,
>> if the defaults provide a working configuration.
>>
>> Note that I do attempt to suggest other working options in the defcustom
>> definitions.
>
>>> As a general rule, we do not expose internal details that are _required_
>>> for things to work to users.
>>
>> I understand this principle, but, why not provide enough options for
>> users to configure a package to do what they want? Yes, that may mean
>> they break the package--but only temporarily, because returning to the
>> default options will return the package to a working state.
>
> That's a bit more tricky.
> Imagine, for example, that we commit
>
> +(defcustom org-babel-maxima-command-arguments
> +  "--very-quiet"
>
> and some users will later customize the default value to
>
> "--very-quite --my-personal-switch-I-want"
>
> Then, in future, due to changes in Org or maxima, we might need to
> change "--very-quite" to something else in order to keep ob-maxima in
> working condition: "--very-quite=yes 
> --another-useful-flag-we-absolutely-need-in-org"
>
> In order to make such a switch, we will have to force all the users
> change their customization - something we do not want to annoy users
> with.

I understand your general argument, but I doubt it is relevant to this
particular case.

In this specific case, that command-line option `--very-quiet' was
introduced in 17 years ago
(https://sourceforge.net/p/maxima/mailman/message/11796355/). The syntax
has not changed since it was introduced.

>
> So, leaving essential settings customizeable is not necessarily a good idea.

I understand your hesitation about full-blown customization using
`defcustom'. However, I would still like to have more dials to turn.

Perhaps we could add header arguments to get the desired customization?
E.g.

- :batch :: Control how the Maxima source is evaluated by Maxima.
  1. Default. If nil or no, then use batchload with the --very-quiet
 command-line flag.
  2. If t or yes, then use batch with the --quiet command-line flag;

- :plot-engine :: Set the plotting package.
  1. Default. If nil or no, the use `plot';
  2. If `draw', then use `draw'.

- Similarly, we could do something like ob-R.el does, and construct the
  graphics instructions using some additional header arguments and
  grovelling the terminal from the filename (see
  org-babel-R-construct-graphics-device-call).

My sense is that this would be more in keeping with how other ob-*.el
packages do things.

Best,
Leo

[BUG] wrong-type-argument listp 4240 [9.7-pre (release_9.6.8-749-g4fe52f @ .emacs.d/org-mode-git/lisp/)]

[Paul Stansell]

Hello,

I don't know what caused the following message when I opened an org file,
but I'm reporting it as requested by the message:

Warning (org-element-cache): org-element--cache: Org parser error in
tmp_train_notes.org::1. Resetting.
 The error was: (wrong-type-argument listp 4240)
 Backtrace:
nil
 Please report this to Org mode mailing list (M-x org-submit-bug-report).
Disable showing Disable logging

When I opened the same file a second time there was no error message.

Paul


Emacs  : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.37, cairo version 1.16.0)
 of 2023-03-16, modified by Debian
Package: Org mode version 9.7-pre (release_9.6.8-749-g4fe52f @
~/.emacs.d/org-mode-git/lisp/)

current state:
==
(setq
 org-link-elisp-confirm-function 'yes-or-no-p
 org-bibtex-headline-format-function 'org-bibtex-headline-format-default
 org-log-done 'time
 org-fontify-done-headline nil
 org-log-into-drawer t
 org-startup-folded t
 org-persist-after-read-hook '(org-element--cache-persist-after-read)
 org-format-latex-options '(:foreground "Yellow" :background default :scale
1.2
:html-foreground "Black" :html-background
"Transparent"
:html-scale 1.07 :matchers ("begin" "$1" "$"
"$$" "\\(" "\\["))
 org-export-before-parsing-hook '(org-attach-expand-links)
 org-cycle-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-file-apps '((auto-mode . emacs) ("\\.odt\\'" . "libreoffice %s")
 ("\\.docx\\'" . "libreoffice %s") ("\\.xlsx\\'" .
"libreoffice %s")
 ("\\.png\\'" . "xv %s") ("\\.jpg\\'" . "xv %s")
("\\.jpeg\\'" . "xv %s")
 ("\\.webp\\'" . "xv %s") ("\\.pdf\\'" . "okular \"%s\"")
 ("\\.xoj" . "xournal %s") ("\\.xopp" . "xournalpp %s"))
 org-odt-format-inlinetask-function
'org-odt-format-inlinetask-default-function
 org-ascii-format-drawer-function #[771 " \207" [] 4 "\n\n(fn NAME CONTENTS
WIDTH)"]
 org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-show-empty-lines
  org-cycle-optimize-window-after-visibility-change
  org-cycle-display-inline-images)
 org-persist-before-read-hook '(org-element--cache-persist-before-read)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook org-fold-show-all
append local] 5]
 #[0 "\300\301\302\303\304$\207"
   [add-hook change-major-mode-hook
org-babel-show-result-all append local]
   5]
 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-babel-load-languages '((R . t) (emacs-lisp . t) (gnuplot . t) (octave
. t) (python . t)
(fortran . t) (sql . t) (ditaa . t) (dot . t)
(shell . t))
 org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
 org-latex-format-headline-function
'org-latex-format-headline-default-function
 org-confirm-shell-link-function 'yes-or-no-p
 org-adapt-indentation t
 org-html-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 outline-isearch-open-invisible-function 'outline-isearch-open-invisible
 org-highlight-latex-and-related '(latex)
 org-odt-format-headline-function 'org-odt-format-headline-default-function
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-src-preserve-indentation t
 org-babel-tangle-lang-exts '(("fortran" . "F90") ("python" . "py")
("emacs-lisp" . "el")
  ("elisp" . "el"))
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-clock-out-remove-zero-time-clocks t
 org-hide-leading-stars t
 org-todo-keywords '((sequence "TODO(t!)" "MAYBE(m!)" "STARTED(s!)"
"WAITING(w@/!)" "|"
  "DONE(d)" "INFO(i!)" "CANCELLED(c@)" "UNFINISHED(u@)"
"ABANDONED(a@)")
 )
 org-id-link-to-org-use-id t
 org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
 org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
 org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
 org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME CONTENTS)"]
 org-confirm-babel-evaluate nil
 org-fold-core-isearch-open-function 'org-fold-core--isearch-reveal
 org-clock-in-switch-to-state "STARTED"
 org-clock-persist 'history
 org-latex-format-inlinetask-function
'org-latex-format-inlinetask-default-function
 org-persist-before-write-hook '(org-element--cache-persist-before-write)
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
 org-link-shell-confirm-function 'yes-or-no-p
 org-babel-pre-tangle-hook '(save-buffer)
 org-clock-display-default-range 'untilnow
 org-agenda-loop-over-headlines-in-active-region nil
 org-todo-keyword-faces '(("TODO" :foreground 

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

[Vladimir Nikishkin]

Dear Org developers,

Emacs has a long established tradition of adjusting presentation mode
for a command using prefix parameters. One can run C-x 4 C-f to visit a
file in a new window. (C-x 5, and C-x t for the new frame and tab,
respectively). However, org-open-at-point does not seem to follow this
tradition.

Would it be possible to add it, at least for the types of links that are
known to work within Emacs itself, such as info: and *?


Emacs  : GNU Emacs 30.0.50 (build 1, x86_64-slackware-linux-gnu, GTK+ Version 
3.24.31, cairo version 1.16.0)
 of 2023-07-31
Package: Org mode version 9.6.6 (release_9.6.6 @ 
/usr/share/emacs/30.0.50/lisp/org/)
-- 
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)

[Bug] Some parentheses are not visible in the html export but are present

[Niall Dooley]

Some parentheses are not visible in the html export but are present.  This
was not always the case with the provided example.

--- Begin Example ---
* islower()
** Front
*String method* that returns =True= if the string is a lowercase string, =False=
 otherwise.
** Back
*String method:* islower(self, /) -> bool
** Usage
#+name: str.islower()
#+begin_src python
.islower()
#+end_src
** Remarks
A string is lowercase if all /cased/ characters in the string are lowercase and
there is at least one cased character in the string.
--- End Example

The parentheses under the Back subheading are displayed in the export.
However, the parentheses within the src block under the Usage headline are not
visible but are nonetheless present.  This can be seen by highlighting the
region in the exported html file.  If I add some text within these parentheses
the text is visible on export but the parentheses are still not.

Org mode version 9.7-pre (release_9.6.8-740-gdeb5ea @
/home/doolio/.emacs.d/straight/build/org/)
GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.24,
cairo version 1.16.0) of 2023-02-23, modified by Debian

Re: bug#65734: [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]

> From: Ihor Radchenko 
> Date: Wed, 2023-09-06 08:30 +
>
> Eli Zaretskii  writes:
>
>>> It would also make sense to group the two edits together via
>>> `combine-after-change-calls', although a more universal way to know that
>>> certain edits are a part of the same known command (even when called
>>> non-interactively) would be useful.
>>
>> The command kills in two parts for a good reason, which is explained
>> in the comments to the code.  So making a single group will not work,
>> I think, at least not in all situations.
>
> I think there is misunderstanding. `combine-after-change-calls' will not
> affect the two-step modification of the kill ring, if we put it around
> `kill-whole-line'. Or do I miss something?

I tried to wrap the problematic portion of `kill-whole-line' into
`combine-after-change-calls'.  It seems to have no effect.  The
after-change function `org-fold-core--fix-folded-region' still gets
called twice, not fixing the bug.  I did not dig deeper, because the
stuff that makes `combine-after-change-calls' work at least partially
goes in C and seems to be scattered over several places.

The Emacs Lisp manual states that `combine-after-change-calls' "arranges
to call the after-change functions just once for a series of several
changes—if that seems safe."  So this case does not seem safe.  Apart
from that, there is no stated guarantee for when it would seem it safe.

I conclude that, although this path looked possibly elegant at first,
and I wanted to give it a try, this cannot work out.

Re: Fallback fonts in LaTeX export for non latin scripts

[Juan Manuel Macías]

Ihor Radchenko writes:

> Do I understand correctly that onchar=id will not break anything if text
> is correctly marked with \selectlanguage{}?

To load language features (hyphen rules, captions, etc.) there is no
problem. But to load a font associated with a language, the font of the
last declared language will always be loaded. Well, it is not a problem,
because if in a document there are texts in Russian and Bulgarian, for
example, the natural thing is that they go in the same font, since both
languages share the Cyrillic script. But there may be cases when the
author needs different fonts. In such a case, the user should not use
the onchar = etc property:

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

In any case (to organize myself mentally) I thought that it could be
done on two levels:

- Level 0: The fonts associated with each script are loaded (from a
  defcustom list) if luatex is the current engine. And low-level code is
  generated in Lua with the luaotfload.add_fallback function. That code
  can be in a Lua file or directly within the preamble, enclosed in the
  \directlua primitive (mode=harf means that HarfBuzz is used as otf
  rendering):

   \directlua
   {luaotfload.add_fallback("orgfallback",
   {
   "oldstandard:mode=harf;script=grek;",
   "oldstandard:mode=harf;script=cyrl;",
   "freeserif:mode=harf;script=arab;",
   "freeserif:mode=harf;script=dev2;",
   etc., etc.
   })
   }

  And, to load the fallback fonts:

  \setmainfont{latinmodernroman}[RawFeature={fallback=orgfallback}]

 At this level per-language properties are not loaded, but at least
 readability is ensured. The user cannot modify the fonts associated
 with each script within the document, but can modify, of course, the
 defcustom.

- Level 1: The user can load language properties and associate fonts
  with each language using Babel's high-level code (via keywords in Org,
  as we have commented in previous messages). Here you can also modify
  the default fonts (also, as we mentioned before): main, mono, sans and
  math. If the language is declared with an asterisk (for example:
  russian*) the onchar=etc property will be included in the preamble,
  and it would not be necessary to switch to russian explicitly. It is
  assumed that in this scenario the only language with Cyrillic script
  would be Russian. For language swithcing, in the rest of the cases,
  some babel command would have to be used using @@latex:@@, special
  blocks, etc. When Org already has its own language switching
  mechanism, this would be used instead. Wdyt?

-- 

Juan Manuel Macías 

https://juanmanuelmacias.com

https://lunotipia.juanmanuelmacias.com

https://gnutas.juanmanuelmacias.com

ox-latex language handling in Org-9.5 vs 9.6

[Max Nikulin]

Hi,

I consider the following as an issue rather close to the discussion in 
the thread
Juan Manuel Macías. Fallback fonts in LaTeX export for non latin 
scripts. Wed, 30 Aug 2023 08:25:53 +.

https://list.orgmode.org/878r9t7x7y@posteo.net

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042450
elpa-org: #+LANGUAGE: de-de is not working in LaTeX export. Debian Bug 
report logs


I am unsure if the change was intentional.

#+language: de-de
#+latex_header: \usepackage[AUTO]{babel}

is exported to

\usepackage[ngerman]{babel}
% ...
\hypersetup{
% ...
 pdflang={Ngerman}}

by Org-9.5 and as

\usepackage[]{babel}
% ...
\hypersetup{
% ...
 pdflang={De-De}}

by Org-9.6. Similar user expectation should be had in mind during 
planning of further changes.

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 05/09/2023 18:02, Ihor Radchenko wrote:


What I had in mind is a bit elaborate:
1. We get actual link type
2. If link type is not registered, we try "fuzzy"
3. If "fuzzy" target is not found, instead of broken link, we export a
link with unknown type.


It makes sense as an additional variant for 
`org-export-with-broken-links'. Currently no option allows to export 
description of broken links and sometimes it is inconvenient.



Max Nikulin writes:

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.


May you elaborate?


I am considering another behavior. If any PREFIX: is recognized then the 
link exported literally as PREFIX:PATH unless the PREFIX is registered as


   (org-link-register-search-link-prefix "sec")

So if the document does not contain PREFIX:NAME target then it is an 
export error (or another prescription controlled by 
`org-export-with-broken-links') and it may be reported so by `org-lint'.


Different users expect different degree of strictness during link 
export. I am unsure which variant is better.

Re: bug#65734: [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]

> From: Eli Zaretskii 
> Date: Wed, 2023-09-06 15:16 +0300
>
>> From: Ihor Radchenko 
>> Date: Wed, 06 Sep 2023 08:23:23 +
>> 
>> Eli Zaretskii  writes:
>> 
>> >> The following would do it.  I think I tested it rather thoroughly.
>> >> During testing I found another bug that is addressed by the let-binding
>> >> of kill-read-only-ok during the first kill-region below.
>> >
>> > Thanks.  Sadly, we don't have any tests for this function in our test
>> > suite, so verifying this non-trivial change will not be easy...
>> 
>> Then, what should we do to move things forward? I guess the first step
>> will be writing these missing tests.
>
> Yes, that'd be most welcome.

I will write the tests.  And I will probably come up with an updated
version of the original patch.  There is at least one cosmetic change.
And something else that I want to have tried.  May take some time.

>> Anything else?
>
> How about asking on emacs-devel that people who use kill-whole-line
> frequently install the patch and run with it for some time?  (We could
> do that after installing the changes on master, of course.)

Re: bug#65734: [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/)]

[Eli Zaretskii]

> From: Ihor Radchenko 
> Cc: i...@whxvd.name, 65...@debbugs.gnu.org, emacs-orgmode@gnu.org
> Date: Wed, 06 Sep 2023 08:30:36 +
> 
> Eli Zaretskii  writes:
> 
> >> In addition, `org-kill-line' acts specially in certain scenarios:
> >> 
> >> For
> >> * Heading  text :tag1:tag2:
> >> 
> >> `org-kill-line' will keep and re-align ":tag1:tag2:":
> >> 
> >> * Heading   :tag1:tag2:
> >> 
> >> It would be nice if we could express such behavior without overriding
> >> the `kill-line' command.
> >
> > This could be handled by a suitable extension to end-of-visible-line.
> > For example, introduce a new text property which end-of-visible-line
> > would then handle the same as it currently handles invisible text.
> 
> I am not sure if I like the idea of text property - marking all the tags
> in buffer with text property is expensive.

Then perhaps just a special value for buffer-invisibility-spec, or
some other simple variation of a property Org already uses?

> What about something like `end-of-visible-line-function'?

That is also a possibility, but it will then affect kill-line
_anywhere_ in the buffer, whereas a text property can have a more
localized effect.  Are you sure kill-line will need this customization
on the whole buffer?

Re: bug#65734: [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/)]

[Eli Zaretskii]

> From: Ihor Radchenko 
> Cc: Sebastian Miele , 65...@debbugs.gnu.org,
>  emacs-orgmode@gnu.org
> Date: Wed, 06 Sep 2023 08:23:23 +
> 
> Eli Zaretskii  writes:
> 
> >> The following would do it.  I think I tested it rather thoroughly.
> >> During testing I found another bug that is addressed by the let-binding
> >> of kill-read-only-ok during the first kill-region below.
> >
> > Thanks.  Sadly, we don't have any tests for this function in our test
> > suite, so verifying this non-trivial change will not be easy...
> 
> Then, what should we do to move things forward? I guess the first step
> will be writing these missing tests.

Yes, that'd be most welcome.

> Anything else?

How about asking on emacs-devel that people who use kill-whole-line
frequently install the patch and run with it for some time?  (We could
do that after installing the changes on master, of course.)

Re: [BUG] unexpected octave output from code blocks [9.7-pre (release_9.6.7-581-gd38ca5)]

[Paul Stansell]

>
> Thanks for reporting!
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=13e4ee737


Great work, thanks!

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:

> I've amended the test using cl-letf.
> I also bound the variables which may generate output files to nil 
> to prevent generating any output files if the test is run 
> interactively.
> See attached.

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

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

> True. Thanks for pointing it out. Indeed, \babelprovide with the
> ochar=id fonts option only makes sense when 1 foreign language = 1
> script. For example, different variants of Greek cannot be combined
> without an explicit switch.
>
> And something like this wouldn't work either:
>
> \babelprovide[import,onchar=id fonts]{russian}
> \babelprovide[import,onchar=id fonts]{bulgarian}
> \babelfont[russian]{rm}[Color=blue]{Old Standard}
> \babelfont[bulgarian]{rm}[Color=green]{FreeSerif}
>
> because bulgarian overwrites russian.
>
> Well, another added complication :-(.

AFAIU, there is simply no way to solve this unless the user manually
indicates the indented language.

Do I understand correctly that onchar=id will not break anything if text
is correctly marked with \selectlanguage{}?

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

Re: [BUG] unexpected octave output from code blocks [9.7-pre (release_9.6.7-581-gd38ca5)]

[Ihor Radchenko]

Paul Stansell  writes:

> The attached org file gives examples of outputs from octave code blocks
> that are unexpected and inconsistent.

Thanks for reporting!
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=13e4ee737

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

Re: Possible File Saving Bug with [/]?

[Ihor Radchenko]

Summer Emacs  writes:

> I have a .org file which is just a list of Emacs commands I like to keep 
> handy to refer to (navigation, selection, commands in some modes etc…) One of 
> these had help about the [/] command for a header for a list. However, 
> because I had [/] and no numbers in it (it was just an example to show me how 
> to do it if I forgot), it kept saving a backup copy of that file anytime that 
> I saved it, and kept that backup “alive” to track. The name of the regular 
> file is emacshelp.org, and the file it kept creating in my directory was 
> .#emacshelp.org#  -> 
> summer@summer.localhost.randomnumberhere:randomportnumberhere

Thanks for the report!
Unfortunately, it is not clear to me what exactly is going on from your
description.
May you please provide more detailed instructions how to trigger the
observed behavior? See https://orgmode.org/manual/Feedback.html#Feedback

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

Re: bug#65734: [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/)]

[Ihor Radchenko]

Eli Zaretskii  writes:

>> It would also make sense to group the two edits together via
>> `combine-after-change-calls', although a more universal way to know that
>> certain edits are a part of the same known command (even when called
>> non-interactively) would be useful.
>
> The command kills in two parts for a good reason, which is explained
> in the comments to the code.  So making a single group will not work,
> I think, at least not in all situations.

I think there is misunderstanding. `combine-after-change-calls' will not
affect the two-step modification of the kill ring, if we put it around
`kill-whole-line'. Or do I miss something?

> ...  And relying on after-change
> hooks to fix this use case sounds too obscure and fragile to me.

Indeed. I did not talk about this particular bug report. What I meant is
some way to group change hooks executed by the same function/command.

>> In addition, `org-kill-line' acts specially in certain scenarios:
>> 
>> For
>> * Heading  text :tag1:tag2:
>> 
>> `org-kill-line' will keep and re-align ":tag1:tag2:":
>> 
>> * Heading   :tag1:tag2:
>> 
>> It would be nice if we could express such behavior without overriding
>> the `kill-line' command.
>
> This could be handled by a suitable extension to end-of-visible-line.
> For example, introduce a new text property which end-of-visible-line
> would then handle the same as it currently handles invisible text.

I am not sure if I like the idea of text property - marking all the tags
in buffer with text property is expensive. What about something like
`end-of-visible-line-function'?

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

Re: bug#65734: [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/)]

[Ihor Radchenko]

Eli Zaretskii  writes:

>> The following would do it.  I think I tested it rather thoroughly.
>> During testing I found another bug that is addressed by the let-binding
>> of kill-read-only-ok during the first kill-region below.
>
> Thanks.  Sadly, we don't have any tests for this function in our test
> suite, so verifying this non-trivial change will not be easy...

Then, what should we do to move things forward? I guess the first step
will be writing these missing tests. Anything else?

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

Re: [BUG] unexpected octave output from code blocks [9.7-pre (release_9.6.7-581-gd38ca5)]

[Rens Oliemans]

Confirmed on my machine, thanks for the bug report and reproduction files.

I could reproduce the bug on GNU Emacs 28.2, git bisect told me that commit
866ed1a3c5c37cad243085f9a8fa904970e4d614 was the first bad commit.

--
Rens Oliemans