Re: [dev] org-indent-mode patch

[Linus Arver <linusarver@gmail.com>]

Hello,

On Mon, Mar 14, 2011 at 08:51:27AM +0100, Carsten Dominik wrote:
> Hi Nicolas,
> 
> On 13.3.2011, at 17:21, Nicolas wrote:
> 
> > Hello,
> > 
> > I'd like to submit the following org-indent-mode patch for testing.
> > 
> >     git://github.com/ngz/org-mode-lists.git indent-patch-no-timer
> > 
> > It implements two things:
> > 
> > 1. It indents correctly text when using visual-line-mode;
> > 2. It removes the idle timer previous implementation was using, which
> >   means it won't refresh indentation more often than necessary.
> > 
> > Unfortunately, there is a price to pay:
> > 
> > 1. Initialization will be much longer for large Org files, but I've
> >   added a message to the user saying so.
> > 2. It is a bit slower, as the algorithm has more things to check.
> > 
> > 
> > Last point is obviously my main concern. Although not noticeable on my
> > not-so-recent laptop, I don't know how it behaves on old machines.
> > 
> > That's why a testing is necessary to determine (bugs and) if it is
> > usable. Any help welcome.
> > initial testing seems to show that this works well, very nice.
> 
> The delay at the beginning is long, and it might be annoying
> when org pulls in a buffer just to look something up,
> without org-inhibit-startup scoped into the file loading.
> 
> Maybe one could arrange for the initialization to happen just
> before the buffer is first *displayed* (I do not know if that
> is possible).

From my tests, the delay at the beginning is only long for a file with
unreasonably long lists. I tested a sample file with 1000 lists each
with 1140 characters and it took me roughly 12 seconds on an Intel Q6600
2.4Ghz. On the other hand, 1000 lists with 304 characters took me a
little over 3 seconds. Lastly, 1000 lists with only 102 characters each
took me just over a second. So, I think the startup delay is very
reasonable, since only very long list lines slow down the startup time,
and such list items are almost always rarer than shorter list items.

> Just one nitpicking:  The idle timer may force updating when
> not necessary - but using after-change-functions will update after
> each character inserted.  So in fact your code might be updating
> more often at least while typing - maybe not while looking at
> the buffer and jumping around.  I am not a fast typist, but maybe
> fast typists will notice significant delays, in particular
> while writing inside a very long section?

In my 1000 list (1140-characters per list) file, I smashed my keys as
fast as I could inside one of those lists, and there was no slowdown at
all. The only time there was a slowdown was when I held down a key to
let it repeat (although I have an unusually fast key repeat rate on my
keyboard --- I have "xset r rate 250 80" in my ~/.xinitrc). According to
the xset man page this means 80 characters per second.

-Linus