From: Gennady Uraltsev <gennady.uraltsev@gmail.com>
To: Maxim Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Large source block causes org-mode to be unusable
Date: Wed, 23 Jun 2021 15:42:41 -0400 [thread overview]
Message-ID: <CACH4KQQ_r5DMMcuFWP1XXMqce0KhnhoUmTr=D=ff13JsmOa=hg@mail.gmail.com> (raw)
In-Reply-To: <savo60$7bj$1@ciao.gmane.io>
Hello Everyone,
I wanted to chime in to say I encountered a very similar problem. I
author my math papers in LaTeX but I really wanted to use org to have
an interconnected corpus of math notes with definitions, proofs,
ideas, attempted computations, etc. Then they could be exported to
LaTeX or even better: HTML to make for quite nice interactive notes
(with popups backlinking to definitions of mathematical objects,
etc...) (I was writing the latter in some JS). Unfortunately, HTML
(+mathjax or whatever) is much more flexible than PDFs
>I suggest that special block in LateX export (https://orgmode.org/manual/Special-blocks-in-LaTeX-export.html) may be treated differently. Once again, I'm new to org-mode, but here is my intuition:
>- What is happening now. The #+BEGIN_proof / #+END_proof keywords cause my proof to be seen as a block. Therefore, babel fontification is called to highlight syntax of my proof within my buffer. Timothy already discussed here how inefficient the >babel fontification is.
>- What could happen. Changing (somewhere) the treatment of #BEGIN_proof & co the following way: Assign them to a new face "latex_export_sugar" and ignore them while editing. Doing this, the fontification of the org proof will be made as usual and >will be fast enough. While exporting, replace #+BEGIN_proof by \begin{proof} and so on...
Exactly! Before HTML export becomes relevant, I if I tried to use
#+BEGIN_proof #+END_proof or #+BEGIN_definition #+END_definition
insertion in these environments slowed very quickly down to a crawl.
If I remember correctly the profiler told me that it was due to
fontification.
For me, the slowness in fontification INSIDE actual latex math blocks
(the only place where I need fontification, and I would prefer to use
AucTeX to do that, since it is really good at it) is generally not an
issue since I mostly have latex previews and use the edit source
command to work on the formulae. It would allow for a greater variety
of workflows if one could specify that some blocks lines should be
ignored for fontification purposes and the contents be treated as
usual org-mode text.
If you think it can be useful I can try to dig up my (abandoned)
attempts and try to provide test cases to improve performance.
> If proof environment is still required, maybe it is possible to
> customize export backend to have proofs as a headings with some property
> in the source document.
Unfortunately this is not really fitting with my workflow (and I think
this is not only my issue). In Org Mode, headings cannot "terminate"
i.e. only a new section can stop a previous one. So, essentially, one
would need to do a very non-elegant trick similar to one used by the
"inline TODOs" i.e. having a very deep level of heading (10?) that
"starts" a proof and then an artificial one that "ends" it.
Also, the point of having "proof" blocks and "example" blocks that
often, when reading math, you do not want to go through the proof on
the first reading.
One issue that many colleagues have agreed when discussing is that it
would be so great to have a "collapsible" environment or block. When
we write notes or explanations of material, often we are tasked with
making a call: do we do computations step by step and risk being
verbose, or do we write only the main steps and leave it to the reader
to fill in the intermediate ones. Both these approaches have
downsides. The former makes seeing the main points of the reasoning
difficult to catch and forces a reader to commit significant effort to
completely read the paper or notes (even if they just want the gist of
it). The other approach may frustrate the reader interested in details
because he/she has to work through the material to fill in all the
gaps, often spending a lot of time on omitted intermediate steps.
I was actually trying to come up with a natural system through org
and HTML export to avoid this dilemma and have sections that are
hidden by default but can be "expanded" on request.
> On the other hand my impression was that \begin{proof} environment is
> intended to emphasize a paragraph or two to separate it from regular
> text on the same page. My expectation is that 4-page long proof should
> be formatted as ordinary sections and subsections.
Unfortunately this goes against the standard of mathematical writing
(that I at least am familiar with).
Proofs are often long and technical and can span multiple pages. If
there are self-contained results in the proofs you separate them out
in statements (lemmata) with their own (shorter) proofs.
Text outside proofs is usually explanations and "glue" that explains
the process, the idea, but does so on a more "informal" level.
Having "proof" environments is also very useful as a method of having
"namespaces", often you need to introduce auxiliary objects,
expressions, operations, that are relevant only for the proof of the
result but that should not be "polluting" the full paper or writeup.
For example, if you introduce something inside a proof and denote it
with a symbol (e.g. $\phi$) then as soon as you hit the QED symbol at
the end of the proof, that symbol is freed and can be used in other
proofs/constructions. It is very bad form, for example, to reference
objects inside proofs of theorems outside the proofs themselves. If
something is an object of general interest then it should be "defined"
(included in a definition) on its own.
I apologize for going on a tangent.
Thanks again to everyone for the great package that is ORG, that I am
progressively trying to incorporate in more and more of my day-to-day
work and life.
Best!
Gena
--
Gennady Uraltsev
<gennady.uraltsev@gmail.com>
(https://guraltsev.gitlab.io)
next prev parent reply other threads:[~2021-06-23 19:43 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
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 [this message]
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='CACH4KQQ_r5DMMcuFWP1XXMqce0KhnhoUmTr=D=ff13JsmOa=hg@mail.gmail.com' \
--to=gennady.uraltsev@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
/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).