Ihor Radchenko writes:
> See the attached patch.
Applied onto main via f095cfc3c.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f095cfc3c0c0905fdfb95ad2485e4a7b9f5a1a47
Best,
Ihor
Ihor Radchenko writes:
> Caleb Chase writes:
>
>> I discovered a bug with org-capture and org-capture kill when
>> canceling an item or plain type template on a heading that has only an
>> empty line for content. Minimal reproduction is as follows:
>
> The fix is attached.
> The reason why this
David Lukeš writes:
> Ihor: Thank you for the feedback! I'll send a proper patch then.
Did you get a chance to work on this?
Best,
Ihor
Matt Huszagh writes:
> This patch fixes an issue in which captions for custom listing
> environments are not converted correctly. To illustrate the issue,
> take the following MWE.
Since the original issue cannot be reproduced (see the other email in
the thread) I am closing this.
Canceled.
Max Nikulin writes:
>> All the above makes sense. Do I miss something?
>
> To be precise, \date is not exported to LaTeX file, but current date
> appears in PDF. That is why I consider the change as a breaking one.
>
> Try to export to PDF the following document.
>
> >8
> #+options:
András Simonyi writes:
>> This is an important point. I think that we should describe this gotcha
>> in the "Bibliography printing". oc-basic and oc-csl just print the list
>> of bibliography entries, while oc-bibtex/oc-natbib/oc-biblatex insert a
>> separate section. It is a very important
On 31/07/2022 07:53, Ihor Radchenko wrote:
Max Nikulin writes:
(let ((date (and (plist-get info :with-date) (org-export-get-date
info
- (format "\\date{%s}\n" (org-export-data date info)))
+ (cond date
I would consider (plist-get info :with-date) instead of date here
András Simonyi writes:
> the attached patch adds support for filter-based sub-bibliographies in the
> "csl"
> org-cite export processor. It supports the same syntax for specifying
> filters as the biblatex processor and supports some of the biblatex
> filter types, concretely, entry-type and
Tor Kringeland writes:
> Ihor Radchenko writes:
>
>> Could you please elaborate why you prefer not folding drawers in
>> `org-clock-goto'?
>
> If I already unfolded a drawer (for example with notes), then I want to
> keep it open, at least as long as the heading itself is unfolded.
Should be
Ihor Radchenko writes:
> In fact, forcefully folding the drawers is relatively recent addition by
> Nicolas in 1027e0256903bc2.
>
> I am attaching the patch making drawer folding controllable via optional
> argument. WDYT?
No objections have been given.
Applied onto main via 785f003de with
Hi,
I've managed to get some free time to remake this list, following Maxim
Nikulin's suggestion
(https://list.orgmode.org/orgmode/taeb0a$r62$1...@ciao.gmane.io/). It's no
longer an anonymous list and I agree it now has a more robust structure
with name fields. I have also added the `:lang-name'
Max Nikulin writes:
>> (let ((date (and (plist-get info :with-date) (org-export-get-date
>> info
>> - (format "\\date{%s}\n" (org-export-data date info)))
>> + (cond date
>
> I would consider (plist-get info :with-date) instead of date here to
> allow to suppress date in
On 7/30/22 12:56 AM, Ihor Radchenko wrote:
> Hraban Luyat writes:
>
>> This is my first org-mode patch, all comments welcome :). I signed a
>> copyright assignment to the FSF 2021-07-12.
>
> Thanks for the contribution!
>
> Bastien, could you please check the FSF records?
>
> The patch looks good
On 29/07/2022 19:49, emacs--- via General discussions about Org-mode. wrote:
In the attachment you can find a patch which omits an empty \date{} line in
a latex document when the option to include the date is set to nil or when
no date is provided. This empty date line can cause problems is
On 30/07/2022 13:49, Ihor Radchenko wrote:
Samuel Wales writes:
$[emphasis :position beg :type bold :display "*"]bold text$[emphasis
:position end :type bold :display "*"]
This is similar to another recent idea about inline special blocks.
Among other things, we discussed supplying
On 30/07/2022 15:02, Ihor Radchenko wrote:
Hugo Heagren writes:
The rx-to-string call may still suffer from the described edge case.
Yes, I think this is a good idea.
(and all-prefixes ...)
I'm not sure what you mean, but I don't think it will work.
I mean
(and ,all-prefixes
Uwe Brauer writes:
>> Headline markup has the top priority all the times.
> I am confused
Never mind then. I was explaining something you did not look for.
pinm...@cas.cat writes:
> on:
>
> https://orgmode.org/worg/org-contrib/babel/header-args.html
>
> points to:
>
> https://orgmode.org/manual/Specific-header-arguments.html
>
> which is 404
Confirmed.
> I think the correct link is:
>
>
on:
https://orgmode.org/worg/org-contrib/babel/header-args.html
points to:
https://orgmode.org/manual/Specific-header-arguments.html
which is 404
I think the correct link is:
https://orgmode.org/manual/Using-Header-Arguments.html#Using-Header-Arguments
OpenPGP_0x9D64597C3A982DCA.asc
Matt Huszagh writes:
> These are nice ideas, and ones I hadn't considered. Thanks for the
> suggestions! I'll think about it a bit and may modify the patch
> accordingly.
May I ask if you further considered changing the patch?
Best,
Ihor
Hello Ihor.
Ihor Radchenko writes:
> Well. You convinced me. If Asymptote has very stable syntax and major
> features, it probably makes more sense to maintain it within Org or
> within Org community.
If Bastien shows the green light, I am looking forward to giving back
something to the
That makes perfectly sense. Thank you!
On Sat, 30 Jul 2022, 10:55 Ihor Radchenko, wrote:
> One thing that's still bugging me though is why the table would not hang
>> with the older version of org-mode. As far as I can tell nothing has
>> changed around tables between 9.5.2 and 9.5.4. Do you
>
> One thing that's still bugging me though is why the table would not hang
> with the older version of org-mode. As far as I can tell nothing has
> changed around tables between 9.5.2 and 9.5.4. Do you have any idea what
> could cause the difference in behaviour?
`org-string-width` is now
Hello Ihor,
thanks for your reply, and thanks for further debugging the issue. I
created an issue for evil here:
https://github.com/emacs-evil/evil/issues/1642. Feel free to add some more
details to my report.
One thing that's still bugging me though is why the table would not hang
with the
Adding Org ML back to CC.
Hugo Heagren writes:
>> The rx-to-string call may still suffer from the described edge case.
>
> Yes, I think this is a good idea.
>
>> (and all-prefixes ...)
>
> I'm not sure what you mean, but I don't think it will work.
I mean
(and ,all-prefixes (rx-to-string `(:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Ihor Radchenko writes:
> Sharon Kimble writes:
>
>> foo$ git pull
>> - From https://git.savannah.gnu.org/git/emacs/org-mode
>>5be0c709b3..d37c0ee5fa main -> origin/main
>> Updating 5be0c709b3..d37c0ee5fa
>> Fast-forward
>> lisp/org.el
Samuel Wales writes:
> i am not in a position to judge \-- but i like the idea of not having
> zws be used, and expect you have thought it out.
>
>
> just an idea: something approximately like this might work, or
> something like john kitchen's poc implementation of it might. this is
> called
Hugo Heagren writes:
> The test fails because of an error in `rx-to-string', which is called
> by `org-insert-link'. It was failing because I have the following
> code:
>
> ,
> | (rx-to-string `(: string-start (submatch (or ,@all-prefixes)) ":"))
> `
> ...
> We could just as easily do it
> Uwe Brauer writes:
> Thanks!
> To clarify, when you have
> * Heading
> #+begin_comment
> * Lorem ipsum
> #+end_comment
> it is not seen by Org as comment block.
> Instead, what Org "sees" is
>
> * Heading
>
> #+begin_comment
>
>
>
> * Lorem ipsum
>
> #+end_comment
>
>
>
Uwe Brauer writes:
>> Uwe Brauer writes:
>
>> I am sorry, but I am not familiar with the feature you are referring to.
>
> I applied your patch and did a bit of testing: works flawlessly.
Thanks!
>> Either way, both src and comment blocks are supposed to contain
>> arbitrary non-parseable
> Uwe Brauer writes:
> I am sorry, but I am not familiar with the feature you are referring to.
I applied your patch and did a bit of testing: works flawlessly.
> Either way, both src and comment blocks are supposed to contain
> arbitrary non-parseable text, which should not contribute to the
31 matches
Mail list logo
