On Saturday, 26 Jun 2021 at 16:10, Léo Ackermann wrote:
> @EricSFrada, would you mind sharing your code for your proof sections ?
> If you've got ideas for this module, or/and want to participate to its
> development, please let me know :)
I have no code for proofs. Sorry! I was simply illustrat
On Monday, 28 Jun 2021 at 08:28, Sébastien Miquel wrote:
> Léo Ackermann writes:
>> @EricSFrada, would you mind sharing your code for your proof sections ?
> This functionality is now built-in: headings with an `ignore' tag do
> not get exported (their contents do). For very large proof, this seems
Hi,
Léo Ackermann writes:
@EricSFrada, would you mind sharing your code for your proof sections ?
This functionality is now built-in: headings with an `ignore' tag do not get
exported (their contents do). For very large proof, this seems like the
right
thing to do.
In small to moderate sized
Hi,
As I found no convenient solution, I will try to write a small module that
adress this problem. It will be a good occasion to discover Elisp :). It is
thought as an alternative to org-special-latex-block: efficient
fontification using default face, folding environment to hide proofs,
pretty la
On Wednesday, 23 Jun 2021 at 15:42, Gennady Uraltsev wrote:
> In Org Mode, headings cannot "terminate" i.e. only a new section can
> stop a previous one.
True.
What I do for cases where I want "separation" for visibility etc. is use
headings at the same level but tell the exporter to ignore the
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 ev
On 22/06/2021 19:32, Léo Ackermann wrote:
I suggest that special block in LateX export
(https://orgmode.org/manual/Special-blocks-in-LaTeX-export.html) may be
treated differently.
Generally I agree with you that #+begin_proof should be a thin wrapper
unlike a source code block. However I am
Neither do I (concerning the special fontification).
Nevertheless, if you look at the profiler report (1st mail), the
fontification process differ from the usual one (see attached screenshot)
*because* the proof is considered as a block by org-mode.
[image: image.png]
Best,
Le mar. 22 juin 2021
On Tuesday, 22 Jun 2021 at 14:32, Léo Ackermann wrote:
> Do you see what I mean ?
I do but I guess I must have a differently configured system as I do not
see any special fortification due to being in a special block.
However, I see nothing in my configuration that affects special blocks.
--
:
> I am not sure what you are asking. What specific treatment are you
referring to?
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 happen
On Tuesday, 22 Jun 2021 at 13:20, Léo Ackermann wrote:
> I am new to org-mode but, is there a reason why #+BEGIN_proof #+END_proof
> and other org-latex-special-block are treated as block ?
I am not sure what you are asking. What specific treatment are you
referring to?
--
: Eric S Fraga via Em
Hi all,
Many thanks for those advices!
I am new to org-mode but, is there a reason why #+BEGIN_proof #+END_proof
and other org-latex-special-block are treated as block ?
I mean; those #+... aim, as far as I understand, to give tips to org-export
for prettier exports but nothing else (between those
Hi Léo,
I think I can actually speak a bit on this. As it stands, babel fontification
operates by:
- sending the src block to a dedicated buffer
- turning on the relevant major mode for the language
- forcing font-lock of the entire buffer
- cloning the font-lock information for the entire buffer
On Monday, 21 Jun 2021 at 14:36, John Hendy wrote:
> [...] or split the block into a number of more reasonably sized
> cells.
This is what I do in practice. I then use noweb syntax to bring
everything together. In my case, the long LaTeX blocks tend to be tikz
pictures.
Using (native) for org-h
Tom Gillespie 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
> r
> 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 o
Indeed. The top google hit for "emacs fontify proof block slow" I provided
says exactly that :)
https://emacs.stackexchange.com/questions/46561/org-mode-9-too-slow-with-long-code-blocks
"""
That said, I think keeping 2000 lines of source code inside an org src
block is neither a standard use case
A quick and dirty way to fix this might be an include file, i.e. move
the block out of your manuscript file into a separate org file, and then
just include it.
Léo Ackermann writes:
> Dear all,
>
> I am working in an org-file of reasonable size (<2000 lines): my first
> paper written in org-mode
Hi Léo,
Léo Ackermann writes:
I am working in an org-file of reasonable size (<2000 lines): my first
paper written in org-mode. Everything fine (and fast) until I started
to add `#+BEGIN_proof / #+END_proof` within my .org to make my .pdf
export prettier. This caused the editing of the proofs
19 matches
Mail list logo