From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Unhiding edited areas Date: Mon, 3 Aug 2009 15:53:56 +0200 Message-ID: References: <4A71BF50.2050401@os.inf.tu-dresden.de> <20524da70907301110m208bc575jc1f18de4460cc56e@mail.gmail.com> <4A71EB7A.8060608@os.inf.tu-dresden.de> Mime-Version: 1.0 (Apple Message framework v935.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MXxzL-00074a-Ej for emacs-orgmode@gnu.org; Mon, 03 Aug 2009 09:54:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MXxzF-00071t-T7 for emacs-orgmode@gnu.org; Mon, 03 Aug 2009 09:54:06 -0400 Received: from [199.232.76.173] (port=43259 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MXxzF-00071o-NA for emacs-orgmode@gnu.org; Mon, 03 Aug 2009 09:54:01 -0400 Received: from ey-out-1920.google.com ([74.125.78.144]:5593) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MXxzF-0006PO-3d for emacs-orgmode@gnu.org; Mon, 03 Aug 2009 09:54:01 -0400 Received: by ey-out-1920.google.com with SMTP id 5so917417eyb.24 for ; Mon, 03 Aug 2009 06:54:00 -0700 (PDT) In-Reply-To: <4A71EB7A.8060608@os.inf.tu-dresden.de> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Martin Pohlack Cc: emacs-orgmode@gnu.org On Jul 30, 2009, at 8:50 PM, Martin Pohlack wrote: > Hi Samuel, > > Samuel Wales wrote: >> Hi Martin, >> >> This is a huge issue.[1] >> >> Here is what I do to try to work around it. >> >> I use git, to limit the damage from confusion. > > Yes, this or a versioning filesystem is probably advisable. > >> I expand the entire buffer if I think I am about to be confused. >> >> ;;i like the idea of clustering undo but find it disconcerting >> (setf org-self-insert-cluster-for-undo nil) >> ;;somebody, I think Carsten, suggested this, and it might work for >> you, but for some reason I commented it out. I don't remember what >> the reason was. Maybe speed. >> '(defadvice undo (after org-undo-reveal activate) >> "Make point and context visible after an undo command in Org-mode." >> (and (org-mode-p) (org-reveal))) >> ;;(ad-unadvise 'undo) Hi Samuel, Martin, this could be a good FAQ entry, I think. If speed was the reason to discard this, maybe try again, because I believe that recent changes will have solved many of the speed issues that might plague org-reveal in lists with many siblings. - Carsten > > Awesome, this is exactly what I was looking for! > >> [1] It is even more important when combined with what is IMO Emacs's >> greatest need for improvement, which is that you can undo, and undo >> an >> undo, and this is considered to be sufficient since you can get >> anywhere in the timeline in principle -- but many users, myself >> included, prefer a true redo command, both because undoing an undo >> does not let you do commands (such as copying) in the middle of an >> undo sequence without going the other direction, and because it feels >> more intuitive to tell emacs where in the timeline we want to go, and >> go forward or backward if we overshoot, thus making it possible to >> view the timeline the same way as we go backward and forward in any >> linear sequence. (redo.el provides the functionality, but it >> corrupts >> the buffer.) Of course, many are comfortable with the traditional >> undo-the-undo mechanism, so that should stay possible, but there are >> many who are not, and a redo mechanism would satisfy them. It is >> possible to get more fancy with a tree. > > The current undo system is very powerful as it doesn't lose history > (unless you hit a quota limit). With undo-redo systems you usually > can > lose history if you edit things in an old state. Suddenly redo is not > available anymore. You can only access the most recent branch in the > history tree. > > In emacs this will not happen as you can reach all nodes in the buffer > history, but these states are not easily accessible, especially, if > you > went back and forth some times. I cannot track the list of states > in my > mind or imagine the current structure of the undo tree, I can only go > step by step and look at the situation in the buffer and decide > whether > this is what I wanted or not. > > I recently stumbled upon an article which, I think, quiet nicely > summarized what one wants: > > http://e-texteditor.com/blog/2006/making-undo-usable > > But it's not available for emacs ... > > Cheers, > Martin > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode