Karl Voit <devn...@karl-voit.at> writes:
> M-<up>/<down> of list item is fast again.
>
> Re-calculate table is fast again.
>
> Wohoo! :-) Thanks!
Applied. Thank you for the report.
> However, M-<up>/<down> of a big heading is still slow (see profile
> below). Probably, I am able to find other examples of slow behavior
> on the weekend, where I am using the Linux-machine that has the
> issue.
This operation is bound to be slow anyway. On top of it, you use
`org-indent-mode', which can be costly on large buffer changes.
Is it really worse than in 23.3?
Also, would you mind testing the following patch on top of master?
I don't expect much out of it since you're moving a behemoth, but it may
help.
Regards,
--
Nicolas Goaziou
>From 6681efd30c34e86ede597b5b9ec219c9358fc7eb Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <n.goaz...@gmail.com>
Date: Thu, 9 Jan 2014 21:59:59 +0100
Subject: [PATCH] Try something out
---
lisp/org-list.el | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/lisp/org-list.el b/lisp/org-list.el
index c0cf77e..f85c19b 100644
--- a/lisp/org-list.el
+++ b/lisp/org-list.el
@@ -134,6 +134,8 @@
(declare-function org-export-string-as "ox"
(string backend &optional body-only ext-plist))
+(declare-function org-element-type "org-element" (element))
+
@@ -489,10 +491,13 @@ group 4: description tag")
(t (forward-line -1)))))))))))
(defun org-at-item-p ()
- "Is point in a line starting a hand-formatted item?"
+ "Non-nil when point is in a line starting a list item."
(save-excursion
(beginning-of-line)
- (and (looking-at (org-item-re)) (org-list-in-valid-context-p))))
+ (and (looking-at (org-item-re))
+ (or (not (derived-mode-p 'org-mode))
+ (memq (org-element-type (save-match-data (org-element-at-point)))
+ '(item plain-list))))))
(defun org-at-item-bullet-p ()
"Is point at the bullet of a plain list item?"
--
1.8.5.2
