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.
next prev parent 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).