Re: Large source block causes org-mode to be unusable
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 > 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
html export backend with inlined css?
I regularly have to upload HTML to a CMS that strips out ,
Re: table: problem with nan and if
Uwe Brauer writes:
> Hi
>
> I have the following table
>
> #+begin_src elisp
> #+NAME: test
> | Name | E1 | E2 | E3 | Result1 | Result2 | Final |
> |---+++-+-+-+---|
> | User1 ||| | | 8 | nan|
> | User2 ||| | | ||
> | User3 | 1 | 0 | 3.5 | 4.5 | 5.8 | 4.8|
> |---+++-+-+-+---|
> #+TBLFM: $5=if(typeof(vsum($2..$4)) == 12, string(" "),vsum($2..$4));E
> f-1::$7=if("$6" == "nan", string(" "),0.3*$5+0.6*$6); E f-1
> #+end_src
>
>
> The calculations for User2 and 3 are fine, but for User1, the final
> result is a "nan".
>
> I see the problem is caused by ; E f-1 I don't understand why because
>
> As in
>
> #+begin_src elisp
> | user1 | User2 | |
> |---+---+-|
> | | 3 | nan |
> | 0 | 1 | 0.8 |
> #+TBLFM: $3=0.2*$1+0.8*$2; E f-1
> #+end_src
>
> I am not sure, but should I use something like
>
> if("$5" == "nan", string(" "),0.6*$6); E;f-1
>
>
> But how can I combine both ifs, I am puzzled
>
> Any help is strongly appreciated.
>
>
I'm not very familiar with calc, but am wondering if the issue is the
'nan'. In many languages, a nan is a 'polluting' variable i.e. once you
have a nan as a form anywhere in your calculation, the result will
always be a nan. Many languages actually have a special function to test
for a nan because it isn't actually a 'value'. Don't know if this is the
case with calc.
Perhaps an alternative strategy might help. Could you address what is
generating the nan and change that so that it generates something else,
possibly even a blank string and avoid the nan altogether?
--
Tim Cross
allow HTML block to escape from outline-text div? WAS: BUG? unable to surround subtrees with html tag
On Mon, Jun 21, 2021 at 3:07 PM Matt Price wrote: > I'm using the most recent wip-cite-new branch of org, with a recent emacs > git (28.0.50). > > I would like to be able to surround some portion of a subtree with a tag, > e.g.: > > * parent > some text > #+HTML: > ** child 2 > some boxed content > ** child 2 >more boxed content > #+HTML: > ** child 3 > unboxed content > > However, org seems to close the div for me before the ~** child 2~ > headline. > > Is this the intended behaviour? And if so is there any way for me to do > this? > Sorry for the noise, I believe this is user error. I misread the exported source code, and firefox's developer tools added the closing tag for me, so I kept not seeing my mistake. The error here was not realizing that section contents get wrapped in their own div with class ~outline-text-N~, so my ~~ resulted in malformed HTML. I don't know if there is a way to somehow slide my own html in between the outine-text element and the outline-container element for a child subtree. If someone knows a way to do this, I'd appreciate a pointer, but for now I think I have to find another way to accomplish this. thanks & apologies, Matt
Re: Large source block causes org-mode to be unusable
> 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. 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.
Re: Large source block causes org-mode to be unusable
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 nor a reasonable idea. You can use the #+INCLUDE ... src ... directive or split the block into a number of more reasonably sized cells. If you insist on keeping the entire block, then disable native highlighting of src code blocks. """ On Mon, Jun 21, 2021 at 2:23 PM John Kitchin wrote: > 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. 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 to be very slow: > navigation > > within the proof is fast but adding/removing any char takes around 4s per > > char. > > It seems that the fontify function is responsible for that (see > > screenshot). As far as I understand, this function tries to fontify the > > whole block as soon as a single char is modified. In my case, it then > tries > > to fontify a whole proof (~4 pages in my .pdf, with many LaTeX formulas) > > several times per second... > > > > Is there a way to make this fontify function to act "around my cursor" ? > > > > Best, > > Leo > > > -- > Professor John Kitchin > Doherty Hall A207F > Department of Chemical Engineering > Carnegie Mellon University > Pittsburgh, PA 15213 > 412-268-7803 > @johnkitchin > http://kitchingroup.cheme.cmu.edu > Pronouns: he/him/his > >
Re: Large source block causes org-mode to be unusable
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. 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 to be very slow: navigation > within the proof is fast but adding/removing any char takes around 4s per > char. > It seems that the fontify function is responsible for that (see > screenshot). As far as I understand, this function tries to fontify the > whole block as soon as a single char is modified. In my case, it then tries > to fontify a whole proof (~4 pages in my .pdf, with many LaTeX formulas) > several times per second... > > Is there a way to make this fontify function to act "around my cursor" ? > > Best, > Leo -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu Pronouns: he/him/his
BUG? unable to surround subtrees with html tag
I'm using the most recent wip-cite-new branch of org, with a recent emacs git (28.0.50). I would like to be able to surround some portion of a subtree with a tag, e.g.: * parent some text #+HTML: ** child 2 some boxed content ** child 2 more boxed content #+HTML: ** child 3 unboxed content However, org seems to close the div for me before the ~** child 2~ headline. Is this the intended behaviour? And if so is there any way for me to do this?
Re: table: problem with nan and if
>>> "ESF" == Eric S Fraga writes: > Uwe, > it might be easier if you explained what it is you want to do (at a > higher level) instead of trying to get us to help to fix what you have > done? OK fair enough The situation is as follows, there are two exams 1. The result of the first one is calculated as: E1+E2+E3=Result-Ex1 2. The second one Result-Ex2 (column 6, I have extracted from another table via #+BEGIN: aggregate :table Ex1 :cols "Name 'Result-Ex1 " But this is not important here. What is important is how the columns $5, and $7 are calculated. If column $2,$3, and $4 are non empty $5 is just the sum of these. The problem is $7: 1. it should be the sum of $5 and $6, *even* if $5 is empty, 2. but it should be empty if $6 is empty. #+begin_src elisp #+NAME: test | Name | E1 | E2 | E3 | Result-Ex1 | Result-Ex2 | Final | |---+++-+++---| | User1 ||| || 8 | | | User2 ||| ||| | | User3 | 1 | 0 | 3.5 |4.5 |5.8 | 4.8 | |---+++-+++---| #+end_src Did I explain this detailed and clear enough? Uwe smime.p7s Description: S/MIME cryptographic signature
Re: Large source block causes org-mode to be unusable
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 to be very slow: navigation within the proof is fast but adding/removing any char takes around 4s per char. It seems that the fontify function is responsible for that (see screenshot). As far as I understand, this function tries to fontify the whole block as soon as a single char is modified. In my case, it then tries to fontify a whole proof (~4 pages in my .pdf, with many LaTeX formulas) several times per second... You can try setting org-highlight-latex-and-related to '(latex) instead of '(native). Even with this setting, latex fontification in special blocks is slow. The reason being that the whole block has the `font-lock-multiline' property, hence every char insertion triggers refontification of the whole block. In the function `org-do-latex-and-related', I commented out the second condition of the `cond' form, which makes calls to `face-at-point'. This yields a significant speedup, and was enough to make things bearable in my cases. You can also try to simplify the latex regexp. If you try these, I'd be interested to hear how much of an improvement theymake. Regards, -- Sébastien Miquel
Re: table: problem with nan and if
Uwe, it might be easier if you explained what it is you want to do (at a higher level) instead of trying to get us to help to fix what you have done? -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-566-gf0198e : Latest paper written in org: https://arxiv.org/abs/2106.05096
table: problem with nan and if
Hi
I have the following table
#+begin_src elisp
#+NAME: test
| Name | E1 | E2 | E3 | Result1 | Result2 | Final |
|---+++-+-+-+---|
| User1 ||| | | 8 | nan|
| User2 ||| | | ||
| User3 | 1 | 0 | 3.5 | 4.5 | 5.8 | 4.8|
|---+++-+-+-+---|
#+TBLFM: $5=if(typeof(vsum($2..$4)) == 12, string(" "),vsum($2..$4));E
f-1::$7=if("$6" == "nan", string(" "),0.3*$5+0.6*$6); E f-1
#+end_src
The calculations for User2 and 3 are fine, but for User1, the final
result is a "nan".
I see the problem is caused by ; E f-1 I don't understand why because
As in
#+begin_src elisp
| user1 | User2 | |
|---+---+-|
| | 3 | nan |
| 0 | 1 | 0.8 |
#+TBLFM: $3=0.2*$1+0.8*$2; E f-1
#+end_src
I am not sure, but should I use something like
if("$5" == "nan", string(" "),0.6*$6); E;f-1
But how can I combine both ifs, I am puzzled
Any help is strongly appreciated.
Uwe Brauer
Re: [org-cite] request for coding help on a capf to insert citation key
On Sat, Jun 5, 2021 at 12:13 PM Bruce D'Arcus wrote: > > I've been struggling with this for a while, and am a mediocre programmer, so > thought I'd ask for help here. I made progress on this, with one question, for Nicolas: What's the best way to constrain the capf? Idea is if a user is within a citation, and types "@a", it activates. Here's what I have now, but it's too tight; I'm assuming that second line is the issue. (when (and (eq major-mode 'org-mode) (eq (car (org-element-context)) 'citation) (looking-back "@[a-zA-Z]*" 5)) Bruce
Re: [wip-cite-new] Adjust punctuation around citations
Hi, Am 21.06.2021 um 10:45 schrieb Nicolas Goaziou: Hello, Denis Maier writes: Using a space for this is perhaps too subtle as you say. Also, the question is which one should be the default. I'd actually suggest to turn it around: "A quotation ending without punctuation"[cite: @hoel-71-whole]. "A quotation ending with a period" [cite: @hoel-71-whole]. Reason for this: People who don't care for this distinction---either because they use en-us only, or because they never switch from in-text to notes styles---will probably prefer to have a space between quotation and citation (in input and output). People who don't care for this distinction can write "A quotation ending without punctuation" [cite: @hoel-71-whole]. "A quotation ending with a period" [cite: @hoel-71-whole]. So I guess the default doesn't matter in this case? That's probably correct. What about some sort of escaping for punctuation that should stay outside the quotation marks? "A quotation ending without punctuation" [cite: @hoel-71-whole]\. But, of course, that's imperfect as well. Don't know which option is less odd. Actual usage may tell. I implemented the spacing-tweak in "wip-cite-new". You (and others) may want to try it out on real documents and see if it feels somewhat natural. Ok, let's see if others have comments. I can for now at least confirm that this works as intended. Thanks again for all your work! Best, Denis Regards,
Re: [wip-cite-new] Adjust punctuation around citations
Hello, Denis Maier writes: > Using a space for this is perhaps too subtle as you say. Also, the > question is which one should be the default. I'd actually suggest to > turn it around: > >"A quotation ending without punctuation"[cite: @hoel-71-whole]. >"A quotation ending with a period" [cite: @hoel-71-whole]. > > Reason for this: People who don't care for this distinction---either > because they use en-us only, or because they never switch from in-text > to notes styles---will probably prefer to have a space between > quotation and citation (in input and output). People who don't care for this distinction can write "A quotation ending without punctuation" [cite: @hoel-71-whole]. "A quotation ending with a period" [cite: @hoel-71-whole]. So I guess the default doesn't matter in this case? > What about some sort of escaping for punctuation that should stay > outside the quotation marks? >"A quotation ending without punctuation" [cite: @hoel-71-whole]\. > > But, of course, that's imperfect as well. Don't know which option is > less odd. Actual usage may tell. I implemented the spacing-tweak in "wip-cite-new". You (and others) may want to try it out on real documents and see if it feels somewhat natural. Regards, -- Nicolas Goaziou
Re: [wip-cite-new] Adjust punctuation around citations
Am 20.06.2021 um 09:41 schrieb Nicolas Goaziou: Hello, "Bruce D'Arcus" writes: On Mon, Jun 14, 2021 at 7:45 AM Denis Maier wrote: * Note style input (=semantically strict input) "A quotation ending with a period." [cite: @hoel-71-whole] "A quotation ending without punctuation". [cite: @hoel-71-whole] As the input preserves the location of punctuation in the original material, I'd say it should be much easier to deal with this. We don't have to add information which isn't in the input, but rather we'll just have to move any punctuation to after the citation object. Maybe I'm missing something, but to me this looks like a much simpler operation than going in the opposite direction. This cannot be. [...] As another, imperfect, workaround, I submit the following idea for consideration: "A quotation ending without punctuation" [cite: @hoel-71-whole]. "A quotation ending with a period"[cite: @hoel-71-whole]. IOW, the presence or absence of a space before the citation determines, according to a note rule, if the punctuation should go inside or outside the quotation. When processing non-note citations, we just need to ensure there is at least a space after the previous element, which is less "dangerous" than removing punctuation. Yes, I guess we should be safe here. I can't think of a case where you wouldn't want a space before a citation. I find it a bit too subtle, and so error-prone, but so is punctuation anyway. > WDYT? Not a bad approach. Using a space for this is perhaps too subtle as you say. Also, the question is which one should be the default. I'd actually suggest to turn it around: "A quotation ending without punctuation"[cite: @hoel-71-whole]. "A quotation ending with a period" [cite: @hoel-71-whole]. Reason for this: People who don't care for this distinction---either because they use en-us only, or because they never switch from in-text to notes styles---will probably prefer to have a space between quotation and citation (in input and output). On the other hand, this here feels also a bit odd: "A quotation ending without punctuation"[cite: @hoel-71-whole]. In your example the rule would simply be that punctuation cannot jump across spaces. What about some sort of escaping for punctuation that should stay outside the quotation marks? "A quotation ending without punctuation" [cite: @hoel-71-whole]\. But, of course, that's imperfect as well. Don't know which option is less odd. Denis
