Re: Emacs slow-down

[Pedro Andres Aranda Gutierrez]

Hi Bill

another sleepless night. Having something to distract me is helpful. In
this case, one of the root causes for my insufferable slowdown was not
org-mode but jinx (the spell checker). Without it, I do notice a slow down
when going through my slides, but much less.

Going back to ispell...

Best, /PA

On Thu, 7 Mar 2024 at 17:21, William Denton 
wrote:

> On Thursday, March 7th, 2024 at 11:03, Pedro Andres Aranda Gutierrez <
> paag...@gmail.com> wrote:
>
> > Interestingly enough, this redisplay_internal function seems to be the
> real pain. I think we need to switch to the main
> > emacs devel list here...
>
> I wonder if those of us seeing this have something in common about our
> configurations.  Might it be a package that's getting in the way, and a
> change there is causing this?  Or does the profiling show it's in base Org?
>
>
> Bill
>
> --
> William Denton
> https://www.miskatonic.org/
> Librarian, artist and licensed private investigator.
> Toronto, Canada
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: [DISCUSSION] Add "Recent News" to orgmode.org

[Bastien Guerry]

Ihor Radchenko  writes:

> Bastien Guerry  writes:
>
>> Ihor Radchenko  writes:
>>
>>> Wouldn't a cron job work? Similar to how we schedule CI for Org mode
>>> tests.
>>
>> I've set this cron job to run every six hours and limited the number
>> of entries to 5 to not clutter the homepage.
>
> Note that
> https://git.sr.ht/~bzg/orgweb/commit/c9531ba7ad7647d7322c06e8dd8ee3fabbb992a8
> has stray unresolved conflict markers:
>
> +<<< HEAD

Oups, fixed.

> Also, it looks like https://tracker.orgmode.org/index.org does not sort
> links by date. It would be nice if top 5 links were also the most recent.

Yes, indeed. I'll see when I can hack on this. Help from Clojure
hackers is welcome here: https://git.sr.ht/~bzg/woof

-- 
 Bastien Guerry

Re: [DISCUSSION] Add "Recent News" to orgmode.org

[Ihor Radchenko]

Bastien Guerry  writes:

> Ihor Radchenko  writes:
>
>> Wouldn't a cron job work? Similar to how we schedule CI for Org mode
>> tests.
>
> I've set this cron job to run every six hours and limited the number
> of entries to 5 to not clutter the homepage.

Note that
https://git.sr.ht/~bzg/orgweb/commit/c9531ba7ad7647d7322c06e8dd8ee3fabbb992a8
has stray unresolved conflict markers:

+<<< HEAD

Also, it looks like https://tracker.orgmode.org/index.org does not sort
links by date. It would be nice if top 5 links were also the most recent.

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

Re: [DISCUSSION] Add "Recent News" to orgmode.org

[Bastien Guerry]

Ihor Radchenko  writes:

> Wouldn't a cron job work? Similar to how we schedule CI for Org mode
> tests.

I've set this cron job to run every six hours and limited the number
of entries to 5 to not clutter the homepage.

-- 
 Bastien Guerry

Re: naming: Re: Experimental public branch for inline special blocks

[Samuel Wales]

cannot follow discussion but is the role and scope of the proposed
semantics settled and agreed upon by those who do?

Re: [BUG] With R using ":var d=data" breaks ":colnames yes" [9.7-pre (release_9.6.10-881-g595a32]

[Ihor Radchenko]

Paul Stansell  writes:

> Thanks for your advice, it helps a lot.  Sorry for submitting
> something that wasn't a bug.

While not a bug, the situation can certainly be improved.
Things should be a bit smarter on main after
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=cab81f242

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

Re: [BUG] With R using ":var d=data" breaks ":colnames yes" [9.7-pre (release_9.6.10-881-g595a32]

[Paul Stansell]

Hi Ihor,

Thanks for your advice, it helps a lot.  Sorry for submitting
something that wasn't a bug.

Paul

On Thu, 7 Mar 2024 at 13:16, Ihor Radchenko  wrote:

> Paul Stansell  writes:
>
> > It seems that using ":var d=data" breaks ":colnames yes" in the header of
> > an R code block.
> > ...
> > #+name: data
> > |+|
> > |  x |  y |
> > |+|
> > | 111.89 |  88.37 |
> > | 392.12 | 297.33 |
> > |+|
>
> It is expected.
> :colnames yes implies:
>
>  The ‘colnames’ header argument accepts ‘yes’, ‘no’, or ‘nil’
>  values.  The default value is ‘nil’: if an input table has column
>  names--because the second row is a horizontal rule--then Org
>  removes the column names, processes the table, puts back the column
>  names, and then writes the table to the results block.  Using
>  ‘yes’, Org does the same to the first row, even if the initial
>  ^
>  table does not contain any horizontal rule.  When set to ‘no’, Org
>  does not pre-process column names at all.
>
> In your table, the first row is a horizontal line, so Org tries to parse
> the first line as column names. And fails, of course.
>
> I guess that we can make `org-babel-get-colnames' smarter and make it
> skip the leading hlines.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...))

[Ihor Radchenko]

Bruno Barbier  writes:

>> I now think that overlays are the right way; the /pending content/ is
>> attached to one buffer: a base or a clone; this is for the user to
>> decide.
>>
>> I will manually add text properties, below the overlay, to mark the text
>> as /pending/, so that pending contents will be visible and read-only in
>> all other buffers, base or indirect ones.

Thanks!
I have some minor concerns about implementation, but you clearly
demonstrated the things can be working in general.

Let me now zoom out all the way down to org-pending library design.

While reading the library header and `org-pending' docstring (btw, it
should probably be a separate library, not a part of org-macs), I felt
confused about terminology and also had déjà vu's about what org-pending
does.

More or less, org-pending implements Elisp asynchronous process control,
but the processes are associated with region, not the whole buffer.
Hence, I feel that we should adopt terminology similar to the existing
terminology for processes - process filters, process sentinels, sending
signals to processes, etc. And similar API.

Also, I am not sure if I like the idea of exposing raw PINFO alist and
mutating it. In particular, I have doubts about mutating CONTENT.
What we might do instead is implement PINFO as struct with custom
accessors/setters.

WDYT?

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

Re: false positives: Re: Experimental public branch for inline special blocks

[Juan Manuel Macías]

Juan Manuel Macías writes:

> Ihor Radchenko  escribió:
>
>> I am wondering if @@[...]{...} would be better than @_...
>> It should be slightly easier to type.
>
> Another possibility would be @:[...]{...}, which is somewhat shorter.
>
> (I don't have any special preference, although @@ visually reminds me a
> bit of the export snippet).

Anyway, in the last commit I replaced _ with @. Let's see how it goes...
Now the anonymous variant is @@[...]{...}.

Re: Things got very slow: profiler output

[Bruno Barbier]

William Denton  writes:

> On Thursday, February 29th, 2024 at 04:25, Bruno Barbier 
>  wrote:
>
[...]
> I checked:
>
> |  Its value is (latex)
> |  Original value was nil
>
> I didn't have a chance to dig back into this but now I see other people are 
> reporting slowness and I hope this helps.
>
[...]

Is it slow too when using the default config (emacs -Q and no customization)
(see https://orgmode.org/org.html#Feedback) ?


Bruno


> I'm happy to try anything else ...
>
> Bill
>
> --
> William Denton
> https://www.miskatonic.org/
> Librarian, artist and licensed private investigator.
> Toronto, Canada

Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...))

[Bruno Barbier]

Hi,

Bruno Barbier  writes:

> Ihor Radchenko  writes:
>
>> Bruno Barbier  writes:
>>
 Overlays are not transferred when a new indirect buffer is created (for
 example, by org-capture, or by user). So, it will be (1) impossible to
 see pending overlays in indirect buffers; (2) user edits of pending text
 from indirect buffer will not be prevented.
>>>
[...]
> I now think that overlays are the right way; the /pending content/ is
> attached to one buffer: a base or a clone; this is for the user to
> decide.
>
> I will manually add text properties, below the overlay, to mark the text
> as /pending/, so that pending contents will be visible and read-only in
> all other buffers, base or indirect ones.
>
> Cloning buffers is easy to test. I'm not sure which scenario I should
> use to test org-capture though.
>
> I'll update my branch with that improvement soon.
>
>
> Thanks Ihor!
>
> Bruno



Hi,

After some work, some bug fixes and a few segfaults (using indirect
buffers, see bug#69529), I pushed a new version.  The main changes are:

• Handle indirect buffers: the pending content belongs to the buffer
  that started it (using text properties to mirror overlays).
• Use the fringe to indicate success or failure.
• Describe the pending content (past) when the user clicks it
  (pending, success or failure, time, duration, log, etc.).
• Improve the logging API and provide examples (may be used to collect
  stderr for example).

As before, the org file describes how to test it, see the file
[scratch/bba-pending-contents/my-async-tests.org] (direct link below).

Comments, critiques, ideas, corrections are most welcome.

Thanks,

Bruno


[scratch/bba-pending-contents/my-async-tests.org]

Re: false positives: Re: Experimental public branch for inline special blocks

[Juan Manuel Macías]

Ihor Radchenko  escribió:

> I am wondering if @@[...]{...} would be better than @_...
> It should be slightly easier to type.

Another possibility would be @:[...]{...}, which is somewhat shorter.

(I don't have any special preference, although @@ visually reminds me a
bit of the export snippet).

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

Re: Emacs slow-down

[William Denton]

On Thursday, March 7th, 2024 at 11:03, Pedro Andres Aranda Gutierrez 
 wrote:

> Interestingly enough, this redisplay_internal function seems to be the real 
> pain. I think we need to switch to the main
> emacs devel list here...

I wonder if those of us seeing this have something in common about our 
configurations.  Might it be a package that's getting in the way, and a change 
there is causing this?  Or does the profiling show it's in base Org?


Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada

Re: Things got very slow: profiler output

[William Denton]

On Thursday, February 29th, 2024 at 04:25, Bruno Barbier  
wrote:

> Oops, sorry, the customization option is:
> 
> org-highlight-latex-and-related
> 
> (the other value is computed by Org)
> 
> You may try to change that option org-highlight-latex-and-related to see
> if it helps.

I checked:

|  Its value is (latex)
|  Original value was nil

I didn't have a chance to dig back into this but now I see other people are 
reporting slowness and I hope this helps.

I recompiled Emacs and Org last night and closed all my buffers except for two 
medium-sized ones, neither with any LaTeX in them.  I restarted and spent a 
minute or two with one buffer, closing and expanding headings, and just moving 
around without typing, and it quickly slowed down.  When I did do a bit of 
typing it was very laggy (and will only get worse). The profiler said this:

   44032  66% - redisplay_internal (C function)
   42619  63%  - jit-lock-function
   42603  63%   - jit-lock-fontify-now
   42551  63%- jit-lock--run-functions
   42547  63% - run-hook-wrapped
   42543  63%  - #
   42535  63%   - font-lock-fontify-region
   42531  63%- font-lock-default-fontify-region
   41987  62% - font-lock-fontify-keywords-region
   40255  60%  - org-do-latex-and-related
   40243  60% re-search-forward
  12   0% org-string-nw-p
1224   1%  + org-activate-folds
 156   0%re-search-forward
 ...   

I'm happy to try anything else ...

Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada

Re: Emacs slow-down

[Pedro Andres Aranda Gutierrez]

Hi,

my profiling when deleting a line from a table:

 650  43% + redisplay_internal (C function)
 521  35% - command-execute
 470  31%  - byte-code
 470  31%   - read-extended-command
 470  31%- read-extended-command-1
 470  31% - completing-read-default
 443  29%  + redisplay_internal (C function)
  11   0%  - timer-event-handler
  11   0%   - apply
   7   0%+ jinx--timer-handler
   4   0%+ org-element--cache-sync
  51   3%  - funcall-interactively
  34   2%   + org-kill-line
  17   1%   + next-line
 200  13%   Automatic GC
  57   3% + ...
  57   3% + timer-event-handler

Interestingly enough, this redisplay_internal function seems to be the real
pain. I think we need to switch to the main
emacs devel list here...

Best, /PA

On Thu, 7 Mar 2024 at 16:50, Pedro Andres Aranda Gutierrez <
paag...@gmail.com> wrote:

> Hi Ihor,
>
> same here and changing to text-properties didn't help making editing org
> files less bumpy and slow.
> I don't know if 886 lines is really very much... but that's my org-beamer
> size for a double lecture.
>
> Best, /PA
>
> On Thu, 7 Mar 2024 at 15:58, Bruno Cardoso  wrote:
>
>>
>> On 2024-03-07, 13:23 +, Ihor Radchenko  wrote:
>>
>> > This is strange. `org-fold-core--property-symbol-get-create' should be
>> > very fast normally.
>> >
>> > A blind guess: do you have `org-fold-core-style' set to
>> 'text-properties?
>> >
>>
>> Hi Ihor,
>>
>> No, `org-fold-core-style' is set to 'overlays.
>>
>>
>
> --
> Fragen sind nicht da, um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
> a leader-deposed hook here, but we can't yet
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: Emacs slow-down

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

>  443  29%  + redisplay_internal (C function)
> ...
> Interestingly enough, this redisplay_internal function seems to be the real
> pain. I think we need to switch to the main
> emacs devel list here...

Unlikely. Note the +. redisplay_internal can (and does) call Elisp code.
In particular fontification.

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

Re: false positives: Re: Experimental public branch for inline special blocks

[Ihor Radchenko]

Juan Manuel Macías  writes:

> I have modified the syntax in the last commit. Now:
>
> @type[...]{...} (or @_[...]{...})

I am wondering if @@[...]{...} would be better than @_...
It should be slightly easier to type.

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

Re: Emacs slow-down

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> same here and changing to text-properties didn't help making editing org
> files less bumpy and slow.
> I don't know if 886 lines is really very much... but that's my org-beamer
> size for a double lecture.

Any chance you can provide a reproducer starting from make repro?

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

Re: false positives: Re: Experimental public branch for inline special blocks

[Juan Manuel Macías]

Ihor Radchenko writes:

> I suggest @type[...]{...}. Akin Texinfo constructs.
>
> (Texinfo because of
> previous RMS' request to implement better support for markup used in
> software manuals - keeping things close to Texinfo syntax will make life
> easier if we ever reach the point when Org mode is used as standard
> documentation format.) 

I have modified the syntax in the last commit. Now:

@type[...]{...} (or @_[...]{...})

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

Re: Emacs slow-down

[Pedro Andres Aranda Gutierrez]

Hi Ihor,

same here and changing to text-properties didn't help making editing org
files less bumpy and slow.
I don't know if 886 lines is really very much... but that's my org-beamer
size for a double lecture.

Best, /PA

On Thu, 7 Mar 2024 at 15:58, Bruno Cardoso  wrote:

>
> On 2024-03-07, 13:23 +, Ihor Radchenko  wrote:
>
> > This is strange. `org-fold-core--property-symbol-get-create' should be
> > very fast normally.
> >
> > A blind guess: do you have `org-fold-core-style' set to 'text-properties?
> >
>
> Hi Ihor,
>
> No, `org-fold-core-style' is set to 'overlays.
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: noweb-start and noweb-end header args

[Amy Grinn]

Ihor Radchenko  writes:

> Amy Grinn  writes:
>
>> Here is a simple way to implement this feature.
>
> Since you are adding a new feature, it should have (1) test coverage;
> (2) be documented in the manual; (3) be announced in etc/ORG-NEWS.

Thank you for the tips, will do!

Re: Emacs slow-down

[Bruno Cardoso]

On 2024-03-07, 13:23 +, Ihor Radchenko  wrote:

> This is strange. `org-fold-core--property-symbol-get-create' should be
> very fast normally.
>
> A blind guess: do you have `org-fold-core-style' set to 'text-properties?
>

Hi Ihor,

No, `org-fold-core-style' is set to 'overlays.

Re: naming: Re: Experimental public branch for inline special blocks

[Ihor Radchenko]

Max Nikulin  writes:

>> IMHO, the whole point of the discussed construct is exactly being abstract
>> and multi-purpose.
>
> Almost everything in Org syntax may be called "markup", so using this 
> word for a specific object may lead to confusion unless a couple of 
> extra words are added to make it clear what kind of markup is referred to.

Yup. "inline custom markup". I feel that it's enough. Do I miss something?

> I had an idea to name new object "markup macro" since its role is close 
> to existing macro ("substitution macro"), but I discarded it because 
> "markup" is too general.

I do not find "too general" as a big problem.
I am not sure if I like macro. "macro" feels like something replaced
literally, without extra processing. But the proposed object has little
to do with literal replacement.

>>> Decorators sometimes stressed as "inline decorators"?
>> 
>> I dislike "decorators" because it is not a term we use anywhere in Org
>> mode. I'd prefer to reuse an existing term, if at all possible.
>
> I had a hope to find a unique word that will be convenient for usage in 
> discussions, a term that will be uniformly used in the manual and in the 
> syntax specification.

Manual was one of the reasons I chose "markup". Because this word is
used in "Markup for Rich Contents" section of the manual. Further, we
refer to "markup" when talking about emphasis/monospace in "12.2
Emphasis and Monospace" section.

> If others are happy to name "block" instances that are neither solid nor 
> shaped as blocks then I see no point to continue this discussion.

I am slightly in favor of "markup" vs. "block".

> P.S. I am neutral in respect to "span".

I do not like this for the same reason as "decorators" - unfamiliar
terminology.

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

Re: Just thinking...

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> duplicating export entries for LaTeX and Beamer makes the interface not
> exactly clean.
> We do have the LaTeX class, which should be "beamer" (I hope) for Beamer
> presentations, right?
>
> So why not use that to decide internally between (org-latex-export-...) and
> (org-beamer-...) and then have a unified interaction with the user?

I am afraid that implementing this would be a kludge. For technical
reasons.

For example, Org export parses keywords depending on the selected export
backend. Selected in advance.

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

Re: noweb-start and noweb-end header args

[Ihor Radchenko]

Amy Grinn  writes:

> I kinda disagree with your reasoning but I agree with your conclusion.
> I think it would be strange for third party or user configuration to
> parse the value of a noweb header argument directly.  Org provides a
> lublic api for this which should be backwards compatible:
>
>   (org-babel-noweb-p (nth 2 (org-babel-get-src-block-info t)) :tangle)

Yeah, but this API is not uniform. Most other header arguments must be
retrieved using `assq'. So, it is very common to use `assq' for
everything, even if there is a specific API.
(Ideally, we need to implement a uniform API to retrieve header argument
values)

> The middle way is to create just one new header arg:
>
> :noweb-wrap  [end]

Maybe  should be mandatory. Otherwise, LGTM.


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

Re: noweb-start and noweb-end header args

[Amy Grinn]

Ihor Radchenko  writes:

> :noweb yes <<< >>> is actually backwards-incompatible. Consider
> third-party code that makes assumptions about possible values of
> :noweb
> header argument. If third-party code does a check like
> (equal noweb-value "yes"), the new syntax can break such code.

I kinda disagree with your reasoning but I agree with your conclusion.
I think it would be strange for third party or user configuration to
parse the value of a noweb header argument directly.  Org provides a
lublic api for this which should be backwards compatible:

  (org-babel-noweb-p (nth 2 (org-babel-get-src-block-info t)) :tangle)

However, other parsers besides Emacs exist for Org mode and they may
directly compare the entire noweb argument.

The middle way is to create just one new header arg:

:noweb-wrap  [end]

Re: cannot export asynchronously because of org-fold-core--update-buffer-folds

[Alan Schmitt]

On 2024-03-07 12:35, Ihor Radchenko  writes:

> Alan Schmitt  writes:
>
>> I’m trying to export a file asynchronously to beamer/pdf, and I have a
>> strange error. Here is the contents of the *Org Export Process* buffer:
>>
>> Debugger entered--Lisp error: (void-function 
>> org-fold-core--update-buffer-folds)
>> ...
>> To make sure I have a reproducible export, I set
>> org-export-async-init-file to a file with the following contents:
>> ...
>> (require 'ox-latex)
>> ...
>> I assume the problem is that there is a version mismatch between the org
>
> Yes, looks like it. If you are using custom
> `org-export-async-init-file', you need to make sure that Org mode
> available to that init file has the same version as the Org mode that
> initiates export process. Basically, you need to set the right
> load-path.

Thank you, I can confirm that this fixes it.

>> I’m using to start the export and the org in the async process, but I do
>> not understand how they would interact. In particular, I don’t
>> understand why there is a mention of byte-compiled code in the error
>> trace.
>
> byte-compiled code is a function passed by Org mode to the async Emacs.
> That function takes care about re-creating the right Elisp environment
> inside the async process.

Ah, ok, I understand better now. Thanks again!

Alan


signature.asc
Description: PGP signature

Re: noweb-start and noweb-end header args

[Ihor Radchenko]

Amy Grinn  writes:

> Here is a simple way to implement this feature.
> ...
> -(defun org-babel-noweb-wrap ( regexp)
> +(defun org-babel-noweb-wrap ( regexp info)
>"Return regexp matching a Noweb reference.
>  
>  Match any reference, or only those matching REGEXP, if non-nil.
>  
>  When matching, reference is stored in match group 1."

INFO argument needs to be documented.

> -  (org-babel-noweb-wrap)
> +  (org-babel-noweb-wrap nil info)

Please, also update all other cases when `org-babel-noweb-wrap' is
called.

Also, `org-babel-goto-named-src-block' uses
org-babel-noweb-wrap-start/end directly. It should be adjusted.

Since you are adding a new feature, it should have (1) test coverage;
(2) be documented in the manual; (3) be announced in etc/ORG-NEWS.

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

Re: noweb-start and noweb-end header args

[Ihor Radchenko]

Amy Grinn  writes:

> To expand on this, some major modes can fundamentally conflict with the
> default noweb syntax.  Here is a valid shell script *and* a valid noweb
> reference to a block named EOF:
>
> cat <> file.txt
> Hello
> EOF
>
> I hope this helps explain why the wrap-start and wrap-end options were
> necessary to include more than a decade ago.  In terms of actually using
> them, it's a bit cumbersome, especially in Org mode buffers that use
> multiple languages.

This makes sense.
I agree that setting noweb reference syntax per-language is useful in
some cases.

> The second diff I sent (under the termux handle, accidentally) is my
> preferred solution (:noweb yes <<< >>>).  This would avoid the need for
> new header arguments to be introduced while maintaining backwards
> compatibility.  It also feels natural to specify the two options
> together: I can't think of a good reason to only need to specify the
> wrap-end option.

:noweb yes <<< >>> is actually backwards-incompatible. Consider
third-party code that makes assumptions about possible values of :noweb
header argument. If third-party code does a check like
(equal noweb-value "yes"), the new syntax can break such code.

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

Re: noweb-start and noweb-end header args

[Ihor Radchenko]

Amy Grinn  writes:

>> Org mode does not _currently_ modify the code. But that's actually wrong
>> - things like escaped ,* or indentation sometimes also stay on the way
>> and produce incorrect fontification. So, rewriting the fontification of
>> src blocks to cleanup the code before fontification is long due.
>> noweb references is just another manifestation of this problem.
>
> I think we're talking past each other a little.  I'm not talking about
> changing the text content of a src block, I'm talking about modifying
> the syntax table of a major mode such as sh-mode to ignore or handle
> <> syntax in an "edit-special" buffer.  That was my
> interpretation of your suggestion of using fontification to solve this
> issue.  And if that's the case, I foresee a lot of edge cases for
> modifying the display of major modes.

That's not what I had in mind. I thought of resolving/replacing noweb
references before fontifying the code. That way, the major mode for src
block will simply not see <> text and will not be confused.

>> I am not in favor of adding features that aim to serve as workarounds to
>> Org mode.
>
> This discussion is not about whether to allow users to modify noweb
> syntax.  That feature is already a part of Org, well documented, and
> utilized.  The feature request I'm making is to allow that modification
> to be done on a per-block level.

Sure, but I wanted to hear why such feature is useful in practice. Your
example with fontification is not something I consider as a good
justification for adding a new feature. You another email provides a
better justification though.

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

Re: Provide sane default for the @direntry

[Ihor Radchenko]

Stefan Monnier  writes:

>> The patches are against Emacs git repository, not against Org mode. May
>> your please port them?
>
> See attached.

Thanks!
Unfortunately, the patch causes some tests (make test) to fail.
Looks like export to temporary buffer is broken (temporary buffer does
not have a filename):

2 unexpected results:
   FAILED  test-ox-texinfo/end-to-end-inline  stringp
   FAILED  test-ox-texinfo/end-to-end-sanity-check-displayed  stringp

> Subject: [PATCH 1/2] lisp/ox-texinfo.el: Remove redundant `:group`s
>
>'("aux" "toc" "cp" "fn" "ky" "pg" "tp" "vr")
>"The list of file extensions to consider as Texinfo logfiles.
>  The logfiles will be remove if `org-texinfo-remove-logfiles' is
> +
>  non-nil."

^^ stray newline.

> --- a/etc/ORG-NEWS
> +++ b/etc/ORG-NEWS
> @@ -1727,6 +1727,13 @@ following properties: ~:hook~, ~:prepare-finalize~,
>  ~:before-finalize~, ~:after-finalize~.  These nullary functions run
>  prior to their global counterparts for the selected template.
>  
> +*** ox-texinfo always generates a ~@direntry~
> +We use defaults based on the file name and title of the document, and
> +place the entry in the ~Misc~ category if ~TEXINFO_DIR_CATEGORY~ is missing.
> +
> +=TEXINFO_DIR_TITLE= is renamed to =TEXINFO_DIR_NAME=.
> +The old name is obsolete.

This is under Org 9.6 header, while should be under Org 9.7 (not yet released).

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

Re: Emacs slow-down

[Ihor Radchenko]

Bruno Cardoso  writes:

> I also did noticed some slow-down in the most recent org. This is the CPU 
> profiler report after typing some words in an org-file I'm working on:
>
> ...
> 2122  23%  - org-fold-core-get-folding-spec
> 2035  22% org-fold-core--property-symbol-get-create

This is strange. `org-fold-core--property-symbol-get-create' should be
very fast normally.

A blind guess: do you have `org-fold-core-style' set to 'text-properties?

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

Re: [BUG] With R using ":var d=data" breaks ":colnames yes" [9.7-pre (release_9.6.10-881-g595a32]

[Ihor Radchenko]

Paul Stansell  writes:

> It seems that using ":var d=data" breaks ":colnames yes" in the header of
> an R code block.
> ...
> #+name: data
> |+|
> |  x |  y |
> |+|
> | 111.89 |  88.37 |
> | 392.12 | 297.33 |
> |+|

It is expected.
:colnames yes implies:

 The ‘colnames’ header argument accepts ‘yes’, ‘no’, or ‘nil’
 values.  The default value is ‘nil’: if an input table has column
 names--because the second row is a horizontal rule--then Org
 removes the column names, processes the table, puts back the column
 names, and then writes the table to the results block.  Using
 ‘yes’, Org does the same to the first row, even if the initial
 ^
 table does not contain any horizontal rule.  When set to ‘no’, Org
 does not pre-process column names at all.

In your table, the first row is a horizontal line, so Org tries to parse
the first line as column names. And fails, of course.

I guess that we can make `org-babel-get-colnames' smarter and make it
skip the leading hlines.

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

Re: Bug: file names capitalised when using gnuplot [9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/)]

[Ihor Radchenko]

Paul Stansell  writes:

> A bug occurs when plotting data from an Org table using Gnuplot.  An
> example is given below.  In the first code block the plot is produced as
> expected, but in the second code block (where I have changed a lowercase
> "c" to an uppercase "C") gnuplot tries to plot data from a
> non-existent file name that consists of all uppercase letters.
> ...
> This code block does not work.  It tries to read the data from
> "/TMP/BABEL-STABLE-462/GNUPLOT-2096937058546578295", which does not
> exist.
> #+begin_src gnuplot :var C=data :results silent

Thanks for reporting!
Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=01a0f15b6

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

Re: cannot export asynchronously because of org-fold-core--update-buffer-folds

[Ihor Radchenko]

Alan Schmitt  writes:

> I’m trying to export a file asynchronously to beamer/pdf, and I have a
> strange error. Here is the contents of the *Org Export Process* buffer:
>
> Debugger entered--Lisp error: (void-function 
> org-fold-core--update-buffer-folds)
> ...
> To make sure I have a reproducible export, I set
> org-export-async-init-file to a file with the following contents:
> ...
> (require 'ox-latex)
> ...
> I assume the problem is that there is a version mismatch between the org

Yes, looks like it. If you are using custom
`org-export-async-init-file', you need to make sure that Org mode
available to that init file has the same version as the Org mode that
initiates export process. Basically, you need to set the right load-path.

> I’m using to start the export and the org in the async process, but I do
> not understand how they would interact. In particular, I don’t
> understand why there is a mention of byte-compiled code in the error
> trace.

byte-compiled code is a function passed by Org mode to the async Emacs.
That function takes care about re-creating the right Elisp environment
inside the async process.

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

[BUG] obscure error for invalid :exports

[Max Nikulin]

Hi,

Trying to export (to HTML buffer)

src_elisp[:exports source]{a}

I have got an obscure error

org-export-as: Wrong type argument: char-or-string-p, nil

I believe, some meaningful error should be signaled.

I was quite surprised since the following is exported with no error

#+begin_src elisp :exports source
  a
#+end_src

So source blocks are more liberal in respect to user errors.

`org-lint' warns

 2 low   Unknown value "source" for header ":exports"

Reproducible with Org main HEAD and 9.5.5

Of course, it should be

src_elisp[:exports code]{a}

but I was going to test org-element parser on a more tricky input and by 
mistake typed wrong keyword. It took some time to figure that it is not 
a parser error.

Re: false positives: Re: Experimental public branch for inline special blocks

[Juan Manuel Macías]

Ihor Radchenko writes:

> Juan Manuel Macías  writes:
>
>>>   (org-export-string-as "Alpha{"
>> ...
>> mmm, right. And there may also be a problem with the subscripts: 
>> &_{subscript}...
>>
>> Perhaps we should think about a structure less prone to ambiguities. For
>> example:
>>
>> &:type[attrs]{text} / &:_[attrs]{text}
>
> I suggest @type[...]{...}. Akin Texinfo constructs.
>
> (Texinfo because of
> previous RMS' request to implement better support for markup used in
> software manuals - keeping things close to Texinfo syntax will make life
> easier if we ever reach the point when Org mode is used as standard
> documentation format.) 

+1

(one character is always better than two)

Re: false positives: Re: Experimental public branch for inline special blocks

[Ihor Radchenko]

Juan Manuel Macías  writes:

>>   (org-export-string-as "Alpha{"
> ...
> mmm, right. And there may also be a problem with the subscripts: 
> &_{subscript}...
>
> Perhaps we should think about a structure less prone to ambiguities. For
> example:
>
> &:type[attrs]{text} / &:_[attrs]{text}

I suggest @type[...]{...}. Akin Texinfo constructs.

(Texinfo because of
previous RMS' request to implement better support for markup used in
software manuals - keeping things close to Texinfo syntax will make life
easier if we ever reach the point when Org mode is used as standard
documentation format.) 

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

Re: false positives: Re: Experimental public branch for inline special blocks

[Juan Manuel Macías]

Max Nikulin writes:

> It seems the parser finds new objects where syntactical constructs are
> incomplete:
>
>   (org-export-string-as "Alpha{"
> 'html
> '(:export-options (body-only)))
>   "\nAlpha{\n"

mmm, right. And there may also be a problem with the subscripts: 
&_{subscript}...

Perhaps we should think about a structure less prone to ambiguities. For
example:

&:type[attrs]{text} / &:_[attrs]{text}

(I think someone had suggested something like this in a past message,
but I can't find it, apologies).

-- 
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño 
editorial y ortotipografía

false positives: Re: Experimental public branch for inline special blocks

[Max Nikulin]

On 02/03/2024 03:34, Juan Manuel Macías wrote:


Finally, I have made public on GitLab my experimental branch for the new
(possible) inline-special-block element:




It seems the parser finds new objects where syntactical constructs are 
incomplete:


  (org-export-string-as "Alpha{"
  'html
  '(:export-options (body-only)))
  "\nAlpha{\n"

My expectation is

  "\nAlphaBeta{\n"

Even worse

  (org-export-string-as "Alpha["
  'html
  '(:export-options (body-only)))

   Debugger entered--Lisp error: (wrong-type-argument 
number-or-marker-p nil)


I think, this particular case deserves a unit test despite it is too 
early for extensive test suite.

Re: Subject: cannot export asynchronously because of org-fold-core--update-buffer-folds

[Pedro Andres Aranda Gutierrez]

Will try with my setup @home with the main branch of the git to check again.
 /PA
Enviado desde mi iPhone

> El 7 mar 2024, a las 10:42, Alan Schmitt  
> escribió:
> 
> Hi Pedro,
> 
> On 2024-03-07 10:03, Pedro Andres Aranda Gutierrez  writes:
> 
>> could you please try to add
>> 
>> #+LATEX_CLASS: beamer
>> #+LATEX_CLASS_OPTIONS: [presentation,aspectratio=169]
>> 
>> instead of
>> 
>> (require 'ox-latex)
>> 
>> (add-to-list 'org-latex-classes
>> '("my-beamer"
>>   "\\documentclass\[presentation,aspectratio=169\]\{beamer\}
>> [NO-DEFAULT-PACKAGES]"
>>   ("\\section\{%s\}" . "\\section*\{%s\}")
>>   ("\\subsection\{%s\}" . "\\subsection*\{%s\}")
>>   ("\\subsubsection\{%s\}" . "\\subsubsection*\{%s\}")))
>> 
>> and see if that makes any difference?
> 
> Thank you for the suggestion. I tried this and it does not help, I have
> the same error. I do not know how to debug it since the error happens in
> compiled code whose origin is not given…
> 
> The surprising part is that the problematic function was introduced very
> recently
> (https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=87c9f9b5db2e14fe0c5254105b7b90b01bbf8d61)
> but it seems to be used in the asynchronous export that does not load
> any package, so there I should be using the orgmode version shipped with
> emacs…
> 
> Alan

Re: naming: Re: Experimental public branch for inline special blocks

[Max Nikulin]

On 06/03/2024 17:56, Ihor Radchenko wrote:

Max Nikulin writes:


Custom inline markup.


"Markup" is something abstract to my taste. I would prefer something
related to concrete instances of such objects.


IMHO, the whole point of the discussed construct is exactly being abstract
and multi-purpose.


Almost everything in Org syntax may be called "markup", so using this 
word for a specific object may lead to confusion unless a couple of 
extra words are added to make it clear what kind of markup is referred to.


I had an idea to name new object "markup macro" since its role is close 
to existing macro ("substitution macro"), but I discarded it because 
"markup" is too general.



Decorators sometimes stressed as "inline decorators"?


I dislike "decorators" because it is not a term we use anywhere in Org
mode. I'd prefer to reuse an existing term, if at all possible.


I had a hope to find a unique word that will be convenient for usage in 
discussions, a term that will be uniformly used in the manual and in the 
syntax specification.


If others are happy to name "block" instances that are neither solid nor 
shaped as blocks then I see no point to continue this discussion.


P.S. I am neutral in respect to "span".

Re: Emacs slow-down

[Bruno Cardoso]

Hello,

I also did noticed some slow-down in the most recent org. This is the CPU 
profiler report after typing some words in an org-file I'm working on:

6493  71% - redisplay_internal (C function)
6372  70%  - jit-lock-function
6323  69%   - jit-lock-fontify-now
6257  68%- jit-lock--run-functions
6257  68% - #
6246  68%  - font-lock-fontify-region
6191  68%   - font-lock-default-fontify-region
3300  36%- font-lock-fontify-keywords-region
2448  26% - org-activate-folds
2122  23%  - org-fold-core-get-folding-spec
2035  22% org-fold-core--property-symbol-get-create
 217   2%  + org-fold-previous-visibility-change
 178   1% - org-activate-links
 178   1%  - org-activate-links--overlays
   3   0%   - org-element-link-parser
   3   0%  org-link-expand-abbrev

Best,

Bruno.


On 2024-03-07, 08:23 +0100, Pedro Andres Aranda Gutierrez  
wrote:

> Hi
>
> is it just me, or have other people also noticed hiccups when editing org
> files with org-mode (main from savannah). The moment I revert to the
> org-mode shipped with emacs master, editing returns to normal (and fluid).
>
> Would it make sense to take a closer look at this?
>
> Best, /PA
> --
> Fragen sind nicht da, um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
> a leader-deposed hook here, but we can't yet

Just thinking...

[Pedro Andres Aranda Gutierrez]

Hi,

duplicating export entries for LaTeX and Beamer makes the interface not
exactly clean.
We do have the LaTeX class, which should be "beamer" (I hope) for Beamer
presentations, right?

So why not use that to decide internally between (org-latex-export-...) and
(org-beamer-...) and then have a unified interaction with the user?

Best, /PA

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

Re: Subject: cannot export asynchronously because of org-fold-core--update-buffer-folds

[Alan Schmitt]

Hi Pedro,

On 2024-03-07 10:03, Pedro Andres Aranda Gutierrez  writes:

> could you please try to add
>
> #+LATEX_CLASS: beamer
> #+LATEX_CLASS_OPTIONS: [presentation,aspectratio=169]
>
> instead of
>
> (require 'ox-latex)
>
> (add-to-list 'org-latex-classes
>  '("my-beamer"
>"\\documentclass\[presentation,aspectratio=169\]\{beamer\}
> [NO-DEFAULT-PACKAGES]"
>("\\section\{%s\}" . "\\section*\{%s\}")
>("\\subsection\{%s\}" . "\\subsection*\{%s\}")
>("\\subsubsection\{%s\}" . "\\subsubsection*\{%s\}")))
>
> and see if that makes any difference?

Thank you for the suggestion. I tried this and it does not help, I have
the same error. I do not know how to debug it since the error happens in
compiled code whose origin is not given…

The surprising part is that the problematic function was introduced very
recently
(https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=87c9f9b5db2e14fe0c5254105b7b90b01bbf8d61)
but it seems to be used in the asynchronous export that does not load
any package, so there I should be using the orgmode version shipped with
emacs…

Alan


signature.asc
Description: PGP signature

Re: Subject: cannot export asynchronously because of org-fold-core--update-buffer-folds

[Pedro Andres Aranda Gutierrez]

Hi,

could you please try to add

#+LATEX_CLASS: beamer
#+LATEX_CLASS_OPTIONS: [presentation,aspectratio=169]

instead of

(require 'ox-latex)

(add-to-list 'org-latex-classes
 '("my-beamer"
   "\\documentclass\[presentation,aspectratio=169\]\{beamer\}
[NO-DEFAULT-PACKAGES]"
   ("\\section\{%s\}" . "\\section*\{%s\}")
   ("\\subsection\{%s\}" . "\\subsection*\{%s\}")
   ("\\subsubsection\{%s\}" . "\\subsubsection*\{%s\}")))

and see if that makes any difference?

My .2cents, /PA
-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet