Johannes Mueller writes:
> When using refill-mode in combination with org-mode adding a new section or a
> list item at the end of the buffer, obviously because refill-mode steps in and
> deletes the line break before the headline marker or the list marker.
I would say that it is a bug in refill
Hi everyone,
This is my first post to Org mailing list.
I would like to introduce an add-on package I have been developing for
about one year and ask for discussion / advice.
The package is named "Org-transclusion", and is available on GitHub at
https://github.com/nobiot/org-transclusion. Simpl
Hi Noboru,
Noboru Ota writes:
> I would like to introduce an add-on package I have been developing for
> about one year and ask for discussion / advice.
>
> The package is named "Org-transclusion", and is available on GitHub at
> https://github.com/nobiot/org-transclusion. Simply put, it lets yo
Hi, in org.el , when defining the mode there's the code
(setq bidi-paragraph-direction 'left-to-right)
which makes everything left-to-right instead of 'nil which smartly
aligns paragraphs either LTR or RTL according to the language of that
paragraph.
nil is Emacs default. I don't understand
Daniel Fleischer writes:
> nil is Emacs default. I don't understand why Org chooses to align
> everything to the left, disregarding any RTL language. Org works great
> with RTL and even with mixed languages, as many people can attest.
See https://lists.gnu.org/archive/html/emacs-devel/2011-09/ms
Noboru Ota writes:
> This is my first post to Org mailing list.
Welcome ;)
> Is this type of add-on packages worth considering for inclusion into
> Org? I am asking this question without knowing the practice of how
> these things are considered in this mailing list; apologies if I am
> missing
Hi Jason, sorry for the late reply.
Jason Ross writes:
> I'm looking at declaring a "figure" block the way you are, but
> `org-element-map'ing over the links inside the block and processing them
> with the "normal" link-handling machinery. That way, image options work
> the same way in a subfigur
Ihor Radchenko writes:
> See https://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00285.html
OK, so 10 years ago on Emacs 24 it might have caused some slowdown on
large Org files. It wasn't clear if these people needed RTL or not,
because I set it to nil as soon as I open my Org files. I gue
On 30/10/2021 00:58, Greg Minshall wrote:
Some hash-based build systems are mentioned in that thread. Since that
time more more similar tools have appeared, e.g. buck,
reimplementations of DJB's redo https://cr.yp.to/redo.html
i think different people will settle on different build tools.
G
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
https://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org mailing list.
Daniel Fleischer writes:
> Ihor Radchenko writes:
>> See https://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00285.html
>
> OK, so 10 years ago on Emacs 24 it might have caused some slowdown on
> large Org files. It wasn't clear if these people needed RTL or not,
> because I set it to nil
Aaron Jensen writes:
> I don't have a consistent repro, but I am seeing this error often. At
> different times it is in different files and lists different nodes.
Thanks for reporting!
> Warning (emacs): org-element--cache: Unregistered buffer modifications
> detected. Resetting.
> If this war
Max,
thanks for the reply.
> In the meanwhile I realized that check for modification by user should
> be performed *before* tangle, and hash to detect changes is
> appropriate for such purpose. I think, a copy of tangled file just to
> detect modification will cause some tension from users.
i gu
On Sat, Oct 30, 2021 at 11:37 AM Ihor Radchenko wrote:
>
> Aaron Jensen writes:
>
> > I don't have a consistent repro, but I am seeing this error often. At
> > different times it is in different files and lists different nodes.
>
> Thanks for reporting!
>
> > Warning (emacs): org-element--cache:
Am Samstag, dem 30. Oktober 2021 schrieb Marvin Gülker:
> trying to export the following org-document results in an Elisp error:
>
> #+TITLE: Test
> #+AUTHOR: Testauthor
> #+LANGUAGE: de
> #+bibliography: /tmp/mwe/mwe.bib
> #+cite_export: csl /tmp/mwe/juristische-schulung.csl
>
On Sat, Oct 30, 2021 at 12:45 PM Aaron Jensen wrote:
>
> On Sat, Oct 30, 2021 at 11:37 AM Ihor Radchenko wrote:
> >
> > Aaron Jensen writes:
> >
> > > I don't have a consistent repro, but I am seeing this error often. At
> > > different times it is in different files and lists different nodes.
>
Aaron Jensen writes:
>> Do you always see "Current command: nil"? If you do, do you have any
>> minor modes that change text in Org buffers?
>
> I don't know, but I'll keep an eye out for the next time it happens.
If possible, can you also upgrade to latest main? I just pushed a patch
providing
Aaron Jensen writes:
> I just got this warning:
>
> Warning (emacs): org-element--cache: Added org-data parent to
> non-headline element
This is a bad one. I was really hoping that I fixed it. Can you set
org-element--cache-self-verify to 'backtrace before loading Emacs and
post the full backtra
On Sat, Oct 30, 2021 at 10:46 PM Ihor Radchenko wrote:
>
> Aaron Jensen writes:
>
> >> Do you always see "Current command: nil"? If you do, do you have any
> >> minor modes that change text in Org buffers?
> >
> > I don't know, but I'll keep an eye out for the next time it happens.
>
> If possibl
Scott Otterson writes:
> I just updated to org v 9.5, and now, when I open an org file, I get a
> cache error message (between the '=' lines below). Before 9.5, I didn't
> have this problem.
Thanks for reporting! We are enabling org-element-cache by default.
That's where the warnings are coming
20 matches
Mail list logo
