Re: [O] [bug] [babel] babel corrupts undo history

[Samuel Wales]

hi bastien,

On 3/21/14, Bastien <address@hidden> wrote:
>> buffer will be corrupted.
>
> Not for me.  This has surely to do with undo-tree.

in emacs 23, i get the same bug with built-in undo.

>> one thing org sometimes does is try to set buffer-undo-list.  it's
>> really for speed imo.  i can't think of any reason why org really
>> needs it.  perhaps i am mistaken and there is a really good reason for
>> such things, but i suspect it has caused a lot of bugs.
>
> I can safely say this is *never* for speeding things up, it's for
> preserving the undo list state.

no, you misunderstand.  there is no sufficiently good reason for org
code to ever set such an internal variable in any buffer that the user
edits to my knowledge.

the only reason that makes sense to me is to turn off undo by setting
it to t in buffers that the user does not edit [such as a hidden
buffer], so that you avoid possible overhead.  that /is/ a potential
speed issue, even if it is mediated by memory.

thus, in practice, the variable is only really best used for speed imo.

> Unless I misunderstand, the addition of indentation is not manually
> done, so it should not be part of the undo list.

you understand here i think, but we disagree.  at present org
manipulates an undo variable that should not be manipulated, and the
result at best is that the user does this:

  c-c '
  edit
  c-c '
  edit
  undo
  undo OOPS the source edit is skipped over what just happened?
  c-c '
  undo OOPS the undo changes are all gone where did they go?

and at worst there is buffer corruption.  so i would far prefer to
have the indentation adding be NOT specially worked around by changing
the undo variable.

it is much better to not skip an entire set of changes + no bugs than
"the user will never want to see the indentation adding so let's
pretend it doesn't exist".

it might be better to have no indentation by default, but that's another issue.

>> even when there is not a bug per se, when you edit a source block,
>> there is a gap in the undo record.  like nixon's tape gap during
>> watergate, it raises questions.  :/
>
> :)

principle of least surprise is key here.

>> to me, undo is a low-level feature that should never be buggy or
>> surprising.  if it is, then anything that causes those should be
>> ripped out, even if it means losing a fancy undo-related feature.
>
> Fully agreed.  Let's raise bugs in this area when you have time
> and when the bug can be isolated from other third-part package.

i haven't tried with -Q yet but i don't think it's an undo-tree bug.

i think fixing each bug as it comes up is more error-prone for the
future than stopping the changing of undo-tree-list.

in most cases, i think the undo list manipulation should never happen
in the first place.  it just causes too many problems.

samuel