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
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
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
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
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
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
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
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
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
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
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
>
> 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
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
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
