From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Wales Subject: Re: [bug] [babel] babel corrupts undo history Date: Fri, 21 Mar 2014 15:42:49 -0700 Message-ID: References: <87d2oxanct.fsf@gmail.com> <87hae9ajz2.fsf@gmail.com> <87bo4h8x63.fsf@gmail.com> <877gcx19zc.fsf@gmail.com> <871u3517no.fsf@gmail.com> <87lhw7cjws.fsf@bzg.ath.cx> <87r45vkxxm.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WR89K-0004lR-SZ for emacs-orgmode@gnu.org; Fri, 21 Mar 2014 18:42:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WR89J-0006AF-QF for emacs-orgmode@gnu.org; Fri, 21 Mar 2014 18:42:50 -0400 In-Reply-To: <87r45vkxxm.fsf@bzg.ath.cx> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bastien Cc: emacs-orgmode@gnu.org, Eric Schulte hi bastien, On 3/21/14, Bastien 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