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 14:34:51 -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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56933) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WR75Z-00027L-WC for emacs-orgmode@gnu.org; Fri, 21 Mar 2014 17:34:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WR75Y-00017r-EM for emacs-orgmode@gnu.org; Fri, 21 Mar 2014 17:34:53 -0400 In-Reply-To: <87lhw7cjws.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, thanks for revisiting this. i cannot do thorough bug reports at this time, but there are a few undo-related issues in org-mode now. here are a few from memory [there are others]: - occasional buffer or undo-tree corruption from c-c ' [see previous posts in this thread] - disruptive and surprising combining of undo entries when doing agenda operations where you can't undo properly - buffer corruption without c-c ' typical example of last one: === * bastien #+begin_src org bastien ^bastien #+end_src * bastien === put point at ^, fill-paragraph, undo. with undo-tree, at least, the buffer will be corrupted. === often there is no way to fix the buffer corruption. undo is after all a way to fix things. so i'm particularly sensitive to it not working. if org did not touch undo internal features, then i think undo would be more trustworthy. this is what i prefer as a user. i think not touching undo internals is the safer, more defensive strategy. === 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. in the case of c-c ', i would prefer having the indentation adding show up as an undo entry [or whatever would happen if we ripped out the undo-related setting]. separating the undo of the base and indirect buffers leads to surprises. i expect undo to just work in both places and not to undo things that i did not edit last. 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. :/ === 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. for me, the best undo feature of all is reliability. :] samuel On 3/18/14, Bastien wrote: > Hi Samuel, > > Samuel Wales writes: > >> as far as i know, my assessment below is correct, but i cannot >> confirm. > > I revisited this thread. > >> i believe that if undo-related code is ripped out of babel, then undo >> will work correctly in the source buffer and in the edit buffer. >> i am not clear on what the purpose of changing undo behavior is? > > Time flies: maybe it was clear before, but for now undo works fine > for me, in the source editing buffer and in the original buffer too. > > When I do C-c ' from the *Org Src* buffer, then C-/, the buffer is > restored to its previous state, that is: before the insertion of the > edited source. > > Can you restate what the bug is? > > Thanks, > > -- > Bastien > -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. And ANYBODY can get it. Denmark: free Karina Hansen NOW.