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. Regards, -- Nicolas
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).
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?
Regards
- Carsten
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
Hello, Carsten Dominik <carsten.dominik@gmail.com> writes: > On 13.3.2011, at 17:21, Nicolas wrote: > >> I'd like to submit the following org-indent-mode patch for testing. >> >> >> 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. >> > 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). > > 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 order to circumvent the slow process at initialization, I've implemented an asynchronous initialization. Thus, one can open the buffer and start to write in it before initialization is complete. Once it is done, everything else is synchronous again. I think it is a good compromise. It needs testing though. Thus, if anyone is interested, I'll gladly hear his feedback. The branch is located at : git://github.com/ngz/org-mode-lists.git indent-patch-no-timer Regards, -- Nicolas Goaziou
Hi Nicolas,
what has happened to this patch? Did you stop it due to my questions?
That was not my intention - so if you are convinced that it works well,
it might be a good solution.
- Carsten
On Jul 21, 2011, at 5:14 PM, Nicolas Goaziou wrote:
> Hello,
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> On 13.3.2011, at 17:21, Nicolas wrote:
>>
>>> I'd like to submit the following org-indent-mode patch for testing.
>>>
>>>
>>> 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.
>>>
>
>> 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).
>>
>> 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 order to circumvent the slow process at initialization, I've
> implemented an asynchronous initialization. Thus, one can open the
> buffer and start to write in it before initialization is complete. Once
> it is done, everything else is synchronous again.
>
> I think it is a good compromise. It needs testing though. Thus, if
> anyone is interested, I'll gladly hear his feedback.
>
> The branch is located at :
>
> git://github.com/ngz/org-mode-lists.git indent-patch-no-timer
>
>
> Regards,
>
> --
> Nicolas Goaziou
- Carsten
Hello,
Carsten Dominik <carsten.dominik@gmail.com> writes:
> what has happened to this patch? Did you stop it due to my questions?
> That was not my intention - so if you are convinced that it works well,
> it might be a good solution.
>
> On Jul 21, 2011, at 5:14 PM, Nicolas Goaziou wrote:
>
>> In order to circumvent the slow process at initialization, I've
>> implemented an asynchronous initialization. Thus, one can open the
>> buffer and start to write in it before initialization is complete. Once
>> it is done, everything else is synchronous again.
>>
>> I think it is a good compromise. It needs testing though. Thus, if
>> anyone is interested, I'll gladly hear his feedback.
>>
>> The branch is located at :
>>
>> git://github.com/ngz/org-mode-lists.git indent-patch-no-timer
It's still there. As I use neither Org indent mode nor Visual line mode,
feedback is important. Have you tried it since asynchronous
initialization implementation? Does it solve the problems you raised?
Bernt Hansen has been testing it for a few weeks now. As far as I know,
he hasn't encountered any problem so far.
Regards,
--
Nicolas Goaziou
On Aug 18, 2011, at 12:19 PM, Nicolas Goaziou wrote:
> Hello,
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> what has happened to this patch? Did you stop it due to my questions?
>> That was not my intention - so if you are convinced that it works well,
>> it might be a good solution.
>>
>> On Jul 21, 2011, at 5:14 PM, Nicolas Goaziou wrote:
>>
>>> In order to circumvent the slow process at initialization, I've
>>> implemented an asynchronous initialization. Thus, one can open the
>>> buffer and start to write in it before initialization is complete. Once
>>> it is done, everything else is synchronous again.
>>>
>>> I think it is a good compromise. It needs testing though. Thus, if
>>> anyone is interested, I'll gladly hear his feedback.
>>>
>>> The branch is located at :
>>>
>>> git://github.com/ngz/org-mode-lists.git indent-patch-no-timer
>
> It's still there. As I use neither Org indent mode nor Visual line mode,
> feedback is important. Have you tried it since asynchronous
> initialization implementation? Does it solve the problems you raised?
>
> Bernt Hansen has been testing it for a few weeks now. As far as I know,
> he hasn't encountered any problem so far.
Well, if Bernt has been testing is w/o problems, it probably works.
I propose you push it into master, to make everyone use it - this
will be a good way to find out if there are niches
where it causes problems.
- Carsten
Carsten Dominik <carsten.dominik@gmail.com> writes:
> On Aug 18, 2011, at 12:19 PM, Nicolas Goaziou wrote:
>
>> Hello,
>>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>> what has happened to this patch? Did you stop it due to my questions?
>>> That was not my intention - so if you are convinced that it works well,
>>> it might be a good solution.
>>>
>>> On Jul 21, 2011, at 5:14 PM, Nicolas Goaziou wrote:
>>>
>>>> In order to circumvent the slow process at initialization, I've
>>>> implemented an asynchronous initialization. Thus, one can open the
>>>> buffer and start to write in it before initialization is complete. Once
>>>> it is done, everything else is synchronous again.
>>>>
>>>> I think it is a good compromise. It needs testing though. Thus, if
>>>> anyone is interested, I'll gladly hear his feedback.
>>>>
>>>> The branch is located at :
>>>>
>>>> git://github.com/ngz/org-mode-lists.git indent-patch-no-timer
>>
>> It's still there. As I use neither Org indent mode nor Visual line mode,
>> feedback is important. Have you tried it since asynchronous
>> initialization implementation? Does it solve the problems you raised?
>>
>> Bernt Hansen has been testing it for a few weeks now. As far as I know,
>> he hasn't encountered any problem so far.
>
> Well, if Bernt has been testing is w/o problems, it probably works.
> I propose you push it into master, to make everyone use it - this
> will be a good way to find out if there are niches
> where it causes problems.
I've been using it for awhile and haven't noticed any issues with it. I
use org-indent mode but I don't use visual line mode. I've switched
back and forth between this branch and master a few times during my
testing.
I think incorporating it in master so it gets more exposure for testing
is a good idea.
-Bernt
Hi Bernt,
Bernt Hansen <bernt@norang.ca> writes:
> I think incorporating it in master so it gets more exposure for
> testing is a good idea.
Thanks for the feedback.
Nicolas, feel free to merge this change so that more users can test it.
Thanks,
--
Bastien
Hello,
Bastien <bzg@altern.org> writes:
> Nicolas, feel free to merge this change so that more users can test
> it.
Done.
Regards,
--
Nicolas Goaziou
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> Bastien <bzg@altern.org> writes:
>
>> Nicolas, feel free to merge this change so that more users can test
>> it.
>
> Done.
Great work, thanks!!
--
Bastien