>>> "IR" == Ihor Radchenko writes:
> Uwe Brauer writes:
>>> It might be changed. Currently, we mimic the behavior of
>>> org-yank-subtree, so that we always insert captured entry under the
>>> correct level regardless of the capture target. For example, when you
>>> use OLP, the level will be
Ihor Radchenko writes:
>> I agree it's a problem -- if there are multiple blocks with the same
>> session but different ":dir" arguments, then a ":file" result of the
>> second block will be relative to the wrong :dir.
>>
>> This seems like a longstanding problem, and affects both async and
>>
Hi, list moderators.
I'd like to submit a code to this mailing list without subscribing it.
Or, if you can forward the following to the list.
Thanks a lot for keeping this list.
[Wishitem] Show the current node name in the
[ CCing Timothy and Karthic ]
Jacob Fong writes:
> It appears that the math-matching regexes are hard-coded in
> `org-format-latex`, as seen in this line:
>
> ```
> (let* ((math-regexp "\\$\\|[([]\\|^[ \t]*begin{[A-Za-z0-9*]+}")
> ```
>
> As a result of this, :matchers does not work as
Uwe Brauer writes:
>> It might be changed. Currently, we mimic the behavior of
>> org-yank-subtree, so that we always insert captured entry under the
>> correct level regardless of the capture target. For example, when you
>> use OLP, the level will be adjusted.
>
>> May you please explain more
Hey everyone,
It appears that the math-matching regexes are hard-coded in
`org-format-latex`, as seen in this line:
```
(let* ((math-regexp "\\$\\|[([]\\|^[ \t]*begin{[A-Za-z0-9*]+}")
```
As a result of this, :matchers does not work as documented, for
example with `org-latex-preview`.
>>> "IR" == Ihor Radchenko writes:
> Uwe Brauer via "General discussions about Org-mode."
> writes:
>>> Uwe Brauer writes:
>>
>> Thanks for you answer
>>> This is expected. As per `org-capture-templates' docstring, "entry"
>>> capture type inserts top-level entries into files:
>>
>>> entry
Ypo writes:
> I can't share my private org files. And I find myself unable to isolate
> the causes of the possible errors.
One strategy that might help is to "bisect" the Org file by repeatedly
splitting it into 2 files, and exporting each, to find where the
problematic entries are. By
Pedro Andres Aranda Gutierrez writes:
> This is another low hanging fruit. I was a bit annoyed to have to leave an
> empty label for inlined footnotes (à la LaTeX)... I don't know if this
> qualifies as a TINYCHANGE...
Don't you have FSF copyright assignment?
--
Ihor Radchenko // yantar92,
Jack Kamm writes:
> Ihor Radchenko writes:
>
>> The patch generally looks reasonable, although I am slightly concerned
>> about interaction between :dir and session we describe in the manual:
>>
>> When ‘dir’ is used with ‘session’, Org sets the starting directory
>> for a new session.
Samuel Wales writes:
>> May you please elaborate what you want to add to the manual and where?
>
> had been merely thinking mentioning non-brittleness for newcomers.
> in handling links.
Isn't it already mentioned?
... In addition or alternatively, depending on the value of
Thanks, Ihor
I can't share my private org files. And I find myself unable to isolate
the causes of the possible errors.
I think I will keep waiting till somebody shares an easy and robust way
to get an .ics calendar from org files.
Best!
On 02/02/2024 22:25, Ihor Radchenko wrote:
Ypo
On Saturday, 3 Feb 2024 at 13:13, Ypo wrote:
> I think I will keep waiting till somebody shares an easy and robust
> way to get an .ics calendar from org files.
Not sure what you are expecting but I can show you my (elided) shell
script that generates a single ics file from multiple org files:
Ihor Radchenko writes:
> Joshua Honeycutt writes:
>
>> I added a class attribute to an example block as in:
>>
>>#+ATTR_HTML :class cmdout
>>#+BEGIN_EXAMPLE
>>text text text
>>#+END_EXAMPLE
>>
>> I expected this to produce a html tag like:
>>
>>
>>
>> but the output was
Hi,
On Sat, 3 Feb 2024 at 10:27, gusbrs wrote:
> On Sat, 3 Feb 2024 at 09:32, Ihor Radchenko wrote:
> > Would it make sense to add a new `org-blank-after-new-entry'
> > customization that will provide explicit user control over what Org does
> > when inserting a new heading?
>
> Looking from
Hi Ihor,
Thanks for looking into this.
On Sat, 3 Feb 2024 at 09:32, Ihor Radchenko wrote:
> The number of blank lines after newly inserted is not defined by Org
> mode, unlike the number of blank lines before heading that is controlled
> by `org-blank-before-new-entry'.
Well, "not defined" is
"Rick Lupton" writes:
> I see. Updated to get the search string first, before the possible
> properties draw appears.
>
> To make this work I changed `org-link-precise-link-target': instead of
> accepting the RELATIVE-TO argument and rejecting unsuitable targets
> internally, it now sets a
gusbrs writes:
> I recently upgraded to Emacs 29.2 (from 29.1) and observed that
> `org-insert-heading-respect-content' has changed behavior with regard
> to how it handles blank lines at the end of the entry at which the
> command was called.
>
> Consider the following document (with "|"
18 matches
Mail list logo
