Re: [Bug] isearch errors when org-fold-core-style is 'overlays

[Samuel Wales]

possibly related: are links still not searchable with iserch without
being in reveal mode or similar?  [9.4 here.)

On 12/28/22, Ihor Radchenko  wrote:
> Matt Lundin  writes:
>
>> Here is a minimal recipe for reproducing the bug:
>>
>> Use a minimal emacs startup file:
>>
>> --8<---cut here---start->8---
>> (add-to-list 'load-path "~/org-mode/lisp/")
>> (setq org-startup-folded t)
>> (setq org-fold-core-style 'overlays)
>> --8<---cut here---end--->8---
>>
>> Open the following file:
>>
>> --8<---cut here---start->8---
>> * One
>> word
>> * Two
>> word
>> --8<---cut here---end--->8---
>>
>> Issue #1:
>>
>> Go to the beginning of headline "Two" when the trees are folded.
>>
>> Type "M-x isearch word [RET]".
>
> Confirmed.
> Part of the problem is some undocumented behaviour of isearch.
> I will need to consult Emacs devs before fixing.
>
> --
> 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: @@latex: ... @@ contruct not valid in [sub-]headlines?

[Alain . Cochard]

alain.coch...@unistra.fr writes on Wed 28 Dec 2022 20:00:

 > For example, for the file made of
 > 
 >* foo @@latex:x x x x x x x x x x@@
 > 
 > upon LaTeX export, the x's in are not in mathematical font.

So stupid of me.  Sorry.

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

@@latex: ... @@ contruct not valid in [sub-]headlines?

[Alain . Cochard]

For example, for the file made of

   * foo @@latex:x x x x x x x x x x@@

upon LaTeX export, the x's in are not in mathematical font.

PS: with release_9.6-149-g55493, after I hit 'C-c C-e l o', on the
file above, the following appears in the *Messages* buffer:

   Invalid face reference: help-key-binding [12 times]

-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

Problems with LaTeX export for $x\text{foo $x$}$-like construts?

[Alain . Cochard]

Version used: release_9.6-149-g554935 

With an org file containing only

   #+begin_export latex
   $x \text{foo $y$}$

   \(x \text{foo \(y\)}\)

   $x \text{foo \(y\)}$

   \(x \text{foo $y$}\)
   #+end_export

the pdf generated upon latex export gives as expected, i.e., with 'x'
and 'y' in mathematical font.

Maybe this is fully normal, but I find it annoying: when the 4 lines
above are not within a latex block, only the last 2 (that is, with
mixed "$...$" and "\(...\)" constructs), are shown correctly on the
resulting pdf.

The 1st one shows, on the pdf

   $x foo y$
   
(with 'y' in mathematical font).

The 2nd one (if alone in the org file) gives

   File "/home/cochard/Org/debug.pdf" wasn’t produced.  See "*Org PDF
   LaTeX Output*" for details


PS/incidentally: if one adds a blank line and another line to that 2nd
one, i.e., if the org file contains something like

   \(x \text{foo \(y\)}\)

   foo

then a pdf is generated, which shows

   x
   foo

The *Messages* buffer contains

   PDF file produced with errors.
   Running /usr/bin/xdg-open /home/cochard/Org/debug.pdf...done

but only the last of those lines is seen in the minibuffer.  So this
adds another example to those discussed in thread
https://list.orgmode.org/25477.57044.35186.766...@gargle.gargle.howl/
where one (at least I) would like to more permanently see "PDF file
produced with errors."


-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

Re: [Bug] isearch errors when org-fold-core-style is 'overlays

[Ihor Radchenko]

Matt Lundin  writes:

> Here is a minimal recipe for reproducing the bug:
>
> Use a minimal emacs startup file:
>
> --8<---cut here---start->8---
> (add-to-list 'load-path "~/org-mode/lisp/")
> (setq org-startup-folded t)
> (setq org-fold-core-style 'overlays)
> --8<---cut here---end--->8---
>
> Open the following file:
>
> --8<---cut here---start->8---
> * One
> word
> * Two
> word
> --8<---cut here---end--->8---
>
> Issue #1:
>
> Go to the beginning of headline "Two" when the trees are folded.
>
> Type "M-x isearch word [RET]".

Confirmed.
Part of the problem is some undocumented behaviour of isearch.
I will need to consult Emacs devs before fixing.

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

Re: Radio links work only in small numbers

[Daniel Clemente]

Hi,
I also found this limitation, and my solution was to disable radio links
and to replace them by a manual approach:

1. I disabled the call to (org-update-radio-target-regexp) in org.el. Well,
I added a boolean org-inhibit-startup-radio-refresh, that works in a
similar way to org-inhibit-startup-visibility-stuff. After this change, I
still type <<>> to define a title, but org doesn't handle it anymore

2. I created a helm  menu, that offers
me all the radio links. I compute the list of radio links myself, through
grep, by looking for <<<. It's easier than it seems, and very fast. The
code (no explanations) is my configuration
, in these functions:
anythingyhelm-fuente-etiquetas-radio-org,
precarga-etiquetas-radio-de-wiki-para-helm

3. Often, when I want to refer to a title, I write in in cursive, /like
this/. That's my way of telling myself „that's a link, you can manually
search for it through helm“. The target will be tagged <<>>. I
could automate this link-following but I don't mind typing for 1 or 2
seconds to go a header. I still use normal links (C-c C-l, :ID: etc.) if I
want something that is easier to follow.

My system doesn't provide the same features as org's radio links, but I get
an interactive menu with pattern matching and very fast access to all
headers. I would still prefer the real radio links, with no limitations.
However, I understand that org-mode's approach is computationally harder.
Whereas I'm looking for ONE target link through all my 100 files, org-mode
is doing a regexp that looks for ALL target links in the current file. And
I have around 20k radio links!. Grepping for 20k things everywhere is
harder than grepping for 1 thing everywhere. Even GNU grep is slow (>25
seconds) if I use a long regular expression
 with
20k things inside.

In other words: since radio links don't scale well, I have replaced the
real radio links (search for everything everywhere) with a directed
approach (search for 1 thing everywhere).


On Tue, 13 Dec 2022 at 23:11, Rudolf Adamkovič  wrote:

> Greetings smart people!
>
> All [[link]]s in my notes perfectly match LEVEL-1 headings, so I figured
> that I may as well ask Org to make links for me.  So, I replaced all the
> ~4000 headings in my notes with radio <<>>.  However, Org now
> errors out with "Regular expression too big".
>
> Does anyone know how to overcome this limitation?  Or, perhaps someone
> has a patch in works that fixes it?  If so, please let me know!
>
> Thank you.
>
> Rudy
> --
> "The introduction of suitable abstractions is our only mental aid to
> organize and master complexity."
> -- Edsger Wybe Dijkstra, 1930-2002
>
> Rudolf Adamkovič  [he/him]
> Studenohorská 25
> 84103 Bratislava
> Slovakia
>
>

Re: Bug? org-assert-version does not prevent mixed install

[Ihor Radchenko]

Max Nikulin  writes:

 We might do something like

 (eval-and-compile (org-assert-version))
>>>
>>> This will give obscure error during compiling since `org-assert-version'
>>> is not defined.
>> 
>> Yes, but we will at least abort the compilation this way.
>
> You are right that it prevents creation of .elc files. Unfortunately 
> `byte-recompile-directory' converts failure into a message instead of 
> aborting package install completely.

> When used consistently, it should cause load of Org completely 
> uncompiled during next Emacs session. It is better than having 
> incorrectly compiled files.
>
> Notice that `org-assert-version' works for compiled files only, so if a 
> user loads some third-party package (hyperbole?) that loads built-in Org 
> and later adds new Org to `load-path' then we get an obscure error again.

I think that most reliable approach in this situation would be pulling
`org-assert-version' into a dedicated new file, similar to what you
suggested below. That way, we will not have feature cashes.

However, I am concerned about what is going to happen if wrong
org-version is defined during compilation. `org-assert-version' can
then be compiled with wrong org-version value and later produce similar
obscure error. Can you test such scenario using your Debian reproducer?

> In addition I have noticed that e.g. org-matlab.el contains
>
>   (require 'org-macs)
>   (org-assert-version)
>
> Shouldn't it be (eval-when-compile (require 'org-macs)) since no 
> functions are used from this file? Some files have duplicated (require 
> 'org-macs).

org-macs is pulled in by Org feature dependencies anyway. So, it does
not matter in practice. I also left the duplicates consciously to keep
the same pattern with `org-assert-version' usage.

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