* Slow/poor responsiveness in org files @ 2011-08-18 5:56 Tim Cross 2011-08-18 7:49 ` Bastien 2011-09-13 3:20 ` Torsten Wagner 0 siblings, 2 replies; 24+ messages in thread From: Tim Cross @ 2011-08-18 5:56 UTC (permalink / raw) To: Emacs developers About a week or so ago, I updated emacs from bzr and saw that org 7.7 had been merged in. Since then, I have also noticed a distinct delay when performing various editing operations within org files. For example, killing a line wiht C-k in an org mode buffer is taking about 4 seconds! I updated emacs and tried again with emacs -Q and got the same result My version is 24.0.50 bzr relno 105475 Has anyone else seen this? What would be the best way to debug this sort of issue, emacs profiler? Tim ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-08-18 5:56 Slow/poor responsiveness in org files Tim Cross @ 2011-08-18 7:49 ` Bastien 2011-08-18 11:53 ` Antoine Levitt 2011-09-13 3:20 ` Torsten Wagner 1 sibling, 1 reply; 24+ messages in thread From: Bastien @ 2011-08-18 7:49 UTC (permalink / raw) To: Tim Cross; +Cc: Emacs developers Hi Tim, Tim Cross <theophilusx@gmail.com> writes: > About a week or so ago, I updated emacs from bzr and saw that org 7.7 > had been merged in. Since then, I have also noticed a distinct delay > when performing various editing operations within org files. For > example, killing a line wiht C-k in an org mode buffer is taking about > 4 seconds! This might come either from Org and/or from Emacs. > I updated emacs and tried again with emacs -Q and got the same result > > My version is 24.0.50 bzr relno 105475 > > Has anyone else seen this? Yes. > What would be the best way to debug this sort of issue, emacs > profiler? Four tests would be useful: - Emacs 23 + Org 7.4 - Emacs 23 + Org 7.7 - Emacs 24 (from trunk) + Org 7.4 - Emacs 24 (from trunk) + Org 7.7 For each case, M-x elp-instrument-package RET org-mode RET to see if there is any particular function that takes significantly more time. I'm busy fixing small bugs in Org 7.7 but fixing such slowniness is high priority and such tests would really help me *a lot*. Thanks in advance! -- Bastien ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-08-18 7:49 ` Bastien @ 2011-08-18 11:53 ` Antoine Levitt 2011-08-19 23:42 ` Tim Cross 0 siblings, 1 reply; 24+ messages in thread From: Antoine Levitt @ 2011-08-18 11:53 UTC (permalink / raw) To: emacs-devel 18/08/11 09:49, Bastien > Hi Tim, > > Tim Cross <theophilusx@gmail.com> writes: > >> About a week or so ago, I updated emacs from bzr and saw that org 7.7 >> had been merged in. Since then, I have also noticed a distinct delay >> when performing various editing operations within org files. For >> example, killing a line wiht C-k in an org mode buffer is taking about >> 4 seconds! > > This might come either from Org and/or from Emacs. > >> I updated emacs and tried again with emacs -Q and got the same result >> >> My version is 24.0.50 bzr relno 105475 >> >> Has anyone else seen this? > > Yes. > >> What would be the best way to debug this sort of issue, emacs >> profiler? > > Four tests would be useful: > > - Emacs 23 + Org 7.4 > - Emacs 23 + Org 7.7 > - Emacs 24 (from trunk) + Org 7.4 > - Emacs 24 (from trunk) + Org 7.7 > > For each case, M-x elp-instrument-package RET org-mode RET to > see if there is any particular function that takes significantly > more time. > > I'm busy fixing small bugs in Org 7.7 but fixing such slowniness > is high priority and such tests would really help me *a lot*. > > Thanks in advance! Also try setting bidi-display-reordering to nil and see if that changes anything. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-08-18 11:53 ` Antoine Levitt @ 2011-08-19 23:42 ` Tim Cross 2011-08-20 0:23 ` Bastien 0 siblings, 1 reply; 24+ messages in thread From: Tim Cross @ 2011-08-19 23:42 UTC (permalink / raw) To: emacs-devel On Thu, Aug 18, 2011 at 9:53 PM, Antoine Levitt <antoine.levitt@gmail.com> wrote: > 18/08/11 09:49, Bastien >> Hi Tim, >> >> Tim Cross <theophilusx@gmail.com> writes: >> >>> About a week or so ago, I updated emacs from bzr and saw that org 7.7 >>> had been merged in. Since then, I have also noticed a distinct delay >>> when performing various editing operations within org files. For >>> example, killing a line wiht C-k in an org mode buffer is taking about >>> 4 seconds! >> >> This might come either from Org and/or from Emacs. >> >>> I updated emacs and tried again with emacs -Q and got the same result >>> >>> My version is 24.0.50 bzr relno 105475 >>> >>> Has anyone else seen this? >> >> Yes. >> >>> What would be the best way to debug this sort of issue, emacs >>> profiler? >> >> Four tests would be useful: >> >> - Emacs 23 + Org 7.4 >> - Emacs 23 + Org 7.7 >> - Emacs 24 (from trunk) + Org 7.4 >> - Emacs 24 (from trunk) + Org 7.7 >> >> For each case, M-x elp-instrument-package RET org-mode RET to >> see if there is any particular function that takes significantly >> more time. >> >> I'm busy fixing small bugs in Org 7.7 but fixing such slowniness >> is high priority and such tests would really help me *a lot*. >> >> Thanks in advance! > > Also try setting bidi-display-reordering to nil and see if that changes > anything. > > > OK, will do. As Bastien indicates this is a known problem, I will assume there is an existing bug report and won't create a new one. I will post my results back here. Given the combinations to test, this will take some work and some time. One question I do have, how do I run emacs bzr trunk with org 7.4? Is it sufficient to just ensure some 7.4 load directory is first in the load path? Also, what is the url to get 7.4? Tim ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-08-19 23:42 ` Tim Cross @ 2011-08-20 0:23 ` Bastien 2011-08-20 0:53 ` Tim Cross 0 siblings, 1 reply; 24+ messages in thread From: Bastien @ 2011-08-20 0:23 UTC (permalink / raw) To: Tim Cross; +Cc: emacs-devel Hi Tim, Tim Cross <theophilusx@gmail.com> writes: > OK, will do. Thanks in advance! > As Bastien indicates this is a known problem, I will assume there is > an existing bug report and won't create a new one. I will post my > results back here. Given the combinations to test, this will take some > work and some time. Please first try what Antoine suggested. > One question I do have, how do I run emacs bzr trunk with org 7.4? Is > it sufficient to just ensure some 7.4 load directory is first in the > load path? I think so. > Also, what is the url to get 7.4? http://orgmode.org/org-7.4.tar.gz Or get Org from git: ~$ git clone git://orgmode.org/org-mode.git and checkout commit 597e2863377fb8763cf6951e3b4e777b4616300d HTH, -- Bastien ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-08-20 0:23 ` Bastien @ 2011-08-20 0:53 ` Tim Cross 2011-08-22 0:52 ` Tim Cross 0 siblings, 1 reply; 24+ messages in thread From: Tim Cross @ 2011-08-20 0:53 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel On Sat, Aug 20, 2011 at 10:23 AM, Bastien <bzg@altern.org> wrote: > Hi Tim, > > Tim Cross <theophilusx@gmail.com> writes: > >> OK, will do. > > Thanks in advance! > >> As Bastien indicates this is a known problem, I will assume there is >> an existing bug report and won't create a new one. I will post my >> results back here. Given the combinations to test, this will take some >> work and some time. > > Please first try what Antoine suggested. > >> One question I do have, how do I run emacs bzr trunk with org 7.4? Is >> it sufficient to just ensure some 7.4 load directory is first in the >> load path? > > I think so. > >> Also, what is the url to get 7.4? > > http://orgmode.org/org-7.4.tar.gz > > Or get Org from git: > > ~$ git clone git://orgmode.org/org-mode.git > > and checkout commit 597e2863377fb8763cf6951e3b4e777b4616300d > > HTH, > > -- > Bastien > OK, will try to do later this weekend. Was going to check the bidi settings first as the changing of the default for bidi mode and the merge of 7.7 occured quite close - probably within the same update for me. I am a daily org user and had not noticed any performance issues with 7.4. Need to wait until my work completes the current major system update outage to get access to my large org file that I want to test with. Should be able to do this tomorrow. Tim P.S. I did notice no significant performance problems with very small org test files. It would seem you need to cross some size threshold before you notice the performance impact. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-08-20 0:53 ` Tim Cross @ 2011-08-22 0:52 ` Tim Cross 2011-08-22 5:55 ` Eli Zaretskii 2011-09-13 20:42 ` Claus Klingberg 0 siblings, 2 replies; 24+ messages in thread From: Tim Cross @ 2011-08-22 0:52 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel SOLVED! Adding the line (setq bidi-display-reordering nil) to my org-mode-hook has fixed the problem. Cursor movement and editing operations are now usable and the delays are gone. This was with Emacs 24.0.50 revno 105525 Unfortunately, I now find I have emacs generating a backtrace when I try to quite with the error void-function bidi-string-mark-left-to-right, but I think that is unrelated and just coincidental. Tim On Sat, Aug 20, 2011 at 10:53 AM, Tim Cross <theophilusx@gmail.com> wrote: > On Sat, Aug 20, 2011 at 10:23 AM, Bastien <bzg@altern.org> wrote: >> Hi Tim, >> >> Tim Cross <theophilusx@gmail.com> writes: >> >>> OK, will do. >> >> Thanks in advance! >> >>> As Bastien indicates this is a known problem, I will assume there is >>> an existing bug report and won't create a new one. I will post my >>> results back here. Given the combinations to test, this will take some >>> work and some time. >> >> Please first try what Antoine suggested. >> >>> One question I do have, how do I run emacs bzr trunk with org 7.4? Is >>> it sufficient to just ensure some 7.4 load directory is first in the >>> load path? >> >> I think so. >> >>> Also, what is the url to get 7.4? >> >> http://orgmode.org/org-7.4.tar.gz >> >> Or get Org from git: >> >> ~$ git clone git://orgmode.org/org-mode.git >> >> and checkout commit 597e2863377fb8763cf6951e3b4e777b4616300d >> >> HTH, >> >> -- >> Bastien >> > > OK, will try to do later this weekend. Was going to check the bidi > settings first as the changing of the default for bidi mode and the > merge of 7.7 occured quite close - probably within the same update for > me. I am a daily org user and had not noticed any performance issues > with 7.4. > > Need to wait until my work completes the current major system update > outage to get access to my large org file that I want to test with. > Should be able to do this tomorrow. > > Tim > > P.S. I did notice no significant performance problems with very small > org test files. It would seem you need to cross some size threshold > before you notice the performance impact. > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-08-22 0:52 ` Tim Cross @ 2011-08-22 5:55 ` Eli Zaretskii 2011-08-22 6:42 ` Tim Cross 2011-09-13 0:22 ` Mathieu Boespflug 2011-09-13 20:42 ` Claus Klingberg 1 sibling, 2 replies; 24+ messages in thread From: Eli Zaretskii @ 2011-08-22 5:55 UTC (permalink / raw) To: Tim Cross; +Cc: bzg, emacs-devel > Date: Mon, 22 Aug 2011 10:52:49 +1000 > From: Tim Cross <theophilusx@gmail.com> > Cc: emacs-devel@gnu.org > > SOLVED! > > Adding the line > > (setq bidi-display-reordering nil) > > to my org-mode-hook has fixed the problem. Cursor movement and editing > operations are now usable and the delays are gone. Please don't consider this a solution. bidi-display-reordering should not slow down redisplay to a degree that makes Emacs unusable. And setting bidi-display-reordering to nil means that R2L scripts cannot be used in Org buffers, which is clearly unacceptable. If you can send me the offending file, that would be the best. Failing that, please answer the following questions: . How large is the Org file, in bytes? . How many entries do you have in it, including distribution between levels (i.e., how many entries of 2nd level do you have, on average, per each 1st-level entry, how many 3rd-level entries per each 2nd-level entry, etc.)? . Is the slowdown the same at the beginning of the file, the end of the file, and in the middle? . Which commands exhibit the slowdown? Are C-f/C-b slow? How about left and right arrows? C-v/M-v? Up/down arrows? . Does the slowdown go away after "M-x show-all RET"? . Do you have any minor modes, in addition to Org mode, turned on in those buffers, and if so, which ones? Please include any sub-modes of Org in the list. . Does setting bidi-paragraph-direction to `left-to-right' eliminate the slowdown? With this info, I can try reproducing the problem and looking for a proper solution. TIA ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-08-22 5:55 ` Eli Zaretskii @ 2011-08-22 6:42 ` Tim Cross 2011-08-22 7:03 ` Eli Zaretskii 2011-09-13 0:22 ` Mathieu Boespflug 1 sibling, 1 reply; 24+ messages in thread From: Tim Cross @ 2011-08-22 6:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: bzg, emacs-devel On Mon, Aug 22, 2011 at 3:55 PM, Eli Zaretskii <eliz@gnu.org> wrote: >> Date: Mon, 22 Aug 2011 10:52:49 +1000 >> From: Tim Cross <theophilusx@gmail.com> >> Cc: emacs-devel@gnu.org >> >> SOLVED! >> >> Adding the line >> >> (setq bidi-display-reordering nil) >> >> to my org-mode-hook has fixed the problem. Cursor movement and editing >> operations are now usable and the delays are gone. > > Please don't consider this a solution. bidi-display-reordering should > not slow down redisplay to a degree that makes Emacs unusable. And > setting bidi-display-reordering to nil means that R2L scripts cannot > be used in Org buffers, which is clearly unacceptable. > > If you can send me the offending file, that would be the best. > Failing that, please answer the following questions: > Sorry, I cannot send the offending file as it contains sensitive information. > . How large is the Org file, in bytes? -rw-r--r-- 1 tcross tcross 612856 2011-08-22 12:51 urs.org > > . How many entries do you have in it, including distribution between > levels (i.e., how many entries of 2nd level do you have, on > average, per each 1st-level entry, how many 3rd-level entries per > each 2nd-level entry, etc.)? > 20 leve 1 headings Average about 6 - 10 level 2 headings in each, though there are 3 sections which contain over 50 level 2 items and a Tasks section which has 120 TODO items (106 marked as done). I have very few level 3 headings as I rarely get that deep. One of the level 1 sections contains over 60 level 2 items which are include either a timestamp or are just a timestamp. > . Is the slowdown the same at the beginning of the file, the end of > the file, and in the middle? Yes, it appears to be > > . Which commands exhibit the slowdown? Are C-f/C-b slow? How about > left and right arrows? C-v/M-v? Up/down arrows? > It appears to affect all commands. Even typing is sluggish (I can get 'in front' of what is being displayed when typing quickly). Kill and yank commands seem to be the worst, but all movement commands appear to be affected to some degree. I get the impression the larger the text being acted upon, the greater the slowdown. > . Does the slowdown go away after "M-x show-all RET"? > Yes it appears to. > . Do you have any minor modes, in addition to Org mode, turned on in > those buffers, and if so, which ones? Please include any sub-modes > of Org in the list. Normally I do. However, the first thing I tested was to run emacs -Q and just start by opening the org file, so only org-mode and no other minor modes were loaded. Problem still existed. > > . Does setting bidi-paragraph-direction to `left-to-right' eliminate > the slowdown? It does appear to remove the slowdown > > With this info, I can try reproducing the problem and looking for a > proper solution. > I will try and 'clean' my org file so that all sensitive info is removed. If after that, the problem still exists, I will send it. Tim ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-08-22 6:42 ` Tim Cross @ 2011-08-22 7:03 ` Eli Zaretskii 0 siblings, 0 replies; 24+ messages in thread From: Eli Zaretskii @ 2011-08-22 7:03 UTC (permalink / raw) To: Tim Cross; +Cc: bzg, emacs-devel > Date: Mon, 22 Aug 2011 16:42:56 +1000 > From: Tim Cross <theophilusx@gmail.com> > Cc: bzg@altern.org, emacs-devel@gnu.org > > > . How large is the Org file, in bytes? > > -rw-r--r-- 1 tcross tcross 612856 2011-08-22 12:51 urs.org Strange. I have a 3MB Org file, and I see no such terrible problems there. What is the speed of your CPU clock? I have a 6-year old single-core Pentium 4 CPU here which runs at 3GHz. > there are 3 sections which contain over 50 level 2 items and a Tasks > section which has 120 TODO items (106 marked as done). Is cursor motion in those 3 sections slower than in the other ones? > > . Which commands exhibit the slowdown? Are C-f/C-b slow? How about > > left and right arrows? C-v/M-v? Up/down arrows? > > > > It appears to affect all commands. Even typing is sluggish (I can get > 'in front' of what is being displayed when typing quickly). Is there any difference between C-f and right-arrow? If setting bidi-paragraph-direction to a non-nil value helps, there ought to be a difference between these two. > I will try and 'clean' my org file so that all sensitive info is > removed. If after that, the problem still exists, I will send it. Thanks. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-08-22 5:55 ` Eli Zaretskii 2011-08-22 6:42 ` Tim Cross @ 2011-09-13 0:22 ` Mathieu Boespflug 2011-09-13 2:59 ` Eli Zaretskii 1 sibling, 1 reply; 24+ messages in thread From: Mathieu Boespflug @ 2011-09-13 0:22 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz <at> gnu.org> writes: > > > Date: Mon, 22 Aug 2011 10:52:49 +1000 > > From: Tim Cross <theophilusx <at> gmail.com> > > Cc: emacs-devel <at> gnu.org > > > > SOLVED! > > > > Adding the line > > > > (setq bidi-display-reordering nil) > > > > to my org-mode-hook has fixed the problem. Cursor movement and editing > > operations are now usable and the delays are gone. > > Please don't consider this a solution. bidi-display-reordering should > not slow down redisplay to a degree that makes Emacs unusable. And > setting bidi-display-reordering to nil means that R2L scripts cannot > be used in Org buffers, which is clearly unacceptable. I have experienced precisely the same behaviour in some of my org files. Here is a link to a large (redacted) org file that exhibits this problem: http://www.cs.mcgill.ca/~mboes/test.org With latest emacs 24, reading this file in org-mode is noticeably slower than in org-mode, even when all trees are folded. However that's behaviour I don't see with emacs -Q. What I do see even with emacs -Q is very slow cursor movement and editing after expanding the tree titled "LONG". You have to scroll down to near the end of that tree to see what I'm talking about. Navigating subsequent trees when the LONG tree is expanded is also slow. > . Does the slowdown go away after "M-x show-all RET"? The slowdown does indeed completely disappear appear this command. > . Does setting bidi-paragraph-direction to `left-to-right' eliminate > the slowdown? Yes. -- Mathieu ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-09-13 0:22 ` Mathieu Boespflug @ 2011-09-13 2:59 ` Eli Zaretskii 2011-09-13 4:36 ` Mathieu Boespflug 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2011-09-13 2:59 UTC (permalink / raw) To: Mathieu Boespflug; +Cc: emacs-devel > From: Mathieu Boespflug <mboes@tweag.net> > Date: Tue, 13 Sep 2011 00:22:26 +0000 (UTC) > > I have experienced precisely the same behaviour in some of my org files. Here is > a link to a large (redacted) org file that exhibits this problem: > > http://www.cs.mcgill.ca/~mboes/test.org Thanks, I will take a look. > With latest emacs 24, reading this file in org-mode is noticeably slower than in > org-mode, even when all trees are folded. However that's behaviour I don't see > with emacs -Q. Can you try to find the customization(s) in your .emacs that cause the slowdown not observed in "emacs -Q"? > > . Does setting bidi-paragraph-direction to `left-to-right' eliminate > > the slowdown? > > Yes. I will propose to Org mode developers a change to set bidi-paragraph-direction automatically on all Org buffers. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-09-13 2:59 ` Eli Zaretskii @ 2011-09-13 4:36 ` Mathieu Boespflug 2011-09-13 5:51 ` Eli Zaretskii 2011-09-13 16:55 ` Slow/poor responsiveness in org files Bruno Tavernier 0 siblings, 2 replies; 24+ messages in thread From: Mathieu Boespflug @ 2011-09-13 4:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel On Tue, Sep 13, 2011 at 05:59:53AM +0300, Eli Zaretskii wrote: > > From: Mathieu Boespflug <mboes@tweag.net> > > Date: Tue, 13 Sep 2011 00:22:26 +0000 (UTC) > > > > I have experienced precisely the same behaviour in some of my org files. Here is > > a link to a large (redacted) org file that exhibits this problem: > > > > http://www.cs.mcgill.ca/~mboes/test.org > > Thanks, I will take a look. > > > With latest emacs 24, reading this file in org-mode is noticeably slower than in > > org-mode, even when all trees are folded. However that's behaviour I don't see > > with emacs -Q. > > Can you try to find the customization(s) in your .emacs that cause the > slowdown not observed in "emacs -Q"? I believed I tracked at least one customization that causes a very noticeable slowdown: global-hl-line-mode. On the org file linked above, navigation is slow even with all trees folded with this minor mode enabled. > > > . Does setting bidi-paragraph-direction to `left-to-right' eliminate > > > the slowdown? > > > > Yes. > > I will propose to Org mode developers a change to set > bidi-paragraph-direction automatically on all Org buffers. Ok. Thank you for looking into this. However, does this mean it won't be possible to have R2L text in Org buffers? -- Mathieu ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-09-13 4:36 ` Mathieu Boespflug @ 2011-09-13 5:51 ` Eli Zaretskii 2011-09-14 15:34 ` Paragraph direction in Org Mode (was: Slow/poor responsiveness in org files) Eli Zaretskii 2011-09-13 16:55 ` Slow/poor responsiveness in org files Bruno Tavernier 1 sibling, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2011-09-13 5:51 UTC (permalink / raw) To: Mathieu Boespflug; +Cc: emacs-devel > Date: Tue, 13 Sep 2011 00:36:25 -0400 > From: Mathieu Boespflug <mboes@tweag.net> > Cc: emacs-devel@gnu.org > > > I will propose to Org mode developers a change to set > > bidi-paragraph-direction automatically on all Org buffers. > > Ok. Thank you for looking into this. However, does this mean it won't be > possible to have R2L text in Org buffers? No, it doesn't mean that. It just means the display will start at the left window boundary, even if the item includes R2L text. To illustrate, you will see * foo * bar * OOF * RAB (where "OOF" and "RAB" are R2L text typed as "FOO" and "BAR", reordered into correct visual order), rather than * foo * bar OOF * RAB * with the default (nil) setting of bidi-paragraph-direction. I think the latter is ugly anyway. The variable that controls reordering is bidi-display-reordering, and it must stay non-nil if we want to support R2L text. The Emacs manual and the ELisp manual have more information about the meaning of bidi-paragraph-direction, if you want to learn more. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Paragraph direction in Org Mode (was: Slow/poor responsiveness in org files) 2011-09-13 5:51 ` Eli Zaretskii @ 2011-09-14 15:34 ` Eli Zaretskii 2011-09-20 15:02 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2011-09-14 15:34 UTC (permalink / raw) To: Bastien Guerry; +Cc: emacs-devel > Date: Tue, 13 Sep 2011 01:51:41 -0400 > From: Eli Zaretskii <eliz@gnu.org> > Cc: emacs-devel@gnu.org > > > Date: Tue, 13 Sep 2011 00:36:25 -0400 > > From: Mathieu Boespflug <mboes@tweag.net> > > Cc: emacs-devel@gnu.org > > > > > I will propose to Org mode developers a change to set > > > bidi-paragraph-direction automatically on all Org buffers. > > > > Ok. Thank you for looking into this. However, does this mean it won't be > > possible to have R2L text in Org buffers? > > No, it doesn't mean that. It just means the display will start at the > left window boundary, even if the item includes R2L text. To > illustrate, you will see > > * foo > * bar > * OOF > * RAB > > (where "OOF" and "RAB" are R2L text typed as "FOO" and "BAR", > reordered into correct visual order), rather than > > * foo > * bar > OOF * > RAB * > > with the default (nil) setting of bidi-paragraph-direction. I think > the latter is ugly anyway. Bastien, As followup to this thread (and other similar discussions in the past), I propose the change below to org.el. Let me know if you want me to commit this to the Emacs trunk or wait for your next merge. Thanks. === modified file 'lisp/org/org.el' --- lisp/org/org.el 2011-09-02 16:38:40 +0000 +++ lisp/org/org.el 2011-09-14 15:30:49 +0000 @@ -4748,6 +4748,7 @@ The following commands are available: (org-set-local 'line-move-ignore-invisible t)) (org-set-local 'outline-regexp org-outline-regexp) (org-set-local 'outline-level 'org-outline-level) + (setq bidi-paragraph-direction 'left-to-right) (when (and org-ellipsis (fboundp 'set-display-table-slot) (boundp 'buffer-display-table) (fboundp 'make-glyph-code)) ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Paragraph direction in Org Mode (was: Slow/poor responsiveness in org files) 2011-09-14 15:34 ` Paragraph direction in Org Mode (was: Slow/poor responsiveness in org files) Eli Zaretskii @ 2011-09-20 15:02 ` Eli Zaretskii 0 siblings, 0 replies; 24+ messages in thread From: Eli Zaretskii @ 2011-09-20 15:02 UTC (permalink / raw) To: bzg, emacs-devel Ping! > Date: Wed, 14 Sep 2011 18:34:21 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: emacs-devel@gnu.org > > > Date: Tue, 13 Sep 2011 01:51:41 -0400 > > From: Eli Zaretskii <eliz@gnu.org> > > Cc: emacs-devel@gnu.org > > > > > Date: Tue, 13 Sep 2011 00:36:25 -0400 > > > From: Mathieu Boespflug <mboes@tweag.net> > > > Cc: emacs-devel@gnu.org > > > > > > > I will propose to Org mode developers a change to set > > > > bidi-paragraph-direction automatically on all Org buffers. > > > > > > Ok. Thank you for looking into this. However, does this mean it won't be > > > possible to have R2L text in Org buffers? > > > > No, it doesn't mean that. It just means the display will start at the > > left window boundary, even if the item includes R2L text. To > > illustrate, you will see > > > > * foo > > * bar > > * OOF > > * RAB > > > > (where "OOF" and "RAB" are R2L text typed as "FOO" and "BAR", > > reordered into correct visual order), rather than > > > > * foo > > * bar > > OOF * > > RAB * > > > > with the default (nil) setting of bidi-paragraph-direction. I think > > the latter is ugly anyway. > > Bastien, > > As followup to this thread (and other similar discussions in the > past), I propose the change below to org.el. > > Let me know if you want me to commit this to the Emacs trunk or wait > for your next merge. > > Thanks. > > > === modified file 'lisp/org/org.el' > --- lisp/org/org.el 2011-09-02 16:38:40 +0000 > +++ lisp/org/org.el 2011-09-14 15:30:49 +0000 > @@ -4748,6 +4748,7 @@ The following commands are available: > (org-set-local 'line-move-ignore-invisible t)) > (org-set-local 'outline-regexp org-outline-regexp) > (org-set-local 'outline-level 'org-outline-level) > + (setq bidi-paragraph-direction 'left-to-right) > (when (and org-ellipsis > (fboundp 'set-display-table-slot) (boundp 'buffer-display-table) > (fboundp 'make-glyph-code)) > > > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-09-13 4:36 ` Mathieu Boespflug 2011-09-13 5:51 ` Eli Zaretskii @ 2011-09-13 16:55 ` Bruno Tavernier 2011-09-14 15:37 ` Eli Zaretskii 1 sibling, 1 reply; 24+ messages in thread From: Bruno Tavernier @ 2011-09-13 16:55 UTC (permalink / raw) To: emacs-devel Mathieu Boespflug <mboes@tweag.net> writes: >> > With latest emacs 24, reading this file in org-mode is noticeably >> > slower than in org-mode, even when all trees are folded. However >> > that's behaviour I don't see with emacs -Q. >> >> Can you try to find the customization(s) in your .emacs that cause >> the slowdown not observed in "emacs -Q"? > > I believed I tracked at least one customization that causes a very > noticeable slowdown: global-hl-line-mode. On the org file linked > above, navigation is slow even with all trees folded with this minor > mode enabled. +1 to Mathieu's observation After checking for the effect of several customizations, `global-hl-line-mode' is the customization that impact most the navigation in large org file. -- Bruno ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-09-13 16:55 ` Slow/poor responsiveness in org files Bruno Tavernier @ 2011-09-14 15:37 ` Eli Zaretskii 2011-09-14 18:00 ` Bruno Tavernier 0 siblings, 1 reply; 24+ messages in thread From: Eli Zaretskii @ 2011-09-14 15:37 UTC (permalink / raw) To: Bruno Tavernier; +Cc: emacs-devel > From: Bruno Tavernier <tavernier.bruno@gmail.com> > Date: Tue, 13 Sep 2011 18:55:10 +0200 > > > I believed I tracked at least one customization that causes a very > > noticeable slowdown: global-hl-line-mode. On the org file linked > > above, navigation is slow even with all trees folded with this minor > > mode enabled. > > +1 to Mathieu's observation > > After checking for the effect of several customizations, > `global-hl-line-mode' is the customization that impact most the > navigation in large org file. Do you also see, like I do, that with `global-hl-line-mode' turned on, navigation backwards is considerably faster than forward? E.g., try C-p and C-n. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-09-14 15:37 ` Eli Zaretskii @ 2011-09-14 18:00 ` Bruno Tavernier 2011-09-14 19:55 ` Eli Zaretskii 0 siblings, 1 reply; 24+ messages in thread From: Bruno Tavernier @ 2011-09-14 18:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Bruno Tavernier <tavernier.bruno@gmail.com> >> Date: Tue, 13 Sep 2011 18:55:10 +0200 >> >> > I believed I tracked at least one customization that causes a very >> > noticeable slowdown: global-hl-line-mode. On the org file linked >> > above, navigation is slow even with all trees folded with this minor >> > mode enabled. >> >> +1 to Mathieu's observation >> >> After checking for the effect of several customizations, >> `global-hl-line-mode' is the customization that impact most the >> navigation in large org file. > > Do you also see, like I do, that with `global-hl-line-mode' turned on, > navigation backwards is considerably faster than forward? E.g., try > C-p and C-n. Nope. C-p and C-n appears to be equally fast. What I notice however, is that if I unfold all the headlines displayed on the screen, the navigation is perfectly normal. The cursor movement only stutter when the headlines are folded (whatever the headline level). Finally, I tried `outline-next-visible-heading' and it turns out to works like a charm. Hope that helps -- Bruno ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-09-14 18:00 ` Bruno Tavernier @ 2011-09-14 19:55 ` Eli Zaretskii 0 siblings, 0 replies; 24+ messages in thread From: Eli Zaretskii @ 2011-09-14 19:55 UTC (permalink / raw) To: Bruno Tavernier; +Cc: emacs-devel > From: Bruno Tavernier <tavernier.bruno@gmail.com> > Cc: emacs-devel@gnu.org > Date: Wed, 14 Sep 2011 20:00:43 +0200 > > What I notice however, is that if I unfold all the headlines displayed > on the screen, the navigation is perfectly normal. > > The cursor movement only stutter when the headlines are folded (whatever > the headline level). That is hardly surprising, if you consider what Emacs needs to do when large portions of the buffer are not shown: it needs to find the next visible line by scanning all the invisible ones in between. So the more text is folded, the slower will be the display. > Finally, I tried `outline-next-visible-heading' and it turns out to works like a charm. Because it doesn't try to preserve the column and support continued lines the way next-line and previous-line do. It simply goes to the next heading by regexp, then checks if that heading is visible, and if not continues to the next one. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-08-22 0:52 ` Tim Cross 2011-08-22 5:55 ` Eli Zaretskii @ 2011-09-13 20:42 ` Claus Klingberg 2011-09-14 3:01 ` Eli Zaretskii 1 sibling, 1 reply; 24+ messages in thread From: Claus Klingberg @ 2011-09-13 20:42 UTC (permalink / raw) To: emacs-devel I can second Tim's observation: Slow scrolling and high CPU-usage in my fairly large org-mode-file, which disappears after setting bidi-display-reordering to nil. I was looking for an existing bug in the tracker, but couldn't find one though. Claus On Mon, Aug 22, 2011 at 2:52 AM, Tim Cross <theophilusx@gmail.com> wrote: > SOLVED! > > Adding the line > > (setq bidi-display-reordering nil) > > to my org-mode-hook has fixed the problem. Cursor movement and editing > operations are now usable and the delays are gone. > > This was with Emacs 24.0.50 revno 105525 > > Unfortunately, I now find I have emacs generating a backtrace when I > try to quite with the error > void-function bidi-string-mark-left-to-right, but I think that is > unrelated and just coincidental. > > Tim > > > On Sat, Aug 20, 2011 at 10:53 AM, Tim Cross <theophilusx@gmail.com> wrote: >> On Sat, Aug 20, 2011 at 10:23 AM, Bastien <bzg@altern.org> wrote: >>> Hi Tim, >>> >>> Tim Cross <theophilusx@gmail.com> writes: >>> >>>> OK, will do. >>> >>> Thanks in advance! >>> >>>> As Bastien indicates this is a known problem, I will assume there is >>>> an existing bug report and won't create a new one. I will post my >>>> results back here. Given the combinations to test, this will take some >>>> work and some time. >>> >>> Please first try what Antoine suggested. >>> >>>> One question I do have, how do I run emacs bzr trunk with org 7.4? Is >>>> it sufficient to just ensure some 7.4 load directory is first in the >>>> load path? >>> >>> I think so. >>> >>>> Also, what is the url to get 7.4? >>> >>> http://orgmode.org/org-7.4.tar.gz >>> >>> Or get Org from git: >>> >>> ~$ git clone git://orgmode.org/org-mode.git >>> >>> and checkout commit 597e2863377fb8763cf6951e3b4e777b4616300d >>> >>> HTH, >>> >>> -- >>> Bastien >>> >> >> OK, will try to do later this weekend. Was going to check the bidi >> settings first as the changing of the default for bidi mode and the >> merge of 7.7 occured quite close - probably within the same update for >> me. I am a daily org user and had not noticed any performance issues >> with 7.4. >> >> Need to wait until my work completes the current major system update >> outage to get access to my large org file that I want to test with. >> Should be able to do this tomorrow. >> >> Tim >> >> P.S. I did notice no significant performance problems with very small >> org test files. It would seem you need to cross some size threshold >> before you notice the performance impact. >> > > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-09-13 20:42 ` Claus Klingberg @ 2011-09-14 3:01 ` Eli Zaretskii 0 siblings, 0 replies; 24+ messages in thread From: Eli Zaretskii @ 2011-09-14 3:01 UTC (permalink / raw) To: Claus Klingberg; +Cc: emacs-devel > Date: Tue, 13 Sep 2011 22:42:59 +0200 > From: Claus Klingberg <cjk@pobox.com> > > Slow scrolling and high CPU-usage in my fairly large org-mode-file, > which disappears after setting bidi-display-reordering to nil. Does it also disappear when you leave bidi-display-reordering at its default value, and instead set bidi-paragraph-direction to `left-to-right'? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-08-18 5:56 Slow/poor responsiveness in org files Tim Cross 2011-08-18 7:49 ` Bastien @ 2011-09-13 3:20 ` Torsten Wagner 2011-09-13 4:52 ` Tim Cross 1 sibling, 1 reply; 24+ messages in thread From: Torsten Wagner @ 2011-09-13 3:20 UTC (permalink / raw) To: Tim Cross; +Cc: Emacs developers Hi Tim, On 08/18/2011 02:56 PM, Tim Cross wrote: > About a week or so ago, I updated emacs from bzr and saw that org 7.7 > had been merged in. Since then, I have also noticed a distinct delay > when performing various editing operations within org files. For > example, killing a line wiht C-k in an org mode buffer is taking about > 4 seconds! This might be not related to your problem but by any chance are you running the linum mode (displaying line numbers on the left side of the buffer). I notice that this plays not well with the folding mechanisms of org-mode. Switching linum mode off and the pointer movement as well as folding/unfolding within the file becomes again very responsive and fast. Thought this might be interesting to know... Totti ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Slow/poor responsiveness in org files 2011-09-13 3:20 ` Torsten Wagner @ 2011-09-13 4:52 ` Tim Cross 0 siblings, 0 replies; 24+ messages in thread From: Tim Cross @ 2011-09-13 4:52 UTC (permalink / raw) To: Torsten Wagner; +Cc: Emacs developers Hi Torsten, no, not running linnum mode or anything 'special' - just org-mode. I started cutting down my org file to try and put together a more concise org file which Eli could work with to try and find the problem, but darn work life has gotten in the way - hope to get back to this today or tomorrow. Tim On Tue, Sep 13, 2011 at 1:20 PM, Torsten Wagner <torsten.wagner@gmail.com> wrote: > Hi Tim, > > > On 08/18/2011 02:56 PM, Tim Cross wrote: >> >> About a week or so ago, I updated emacs from bzr and saw that org 7.7 >> had been merged in. Since then, I have also noticed a distinct delay >> when performing various editing operations within org files. For >> example, killing a line wiht C-k in an org mode buffer is taking about >> 4 seconds! > > This might be not related to your problem but by any chance are you running > the linum mode (displaying line numbers on the left side of the buffer). > > I notice that this plays not well with the folding mechanisms of org-mode. > Switching linum mode off and the pointer movement as well as > folding/unfolding within the file becomes again very responsive and fast. > > Thought this might be interesting to know... > > Totti > -- Tim Cross Phone: 0428 212 217 ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2011-09-20 15:02 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-08-18 5:56 Slow/poor responsiveness in org files Tim Cross 2011-08-18 7:49 ` Bastien 2011-08-18 11:53 ` Antoine Levitt 2011-08-19 23:42 ` Tim Cross 2011-08-20 0:23 ` Bastien 2011-08-20 0:53 ` Tim Cross 2011-08-22 0:52 ` Tim Cross 2011-08-22 5:55 ` Eli Zaretskii 2011-08-22 6:42 ` Tim Cross 2011-08-22 7:03 ` Eli Zaretskii 2011-09-13 0:22 ` Mathieu Boespflug 2011-09-13 2:59 ` Eli Zaretskii 2011-09-13 4:36 ` Mathieu Boespflug 2011-09-13 5:51 ` Eli Zaretskii 2011-09-14 15:34 ` Paragraph direction in Org Mode (was: Slow/poor responsiveness in org files) Eli Zaretskii 2011-09-20 15:02 ` Eli Zaretskii 2011-09-13 16:55 ` Slow/poor responsiveness in org files Bruno Tavernier 2011-09-14 15:37 ` Eli Zaretskii 2011-09-14 18:00 ` Bruno Tavernier 2011-09-14 19:55 ` Eli Zaretskii 2011-09-13 20:42 ` Claus Klingberg 2011-09-14 3:01 ` Eli Zaretskii 2011-09-13 3:20 ` Torsten Wagner 2011-09-13 4:52 ` Tim Cross
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.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).