[O] Re: org-src-fontify-natively makes things very, very slow
Hi Matt, Matt Lundin wrote: Sébastien Vauban writes: Maybe this is (partly?) due to the overlay I added: #+begin_src emacs-lisp (overlay-put (make-overlay beg1 block-end) 'face 'org-block-background)) #+end_src I believe there is a bug here. I'm not sure if it is related to the performance issues, but when org-src-fontify-natively is t, new overlays keep getting added to the source block with each keypress in the source block. For instance, just typing this line of perl... #+begin_src perl my @apples = (golden delicious, braeburn); #+end_src ...resulted in 54 identical overlays being added to the buffer. ,[ M-x describe-text-properties | There are 54 overlays here: | From 39 to 88 | face org-block-background | From 39 to 88 | face org-block-background | From 39 to 88 | face org-block-background | From 39 to 88 | face org-block-background | [and so on] ` I believe as well there is a problem! The number keeps growing with more typing, since make-overlay is called without a test to see if an overlay already exists. Thanks (a lot) for your very enlightening analysis. I will try to get this fixed in a couple of days. Best regards, Seb -- Sébastien Vauban
[O] Re: org-src-fontify-natively makes things very, very slow
Eric S Fraga e.fr...@ucl.ac.uk writes: yes, I used to use yasnippet a lot but I don't any longer. I am actually in confusion as to which completion mechanism to use in Emacs these days and am going a little crazy... :( I'm currently playing with auto-complete. Skeletons and abbrev-mode have always gotten the job done for me, with minimal fuss. Here's my skeleton for org source blocks: --8---cut here---start-8--- (define-skeleton skel-org-block Insert an org block Type: #+begin_ str - \n _ \n #+end_ str \n) (define-abbrev org-mode-abbrev-table blk 'skel-org-block) --8---cut here---end---8--- You can see a whole range of options for inserting source blocks in this FAQ: http://orgmode.org/worg/org-faq.html#shortcuts-for-entering-source-blocks Best, Matt
[O] Re: org-src-fontify-natively makes things very, very slow
Sébastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: Maybe this is (partly?) due to the overlay I added: #+begin_src emacs-lisp (overlay-put (make-overlay beg1 block-end) 'face 'org-block-background)) #+end_src See http://patchwork.newartisans.com/patch/581/ for a full diff. You can see I only add *one* overlay: for the background face. (well, commenting out the whole condition that includes this code) makes no difference at all. I'm surprised. Good to hear, but as some were finger pointing the overlays, and as I added one for every block... But, OK, better like that! For the sake of completeness, know that I first tried to add the background fontification as a text property, but that made the other properties disappear (annihilating the native fontification in fact). No a solution, or I did not try the right way -- which is entirely possible, seen my poor knowledge on this subject (I have to admit I succeeded by trials and errors). I believe there is a bug here. I'm not sure if it is related to the performance issues, but when org-src-fontify-natively is t, new overlays keep getting added to the source block with each keypress in the source block. For instance, just typing this line of perl... #+begin_src perl my @apples = (golden delicious, braeburn); #+end_src ...resulted in 54 identical overlays being added to the buffer. ,[ M-x describe-text-properties | There are 54 overlays here: | From 39 to 88 | face org-block-background | From 39 to 88 | face org-block-background | From 39 to 88 | face org-block-background | From 39 to 88 | face org-block-background | [and so on] ` The number keeps growing with more typing, since make-overlay is called without a test to see if an overlay already exists. Best, Matt
[O] Re: org-src-fontify-natively makes things very, very slow
Matt Lundin m...@imapmail.org writes: [...] I believe there is a bug here. I'm not sure if it is related to the performance issues, but when org-src-fontify-natively is t, new overlays keep getting added to the source block with each keypress in the source block. I can verify this on my system. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.116.g35a2e)
[O] Re: org-src-fontify-natively makes things very, very slow
Matt Lundin m...@imapmail.org writes: Eric S Fraga e.fr...@ucl.ac.uk writes: yes, I used to use yasnippet a lot but I don't any longer. I am actually in confusion as to which completion mechanism to use in Emacs these days and am going a little crazy... :( I'm currently playing with auto-complete. Skeletons and abbrev-mode have always gotten the job done for me, with minimal fuss. Here's my skeleton for org source blocks: [...] http://orgmode.org/worg/org-faq.html#shortcuts-for-entering-source-blocks Brilliant. Thanks. I learn something new every day. I had never run into skeletons in Emacs before. Elisp snippets. Very nice. More importantly, you have reminded me about the built-in expansion in org mode that I *always* seem to forget about. =s TAB= is easy enough for me to type! I think I am going to stick a post-it note on my forehead until I finally manage to get this imprinted in my conscious memory! I already use abbrev-mode quite extensively, but mostly for normal text. Thanks again, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.116.g35a2e)
[O] Re: org-src-fontify-natively makes things very, very slow
Hi Sébastien, Eric, I'm experiencing the same performance problems with recent org-mode. My observations are ... Sébastien Vauban wxhgmqzgw...@spammotel.com wrote: Eric S Fraga wrote: From these timings, the font locking doesn't seem to be the issue but maybe the overlays are. However, commenting out the code that Sébastien Vauban indicated: Maybe this is (partly?) due to the overlay I added: #+begin_src emacs-lisp (overlay-put (make-overlay beg1 block-end) 'face 'org-block-background)) #+end_src See http://patchwork.newartisans.com/patch/581/ for a full diff. You can see I only add *one* overlay: for the background face. (well, commenting out the whole condition that includes this code) makes no difference at all. That's true. It does not make any difference performance-wise. So, I turned off =org-src-fontify-natively= and things are back to normal: next-line is as fast as previous-line. I can put up without the fontification so this is what I am doing now. It's true that setting `org-src-fontify-natively' to nil boosts performance but it's only half the story. Editing something inside blocks also has a significant negative influence on display performance. Removing things like `#+BEGIN_letter' / `#+END_letter' from the file gets things back to normal for me. Ulf
Re: [O] Re: org-src-fontify-natively makes things very, very slow
Le Wang l26w...@gmail.com writes: On Mon, Mar 21, 2011 at 3:41 AM, Eric S Fraga e.fr...@ucl.ac.uk wrote: Le Wang l26w...@gmail.com writes: Why did you give up on yasnippet? Confusion amongst the key bindings, between org, yasnippet and the autocompletion tools I have been trying. I want to be able to use TAB for completion. I may come back to yasnippet in due course so it's nothing to do with yasnippet per se. I've been using the following yasnippet/org configuration for a long while now binding yas/expand to TAB. #+begin_src emacs-lisp (defun yas/org-very-safe-expand () (let ((yas/fallback-behavior 'return-nil)) (yas/expand))) (add-hook 'org-mode-hook (lambda () ;... ;; yasnippet (using the new org-cycle hooks) (make-variable-buffer-local 'yas/trigger-key) (setq yas/trigger-key [tab]) (add-to-list 'org-tab-first-hook 'yas/org-very-safe-expand) (define-key yas/keymap [tab] 'yas/next-field) )) #+end_src Best -- Eric I too had this issue of expansion confusion, especially when I installed the premade yasnippet packs. I solved it by adding moving yasnippet off the [tab] key, and adding it to hippie-expand, which I map to (M-/): (setq yas/trigger-key nil) (add-to-list 'hippie-expand-try-functions-list 'yas/hippie-try-expand) -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.90.g1fb3.dirty)
Re: [O] Re: org-src-fontify-natively makes things very, very slow
Hello again, going back to the original subject of this thread (although thanks all for your inputs on yasnippet ;-), I have started working on a new document and am finding the slowdown of navigation (next-line) very annoying. In this document, I have two gnuplot source blocks. Navigating through them, I get the following results from elp: --8---cut here---start-8--- next-line 54 5.946677 0.1101236481 previous-line 44 0.435003 0.0098864318 org-encrypt-entries 1 0.000424 0.000424 org-scan-tags 1 0.000368 0.000368 org-make-tags-matcher 1 5.1e-05 5.1e-05 org-activate-plain-links 1 2.4e-05 2.4e-05 org-raise-scripts 1 2.1e-05 2.1e-05 org-fontify-meta-lines-and-blocks 1 1.9e-05 1.9e-05 org-font-lock-hook1 1.9e-05 1.9e-05 org-outline-level 5 1.9e-05 3.8e-06 org-mode-flyspell-verify 14 1.8e-05 1.285...e-06 org-inlinetask-fontify1 1.5e-05 1.5e-05 org-activate-footnote-links 1 1.5e-05 1.5e-05 org-unfontify-region 1 1.2e-05 1.2e-05 org-do-emphasis-faces 1 1.2e-05 1.2e-05 org-activate-angle-links 1 1.2e-05 1.2e-05 org-activate-dates1 1.1e-05 1.1e-05 org-fontify-entities 1 1.1e-05 1.1e-05 --8---cut here---end---8--- From these timings, the font locking doesn't seem to be the issue but maybe the overlays are. However, commenting out the code that Sébastien Vauban indicated: Maybe this is (partly?) due to the overlay I added: #+begin_src emacs-lisp (overlay-put (make-overlay beg1 block-end) 'face 'org-block-background)) #+end_src (well, commenting out the whole condition that includes this code) makes no difference at all. So, I turned off =org-src-fontify-natively= and things are back to normal: next-line is as fast as previous-line. I can put up without the fontification so this is what I am doing now. However, as it's a pity to lose the native fontification, it would be nice to solve this problem in another way. Can anybody suggest any other thing to try? Thanks, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.91.g38c6b)
[O] Re: org-src-fontify-natively makes things very, very slow
Hi Eric, Eric S Fraga wrote: going back to the original subject of this thread (although thanks all for your inputs on yasnippet ;-), I have started working on a new document and am finding the slowdown of navigation (next-line) very annoying. In this document, I have two gnuplot source blocks. Navigating through them, I get the following results from elp: next-line 54 5.946677 0.1101236481 previous-line 44 0.435003 0.0098864318 org-encrypt-entries 1 0.000424 0.000424 org-scan-tags 1 0.000368 0.000368 org-make-tags-matcher 1 5.1e-05 5.1e-05 org-activate-plain-links 1 2.4e-05 2.4e-05 org-raise-scripts 1 2.1e-05 2.1e-05 org-fontify-meta-lines-and-blocks 1 1.9e-05 1.9e-05 org-font-lock-hook1 1.9e-05 1.9e-05 org-outline-level 5 1.9e-05 3.8e-06 org-mode-flyspell-verify 14 1.8e-05 1.285...e-06 org-inlinetask-fontify1 1.5e-05 1.5e-05 org-activate-footnote-links 1 1.5e-05 1.5e-05 org-unfontify-region 1 1.2e-05 1.2e-05 org-do-emphasis-faces 1 1.2e-05 1.2e-05 org-activate-angle-links 1 1.2e-05 1.2e-05 org-activate-dates1 1.1e-05 1.1e-05 org-fontify-entities 1 1.1e-05 1.1e-05 From these timings, the font locking doesn't seem to be the issue but maybe the overlays are. However, commenting out the code that Sébastien Vauban indicated: Maybe this is (partly?) due to the overlay I added: #+begin_src emacs-lisp (overlay-put (make-overlay beg1 block-end) 'face 'org-block-background)) #+end_src See http://patchwork.newartisans.com/patch/581/ for a full diff. You can see I only add *one* overlay: for the background face. (well, commenting out the whole condition that includes this code) makes no difference at all. I'm surprised. Good to hear, but as some were finger pointing the overlays, and as I added one for every block... But, OK, better like that! For the sake of completeness, know that I first tried to add the background fontification as a text property, but that made the other properties disappear (annihilating the native fontification in fact). No a solution, or I did not try the right way -- which is entirely possible, seen my poor knowledge on this subject (I have to admit I succeeded by trials and errors). So, I turned off =org-src-fontify-natively= and things are back to normal: next-line is as fast as previous-line. I can put up without the fontification so this is what I am doing now. However, as it's a pity to lose the native fontification, it would be nice to solve this problem in another way. Can anybody suggest any other thing to try? Not that I can think of now. Sorry for not being of any help here. Best regards, Seb -- Sébastien Vauban
Re: [O] Re: org-src-fontify-natively makes things very, very slow
Le Wang l26w...@gmail.com writes: On Sun, Mar 20, 2011 at 4:34 AM, Eric S Fraga e.fr...@ucl.ac.uk wrote: yes, I used to use yasnippet a lot but I don't any longer. I am actually in confusion as to which completion mechanism to use in Emacs these days and am going a little crazy... :( I'm currently playing with auto-complete. Why did you give up on yasnippet? Confusion amongst the key bindings, between org, yasnippet and the autocompletion tools I have been trying. I want to be able to use TAB for completion. I may come back to yasnippet in due course so it's nothing to do with yasnippet per se. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.90.g1fb3.dirty)
Re: [O] Re: org-src-fontify-natively makes things very, very slow
On Mon, Mar 21, 2011 at 3:41 AM, Eric S Fraga e.fr...@ucl.ac.uk wrote: Le Wang l26w...@gmail.com writes: Why did you give up on yasnippet? Confusion amongst the key bindings, between org, yasnippet and the autocompletion tools I have been trying. I want to be able to use TAB for completion. I may come back to yasnippet in due course so it's nothing to do with yasnippet per se. I too had this issue of expansion confusion, especially when I installed the premade yasnippet packs. I solved it by adding moving yasnippet off the [tab] key, and adding it to hippie-expand, which I map to (M-/): (setq yas/trigger-key nil) (add-to-list 'hippie-expand-try-functions-list 'yas/hippie-try-expand) -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.90.g1fb3.dirty) -- Le
[O] Re: org-src-fontify-natively makes things very, very slow
Hi Eric,
Eric S Fraga wrote:
Sébastien Vauban wxhgmqzgw...@spammotel.com writes:
Maybe this is (partly?) due to the overlay I added:
#+begin_src emacs-lisp
(overlay-put (make-overlay beg1 block-end)
'face 'org-block-background))
#+end_src
This could indeed be one cause, especially depending on what this does when
there is no block-end line, or at least not anywhere near in the buffer. I
seem to get a slowdown when I have a situation like this:
#+begin_example
[... some text ...]
#+begin_src somelanguage
[... text which is part of the source block...]
point here
[... lots of other text ...]
[... including other source blocks]
#+end_example
where there is no matching #+end_src or, more precisely, the next #+end_src
line is one that does not belong to this current source block. Your search
(in org.el) for the end of the block assumes that it does have the end
statement in place already. I'm not sure how to fix this because it's an
ill-defined situation.
You say your search... but I only added the overlay-put command... and I
must admit this whole block is difficult to follow (so many cases).
It may be worthwhile making the overlay optional? Although I must admit that
I like it!
I simply can't live without it, either.
My solution, by the way, is to insert the #+end_src line immediately upon
writing a #+begin_src line and then back up a line to start writing the
code.
My solution is even simpler: just use a yasnippet template, that prompts you
for the language and puts the begin/end upfront:
--8---cut here---start-8---
#name : #+begin_src...#+end_src
# --
#+srcname: ${1:name}
#+begin_src ${2:language} $3
$0
#+end_src
--8---cut here---end---8---
Best regards,
Seb
--
Sébastien Vauban
Re: [O] Re: org-src-fontify-natively makes things very, very slow
2011/3/19 Sébastien Vauban wxhgmqzgw...@spammotel.com: My solution, by the way, is to insert the #+end_src line immediately upon writing a #+begin_src line and then back up a line to start writing the code. My solution is even simpler: just use a yasnippet template, that prompts you for the language and puts the begin/end upfront: Or use org's own template mechanism[fn:1], 1. s - for source blocks 2. e - for example blocks and so on ... Footnotes: [fn:1] [[info:org#Easy%20Templates][info:org#Easy Templates]] -- Suvayu Open source is the future. It sets us free.
Re: [O] Re: org-src-fontify-natively makes things very, very slow
Sébastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Eric, Eric S Fraga wrote: [...] where there is no matching #+end_src or, more precisely, the next #+end_src line is one that does not belong to this current source block. Your search (in org.el) for the end of the block assumes that it does have the end statement in place already. I'm not sure how to fix this because it's an ill-defined situation. You say your search... but I only added the overlay-put command... and I must admit this whole block is difficult to follow (so many cases). Yes but the overlay needs to know where to end; I am using search in a more general sense here in that you are defining the start and end of a region to overlay using regular expressions, are you not? [...] My solution, by the way, is to insert the #+end_src line immediately upon writing a #+begin_src line and then back up a line to start writing the code. My solution is even simpler: just use a yasnippet template, that prompts you for the language and puts the begin/end upfront: yes, I used to use yasnippet a lot but I don't any longer. I am actually in confusion as to which completion mechanism to use in Emacs these days and am going a little crazy... :( I'm currently playing with auto-complete. Thanks, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.83.g1bd87.dirty)
Re: [O] Re: org-src-fontify-natively makes things very, very slow
suvayu ali fatkasuvayu+li...@gmail.com writes: 2011/3/19 Sébastien Vauban wxhgmqzgw...@spammotel.com: My solution, by the way, is to insert the #+end_src line immediately upon writing a #+begin_src line and then back up a line to start writing the code. My solution is even simpler: just use a yasnippet template, that prompts you for the language and puts the begin/end upfront: Or use org's own template mechanism[fn:1], 1. s - for source blocks 2. e - for example blocks and so on ... Footnotes: [fn:1] [[info:org#Easy%20Templates][info:org#Easy Templates]] Thanks for this! I am always forgetting about these and they do work well. For some reason, I always find it difficult to find them in the info manual. I guess it's because I don't think of them as templates and always search for short-cut and abbreviation in the table of contents for the org manual and neither is useful. Could I suggest that maybe the heading for this section be something like Short-cut keys for easy templates? Or something similar? Thanks, eric -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.83.g1bd87.dirty)
Re: [O] Re: org-src-fontify-natively makes things very, very slow
On Sun, Mar 20, 2011 at 4:34 AM, Eric S Fraga e.fr...@ucl.ac.uk wrote: yes, I used to use yasnippet a lot but I don't any longer. I am actually in confusion as to which completion mechanism to use in Emacs these days and am going a little crazy... :( I'm currently playing with auto-complete. Why did you give up on yasnippet? -- Le
Re: [O] Re: org-src-fontify-natively makes things very, very slow
Sébastien Vauban wxhgmqzgw...@spammotel.com writes: [...] Maybe this is (partly?) due to the overlay I added: #+begin_src emacs-lisp (overlay-put (make-overlay beg1 block-end) 'face 'org-block-background)) #+end_src This could indeed be one cause, especially depending on what this does when there is no block-end line, or at least not anywhere near in the buffer. I seem to get a slowdown when I have a situation like this: #+begin_example [... some text ...] #+begin_src somelanguage [... text which is part of the source block...] point here [... lots of other text ...] [... including other source blocks] #+end_example where there is no matching #+end_src or, more precisely, the next #+end_src line is one that does not belong to this current source block. Your search (in org.el) for the end of the block assumes that it does have the end statement in place already. I'm not sure how to fix this because it's an ill-defined situation. It may be worthwhile making the overlay optional? Although I must admit that I like it! My solution, by the way, is to insert the #+end_src line immediately upon writing a #+begin_src line and then back up a line to start writing the code. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.77.g74268)
Re: [O] Re: org-src-fontify-natively makes things very, very slow
Hi Eric, I have a small function to insert the opening and ending of an R code block bound to a key, so I always edit the code between a #+begin_src R and #+end_src R. I still get a considerable slowdown, even with an empty document with a single line of code. Julian On Fri, Mar 18, 2011 at 8:38 AM, Eric S Fraga e.fr...@ucl.ac.uk wrote: Sébastien Vauban wxhgmqzgw...@spammotel.com writes: [...] Maybe this is (partly?) due to the overlay I added: #+begin_src emacs-lisp (overlay-put (make-overlay beg1 block-end) 'face 'org-block-background)) #+end_src This could indeed be one cause, especially depending on what this does when there is no block-end line, or at least not anywhere near in the buffer. I seem to get a slowdown when I have a situation like this: #+begin_example [... some text ...] #+begin_src somelanguage [... text which is part of the source block...] point here [... lots of other text ...] [... including other source blocks] #+end_example where there is no matching #+end_src or, more precisely, the next #+end_src line is one that does not belong to this current source block. Your search (in org.el) for the end of the block assumes that it does have the end statement in place already. I'm not sure how to fix this because it's an ill-defined situation. It may be worthwhile making the overlay optional? Although I must admit that I like it! My solution, by the way, is to insert the #+end_src line immediately upon writing a #+begin_src line and then back up a line to start writing the code. -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 : using Org-mode version 7.5 (release_7.5.77.g74268) -- Julian Mariano Burgos Hafrannsóknastofnunin/Marine Research Institute Skúlagata 4, 121 Reykjavík, Iceland Sími/Telephone : +354-5752037 Bréfsími/Telefax: +354-5752001 Netfang/Email: jul...@hafro.is, jmbur...@uw.edu
[O] Re: org-src-fontify-natively makes things very, very slow
Hi all, Eric S Fraga wrote: Julian Burgos jmbur...@uw.edu writes: I was very excited to discover org-src-fontify-natively, but I´m not having a good experience with it. When it is on, org-mode becomes very slow while typing into a code block. This happens regardless of the size of the file or number of blocks, and the slow down is very noticeable. Each keystroke takes about half a second to appear in screen. Typing outside of the code blocks everything works fine. Turning off font-lock-verbose and global-linum-mode did not make any difference. I´m running OrgMode 7.5 and GNU Emacs 23.2.1. on Windows XP. Any ideas? Idem for me. Slow(er) in Org buffer itself. If you edit the source code block in its native mode (C-c', =org-edit-special=), is it fast or slow? Fast(er) in dedicated buffer. In any case, this may be related to the thread on slow behaviour discussed on this list the past few days. Does the response improve if you kill the buffer and load the file again? Maybe this is (partly?) due to the overlay I added: #+begin_src emacs-lisp (overlay-put (make-overlay beg1 block-end) 'face 'org-block-background)) #+end_src in function #+begin_src emacs-lisp (defun org-fontify-meta-lines-and-blocks (limit) #+end_src in file org.el. Best regards, Seb -- Sébastien Vauban
Re: [O] Re: org-src-fontify-natively makes things very, very slow
When editing the block in native mode everything works fine. Closing the buffer (or even rebooting the computer) had no effect. I´ll keep this off until is fixed. It is though a great feature! 2011/3/17 Sébastien Vauban wxhgmqzgw...@spammotel.com: Hi all, Eric S Fraga wrote: Julian Burgos jmbur...@uw.edu writes: I was very excited to discover org-src-fontify-natively, but I´m not having a good experience with it. When it is on, org-mode becomes very slow while typing into a code block. This happens regardless of the size of the file or number of blocks, and the slow down is very noticeable. Each keystroke takes about half a second to appear in screen. Typing outside of the code blocks everything works fine. Turning off font-lock-verbose and global-linum-mode did not make any difference. I´m running OrgMode 7.5 and GNU Emacs 23.2.1. on Windows XP. Any ideas? Idem for me. Slow(er) in Org buffer itself. If you edit the source code block in its native mode (C-c', =org-edit-special=), is it fast or slow? Fast(er) in dedicated buffer. In any case, this may be related to the thread on slow behaviour discussed on this list the past few days. Does the response improve if you kill the buffer and load the file again? Maybe this is (partly?) due to the overlay I added: #+begin_src emacs-lisp (overlay-put (make-overlay beg1 block-end) 'face 'org-block-background)) #+end_src in function #+begin_src emacs-lisp (defun org-fontify-meta-lines-and-blocks (limit) #+end_src in file org.el. Best regards, Seb -- Sébastien Vauban -- Julian Mariano Burgos Hafrannsóknastofnunin/Marine Research Institute Skúlagata 4, 121 Reykjavík, Iceland Sími/Telephone : +354-5752037 Bréfsími/Telefax: +354-5752001 Netfang/Email: jul...@hafro.is, jmbur...@uw.edu
