From: Tim Cross <theophilusx@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: Large source block causes org-mode to be unusable
Date: Tue, 22 Jun 2021 14:48:57 +1000 [thread overview]
Message-ID: <87lf72lbmy.fsf@gmail.com> (raw)
In-Reply-To: <CA+G3_PNfrK=w2Sw4_udZC_jSDRULfGutJNNkFXe1ZFH7yCKxSQ@mail.gmail.com>
Tom Gillespie <tgbugs@gmail.com> writes:
>> That said, I think keeping 2000 lines of source code inside an
>> org src block is neither a standard use case nor a reasonable idea.
>
> I would say that it certainly is a standard use case for people who
> want to keep everything in a single file (e.g. to simplify
> reproducibility and avoid the mess of trying to distribute multiple
> files to non-technical users). #+INCLUDE is not a substitute if you
> are going to be tangling files, breaks many workflows, and as a result
> should rarely be recommended as a solution when src blocks are
> involved. Org should definitely be able to handle this case because
> there is no reason why performance should be any worse than having a
> 2000 line file in another buffer.
>
While I agree with the sentiment, I disagree with the conclusion "there
is no reason why performance should be any worse than having a 2000 line
file in another buffer.". Org mode is pushing right up against the
limits of Emacs' architecture with what it is doing. The way modes and
font-locking work in Emacs was never designed to support multiple modes
and multiple font-locking schemes within a single buffer. The fact org
is able to do this is a testament to the power of Emacs, but this comes
at a cost and that cost is primarily with respect to performance. You
can experience similar performance degradation when you use other
'modes' which try to support multiple modes in a single buffer (like
mmm-mode). This is not specific to org mode, but shows up more due to
the larger user base for org.
> Org babel has many basic interactivity performance pitfalls that need
> to be investigated. I personally have many workarounds for bad emacs
> performance degradations related to code executing in the event loop
> because I need to get on with the task at hand, but they need to be
> fixed, not dismissed.
I think the big challenge here is that the 'fixes' needed by org mode
really need to be at a deeper level inside Emac core architecture. It
isn't something which can be effectively addressed at the org level.
This makes it a much bigger and more complex task which is further
hampered by the need to maintain compatibility with all the existing
modes and libraries.
From what I've seen in the org-devel list, there is on-going work which
is focused on improvements to font-lock efficiency and I think support
for multiple modes is also being considered in some of this work. Other
developments, such as native compilation and pure gtk implementations
may also help in this area. Unfortunately, it may take some time before
we see the benefits of this work as it is complex and non-trivial work.
In the meantime, we need to consider all possible work-arounds and
tweaks which can help and in some cases, accept some compromise. Having
source blocks which are 2000 lines long is, at this time, a challenge
for org to handle given existing facilities. There are no quick and easy
fixes, but there are some tweaks, such as turning off native
fontification or using include files which can make the system usable.
While not ideal, we have ot work within the limits of the current
architecture while we wait for improvements, which can be expected to be
incremental and slow.
--
Tim Cross
next prev parent reply other threads:[~2021-06-22 5:20 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-21 18:27 Large source block causes org-mode to be unusable Léo Ackermann
2021-06-21 18:43 ` John Hendy
2021-06-21 18:57 ` Sébastien Miquel
2021-06-21 19:22 ` John Kitchin
2021-06-21 19:36 ` John Hendy
2021-06-21 20:41 ` Tom Gillespie
2021-06-22 4:48 ` Tim Cross [this message]
2021-06-22 7:54 ` Eric S Fraga
2021-06-22 11:20 ` Léo Ackermann
2021-06-22 12:13 ` Eric S Fraga
2021-06-22 12:32 ` Léo Ackermann
2021-06-22 13:03 ` Eric S Fraga
2021-06-22 13:32 ` Léo Ackermann
2021-06-23 16:40 ` Maxim Nikulin
2021-06-23 19:42 ` Gennady Uraltsev
2021-06-24 7:54 ` Eric S Fraga
2021-06-26 14:10 ` Léo Ackermann
2021-06-28 8:28 ` Sébastien Miquel
2021-06-28 10:42 ` Eric S Fraga
2021-06-28 10:40 ` Eric S Fraga
2021-06-22 6:10 ` Timothy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lf72lbmy.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).