Re: [BUG] C-c C-* causes "org-element--cache: Unregistered buffer modifications detected."

[Ihor Radchenko]

Max Nikulin  writes:

> Unfortunately currently it fails in Emacs-26.3 event without "#+startup: 
> indent":
>
> Warning (org-element-cache): org-element--cache: Unregistered buffer 
> modifications detected. Resetting.
> If this warning appears regularly, please report it to Org mode mailing 
> list (M-x org-submit-bug-report).
> The buffer is: new.org
>   Current command: (nil 163 167)
>   Chars modified: 163
>   Buffer modified: 167
>   Backtrace:
> nil

I am unable to reproduce on my side also using Emacs 26.3. Are you sure
that you are running a clean Emacs?

Best,
Ihor

Re: [PATCH] Fix behavior of lambda default header arg vars

[Matt Huszagh]

Matt Huszagh  writes:

> Hey Timothy,
>
> Any thoughts on this bug fix?
>
> Thanks
> Matt

Apologies, meant to include the org-mode mailing list in this too.

Thanks
Matt

Re: Patch to align baseline of latex fragments and surrounding text

[Matt Huszagh]

Timothy, looping you in on this.

I feel that maybe it would be useful to attach screenshots to show the
improvement from this patch? Anyway, I've attached two images: one with
the correct baseline alignment to surrounding text and the other with
the current, incorrect, baseline alignment.

I think a lot of people would like this functionality. It looks much
better than the current behavior.

Anyway, feedback appreciated.

Re: ox-extra ignore-headlines mismatching/unexpected behavior

[Gabriel Petrini]

Em sex, 2020-09-04 às 19:40 +0200, Bastien escreveu:
> Hi Alexandre,
> 
> Alexandre Jesus  writes:
> 
> > I am getting some unexpected and/or mismatching (between pdf and html
> > exports) behavior with ox-extra ignore-headlines. The weird behaviors
> > I
> > am getting are:
> 
> thanks for reporting this.  I'm copying if he has time to have a look.
> 

I also have this issue in version 9.6. Are there any workaround?

I've tried the suggestions in
[[https://lists.gnu.org/archive/html/emacs-orgmode/2014-03/msg01458.html][here]
], but it is incompatible with heading properties.

gpetrini

Re: [PATCH] Fix regex for determining image width from attribute

[Matt Huszagh]

Timothy  writes:

> Thanks for your thoughtful deliberation on this.

No worries, and thanks for continuing to engage with it.

>> The other consideration is if we take the first point as a given (that
>> org should use width directives for other backends), should it also
>> attempt to interpret directives that are ambiguous? In this case, do we
>> interpret 1.2 as 1.2? If  could only be ,
>> I’d be inclined to agree that this is logical. I also understand the
>> case for , though this is slightly less clear. But, what if
>> someone used 1.2? Seems a bit unusual I know, but maybe
>> someone would want this. Again, I don’t think we should guess if there’s
>> a chance we could be wrong.
>
> I feel this very much depends on how bad “guessing wrong” is, and as 
> previously
> discussed, since it’s rather easy to correct or set `org-image-actual-width' 
> to
> prevent this, I’m not sure it warrants being terribly concerned about.

I think the problem here is that `org-image-actual-width` is essentially
a global solution to a potentially local problem. I can't set
`org-image-actual-width` to nil for just one image.

> Thanks for continuing with this. Moving forward, I think it would be best to:
> ⁃ Make a patch just for prioritising `#+attr_org'
> ⁃ Make a patch just improving the regex (before or after the `#+attr_org' 
> patch)
> ⁃ Discuss changing the behaviour of image previews separately later / in 
> another
>   thread, linking to this thread when doing so.
>
> How does that sound?

Yep, sounds good.

> Lastly, a comment on your documentation patch from earlier. I like the changes
> to `org-image-actual-width', however I think you’ve been over-eager with 
> scrapping
> the current docstring for `org-display-inline-image--width'. Since the 
> behaviour
> is implemented there, I think it should at a minimum be documented there.
> The docstring for a function referring to a variable’s documentation for how 
> it’s
> handled by the function seems a bit weird.

I was torn on this as well. However, I ended up feeling that it would be
worse to duplicate the same information in two places. This requires
updating the information in two places instead of one, and, worse, the
documentation could easily diverge. Because the function isn't
public-facing, but the variable very much is, I felt it better just to
include the documentation for the variable.

I also don't think removing the documentation from the function is that
bad. A lot of what that function does is to follow what the variable
tells it to do. Again, the function won't be called directly by an
end-user, so requiring that the developer refer to other documentation
for understanding implementation details seems reasonable. Finally,
there are numerous functions in org that tell you to refer to
documentation elsewhere (especially defcustoms) for further information.

Anyway, I still feel that the earlier patch (before regex changes is the
right one). But, if you want me to revert the documentation removal from
the function I will.

Matt

Re: Org-syntax: Intra-word markup

[Juan Manuel Macías]

Nicolas Goaziou writes:

> I'm suggesting to remove zero-width spaces contiguous to emphasis
> markers only. Therefore LaTeX process would npot see them. Other zero
> width spaces, e.g., inserted by user, are kept. AFAICT, the two last
> points you mention are not relevant with my proposal.
>
> Besides, they already part of the syntax, in some way. So that ship has
> sailed long ago.

I understand that it is too late to change certain things, but that is
not an impediment for me to continue to think that using the character
U+200B as a part (at least /de facto/) of the syntax is still shocking
and weird.

On the other hand, what was expected in Org would have been to have the
emphasis marks and at the same time have a universal escape character
for those emphasis marks. In the same way as I can write in markdown:
*foo* AND \*foo\*. In Org we have the emphasis marks but not the escape
character. That was probably the cause of many issues that are being
discussed here. But that means also entering the realm of assumptions.
Still, I wanted to leave an opinion on this question in particular.

Best regards,

Juan Manuel

Re: Org-syntax: Intra-word markup

[Nicolas Goaziou]

Hello,

Juan Manuel Macías  writes:

> I agree that zero width spaces work fine as a solution, but I think they
> should not be understood as part of the syntax but as a punctual
> (temporal?) remedy to certain scenarios. As mentioned before, in LaTeX
> zero width spaces can produce unexpected effects and modify the final
> form of the text (at least in luatex). I also don't know if it would be
> useful to remove all zero width spaces in the export process, because in
> some cases the user may want to keep them, as I think Maxim commented in
> a previous message.

We may be misunderstanding each other. 

I'm suggesting to remove zero-width spaces contiguous to emphasis
markers only. Therefore LaTeX process would npot see them. Other zero
width spaces, e.g., inserted by user, are kept. AFAICT, the two last
points you mention are not relevant with my proposal.

Besides, they already part of the syntax, in some way. So that ship has
sailed long ago.

Regards,
-- 
Nicolas Goaziou

Re: Org-syntax: Intra-word markup

[Samuel Wales]

a silly question.  don't we already use something kinda similar to
\emph{what}ever for all backends?  could we do so?

On 12/2/21, Denis Maier  wrote:
> Am 02.12.2021 um 19:11 schrieb Tom Gillespie:
>> I don't mean to be a wet blanket, but the edge cases for
>> the current markup syntax are already hard enough to
>> implement correctly, to the point where different parts of
>> Org mode are inconsistent. Intra-word markup isn't viable
>> because there simply isn't any sane way to parse something
>> like *hello world*/hrm/oh no*. The other issue is that this will
>> degrade parsing performance because almost every
>> character could precede the start of a markup section.
>>
>> I recommend anyone suggesting solutions try to implement
>> something that can parse the markup unambiguously with
>> lots of nasty test cases. You will likely find that it is impossible
>> to consistently tokenize markup, and that you have to hand
>> write a whole bunch of heuristics, making Org syntax even
>> harder to implement correctly.
>>
>> Any solution that suggests extending how =/*~+_  can be
>> used gets a hard no from me. I could see teaching other
>> exporters how to interpret \emph{hello}world, but trying for
>> to have any sane behavior for something like
>> why *hello*world oh no a wild askterisk*
>> is not worth it.
>
> As I've said before, I could well live with \emph{what}ever or something
> similar.
>
> Denis
>
>


-- 
The Kafka Pandemic

Please learn what misopathy is.
https://thekafkapandemic.blogspot.com/2013/10/why-some-diseases-are-wronged.html

Re: Org-syntax: Intra-word markup

[Denis Maier]

Am 02.12.2021 um 19:11 schrieb Tom Gillespie:

I don't mean to be a wet blanket, but the edge cases for
the current markup syntax are already hard enough to
implement correctly, to the point where different parts of
Org mode are inconsistent. Intra-word markup isn't viable
because there simply isn't any sane way to parse something
like *hello world*/hrm/oh no*. The other issue is that this will
degrade parsing performance because almost every
character could precede the start of a markup section.

I recommend anyone suggesting solutions try to implement
something that can parse the markup unambiguously with
lots of nasty test cases. You will likely find that it is impossible
to consistently tokenize markup, and that you have to hand
write a whole bunch of heuristics, making Org syntax even
harder to implement correctly.

Any solution that suggests extending how =/*~+_  can be
used gets a hard no from me. I could see teaching other
exporters how to interpret \emph{hello}world, but trying for
to have any sane behavior for something like
why *hello*world oh no a wild askterisk*
is not worth it.


As I've said before, I could well live with \emph{what}ever or something 
similar.


Denis

Re: Some commentary on the Org Syntax document

[Timothy]

Hi Tom,

Thanks for your comments, they've been most helpful.
I have some comments on your comments, and have also started drafting
some tweaks to the document in light of your initial comments, put as a
diff excerpt at the end of this email.

For starters, I have come more general comments. However, this has
turned out a bit longer than I intended. Unfortunately I am moments away
from heading to bed, so to quote Pascal "I have only made this letter
longer because I have not had the time to make it shorter".

I think a a big problem is the mix of implicit and explicit information.
Some components are rigorously specified in terms of the characters they
may contain, elements and objects that are recognised inside them, and
even the order in which different parts of the pattern are parsed.

As mentioned originally, the current Dynamic Blocks description doesn't
even mention the CONTENTS part of the pattern, and relies on the reader
inferring that it operates similarly to the CONTENTS part of Drawers.

Forcing the reader to start making inferences like this is a treacherous
path, and I think I can blame for some of the other issues I've
experienced. Take for instance the "surely X can't contain a newline?"
comments I've made. In the Node Properties and Entities descriptions you
have statements along the lines of "X can contain any character [...]
except a newline". In my mind this then sets up the reader to interpret
a similar statement without the "except a newline" clause to mean that
newlines are permitted.

I'm also thinking that the term "element" is overworked in the document.
It's basically pulling tripple duty: you have Elements, Greater
Elements, and elements which are Elements and/or Greater Elements .

The naming here is quite understandable, and I think we all know that
naming things well isn't easy, but I think it would behove us to try to
give each term a single unique meaning across the document --- or at
least try to come as close to that as reasonably possible.

I think we may be able to improve this by tweaking the hierarchy of
terms and then applying it rigorously throughout the document.

At the highest level, I think we want to encapsulate Headlines,
Sections, Greater Elements, Elements, and Objects. I suppose we might
call these the *components* of an Org document. Then we have the group
of Element and Greater Elements, which are useful to clump together.
Each component is usually given in terms of a number of forms or
patterns, which usually contain terms which are elucidated in the
description of that component.

So, the hierarchy appears to be something like.

1. (Headline / Section / Greater Element / Element / Object)
2. Headline
3. Section
4. Greater Element
5. (Greater Element / Element)
6. Element
7. Object
8. Pattern / Form
9. Term

We could say call (1) Components, (7) Units, (6) Objects, (5) Element or
Object (why not spell it out to avoid telling people to remember
something).

I could have put more thought into this, but it should do for
illustrating my line of thinking. Let me know if you have any good
ideas.

A separate improvement could be using more formatting to distinguish
when terms are used in a particular way.


Now for a few specific comments.

Tom Gillespie  writes:

>> As a general comment, in many places the Org Syntax document states what
>> characters a component can contain, but not what objects/elements. This feels
>> like a bit of a hole in the current specifications.
>
> This is indeed confusing because there are some implicit constraints
> that are not listed because they never come up.

I've sort of covered this before, but I think the document would benefit
from being more explicit in general.

> For example, you cannot have two newlines
> inside an inline footnote because the two newlines break the paragraph and the
> thing that appears to be an inline footnote is just plain text that is
> never terminated.

Specifically regarding newlines, perhaps we could add something like
this to the start of the Objects section?

"Furthermore, while many objects may contain newlines, an empty line
(i.e. a double newline) often terminates the element that the object is
a part of, such as a paragraph."

> Ensuring that font locking is in sync org-element and org-export is
> critical to ensure that users know what will actually happen.

On this, I'm cautiously optimistic about the discussion about using
org-element for fontification.

>> Heading
>> ───
>>
>> ⁃ Ok, so `TITLE' can have any character but a newline, but what Org 
>> components can it contain?
>>   I’m going to assume any object?
>
> Via org-element-object-restrictions it is standard-set-no-line-break which is
> all elements except citation-reference, table-cell, and line-break.

I must thank you and Ihor for pointing me to
org-element-object-restrictions! I wasn't aware of that till now, and
it's most helpful. Should all the information given by it be included in
the Syntax document? I lean 

Re: Org-syntax: Intra-word markup

[Juan Manuel Macías]

Hi Nicolas and all,

Nicolas Goaziou writes:

> I find zero-with spaces solution much more elegant. It also doesn't
> change current syntax, which is a big advantage.

I agree that zero width spaces work fine as a solution, but I think they
should not be understood as part of the syntax but as a punctual
(temporal?) remedy to certain scenarios. As mentioned before, in LaTeX
zero width spaces can produce unexpected effects and modify the final
form of the text (at least in luatex). I also don't know if it would be
useful to remove all zero width spaces in the export process, because in
some cases the user may want to keep them, as I think Maxim commented in
a previous message.

As for the solution of using complementary marks ("//...//", etc.), I
think it would undermine consistency, as those marks would only be to
fix exceptions.

It's a tricky subject...

Best regards,

Juan Manuel 

Re: Org-syntax: Intra-word markup

[Juan Manuel Macías]

Tom Gillespie writes:

> I don't mean to be a wet blanket, but the edge cases for
> the current markup syntax are already hard enough to
> implement correctly, to the point where different parts of
> Org mode are inconsistent. Intra-word markup isn't viable
> because there simply isn't any sane way to parse something
> like *hello world*/hrm/oh no*. The other issue is that this will
> degrade parsing performance because almost every
> character could precede the start of a markup section.
>
> I recommend anyone suggesting solutions try to implement
> something that can parse the markup unambiguously with
> lots of nasty test cases. You will likely find that it is impossible
> to consistently tokenize markup, and that you have to hand
> write a whole bunch of heuristics, making Org syntax even
> harder to implement correctly.
>
> Any solution that suggests extending how =/*~+_  can be
> used gets a hard no from me. I could see teaching other
> exporters how to interpret \emph{hello}world, but trying for
> to have any sane behavior for something like
> why *hello*world oh no a wild askterisk*
> is not worth it.

I believe, that emphasis marks are a part of Org that can be very
shocking to new users. I mean, there is a series of behaviors that seem
obvious and trivial in the emphasized text, but that in Org are not
possible out of the box, unless you configure
`org-emphasis-regexp-components'. Three quick examples. This in Org is
not possible out of the box:

#+begin_example
[/emphasis/]
¡/emphasis/!
¿/Emphasis/?
#+end_example

Nor is it possible ---out of the box--- to extend emphasis beyond a
certain number of lines. New users who come from other forms of markup
maybe expect the obvious to be something like:

some-text begin-emphasis whatever-is-in-between end-emphasis more-text

Over time one ends up seeing these things more as a feature than as a
bug :-) But those little inconsistencies make the Org syntax a bit ugly,
IMHO. I can't think of how to improve that, though.

Best regards,

Juan Manuel 

Re: Org-syntax: Intra-word markup

[Nicolas Goaziou]

Hello,

Ihor Radchenko  writes:

> Denis Maier  writes:
>
>> As for suggestions: If just using /intra/word creates ambiguities, what 
>> about the asciidoc solution? So //intra//word?
>
> I do like this idea.
>
> Though I would also like to hear Nicolas' opinion.

I sympathize to the idea of intra-word emphasis, but the syntax above is
going to cause some ambiguous situations.

I do think the marker + zero-width space is one way to go. We could, as
an improvement, consider zero-width spaces around emphasis markers to be
part of the markup, and replace them along during export.

Another solution is to introduce a less-subtle, but less prone to
ambiguity, syntax, e.g.,

  /{bold}/markup   or   /|bold|/markup

where /{ }/  or /|  |/ become "extended" markers.

I find zero-with spaces solution much more elegant. It also doesn't
change current syntax, which is a big advantage.

Regards,
-- 
Nicolas Goaziou

Re: Some commentary on the Org Syntax document

[Tom Gillespie]

Hi Timothy,
Replies in line. Best!
Tom

On Thu, Dec 2, 2021 at 1:32 AM Timothy  wrote:
>
> Hi All (& Nicolas in particular again),
>
> With my recent efforts to write a parser based on
> , I’ve developed a few thoughts 
> on
> that document. Hopefully, they can lead to some improvements and
> clarifications.
>
> 
>
> As a general comment, in many places the Org Syntax document states what
> characters a component can contain, but not what objects/elements. This feels
> like a bit of a hole in the current specifications.

This is indeed confusing because there are some implicit constraints
that are not
listed because they never come up. For example, you cannot have two newlines
inside an inline footnote because the two newlines break the paragraph and the
thing that appears to be an inline footnote is just plain text that is
never terminated.

Ensuring that font locking is in sync org-element and org-export is
critical to ensure
that users know what will actually happen.

>
>
> Sections
> 
>
> Heading
> ───
>
> ⁃ Ok, so `TITLE' can have any character but a newline, but what Org 
> components can it contain?
>   I’m going to assume any object?

Via org-element-object-restrictions it is standard-set-no-line-break which is
all elements except citation-reference, table-cell, and line-break.

>
>
> Affiliated Keywords
> ═══
>
>
> Greater Elements
> 
>
> Greater blocks
> ──
>
> ⁃ It is not explained what is ment by a “special block”
> ⁃ Aren’t lines starting with `#+' also quoted by a comma?
>
>
> Drawers and Property Drawers
> 
>
> ⁃ “Contents can contain any element but another drawer”
>   • Does “any element” mean “any Element or Greater Element”

Any element that does not have greater precedence, so that would
be only a heading.

>
> Dynamic Blocks
> ──
>
> ⁃ It is not specified what `CONTENTS' may be

Implicitly follows the same rules as drawers, no headings
and no nesting of dynamic blocks. Text should be added
that states this explicitly.

> ⁃ Surely `PARAMETERS' cannot contain a newline?

Termination by newline is implicit in the example, but the text is confusing.

> Plain Lists and Items
> ─
>
> ⁃ It is not completely clear what content an item may have.
>   I assume any Object?

By my reading it may contain anything, objects and elements,
except for a heading, but that is already implied by the de-indent.

To quote from the docs:

An item ends before the next item, the first line less or equally
indented than its starting line, or two consecutive empty lines.
Indentation of lines within other greater elements do not count,
neither do inlinetasks boundaries.

This makes plain lists one of the most complex elements to parse.

>
> Tables
> ──
>
> ⁃ Surely newlines are not allowed in `FORMULAS'

No newlines are implicit in the use of "lines" but still confusing.

>
> Elements
> 
>
> Clocks
> ──
>
> Two allowed forms are listed, but are all four of the below allowed or only 
> two?
> ┌
> │ CLOCK: INACTIVE-TIMESTAMP
> │ CLOCK: INACTIVE-TIMESTAMP DURATION
> │ CLOCK: INACTIVE-TIMESTAMP-RANGE
> │ CLOCK: INACTIVE-TIMESTAMP-RANGE DURATION
> └

No. Only the two are allowed. An inactive timestamp alone is a
starting point, adding a duration without the end point means
that there is no way to check that the range and duration match.

> All the best,
> Timothy

Re: Org-syntax: Intra-word markup

[Tom Gillespie]

I don't mean to be a wet blanket, but the edge cases for
the current markup syntax are already hard enough to
implement correctly, to the point where different parts of
Org mode are inconsistent. Intra-word markup isn't viable
because there simply isn't any sane way to parse something
like *hello world*/hrm/oh no*. The other issue is that this will
degrade parsing performance because almost every
character could precede the start of a markup section.

I recommend anyone suggesting solutions try to implement
something that can parse the markup unambiguously with
lots of nasty test cases. You will likely find that it is impossible
to consistently tokenize markup, and that you have to hand
write a whole bunch of heuristics, making Org syntax even
harder to implement correctly.

Any solution that suggests extending how =/*~+_  can be
used gets a hard no from me. I could see teaching other
exporters how to interpret \emph{hello}world, but trying for
to have any sane behavior for something like
why *hello*world oh no a wild askterisk*
is not worth it.

Best,
Tom

Re: citeproc-org and org-ref 3

[John Kitchin]

Glad to hear it is working again for you! Best wishes,

Joseph Vidal-Rosset  writes:

> Dear all,
>
>
> I just succeeded in solving my problem.
>
> l-210-235 of myblogexporter.el, I changed the code for:
>
> (defun org-export-head-export-headers (directory-name backend)
>"Exports each heading to directory-name using backend"
>(if (equal backend "html")
>(org-export-head--run-on-each-heading
> #'(lambda ()
> (org-set-property
>  "EXPORT_FILE_NAME"
>  (concat directory-name (org-export-head--escaped-headline)))
> (deactivate-mark)
> (let ((org-export-before-parsing-hook
> '(org-ref-csl-preprocess-buffer)))
>  (cl-letf (((symbol-function 'org-export-get-reference)
> (symbol-function 'org-export-get-reference-custom)))
>(if org-export-head-click-toc-h2
>(cl-letf ((
>   ;(symbol-function 'org-html-toc)
>   (symbol-function
> 'org-export-head--custom-toc)))
>  (org-html-export-to-html nil t)
> (set-buffer-modified-p t)) "-noexport-noreexport"))
>(if (equal backend "pdf")
>(org-export-head--run-on-each-heading
> #'(lambda ()
> (org-set-property
>  "EXPORT_FILE_NAME"
>  (concat directory-name (org-export-head--escaped-headline)))
> (deactivate-mark)
> (org-latex-export-to-pdf nil t)
> (set-buffer-modified-p t)) "-noexport-noreexport")))
>
> and it works with org-ref 3.
>
> Best wishes,  I attach myblogexporter.el
>
> Jo.
>
> Le 02/12/2021 à 14:17, Joseph Vidal-Rosset a écrit :
>> Dear John (cc. Ivan),
>>
>> First, thanks for your help and for your patience, that's very kind of you.
>>
>> The good news is that indeed, org-ref 3 exports nicely the  html
>> bibliography with my CSL file, it works well with your org file and your
>> bibliography. My error was simple: I did not use the specific org-ref
>> keys but the ordinary h-o keys.. A stupid mistake.
>>
>> The bad news is that this new function for exporting with org-ref 3 is
>> not included in org-export-head, a nice org mode to blog exporter, made
>> by Ivan Tadeu Ferreira Antunes Filho, which converts each header to a
>> different file, I find this exporter very convenient. I had no problem
>> with this org-ref 2 to use this blog-exporter, but it org-ref 3 is
>> unfortunately not still adapted to its use. Nevertheless, I believe that
>> it should be possible to find the lines to include this function
>> (let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
>>   (org-open-file  (org-html-export-to-html)))
>> in org-export-head. I tried, but without success, because I am simply
>> not expert enough. I see the best, that is to export both with org-ref 3
>> (i.e. "r h") and org-export-head, but I am unable to code it.
>>
>> No doubt that it should be for you and Ivan a piece of cake, but please
>> do it only if you think that it is interesting and if you find the time
>> to do it.
>>
>> Best wishes,
>>
>> Jo.
>>
>> PS in attachment, myblogexporter.el in my ~/.emacs.d/personal  (usual
>> path with Prelude Emacs).
>>
>> Le 01/12/2021 à 23:16, John Kitchin a écrit :
>>>
>>> Joseph Vidal-Rosset  writes:
>>>
 Dear Andras,

 You are very probably right. I will have a look on this entry in my
 default bibliography file.

 The code

 (let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
   (org-open-file  (org-html-export-to-html)))

 put in .emacs.d/personal/preload/myorgexport.el

>>> This code should not go in your init file. It is executed each time, and
>>> not what you want. I usually put it a src block at the end in a section
>>> tagged noexport and run it from there.
>>>
>>> Alternatively, if this is the only preprocessing you do, I think you can
>>> do C-c C-e rh to export to html (this runs the org-ref html exporter.
>>>
>>> Finally, if you really want something in your init file it should be
>>> like this:
>>>
>>> (defun my-html ()
>>> (interactive)
>>> (let  ((org-export-before-parsing-hook 
>>> '(org-ref-csl-preprocess-buffer)))
>>>   (org-open-file  (org-html-export-to-html
>>>
>>> and then later you run it with M-x my-html
>>>
>>>
 provokes the request of opening a html file, when emacs --daemon is
 started; therefore I conclude that it should not be used as I did...

 Anyway, every  tentative  to export in a bibliography in html fails at
 the moment, even with a new bibliography file...  :(
>>>
>>> See of the one at
>>> https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org
>>> works. The bib file is in
>>> https://github.com/jkitchin/org-ref/blob/master/org-ref.bib.
>>>
>>>
>>>

 Best wishes,

 Le 01/12/2021 à 17:33, András Simonyi a écrit :
> Dear 

Re: Org-syntax: Intra-word markup

[autofrettage]

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Thursday, December 2nd, 2021 at 4:24 PM, Robert Pluim  
wrote:

>> autofrettage> any kind of rower = Ruder*in
>
> But with the 'female' suffix? Thatʼs almost as bad as 'écriture
> inclusive'. Surely 'Ruder**'? 

The German wikipedia page* about gender neutral language is well
over 30 k words long, and there are almost 250 bibliographic
references. It lists a number of alternatives, such as (based
on Lehrer and Lehrerin, the German words for teacher):

+ Lehrx
+ Lehry
+ Lehrerin
+ Lehrer/-in
+ Lehrer/in
+ LehrerIn
+ Lehrer(in)
+ Lehrer:in
+ Lehrer*in
+ Lehrer_in
+ Lehrer_In
+ Lehrer•in
+ Lehrkraft
+ Lehrperson
+ Lehrende
+ ...

So, by all means, join the party. They will consider all aspects
of your suggestion, and being dead serious about it.

Yours
Rasmus

* https://de.wikipedia.org/wiki/Geschlechtergerechte_Sprache

p.s. There are even browser plug-ins, removing all of this
political correctness, making texts _much_ easier to read.

Re: [BUG] C-c C-* causes "org-element--cache: Unregistered buffer modifications detected."

[Max Nikulin]

On 02/12/2021 08:48, Ihor Radchenko wrote:

Max Nikulin writes:


Well... I added yet another exception on main. Note that this special
case is also just in older Emacs versions.


Ihor, have you pushed the change? I still can reproduce the issue with
Emacs-26.3


Oops. I fixed Emacs 27, but apparently not Emacs 26. Should be fixed
now.


Unfortunately currently it fails in Emacs-26.3 event without "#+startup: 
indent":


Warning (org-element-cache): org-element--cache: Unregistered buffer 
modifications detected. Resetting.
If this warning appears regularly, please report it to Org mode mailing 
list (M-x org-submit-bug-report).

The buffer is: new.org
 Current command: (nil 163 167)
 Chars modified: 163
 Buffer modified: 167
 Backtrace:
nil

Org: 521c534101


tree-sitter is comparable with org-element. org-element
parser is fairly fast and also uses incremental parsing ;)

tree-sitter vs. org-element on 15M Org file
org-element-parse-buffer
(16.090262757 1 0.736568360962)


I hope, Timothy will fix bugs in his new fast parser. Anyway thank you 
for sharing these results. I have not looked closely at various parsers, 
I only created a rudimentary one that understands just headings and 
links to call it from my browser extension (no more than proof of concept).

Re: Unwanted italics formatting between two URLs

[Max Nikulin]

On 29/11/2021 14:03, Rafael Laboissière wrote:

[[https://first/-/url/][pre]] text [[https://second-url/?][post]]


Fortunately this sample is parsed and exported correctly:


https://first/-/url/;>pre text href="https://second-url/?;>post


so it is only issue with regexp-based fontification. There was a recent 
thread if it could be fixed in a general way:


Ihor Radchenko. [DISCUSSION] Refactoring fontification system. Fri, 19 
Nov 2021 22:12:35 +0800. https://list.orgmode.org/87ee7c9quk.fsf@localhost/

Re: Faces for inline src blocks

[Eric S Fraga]

On Thursday,  2 Dec 2021 at 23:56, Timothy wrote:
> [...] but something like 6 faces for inline source blocks just feels
> excessive to me.

Why?  It's just a number.  I cannot imagine it would have any
performance impact?  

If you think that level of granularity is useful, I suggest you go for
it.  Or at least define the 3 you seem to have implicitly chosen already
(by using 2 existing ones and adding one new face)?

-- 
: Eric S Fraga, with org release_9.5.1-231-g6766c4 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: examples for org-manual

[Vincent Breton]

Thank you very much for your message and the link.

Does Org format produce the .texi format for TexInfo ?  I found the
official reply here: https://orgmode.org/manual/Texinfo-export-commands.html

Org format seams to be a top layer format to produce others formats.
That seams to be a good reason to use Org format but in another way and
in my opinion, just providing HTML format on the documentation web page
for Gnu Org is a regression. Most of GNU documentations for others
products provide an access to different formats on the same page. HTML
is useful but it can't replace PDF format.


On 02/12/2021 15:53, Kaushal Modi wrote:
> On Thu, Dec 2, 2021, 8:08 AM Vincent Breton
> mailto:emacs-orgm...@presentiel.fr>> wrote:
>
> Hi,
>
>
> Emacs and Emacs Org documentation, and lot of others GNU products use
> Texinfo to generate their own  documentation to different formats.
>
>
> The Org mode documentation switched to Org format few years
> back: 
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/doc/org-manual.org
> 
>
> Yes, originally, it was in Texinfo. 

Re: Faces for inline src blocks

[Timothy]

Hi Eric,

> I am not very picky (yeah, well, okay, maybe a little ).  All I really
> care about is not having other faces, that have well defined meanings,
> being used.  I would actually be happy with just the whole block having
> a face but maybe others, including yourself, would like to distinguish
> the various bits that make up an inline src block.

Stop me if I surprise you  but I’m quite a fan of the fine highlighting detail
that’s currently occurring. I’m inclined to try to make myself happy without
forcing the same style on other people by adding faces, but something like 6
faces for inline source blocks just feels excessive to me.

All the best,
Timothy

Re: [ANN] An Org parser for Julia

[Eric S Fraga]

On Thursday,  2 Dec 2021 at 22:04, Timothy wrote:
> It worked all the time, except when I tried to `@benchmark' it, where
> strange errors that shouldn’t happen cropped up.

automated benchmarking multi-threaded applications is a form of dark
magic...

-- 
: Eric S Fraga, with org release_9.5.1-231-g6766c4 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: citeproc-org and org-ref 3

[Joseph Vidal-Rosset]

Dear all,


I just succeeded in solving my problem.

l-210-235 of myblogexporter.el, I changed the code for:

(defun org-export-head-export-headers (directory-name backend)
   "Exports each heading to directory-name using backend"
   (if (equal backend "html")
   (org-export-head--run-on-each-heading
#'(lambda ()
(org-set-property
 "EXPORT_FILE_NAME"
 (concat directory-name (org-export-head--escaped-headline)))
(deactivate-mark)
(let ((org-export-before-parsing-hook
'(org-ref-csl-preprocess-buffer)))
 (cl-letf (((symbol-function 'org-export-get-reference)
(symbol-function 'org-export-get-reference-custom)))
   (if org-export-head-click-toc-h2
   (cl-letf ((
  ;(symbol-function 'org-html-toc)
  (symbol-function
'org-export-head--custom-toc)))
 (org-html-export-to-html nil t)
(set-buffer-modified-p t)) "-noexport-noreexport"))
   (if (equal backend "pdf")
   (org-export-head--run-on-each-heading
#'(lambda ()
(org-set-property
 "EXPORT_FILE_NAME"
 (concat directory-name (org-export-head--escaped-headline)))
(deactivate-mark)
(org-latex-export-to-pdf nil t)
(set-buffer-modified-p t)) "-noexport-noreexport")))

and it works with org-ref 3.

Best wishes,  I attach myblogexporter.el

Jo.

Le 02/12/2021 à 14:17, Joseph Vidal-Rosset a écrit :
> Dear John (cc. Ivan),
>
> First, thanks for your help and for your patience, that's very kind of you.
>
> The good news is that indeed, org-ref 3 exports nicely the  html
> bibliography with my CSL file, it works well with your org file and your
> bibliography. My error was simple: I did not use the specific org-ref
> keys but the ordinary h-o keys.. A stupid mistake.
>
> The bad news is that this new function for exporting with org-ref 3 is
> not included in org-export-head, a nice org mode to blog exporter, made
> by Ivan Tadeu Ferreira Antunes Filho, which converts each header to a
> different file, I find this exporter very convenient. I had no problem
> with this org-ref 2 to use this blog-exporter, but it org-ref 3 is
> unfortunately not still adapted to its use. Nevertheless, I believe that
> it should be possible to find the lines to include this function
> (let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
>   (org-open-file  (org-html-export-to-html)))
> in org-export-head. I tried, but without success, because I am simply
> not expert enough. I see the best, that is to export both with org-ref 3
> (i.e. "r h") and org-export-head, but I am unable to code it.
>
> No doubt that it should be for you and Ivan a piece of cake, but please
> do it only if you think that it is interesting and if you find the time
> to do it.
>
> Best wishes,
>
> Jo.
>
> PS in attachment, myblogexporter.el in my ~/.emacs.d/personal  (usual
> path with Prelude Emacs).
>
> Le 01/12/2021 à 23:16, John Kitchin a écrit :
>>
>> Joseph Vidal-Rosset  writes:
>>
>>> Dear Andras,
>>>
>>> You are very probably right. I will have a look on this entry in my
>>> default bibliography file.
>>>
>>> The code
>>>
>>> (let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
>>>   (org-open-file  (org-html-export-to-html)))
>>>
>>> put in .emacs.d/personal/preload/myorgexport.el
>>>
>> This code should not go in your init file. It is executed each time, and
>> not what you want. I usually put it a src block at the end in a section
>> tagged noexport and run it from there.
>>
>> Alternatively, if this is the only preprocessing you do, I think you can
>> do C-c C-e rh to export to html (this runs the org-ref html exporter.
>>
>> Finally, if you really want something in your init file it should be
>> like this:
>>
>> (defun my-html ()
>> (interactive)
>> (let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
>>   (org-open-file  (org-html-export-to-html
>>
>> and then later you run it with M-x my-html
>>
>>
>>> provokes the request of opening a html file, when emacs --daemon is
>>> started; therefore I conclude that it should not be used as I did...
>>>
>>> Anyway, every  tentative  to export in a bibliography in html fails at
>>> the moment, even with a new bibliography file...  :(
>>
>> See of the one at
>> https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org
>> works. The bib file is in
>> https://github.com/jkitchin/org-ref/blob/master/org-ref.bib.
>>
>>
>>
>>>
>>> Best wishes,
>>>
>>> Le 01/12/2021 à 17:33, András Simonyi a écrit :
 Dear Joseph,

 based on the error message there seems to be a problem with the
 'curley-nil-on-bennet-spinoz' bibliography entry, is it possible that
 it contains a 'year = nil' row? If yes then I don't think that is
 well-formed, at least 

Re: Faces for inline src blocks

[Eric S Fraga]

On Thursday,  2 Dec 2021 at 21:57, Timothy wrote:
> Let me know what your thoughts are.

I am not very picky (yeah, well, okay, maybe a little ).  All I really
care about is not having other faces, that have well defined meanings,
being used.  I would actually be happy with just the whole block having
a face but maybe others, including yourself, would like to distinguish
the various bits that make up an inline src block.

thank you,
eric

-- 
: Eric S Fraga, with org release_9.5.1-231-g6766c4 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Org-syntax: Intra-word markup

[Max Nikulin]

On 02/12/2021 20:07, Ihor Radchenko wrote:



As for suggestions: If just using /intra/word creates ambiguities, what
about the asciidoc solution? So //intra//word?


I do like this idea.


- Some //text  surprise//
- ++another ~i++~ problem++

First wins...

Re: Bibliographies on export with ox-context and ox-epub

[Jason Ross]

There is a ConTeXt-specific citation exporter that's in development:

https://github.com/Jason-S-Ross/oc-context

On 12/2/21 12:11 AM, juh wrote:

Am 01.12.21 um 16:01 schrieb Eric S Fraga:

What completion engine are you using?  In selectrum, typing C-j at that
point finishes the completion.  Other engines will differ.  You might
also try up-arrow and RET.

Thanks a lot. I use selectrum and would've never found this door out.

juh

Re: Org-syntax: Intra-word markup

[Robert Pluim]

> On Thu, 02 Dec 2021 13:36:48 +, autofrettage 
>  said:

autofrettage> Someone brought up edge and corner cases, so I simply have to 
mention the German gender stars ("Gendersternchen").
autofrettage> In an effort to make German gender neutral, some individuals 
use '*' in the midst of some words, e.g. rower.
autofrettage> Ordinary German:
autofrettage> male rower = Ruderer
autofrettage> female rower = Ruderin

autofrettage> Gender neutral German with gender star:
autofrettage> any kind of rower = Ruder*in

But with the 'female' suffix? Thatʼs almost as bad as 'écriture
inclusive'. Surely 'Ruder**'? 

Robert
-- 

Re: examples for org-manual

[Kaushal Modi]

On Thu, Dec 2, 2021, 8:08 AM Vincent Breton 
wrote:

> Hi,
>
>
> Emacs and Emacs Org documentation, and lot of others GNU products use
> Texinfo to generate their own  documentation to different formats.


The Org mode documentation switched to Org format few years back:
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/doc/org-manual.org

Yes, originally, it was in Texinfo.

Re: [ANN] An Org parser for Julia

[Timothy]

Hi Eric,

> As an aside, Julia 1.7 was released two or three days ago.  Works very
> well.  None of my codes has broken, which is always a good sign.

Funny you should mention 1.7, I tried multithreading the parser and achieved a
~10x speedup. It worked all the time, except when I tried to `@benchmark' it,
where strange errors that shouldn’t happen cropped up.

I noticed the 1.7 release blog post mentioned fixing some multithreaded race
conditions, so I’m cautiously optimistic that this might work now :)

All the best,
Timothy

Faces for inline src blocks (was: [PATCH] Fontification for inline src blocks)

[Timothy]

Hi Eric,

> However, I am finding the result not very pleasing unfortunately.
> Specifically, I am not happy with the use of other pre-existing faces
> (shadow and org-meta-line) for this purpose.  These other faces have
> their specific uses and the resulting combination for inline src blocks,
> for me, is ugly.  I do not wish to modify those faces for this use case
> as it will affect their use everywhere else.

Yep, I’ve been quite open to the prospect of adding faces, just not entirely
sure how much / what I should do. Since I didn’t want that block this feature
we’ve currently got the one-face version.

The various elements that could have a face are:
⁃ the src_ prefix
⁃ the lang component
⁃ headers
⁃ the square brackets delimiting the headers / curly brackets delimiting the 
content
⁃ the content
⁃ the whole block (this is what currently has a dedicated face)

Let me know what your thoughts are.

All the best,
Timothy

Re: Org-syntax: Intra-word markup

[autofrettage]

Someone brought up edge and corner cases, so I simply have to mention the 
German gender stars ("Gendersternchen").

In an effort to make German gender neutral, some individuals use '*' in the 
midst of some words, e.g. rower.
Ordinary German:
male rower = Ruderer
female rower = Ruderin

Gender neutral German with gender star:
any kind of rower = Ruder*in

Yours
Rasmus

Re: Org-syntax: Intra-word markup

[Denis Maier]

Am 02.12.2021 um 14:14 schrieb Juan Manuel Macías:

Ihor Radchenko writes:


Denis Maier  writes:


Can you create an example of such scenario and post it as a bug?
Probably, we just need to strip all zero-width spaces at the basic ox.el
level.

To be clear: That's not an org bug. It's just that latex won't be able
such a word. If | is a zero width space, the word "hyphen|ation" is not
the same as "hyphenation".
1. hyphenation
2. hyphen|ation

You are right for your example, but if we force the user to put
*hyphen*|ation to create bold emphasis, it should not be any different
compared to @@latex:\textbf{hyphen}ation@@. Meanwhile the*hyphen*|ation
gets exported as \textbf{hyphen}|ation keeping the zero width space.
-- I would say that they are very random cases, and therefore 
difficult to reproduce. In the 'hyphenation' example, if we load the 
package showhypehns, you see that: /hyphen/​ation (with zero width sp) 
and \emph{hyphen}ation they are cut in the same way. But differently 
from hyphenation (without emphasis) (compiled with LuaTeX). Anyway, I 
have come across some curious cases. For example, a long time ago I 
had defined a macro for text in other languages: #+MACRO: lg (eval (if 
(org-export-derived-backend-p org-export-current-backend 'latex) 
(concat "@@latex:\\foreignlanguage{@@" $1 "@@latex:}{@@" "\u200B" $2 
"\u200B" "@@latex:}@@") $2)) I needed to add before and after a zero 
width space, but doing so, the shape of the text was altered. That can 
be reproduced with this example: #+LaTeX_Header: 
\usepackage{showhyphens} #+LaTeX_Header:\usepackage{lipsum,multicol} 
#+LaTeX_Header:\usepackage[spanish]{babel} #+LaTeX_Header: 
\def\example{\lipsum[1]} #+LaTeX_Header: \def\zwsp{\char"200B{}} 
#+OPTIONS: toc:nil @@latex:\begin{multicols}{2}@@ 
@@latex:\foreignlanguage{italian}{\zwsp\example\zwsp}@@ 
@@latex:\foreignlanguage{italian}​{\example}@@ 
@@latex:\end{multicols}@@ Best regards, Juan Manuel


Thanks Juan Manuel. I should have tried that first. Hyphenation is the 
same for both /hyphen/​ation (with zero width sp) and 
\emph{hyphen}ation. (Maybe I can nudge Hans Hagen to add some low level 
trickery in context that removes the groups before doing the 
hyphenation... but that's a different story.) Anyway, as Juan Manuel 
shows there can be cases where zero width spaces cause problems.


Denis

Re: citeproc-org and org-ref 3

[Joseph Vidal-Rosset]

Dear John (cc. Ivan),

First, thanks for your help and for your patience, that's very kind of you.

The good news is that indeed, org-ref 3 exports nicely the  html
bibliography with my CSL file, it works well with your org file and your
bibliography. My error was simple: I did not use the specific org-ref
keys but the ordinary h-o keys.. A stupid mistake.

The bad news is that this new function for exporting with org-ref 3 is
not included in org-export-head, a nice org mode to blog exporter, made
by Ivan Tadeu Ferreira Antunes Filho, which converts each header to a
different file, I find this exporter very convenient. I had no problem
with this org-ref 2 to use this blog-exporter, but it org-ref 3 is
unfortunately not still adapted to its use. Nevertheless, I believe that
it should be possible to find the lines to include this function
(let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
 (org-open-file  (org-html-export-to-html)))
in org-export-head. I tried, but without success, because I am simply
not expert enough. I see the best, that is to export both with org-ref 3
(i.e. "r h") and org-export-head, but I am unable to code it.

No doubt that it should be for you and Ivan a piece of cake, but please
do it only if you think that it is interesting and if you find the time
to do it.

Best wishes,

Jo.

PS in attachment, myblogexporter.el in my ~/.emacs.d/personal  (usual
path with Prelude Emacs).

Le 01/12/2021 à 23:16, John Kitchin a écrit :
>
> Joseph Vidal-Rosset  writes:
>
>> Dear Andras,
>>
>> You are very probably right. I will have a look on this entry in my
>> default bibliography file.
>>
>> The code
>>
>> (let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
>>  (org-open-file  (org-html-export-to-html)))
>>
>> put in .emacs.d/personal/preload/myorgexport.el
>>
> This code should not go in your init file. It is executed each time, and
> not what you want. I usually put it a src block at the end in a section
> tagged noexport and run it from there.
>
> Alternatively, if this is the only preprocessing you do, I think you can
> do C-c C-e rh to export to html (this runs the org-ref html exporter.
>
> Finally, if you really want something in your init file it should be
> like this:
>
> (defun my-html ()
>(interactive)
>(let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
>  (org-open-file  (org-html-export-to-html
>
> and then later you run it with M-x my-html
>
>
>> provokes the request of opening a html file, when emacs --daemon is
>> started; therefore I conclude that it should not be used as I did...
>>
>> Anyway, every  tentative  to export in a bibliography in html fails at
>> the moment, even with a new bibliography file...  :(
>
> See of the one at
> https://github.com/jkitchin/org-ref/blob/master/examples/basic-csl.org
> works. The bib file is in
> https://github.com/jkitchin/org-ref/blob/master/org-ref.bib.
>
>
>
>>
>> Best wishes,
>>
>> Le 01/12/2021 à 17:33, András Simonyi a écrit :
>>> Dear Joseph,
>>>
>>> based on the error message there seems to be a problem with the
>>> 'curley-nil-on-bennet-spinoz' bibliography entry, is it possible that
>>> it contains a 'year = nil' row? If yes then I don't think that is
>>> well-formed, at least citeproc-el cannot currently parse it. Anyhow,
>>> apparently I need to improve/add citeproc-el error messages about
>>> bib(la)tex parsing, because several parsing problems have surfaced
>>> lately and the current error messages aren't helpful at all.
>>>
>>> best wishes,
>>> András
>>>
>>> On Wed, 1 Dec 2021 at 16:50, Joseph Vidal-Rosset
>>>  wrote:

 Dear John,

 I must say that to export references in html with org-ref 3, I meet a
 lot of problems (with LaTeX, it's fine).

 I am using prelude emacs and  GNU Emacs 29.0.50 .

 Starting emacs --daemon, the code

 (let  ((org-export-before-parsing-hook '(org-ref-csl-preprocess-buffer)))
(org-open-file  (org-html-export-to-html)))

 in my setup provokes this unwanting effect:

 [Prelude] Loading personal configuration files in
 /home/joseph/.emacs.d/personal/preload...
 Loading /home/joseph/.emacs.d/personal/preload/myorgexport.el (source)...
 Output file:

 and with Enter :

 [Prelude] Loading personal configuration files in
 /home/joseph/.emacs.d/personal/preload...
 Loading /home/joseph/.emacs.d/personal/preload/myorgexport.el (source)...
 Output file:
 Warning (initialization): An error occurred while loading
 ‘/home/joseph/.emacs.d/init.el’:

 Wrong type argument: stringp, nil

 To ensure normal operation, you should investigate and remove the
 cause of the error in your initialization file.  Start Emacs with
 the ‘--debug-init’ option to view a complete error backtrace. Disable
 showing Disable logging
 Starting Emacs daemon.

 With --debug-init, I 

Re: Org-syntax: Intra-word markup

[Juan Manuel Macías]

Ihor Radchenko writes:

> Denis Maier  writes:
>
>>> Can you create an example of such scenario and post it as a bug?
>>> Probably, we just need to strip all zero-width spaces at the basic ox.el
>>> level.
>> To be clear: That's not an org bug. It's just that latex won't be able 
>> such a word. If | is a zero width space, the word "hyphen|ation" is not 
>> the same as "hyphenation".
>> 1. hyphenation
>> 2. hyphen|ation
>
> You are right for your example, but if we force the user to put
> *hyphen*|ation to create bold emphasis, it should not be any different
> compared to @@latex:\textbf{hyphen}ation@@. Meanwhile the *hyphen*|ation
> gets exported as \textbf{hyphen}|ation keeping the zero width space.

-- 
I would say that they are very random cases, and therefore difficult to
reproduce. In the 'hyphenation' example, if we load the package
showhypehns, you see that:

/hyphen/​ation (with zero width sp)

and

\emph{hyphen}ation

they are cut in the same way. But differently from

hyphenation (without emphasis)

(compiled with LuaTeX).

Anyway, I have come across some curious cases. For example, a long time
ago I had defined a macro for text in other languages:

#+MACRO: lg (eval (if (org-export-derived-backend-p org-export-current-backend 
'latex) (concat "@@latex:\\foreignlanguage{@@" $1 "@@latex:}{@@" "\u200B" $2 
"\u200B" "@@latex:}@@") $2))

I needed to add before and after a zero width space, but doing so, the
shape of the text was altered. That can be reproduced with this example:

#+LaTeX_Header: \usepackage{showhyphens}
#+LaTeX_Header:\usepackage{lipsum,multicol}
#+LaTeX_Header:\usepackage[spanish]{babel}
#+LaTeX_Header: \def\example{\lipsum[1]}
#+LaTeX_Header: \def\zwsp{\char"200B{}}
#+OPTIONS: toc:nil

@@latex:\begin{multicols}{2}@@
@@latex:\foreignlanguage{italian}{\zwsp\example\zwsp}@@
@@latex:\foreignlanguage{italian}​{\example}@@
@@latex:\end{multicols}@@

Best regards,

Juan Manuel 

Re: Org-syntax: Intra-word markup

[Eric S Fraga]

On Thursday,  2 Dec 2021 at 13:27, Denis Maier wrote:
> This works if your target is just latex, but not if you have multiple
> targets, right?

Multiple targets are possible:

@@latex:\textbf{html:@@intra@@latex:}html:@@word.

Just very ugly! 藍

Of course, if you do this more than once, a macro can help...

-- 
: Eric S Fraga, with org release_9.5.1-231-g6766c4 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: examples for org-manual

[Vincent Breton]

Hi,


Emacs and Emacs Org documentation, and lot of others GNU products use
Texinfo to generate their own  documentation to different formats.
Unlucky, they are just the HTML version on
https://www.gnu.org/software/emacs/manual/org.html and It is not for
lack of having written the 22 november 2021 a message about org
documentation... on this list.

I remember you can access to a PDF version of Org I published on
http://www.presentiel.com/org/org.pdf.
and another one more short: http://www.presentiel.com/org/orgguide.pdf.

In my opinion, the trouble with just  a Wiki is not the most appropriate
for printed version and in a Wiki or others CMS, some pages are short
and others long without page number so it's more difficult to appreciate
the length of the document and the time to study it. They are also
others troubles with Web pages about security or about private life when
you explore a web site...

That why I encourage to publish documentation with different formats,
more particularly when the doc is written for Texinfo tool who make all
the work easily.

In my experience, the best thing to do is to start to write a draft
using plain text. If you prefer, you can also use directly a CMS to
generate HTML: only HTML where it's easy to copy and past text but
please in all cases  use a very simple CSS if you use it. In my
opinion,that is a good idea to use a common tool as git to publish and
update your work but don't forget to inform.

If your content is good and clear, it will be interesting to upgrade it
to a beautiful book: that's another work very hard for some people and
very simple for others: generally the last one use (La)TeX years after
years.

I'm sure, some people will play the game with accepting to send and
publish for free interesting examples for Org. On this forum, I'm sure
you will find too lot of tips and tricks.

In my opininon the big difference between a manual and a book about Gnu
products are layout, illustrations and copyrights.

I hope to read soon your first writings  about some Org examples before
I provide you a PDF version made with LaTeX and without change of text.

Best regards

On 02/12/2021 03:58, brownexitus wrote:

> Hi Vincent, t
>
> I hear what you say, but isn't more efficient to have something like the 
> emacs wiki etc? or even links to other sites that explain it that way?
>
> If the manual is available somewhere on git (I'm new to this whole thing), 
> perhaps I can try to offer changes that will go in there. I don't know that 
> that's possible though.
>
> creating a PDF and contributing to it like that is similar to writing a book, 
> which is not a bad idea in itself, but it's not going to lift off the ground 
> as easy as just contributing to the manual...? What do you think.
>
>> Hi,
>>
>> In my opinion, lot of manuals don't have enough examples.
>>
>> One way to solve this would be to create a list of examples in another
>>
>> document with references to the org documentation in PDF format (page
>>
>> numbers, relevant sections...). This would not change anything in the
>>
>> original documentation and would make it easier to understand or to
>>
>> identify possible obscure and incomplete aspects.
>>
>> Once the list of examples is sufficiently complete and validated, it
>>
>> could be attached to the original documentation with for example at
>>
>> least a paragraph and a link to consult this compilation of examples
>>
>> playing the role of a large appendix, or even links to the examples
>>
>> document in the text for the most interesting examples.
>>
>> It's a big job but if enough people would contribute according to their
>>
>> possibilities and time, we would have much more than a simple book of
>>
>> examples.
>>
>> I hope it will be useful.
>>
>> On 01/12/2021 05:09, brownexitus via General discussions about Org-mode.
>>
>> wrote:
>>
>>> The org-manual could use more practical examples, in my opinion.
>>>
>>> How does one submit suggestions/edits?
>

Re: Org-syntax: Intra-word markup

[Ihor Radchenko]

Denis Maier  writes:

> As for suggestions: If just using /intra/word creates ambiguities, what 
> about the asciidoc solution? So //intra//word?

I do like this idea.

Though I would also like to hear Nicolas' opinion.

Best,
Ihor

Re: Org-syntax: Intra-word markup

[Ihor Radchenko]

Denis Maier  writes:

>> An alternative may be some kind of "forced" emphasis syntax where Org
>> does not have to guess about the emphasis using non-transparent rules.
>> But it's what zero width space is for and it is what we recommend in the
>> Org manual.
> As for the forced syntax. What do you think about the asciidoc solution?

Can you elaborate?

Re: [PATCH] Fontification for inline src blocks

[Eric S Fraga]

Timothy,

I am happy to see the fontification of inline src blocks in org.  Thank
you!

However, I am finding the result not very pleasing unfortunately.
Specifically, I am not happy with the use of other pre-existing faces
(shadow and org-meta-line) for this purpose.  These other faces have
their specific uses and the resulting combination for inline src blocks,
for me, is ugly.  I do not wish to modify those faces for this use case
as it will affect their use everywhere else.

Philosophically, the language element in an inline src block is not a
/meta line/, at least not in my view: it's not even a line... 

Would it be possible to create new faces specifically for the various
bits you want to differentiate, e.g. org-inline-src-block-language?  I
don't mind if they have the defaults to be the same as org-meta-line and
org-shadow etc. but at least I can customise them separately.

Thanks again,
eric

-- 
: Eric S Fraga, with org release_9.5.1-231-g6766c4 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Formal syntax for org-cite

[Timothy]

Hi Ihor,

> This is all defined in org-element-object-restrictions together with
> other restrictions on what kinds of objects can be placed inside other
> elements and objects:
>
> (minimal-set ’(bold code entity italic latex-fragment strike-through
>subscript superscript underline verbatim))
> (citation-reference ,@minimal-set)

Ah thanks! I wasn’t aware of that. I think this is something that should be
mentioned in the spec.

All the best,
Timothy

Re: Org-syntax: Intra-word markup

[Ihor Radchenko]

Denis Maier  writes:

>> Can you create an example of such scenario and post it as a bug?
>> Probably, we just need to strip all zero-width spaces at the basic ox.el
>> level.
> To be clear: That's not an org bug. It's just that latex won't be able 
> such a word. If | is a zero width space, the word "hyphen|ation" is not 
> the same as "hyphenation".
> 1. hyphenation
> 2. hyphen|ation

You are right for your example, but if we force the user to put
*hyphen*|ation to create bold emphasis, it should not be any different
compared to @@latex:\textbf{hyphen}ation@@. Meanwhile the *hyphen*|ation
gets exported as \textbf{hyphen}|ation keeping the zero width space.

Best,
Ihor

Re: Formal syntax for org-cite

[Ihor Radchenko]

Timothy  writes:

> Let’s look at a strange citation.
>
> ┌
> │ [cite: @key *bold* text @@org:hey@@ and /italic/ and {{{macro()}}} and 
> [fn:3] and
> │ <> <2021-12-02 Thu> \latex and \alpha and a statscookie [3/7] 
> src_lang{hi}
> │ s^{up} and s_{ub}]
> └
>
> Examining the interpretation of this citation with `org-element', the 
> following
> inline elements / objects are recognised.
> ⁃ bold/italic/etc. (text markup elements)
> ⁃ latex fragment
> ⁃ super/subscript
> but most of the non-markup elements are not.
> ⁃ Export snippet
> ⁃ macro
> ⁃ footnote
> ⁃ target
> ⁃ timestamp
> ⁃ statistics cookie
> ⁃ inline source code

This is all defined in org-element-object-restrictions together with
other restrictions on what kinds of objects can be placed inside other
elements and objects:

(minimal-set '(bold code entity italic latex-fragment strike-through
 subscript superscript underline verbatim))
(citation-reference ,@minimal-set)

Best,
Ihor

Re: Org-syntax: Intra-word markup

[Max Nikulin]

On 02/12/2021 19:10, Ihor Radchenko wrote:

Denis Maier writes:


Just a furter remark: while zero-width-spaces can be used as a
workaround, they may create problems in some export formats. E.g., they
will mess up hyphenation in latex. I think if read somewhere that those
can be removed with hooks or filters, but I think that shouldn't be
necessary.


Probably, we just need to strip all zero-width spaces at the basic ox.el
level.


I think, legitimate cases when zero-width spaces should be preserved in 
a document may exist, so unconditionally stripping them is not a perfect 
solution.


I am afraid, regexps detecting start and end of emphasis are similar to 
a short blanket. They will always fail for some cases, especially since 
verbatim, URLs and similar contexts (that significantly differ from 
prose in respect to punctuation) do not have higher priority for parser.


Extensive test set is required for tuning of heuristics. Failures should 
be reported in a such way that allows to estimate overall quality before 
and after change. Ideally, format of file with such tests should allow 
to use the *same* input data for other tools like ruby-org.

Re: Org-syntax: Intra-word markup

[Denis Maier]

Am 02.12.2021 um 13:10 schrieb Ihor Radchenko:

Denis Maier  writes:


Just a furter remark: while zero-width-spaces can be used as a
workaround, they may create problems in some export formats. E.g., they
will mess up hyphenation in latex. I think if read somewhere that those
can be removed with hooks or filters, but I think that shouldn't be
necessary.

Can you create an example of such scenario and post it as a bug?
Probably, we just need to strip all zero-width spaces at the basic ox.el
level.
To be clear: That's not an org bug. It's just that latex won't be able 
such a word. If | is a zero width space, the word "hyphen|ation" is not 
the same as "hyphenation".

1. hyphenation
2. hyphen|ation


Best,
Denis

Re: Org-syntax: Intra-word markup

[Denis Maier]

Am 02.12.2021 um 13:00 schrieb Ihor Radchenko:

Juan Manuel Macías  writes:


intra-*word* works just fine for me.


I think what Denis is referring to is a construction of the type
*intra*word, which, if I'm not mistaken, is not supported and can only
be achieved by inserting a zero width space.

I see. We had a discussion about emphasis issues in
https://orgmode.org/list/8735nnq73n.fsf@localhost

The conclusion from there is that supporting such scenarios will
introduce various edge cases. We would need to make the emaphsis parser
more and more complex inevitably introducing errors.

Thanks, I'll try to read that thread in due time.


An alternative may be some kind of "forced" emphasis syntax where Org
does not have to guess about the emphasis using non-transparent rules.
But it's what zero width space is for and it is what we recommend in the
Org manual.

As for the forced syntax. What do you think about the asciidoc solution?

Denis

Re: Org-syntax: Intra-word markup

[Denis Maier]

Am 02.12.2021 um 13:08 schrieb Eric S Fraga:

My solution, in these case, is to fall back to LaTeX using @@latex:...@@
(and equivalent for HTML, if desired).  Not pretty but I need this so
seldom that I am happy with the org emphasis support generally.


Hi Eric,

Am 02.12.2021 um 13:08 schrieb Eric S Fraga:

My solution, in these case, is to fall back to LaTeX using @@latex:...@@
(and equivalent for HTML, if desired).  Not pretty but I need this so
seldom that I am happy with the org emphasis support generally.

This works if your target is just latex, but not if you have multiple 
targets, right?


Denis

Re: Org-syntax: Intra-word markup

[Denis Maier]

Hi Timothy,

Am 02.12.2021 um 12:58 schrieb Timothy:

Hi Denis,


Currently, org syntax doesn’t officially seem to support intra-word emphasis. Am
I missing something?

I’d describe it as supported via-zero width spaces.

You may be interested in 
.

Thank's that's helpful.



If the assessment is correct: Is there a reason for this? And, shouldn’t that
be officially added?

Do you happen to have any ideas on how this could be achieved? I’d rather not
resort to having to do things like `\ast{}' and `\tilde{}' too much.


Well, not really. I just don't understand why /intra/word shouldn't mean 
\emph{intra}word. Pandoc's markdown supports *intra*word, asciidoc 
supports it via unconstrained formatting pairs: 
https://docs.asciidoctor.org/asciidoc/latest/text/#unconstrained; so 
__intra__word.
And, as org syntax is said to be the superior markup language, I thought 
that must be possible ;-)


I understand zero width spaces are the official workaround, but I don't 
really like having invisible characters in my documents. Automatically 
removing all of them on export might also introduce problems. Perhaps 
some have been added on purpose, and not just to help org?


As for suggestions: If just using /intra/word creates ambiguities, what 
about the asciidoc solution? So //intra//word?
In fact, I'd even use raw latex for this things. It's true, they are 
rare enough. So I wouldn't mind an occassional `\emph{}`.


Best,
Denis

Re: [ANN] An Org parser for Julia

[Eric S Fraga]

Timothy,

this is really good to see!  I have been using Julia as my main
programming language for some years now and all of my codes generate
output with org markup.  Now I could in principle use it for the input
as well which could be quite helpful.

As an aside, Julia 1.7 was released two or three days ago.  Works very
well.  None of my codes has broken, which is always a good sign.

-- 
: Eric S Fraga, with org release_9.5.1-231-g6766c4 in Emacs 29.0.50
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Formal syntax for org-cite

[Timothy]

Hi Nicolas, Tom,

I just thought I’d do a little test to see what markup citations accept with
org-element, and I’m not quite sure what to make of the results. I’d appreciate
hearing your thoughts on the example below.

Let’s look at a strange citation.

┌
│ [cite: @key *bold* text @@org:hey@@ and /italic/ and {{{macro()}}} and [fn:3] 
and
│ <> <2021-12-02 Thu> \latex and \alpha and a statscookie [3/7] 
src_lang{hi}
│ s^{up} and s_{ub}]
└

Examining the interpretation of this citation with `org-element', the following
inline elements / objects are recognised.
⁃ bold/italic/etc. (text markup elements)
⁃ latex fragment
⁃ super/subscript
but most of the non-markup elements are not.
⁃ Export snippet
⁃ macro
⁃ footnote
⁃ target
⁃ timestamp
⁃ statistics cookie
⁃ inline source code

All the best,
Timothy

Re: [ANN] An Org parser for Julia

[Timothy]

Hi Ihor,

> Just FYI that I am getting similar results on your config.org:
> [snip]

Thanks. It’s always nice to see a confirmation of a result. Hopefully in the
near future we’ll be able to run your files through without issue .

All the best,
Timothy

Re: Org-syntax: Intra-word markup

[Ihor Radchenko]

Denis Maier  writes:

>
> Just a furter remark: while zero-width-spaces can be used as a 
> workaround, they may create problems in some export formats. E.g., they 
> will mess up hyphenation in latex. I think if read somewhere that those 
> can be removed with hooks or filters, but I think that shouldn't be 
> necessary.

Can you create an example of such scenario and post it as a bug?
Probably, we just need to strip all zero-width spaces at the basic ox.el
level.

Best,
Ihor

Re: [ANN] An Org parser for Julia

[Ihor Radchenko]

Timothy  writes:

> │ julia> @benchmark parse(Org, config)
> │ BenchmarkTools.Trial: 139 samples with 1 evaluation.
> │  Range (min … max):  34.042 ms … 43.269 ms  ┊ GC (min … max): 0.00% … 16.10%
> │  Time  (median): 34.857 ms  ┊ GC (median):0.00%
> │  Time  (mean ± σ):   35.999 ms ±  2.490 ms  ┊ GC (mean ± σ):  2.63% ±  5.30%
> │ 
> │ █▁
> │   ▃▇██▄▆▄▃▂▃▅▅▅▄▄▁▂▂▃▁▃▂▂▃▂▃▁▁▂▃▁▂▂▁▂ ▂
> │   34 ms   Histogram: frequency by time  43 ms <
> │ 
> │  Memory estimate: 7.17 MiB, allocs estimate: 142185.
> └
>
> It’s worth noting that the first time `parse(Org, config)' is called, it will
> trigger JIT compilation (which for me takes ~15s).
>
> `org-element-parse-buffer' seems to tend to take ~200ms.

Just FYI that I am getting similar results on your config.org:

M-: (let ((gc-cons-threshold #x4000)) (benchmark-run 
(org-element-parse-buffer)))
(0.133567423 0 0.0), which is 133ms

and

@benchmark parse(Org, textorgfile)
BenchmarkTools.Trial: 196 samples with 1 evaluation.
 Range (min … max):  22.235 ms … 81.101 ms  ┊ GC (min … max): 0.00% … 0.00%
 Time  (median): 23.652 ms  ┊ GC (median):0.00%
 Time  (mean ± σ):   25.535 ms ±  5.921 ms  ┊ GC (mean ± σ):  2.56% ± 5.36%

█▃  ▂▂ 
  ▆▅███▇▅▅▁▅██▆▄▄▁▄▁▁▅▁▅▁▁▄▁▁▁▄▁▄ ▄
  22.2 ms  Histogram: log(frequency) by time  51.3 ms <

 Memory estimate: 7.07 MiB, allocs estimate: 139566.

Best,
Ihor

Re: Org-syntax: Intra-word markup

[Ihor Radchenko]

Marco Wahl  writes:

> Is there a recommended way to insert a zero with space?

C-x 8 

Re: Org-syntax: Intra-word markup

[Timothy]

Hi Denis,

> Currently, org syntax doesn’t officially seem to support intra-word emphasis. 
> Am
> I missing something?

I’d describe it as supported via-zero width spaces.

You may be interested in 
.

> If the assessment is correct: Is there a reason for this? And, shouldn’t that
> be officially added?

Do you happen to have any ideas on how this could be achieved? I’d rather not
resort to having to do things like `\ast{}' and `\tilde{}' too much.

All the best,
Timothy

Re: Org-syntax: Intra-word markup

[Ihor Radchenko]

Denis Maier  writes:
> Yes, Juan Manuel. That's it.
>
> See for reference: 
> https://stackoverflow.com/questions/1218238/how-to-make-part-of-a-word-bold-in-org-mode

Please, do not use that stackoverflow answer. It is not officially
supported, breaks exporting, and will not work anymore in future Org
versions. 

Best,
Ihor

Re: Org-syntax: Intra-word markup

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> intra-*word* works just fine for me.
>>
> I think what Denis is referring to is a construction of the type
> *intra*word, which, if I'm not mistaken, is not supported and can only
> be achieved by inserting a zero width space.

I see. We had a discussion about emphasis issues in
https://orgmode.org/list/8735nnq73n.fsf@localhost

The conclusion from there is that supporting such scenarios will
introduce various edge cases. We would need to make the emaphsis parser
more and more complex inevitably introducing errors.

An alternative may be some kind of "forced" emphasis syntax where Org
does not have to guess about the emphasis using non-transparent rules.
But it's what zero width space is for and it is what we recommend in the
Org manual.

Best,
Ihor

Re: Org-syntax: Intra-word markup

[Denis Maier]

Am 02.12.2021 um 12:42 schrieb Marco Wahl:

Hi!


Currently, org syntax doesn't officially seem to support intra-word
emphasis. Am I missing something?


intra-*word* works just fine for me.

Best,
Ihor


I think what Denis is referring to is a construction of the type
*intra*word, which, if I'm not mistaken, is not supported and can only
be achieved by inserting a zero width space.


Is there a recommended way to insert a zero with space?

BTW occasionally I use

(defun mw-insert-zero-width-whitespace ()
  "Insert a space with zero width."
  (interactive)
  (insert ?\x200B))


Thanks and ciao,


Just a furter remark: while zero-width-spaces can be used as a 
workaround, they may create problems in some export formats. E.g., they 
will mess up hyphenation in latex. I think if read somewhere that those 
can be removed with hooks or filters, but I think that shouldn't be 
necessary.


Denis

Re: Org-syntax: Intra-word markup

[Marco Wahl]

Hi!

>>> Currently, org syntax doesn't officially seem to support intra-word 
>>> emphasis. Am I missing something?
>>
>> intra-*word* works just fine for me.
>>
>> Best,
>> Ihor
>
> I think what Denis is referring to is a construction of the type
> *intra*word, which, if I'm not mistaken, is not supported and can only
> be achieved by inserting a zero width space.

Is there a recommended way to insert a zero with space?

BTW occasionally I use

(defun mw-insert-zero-width-whitespace ()
  "Insert a space with zero width."
  (interactive)
  (insert ?\x200B))


Thanks and ciao,
-- 
Marco

Re: Org-syntax: Intra-word markup

[Denis Maier]

Yes, Juan Manuel. That's it.

See for reference: 
https://stackoverflow.com/questions/1218238/how-to-make-part-of-a-word-bold-in-org-mode


Best,
Denis

Am 02.12.2021 um 12:30 schrieb Juan Manuel Macías:

Hi Denis and Ihor,

Ihor Radchenko writes:


Denis Maier  writes:


Currently, org syntax doesn't officially seem to support intra-word
emphasis. Am I missing something?

intra-*word* works just fine for me.

Best,
Ihor

I think what Denis is referring to is a construction of the type
*intra*word, which, if I'm not mistaken, is not supported and can only
be achieved by inserting a zero width space.

Best regards,

Juan Manuel

Re: [ANN] An Org parser for Julia

[Timothy]

Hi Ihor,

> I am wondering how you did the benchmark.
> I just tried the following on my config.org
> ():
>
> The config.org is about 18k lines, but I did not manage to wait enough
> for the parser to return.

Hmm, I just tried yours and I think something in your file is causing it to trip
up. Not sure what though, further investigation is required. For this alone I’m
glad you’ve shared this with me :)

For reference, this is what I’ve been doing:
┌
│ julia> using OrgMode
│ 
│ julia> config = read("/home/tec/.config/doom/config.org", String);
│ 
│ julia> @benchmark parse(Org, config)
│ BenchmarkTools.Trial: 139 samples with 1 evaluation.
│  Range (min … max):  34.042 ms … 43.269 ms  ┊ GC (min … max): 0.00% … 16.10%
│  Time  (median): 34.857 ms  ┊ GC (median):0.00%
│  Time  (mean ± σ):   35.999 ms ±  2.490 ms  ┊ GC (mean ± σ):  2.63% ±  5.30%
│ 
│ █▁
│   ▃▇██▄▆▄▃▂▃▅▅▅▄▄▁▂▂▃▁▃▂▂▃▂▃▁▁▂▃▁▂▂▁▂ ▂
│   34 ms   Histogram: frequency by time  43 ms <
│ 
│  Memory estimate: 7.17 MiB, allocs estimate: 142185.
└

It’s worth noting that the first time `parse(Org, config)' is called, it will
trigger JIT compilation (which for me takes ~15s).

`org-element-parse-buffer' seems to tend to take ~200ms.

> Also, the tests I mentioned are with my latest commit for
> org-element-parse-buffer and on native-compiled Emacs.

I’m on native-compiled Emacs, but ~12 commits behind.

>> Org LSP
> Thanks for reminding about this. I have seen it, forgot it, and now
> reinvent the idea :D.

I’m just hoping I’ll get to it / get help eventually .

> Also, it would be great to have a unified test set to verify third-party
> parsers and org-element parser.

You know, I’ve had the same thought .

>>> tree-sitter vs. org-element on 15M Org file
>>
>> Might you have a link to this file? I’d be interested to try it.
>
> That’s my personal notes file. I can test it for you if you give me the
> instructions.

Cool, since your config seems to have revealed some issues, it would probably be
worth waiting till I’ve sorted that out.

All the best,
Timothy

Re: Org-syntax: Intra-word markup

[Juan Manuel Macías]

Hi Denis and Ihor,

Ihor Radchenko writes:

> Denis Maier  writes:
>
>> Currently, org syntax doesn't officially seem to support intra-word 
>> emphasis. Am I missing something?
>
> intra-*word* works just fine for me.
>
> Best,
> Ihor

I think what Denis is referring to is a construction of the type
*intra*word, which, if I'm not mistaken, is not supported and can only
be achieved by inserting a zero width space.

Best regards,

Juan Manuel 

Re: org-element-cache warning even when off

[Ihor Radchenko]

Colin Baxter   writes:

> I have done this but now do not see any warning. Further, I now don't
> seem to be able to re-produce the issue at all. It could that the
> original warning was spurious and reflected some stale state. I did have
> multiple emacsen open at the time.

Note that I fixed some parser error a dozen of hours ago. Maybe it
helped. In any case, let us know if you encounter a similar warning
in future.

Best,
Ihor

Re: Org-syntax: Intra-word markup

[Ihor Radchenko]

Denis Maier  writes:

> Currently, org syntax doesn't officially seem to support intra-word 
> emphasis. Am I missing something?

intra-*word* works just fine for me.

Best,
Ihor

Re: org-element-cache warning even when off

[Colin Baxter ]

> Ihor Radchenko  writes:

> Colin Baxter   writes:
>> I do not have an org-persist cache present. So I wonder where is
>> the cache that I am supposedly corrupting.

> That warning is shown when org-element--parse-to throws an error
> (the parser fails). Apparently, there is some problem with Org
> parser.

>> Warning (org-element-cache): org-element--cache: Cache corruption
>> detected in todo.habits.org::539. Resetting.

> Can you try to copy the file text around 539 buffer point into
> separate Org file and check if you are seeing this kind of error
> there?

I have done this but now do not see any warning. Further, I now don't
seem to be able to re-produce the issue at all. It could that the
original warning was spurious and reflected some stale state. I did have
multiple emacsen open at the time.

I normally have org-persist on, but occasionally I need to do multiple
edits on an agenda file. On those occasions, I switch org-persist off
and move its cache out of the way in order to avoid cache corruption
warnings and to keep the syntax highlighting. I will look out for any
cache warnings if I edit any agenda files by hand again.


Best wishes,

Colin Baxter.

Re: [ANN] An Org parser for Julia

[Ihor Radchenko]

Timothy  writes:

> I’ve actually had a brief look at my performance using my Emacs config file
> (which is ~10k lines). On this, my parser is about ~5x faster than 
> org-element.
> On a smaller file like the project’s readme it’s closer to ~10x faster. I’ve
> also noticed that I can multithread the parsing, which produces a ~9x speedup 
> on
> my computer. So, that would be ~40-90x faster than org-element. I have yet to 
> do
> much profiling/benchmarking/optimisation though, I’m still in the “feature
> adding” phase. This means that it could well slow down as I add more for it to
> recognise, but there are probably also unrealised potential performance
> improvements.

I am wondering how you did the benchmark.
I just tried the following on my config.org
(https://github.com/yantar92/emacs-config):

cd path/to/OrgMode.jl
julia1.6
push!(LOAD_PATH, pwd())
using OrgMode
orgfile = open("/home/yantar92/Git/emacs-config/config.org")
textorgfile = read(orgfile, String)
parse(Org, textorgfile)

The config.org is about 18k lines, but I did not manage to wait enough
for the parser to return.

Multithread looks promising though.

Also, the tests I mentioned are with my latest commit for
org-element-parse-buffer and on native-compiled Emacs.

>> Maybe we should implement a Elisp LSP server instead of many individual
>> parsers in different languages?
>
> For the sake of tools that operate on Org files, not just the Org editing
> experience, I think it’s quite good if we have a selection of /good/ parsers
> available for different languages. However, I also think an LSP server would 
> be
> good. That’s why I have , even if I 
> haven’t
> spent anywhere near as much time on it as I would like (it’s barely a skeleton
> at the moment).

Thanks for reminding about this. I have seen it, forgot it, and now
reinvent the idea :D.

Also, it would be great to have a unified test set to verify third-party
parsers and org-element parser.

>> tree-sitter vs. org-element on 15M Org file
>
> Might you have a link to this file? I’d be interested to try it.

That's my personal notes file. I can test it for you if you give me the
instructions.

Best,
Ihor

Re: Org babel Python and R, table not transformed when :var is called ?

[Sébastien Rey-Coyrehourcq]

Hi,

I found a solution using *Wrapping*, adding a #+NAME to #+RESULTS block 
resolve the problem.


This is not defined / described into the doc, and actually i found this 
process a little anti-intuitive. #+RESULTS has already a name, 
resulting/linked from/to the execution of mypythoncode ...


Best regards


#+NAME: attr_wrap
#+BEGIN_SRC sh :var data="" :results output
  echo "#+NAME: cities"
  echo "$data"
#+END_SRC

#+NAME:mypythoncode
#+begin_src python  :results value raw :output  :post 
attr_wrap(data=*this*) :return tabulate(df, headers=df.columns, 
tablefmt='orgtbl')

import numpy as np
import pandas as pd
from tabulate import tabulate
df = pd.DataFrame(np.random.randint(0,10,size=(10, 4)), 
columns=list('ABCD'))

#+end_src

Le 01/12/2021 à 09:04, Sébastien Rey-Coyrehourcq a écrit :


Hi there,

Perhaps it's a bug, or something i don't understand, i post on reddit 
(https://www.reddit.com/r/emacs/comments/r5yt4a/r_talking_with_python_using_orgtable_not_work/) 
to see if people on org community know the problem.


I cross post here to see if it's a know bug or somethings ?

There is something i don't understand,
a difference between behavior of org-babel and org-mode when you use 
org table to pass data using or not using :var.


|#+NAME:mypythoncode #+begin_src python :results value raw :output 
:return tabulate(df, headers=df.columns, tablefmt='orgtbl') import 
numpy as np import pandas as pd from tabulate import tabulate df = 
pd.DataFrame(np.random.randint(0,10,size=(10, 4)), 
columns=list('ABCD')) #+end_src #+RESULTS: mypythoncode | | A | B | C 
| D | |---+---+---+---+---| | 0 | 0 | 9 | 6 | 0 | | 1 | 2 | 9 | 0 | 4 
| | 2 | 9 | 6 | 0 | 1 | | 3 | 6 | 1 | 8 | 1 | | 4 | 4 | 2 | 1 | 4 | | 
5 | 2 | 1 | 1 | 1 | | 6 | 4 | 8 | 9 | 0 | | 7 | 1 | 4 | 8 | 7 | | 8 | 
9 | 3 | 2 | 5 | | 9 | 5 | 0 | 7 | 3 | #+NAME:lib-R #+HEADER: :var 
code=mypythoncode #+begin_src R :results output library(ggplot2) 
library(dplyr) library(lubridate) str(code) #+end_src #+RESULTS: lib-R 
: chr "| | A | B | C | D |\n|+-+-+-+-|\n| 0 | 8 | 
0 | 5 | 2 |\n| 1 | 2 | "| __truncated__ |


As you see, the org table is not recognized as a dataframe by R.

If i replace by a basic org table :

|||#+NAME: any_data | | parameter | value | |---+---+---| | 
0 | heats | 30 | | 1 | heats | 30 | #+NAME:lib-R #+HEADER: :var 
code=any_data #+begin_src R :results output library(ggplot2) 
library(dplyr) library(lubridate) str(code) #+end_src #+RESULTS: lib-R 
: 'data.frame': 2 obs. of 3 variables: : $ X : int 0 1 : $ parameter: 
chr "heats" "heats" : $ value : int 30 30 |||


That works...

Best regards,

||

Org-syntax: Intra-word markup

[Denis Maier]

Hi everyone,

while we're at discussing org syntax anyway, I thought it's time to 
bring up another syntax question:
Currently, org syntax doesn't officially seem to support intra-word 
emphasis. Am I missing something?
If the assessment is correct: Is there a reason for this? And, shouldn't 
that be officially added?


Best,
Denis

Re: [ANN] An Org parser for Julia

[Timothy]

Hi Ihor,

> I am wondering how the third-party parsers are going to scale for larger
> Org files. I did some simple testing in the past, and it seems that only
> tree-sitter can potentially get sufficiently close to org-element in
> terms of performance.

I’ve actually had a brief look at my performance using my Emacs config file
(which is ~10k lines). On this, my parser is about ~5x faster than org-element.
On a smaller file like the project’s readme it’s closer to ~10x faster. I’ve
also noticed that I can multithread the parsing, which produces a ~9x speedup on
my computer. So, that would be ~40-90x faster than org-element. I have yet to do
much profiling/benchmarking/optimisation though, I’m still in the “feature
adding” phase. This means that it could well slow down as I add more for it to
recognise, but there are probably also unrealised potential performance
improvements.

> Maybe we should implement a Elisp LSP server instead of many individual
> parsers in different languages?

For the sake of tools that operate on Org files, not just the Org editing
experience, I think it’s quite good if we have a selection of /good/ parsers
available for different languages. However, I also think an LSP server would be
good. That’s why I have , even if I haven’t
spent anywhere near as much time on it as I would like (it’s barely a skeleton
at the moment).

> tree-sitter vs. org-element on 15M Org file

Might you have a link to this file? I’d be interested to try it.

All the best,
Timothy

Re: org-element-cache warning even when off

[Ihor Radchenko]

Colin Baxter   writes:

> I do not have an org-persist cache present. So I wonder where is the
> cache that I am supposedly corrupting.

That warning is shown when org-element--parse-to throws an error (the
parser fails). Apparently, there is some problem with Org parser.

> Warning (org-element-cache): org-element--cache: Cache corruption detected in 
> todo.habits.org::539. Resetting.

Can you try to copy the file text around 539 buffer point into separate
Org file and check if you are seeing this kind of error there?

>  The error was: (error "Not an Org time string: <2021-12-0 Fri .+1d")

May it happen that the text near 539 buffer point looks like "CLOCK:
[2021-10-22 Fri 10:41]--[2021]"? If so, the error may be related to
https://orgmode.org/list/87v90j2gq4.fsf@localhost

P.S. I updated the warning text on main.

Best,
Ihor

Re: [ANN] An Org parser for Julia

[Ihor Radchenko]

Timothy  writes:

> I’ve gone heavily into Julia over the past year, and I recently
> thought it would be nice if an Org parser existed for it — so I made one!
>
> 
> 

I am wondering how the third-party parsers are going to scale for larger
Org files. I did some simple testing in the past, and it seems that only
tree-sitter can potentially get sufficiently close to org-element in
terms of performance. Maybe we should implement a Elisp LSP server
instead of many individual parsers in different languages?

---

tree-sitter vs. org-element on 15M Org file
org-element-parse-buffer
(16.090262757 1 0.736568360962)

org-element-parse-buffer 'element granularity
(7.688000744 0 0.0)
8sec

tree-sitter via https://github.com/milisims/tree-sitter-org
parsed down to 58% of the buffer in 5.3sec and exited with error
extrapolates to ~9sec

Racket's brack via https://github.com/tgbugs/laundry
failed to finish parsing in reasonable time. Cancelled at 10m11.436s

Clojure parser via https://github.com/200ok-ch/org-parser
failed to finish parsing with java.lang.OutOfMemoryError: GC overhead limit 
exceeded
Running time 8m28.078s

Best,
Ihor

org-element-cache warning even when off

[Colin Baxter ]

Hello,

I have

#+begin_src emacs-lisp
(setq org-element-use-cache nil)
(setq org-element-cache-persistent nil)
#+end_src

Yet when editing by hand a time string in a today habit I get the
warning:

--8<---cut here---start->8---

Warning (org-element-cache): org-element--cache: Cache corruption detected in 
todo.habits.org::539. Resetting.
 The error was: (error "Not an Org time string: <2021-12-0 Fri .+1d")
 Backtrace:
nil

--8<---cut here---end--->8---

I do not have an org-persist cache present. So I wonder where is the
cache that I am supposedly corrupting.

Best wishes

Colin Baxter.

Re: [PATCH] Fix ob-plantuml over TRAMP

[Timothy]

Hi Guillaume,

Thanks for picking this up and submitting a patch.

Have you considered using `tramp-handle-file-exists-p'? I’m not overly familiar
with tramp or this sort of issue, but it looks like it could be exactly what we 
want.

> My Emacs Workflow involves connecting to a dev server over SSH so I can use my
> machines as thin clients and avoid synchronizing files, for that I do pretty
> much everything over TRAMP as I don’t want to lose the benefits of GUI Emacs.
> While everything mostly works impressively fine, I noticed writing my
> specifications that ob-plantuml fails to generate diagrams.
>
> It seems to me that there is a redundant check which uses `file-exists-p` even
> if using TRAMP, the plantuml jar is located on the remote server, so it fails
> with an error even though the command to actually render the diagrams works
> fine.

All the best,
Timothy

Re: [PATCH] ob-shell-test, test-ob-shell and introduction

[Timothy]

Hi Matt,

>  > [FSF copyright assignment]. Have you done that yet?
>
> I just verified with my employer that my contract grants an exception for this
> project. Just emailed the request to ass...@gnu.org. Also, got access from
> Bastien for worg. I figure it’s probably best to reserve any more changes ’til
> the paper work is done?

Great to hear that won’t get in the way of things . Feel free to develop and
share patches before the assignment is complete, we’ll just wait till it’s gone
through before merging (the process should just be a quick email or two and take
no more than a few days, just let us know if it’s dragging out).

Hope that helps.

All the best,
Timothy

Some commentary on the Org Syntax document

[Timothy]

Hi All (& Nicolas in particular again),

With my recent efforts to write a parser based on
, I’ve developed a few thoughts on
that document. Hopefully, they can lead to some improvements and
clarifications.



As a general comment, in many places the Org Syntax document states what
characters a component can contain, but not what objects/elements. This feels
like a bit of a hole in the current specifications.


Sections


Heading
───

⁃ Ok, so `TITLE' can have any character but a newline, but what Org components 
can it contain?
  I’m going to assume any object?


Affiliated Keywords
═══


Greater Elements


Greater blocks
──

⁃ It is not explained what is ment by a “special block”
⁃ Aren’t lines starting with `#+' also quoted by a comma?


Drawers and Property Drawers


⁃ “Contents can contain any element but another drawer”
  • Does “any element” mean “any Element or Greater Element”


Dynamic Blocks
──

⁃ It is not specified what `CONTENTS' may be
⁃ Surely `PARAMETERS' cannot contain a newline?


Plain Lists and Items
─

⁃ It is not completely clear what content an item may have.
  I assume any Object?


Tables
──

⁃ Surely newlines are not allowed in `FORMULAS'


Elements


Clocks
──

Two allowed forms are listed, but are all four of the below allowed or only two?
┌
│ CLOCK: INACTIVE-TIMESTAMP
│ CLOCK: INACTIVE-TIMESTAMP DURATION
│ CLOCK: INACTIVE-TIMESTAMP-RANGE
│ CLOCK: INACTIVE-TIMESTAMP-RANGE DURATION
└

All the best,
Timothy

[ANN] An Org parser for Julia

[Timothy]

Hi Everyone,

I’ve gone heavily into Julia over the past year, and I recently
thought it would be nice if an Org parser existed for it — so I made one!




It’s just over a week since I started, so it’s fairly young, but I’m pretty
happy with the way it’s shaping up . To give you an idea, here’s some example
usage from the readme:

┌
│ text1 = org"Some *Org* markup, written with easy using the ~org\"\"~ macro."
│ parsetree(text1)  # show the generated parse tree
│ 
│ text2 = parse(Org, "Some *Org* markup, written with easy using the ~parse~ 
function.")
│ diff(text1, text2)  # show the components of the parse trees that differ
│ 
│ dochead = @doc OrgMode.Heading  # the documentation for the Heading component 
(::Org)
│ org(dochead)  # generate Org text that produces the OrgMode.Heading object
│ string(dochead)  # as above, but produces a String
│ 
│ parse(Org, string(dochead)) == dochead  # round-trip equality
│ 
│ filtermap(dochead, [OrgMode.SourceBlock], s -> s.lang)  # get the lang of 
each source block
└

There’s also a bit of an ulterior motive here, I’ve been rather interested in
the Org syntax and how easy it is to write tools for it outside of Emacs, and
I’ve been thinking that writing a parser would be a great way to find out and
allow me to make some more informed comments on
, hopefully pushing it just a bit
closer to having “(draft)” lopped off the title .

You can expect to see another email from me with some comments the Org Syntax
document shortly.

All the best,
Timothy

Re: Bibliographies on export with ox-context and ox-epub

[juh]

Am 01.12.21 um 16:01 schrieb Eric S Fraga:

What completion engine are you using?  In selectrum, typing C-j at that
point finishes the completion.  Other engines will differ.  You might
also try up-arrow and RET.

Thanks a lot. I use selectrum and would've never found this door out.

juh

Re: Orgdown: negative feedback & attempt of a root-cause analysis

[Greg Minshall]

Karl,

thanks for all of this, and for writing and posting your blog entry
(words of caution for many).

my thoughts on your project are something like this:

- i think non-emacs tools to deal with org mode files is a Good Thing.

- for me, the main motivation is to allow *me* to share an org mode
  file with someone -- say via a git repo -- and have them be able to do
  something reasonable, if restricted, with it -- extract the code,
  query subtrees or tables, etc. -- without recourse to emacs.

- i think collaborative editing with non-emacs users should be not be a
  goal of *this* endeavor.

- for me, your main invention, and the place (non pro-versus-con)
  discussion should focus, is on your levels: what's at level 1, at what
  level is org-mode itself, etc.  there are some tricky things here
  (e.g., for tables, what to do with hlines, with column width
  specifications, at the various "conformance levels"?)

- and, sigh, i prefer some other name; like "org mode syntax (level 0)".
  maybe it will acronymize into omsl0 (gasp!).  who knows.  i do think
  "orgdown" was a clever choice, but i'm not a fan.

cheers, Greg