element-debug-mode breaks capture

element-debug-mode breaks capture

[Samuel Wales]

in maint when i capture, i often get this:

  Error running timer `org-element--cache-sync': (wrong-type-argument
integer-or-marker-p nil)

so i run element-debug-mode on the base buffer of the
capture.  but then capture stops working:

Debugger entered--Lisp error: (error "Capture abort:
(wrong-type-argument keymapp nil)")

capture is being called with nil argument.

user error?

Re: element-debug-mode breaks capture

[Bastien]

Samuel Wales <samologist@gmail.com> writes:

> in maint when i capture, i often get this:
>
>   Error running timer `org-element--cache-sync': (wrong-type-argument
> integer-or-marker-p nil)

I also had a lot of these recently.

I'm now turning org-element-use-cache off and I don't see real issue
when not using it.

Nicolas, what's the real benefit of using the cache?  Is it with
large files?  With frequent updates of the structure?  What actions
are the most impacted by not using the cache?

Thanks,

-- 
 Bastien

Re: element-debug-mode breaks capture

[Nicolas Goaziou]

Hello,

Bastien <bzg@gnu.org> writes:

> I also had a lot of these recently.

I posted some tricks on the ML to help debug the problem. Also, a single
cache corruption can lead to many error reports (basically whenever
a command relying on `org-element-at-point' is used).

> I'm now turning org-element-use-cache off and I don't see real issue
> when not using it.
>
> Nicolas, what's the real benefit of using the cache?  Is it with
> large files?  With frequent updates of the structure?  What actions
> are the most impacted by not using the cache?

It makes `org-element-context'/`org-element-at-point' very fast in
almost every situation. This is of course the most noticeable when
editing large sections.

However, once remaining glitches in the cache are fixed, I expect to
make fontification use it. So, turning cache off in the long run doesn't
help moving forward, though it may be convenient in some unfortunate
situations.


Regards,

-- 
Nicolas Goaziou

Re: element-debug-mode breaks capture

[Bastien]

Hi Nicolas,

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> It makes `org-element-context'/`org-element-at-point' very fast in
> almost every situation. This is of course the most noticeable when
> editing large sections.

How can I test it manually to really _notice_ the difference between
using the cache and not using it?

(I'm not discussing it's general utility, I'm trying to understand in
what circumstances the cache is a noticeable optimization.)

> However, once remaining glitches in the cache are fixed, I expect to
> make fontification use it. So, turning cache off in the long run doesn't
> help moving forward, though it may be convenient in some unfortunate
> situations.

The cache seems still a bit brittle, so yes, let's fix it and see.

-- 
 Bastien

Re: element-debug-mode breaks capture

[Nicolas Goaziou]

Bastien <bzg@gnu.org> writes:

> How can I test it manually to really _notice_ the difference between
> using the cache and not using it?

Create a buffer with a large section (or no section at all).

Edit the end of the section (e.g., fill paragraphs) ...

Regards,

Re: element-debug-mode breaks capture

[Bastien]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Bastien <bzg@gnu.org> writes:
>
>> How can I test it manually to really _notice_ the difference between
>> using the cache and not using it?
>
> Create a buffer with a large section (or no section at all).
>
> Edit the end of the section (e.g., fill paragraphs) ...

With a 13MO file, with 500 headlines, each containing about 100
paragraphs, editing the end of the last paragraph (unfill/fill)
is just very fast.

My machine is this: http://minifree.org/product/libreboot-x200/

So nothing really crazy...

Maybe I don't do the right test.

-- 
 Bastien

Re: element-debug-mode breaks capture

[Eric S Fraga]

On Wednesday, 19 Aug 2015 at 12:55, Bastien wrote:

[...]

> With a 13MO file, with 500 headlines, each containing about 100
> paragraphs, editing the end of the last paragraph (unfill/fill)
> is just very fast.

What about editing at the start of the file?

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.1-117-gc98729

Re: element-debug-mode breaks capture

[Bastien]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Wednesday, 19 Aug 2015 at 12:55, Bastien wrote:
>
> [...]
>
>> With a 13MO file, with 500 headlines, each containing about 100
>> paragraphs, editing the end of the last paragraph (unfill/fill)
>> is just very fast.
>
> What about editing at the start of the file?

Very fast.  I made a small movie, that'll help telling if I'm
doing the wrong tests:

http://bzg.fr/u/org-element-cache-test.ogv

-- 
 Bastien

Re: element-debug-mode breaks capture

[Nicolas Goaziou]

Bastien <bzg@gnu.org> writes:

> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> On Wednesday, 19 Aug 2015 at 12:55, Bastien wrote:
>>
>> [...]
>>
>>> With a 13MO file, with 500 headlines, each containing about 100
>>> paragraphs, editing the end of the last paragraph (unfill/fill)
>>> is just very fast.
>>
>> What about editing at the start of the file?
>
> Very fast.  I made a small movie, that'll help telling if I'm
> doing the wrong tests:
>
> http://bzg.fr/u/org-element-cache-test.ogv

You edit the first paragraph of a section, which is always fast.

Try 1000 paragraphs in a single entry and move to the end of line
anywhere in the last one.

Also, try (require 'benchmark) (benchmark 1 '(org-element-at-point))
*twice* with or without `org-element-use-cache' in that last paragraph.

Without cache, parsing doesn't scale. Some users reported already in
th past having issues with speed on large documents.


Regards,