emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: Bastien <bzg@gnu.org>
Cc: emacs-orgmode@gnu.org, Eric Schulte <schulte.eric@gmail.com>
Subject: Re: [bug] [babel] babel corrupts undo history
Date: Fri, 21 Mar 2014 14:34:51 -0700	[thread overview]
Message-ID: <CAJcAo8swSqkt=VJMnnh4yhG73xPZc5C1qgzV8sAxZSmtFXc9tA@mail.gmail.com> (raw)
In-Reply-To: <87lhw7cjws.fsf@bzg.ath.cx>

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 <bzg@gnu.org> wrote:
> Hi Samuel,
>
> Samuel Wales <samologist@gmail.com> 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.

  reply	other threads:[~2014-03-21 21:34 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-28  1:13 [bug] [babel] babel corrupts undo history Samuel Wales
2013-08-28 14:42 ` Eric Schulte
2013-08-28 16:03   ` Aaron Ecay
2013-08-28 18:52     ` Eric Schulte
2013-08-28 19:41       ` Samuel Wales
2013-08-28 19:43         ` Samuel Wales
2013-08-28 19:51           ` Samuel Wales
2013-10-28 19:17             ` Aaron Ecay
2013-10-28 19:45               ` Samuel Wales
2013-10-28 20:07                 ` Aaron Ecay
2013-10-28 21:26                   ` Samuel Wales
2014-03-10  2:46                     ` Samuel Wales
2014-03-18 20:48                       ` Bastien
2014-03-21 21:34                         ` Samuel Wales [this message]
2014-03-21 22:07                           ` Bastien
2014-03-21 22:42                             ` Samuel Wales
2014-03-21 22:45                               ` Samuel Wales
2014-03-21 23:40                               ` Bastien
2014-03-22  0:11                                 ` Samuel Wales
2014-03-22  0:18                                   ` Bastien
2014-03-22  0:37                                     ` Samuel Wales
2014-03-22  0:44                                       ` Samuel Wales
2014-03-22  8:43                                         ` Bastien
2014-03-22  8:57                                           ` Samuel Wales
2013-08-28 17:08   ` Samuel Wales
2013-08-28 17:18     ` Samuel Wales

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJcAo8swSqkt=VJMnnh4yhG73xPZc5C1qgzV8sAxZSmtFXc9tA@mail.gmail.com' \
    --to=samologist@gmail.com \
    --cc=bzg@gnu.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=schulte.eric@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).