From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Porter Subject: Re: How to do proper folding and semantic markup Date: Tue, 5 Apr 2016 23:56:16 +0000 (UTC) Message-ID: References: <87vb438zm8.fsf@mercovich.net> <87pou5s9i9.fsf@mercovich.net> <871t6j69gf.fsf@mercovich.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:56284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anapn-0007Nj-K3 for emacs-orgmode@gnu.org; Tue, 05 Apr 2016 19:56:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anapi-0005YN-Go for emacs-orgmode@gnu.org; Tue, 05 Apr 2016 19:56:35 -0400 Received: from plane.gmane.org ([80.91.229.3]:52142) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anapi-0005XM-9g for emacs-orgmode@gnu.org; Tue, 05 Apr 2016 19:56:30 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1anapg-0004c2-U4 for emacs-orgmode@gnu.org; Wed, 06 Apr 2016 01:56:29 +0200 Received: from 172-0-42-27.lightspeed.ltrkar.sbcglobal.net ([172.0.42.27]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Apr 2016 01:56:28 +0200 Received: from adam by 172-0-42-27.lightspeed.ltrkar.sbcglobal.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 06 Apr 2016 01:56:28 +0200 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: emacs-orgmode@gnu.org Eduardo Mercovich mercovich.net> writes: > Excuse me if this sounds almost philosophical, but in which situation an > indirect buffer may be better that just focusing on the same (original) > buffer? For example, when you are toying with potentially big > modifications and don't want to replace the original? Is it like opening > a parallel path to try things without worries? > > I know it's far from the original question, but it seems interesting to > understand the possibilities. :) An excellent question. :) I've been thinking about writing an article or something about this, but I'll give a quick explanation here. For years I've used Evernote on an irregular basis (they have been steadily regressing the UI across all platforms), and one of the things I do like about it is that each note is independent of the other notes in the database. When I'm editing one note, I only see that note, and I can only change that note. In Org, since I keep my notes in a few large files, it means that when I jump to a heading, I also see all the surrounding headings. Sometimes that's what I want, like if I'm editing a document, but when I jump to a random entry in my inbox.org file, the headings surrounding it are completely unrelated to the one I'm looking at, and they get in the way. So by jumping to an entry in an indirect buffer, I see only that entry, and I can't modify any other nodes. It means I can treat each entry independently, view and edit them separately, etc. In this way it resembles the way Evernote presents notes independently, but with all the power and flexibility of Org and Emacs. I put functions in org-bookmark-heading and helm-org-rifle to jump to entries in indirect buffers by pressing (by default), but I also do this in Agenda views with this code: (defun ap/org-agenda-goto-heading-in-indirect-buffer (&optional switch-to) "Go to the current agenda headline in an indirect buffer. If SWITCH-TO is non-nil, close the org-agenda window." (interactive) (if switch-to (org-agenda-switch-to) (org-agenda-goto)) (org-tree-to-indirect-buffer) ;; Put the non-indirect buffer at the bottom of the prev-buffers ;; list so it won't be selected when the indirect buffer is killed (set-window-prev-buffers nil (append (cdr (window-prev-buffers)) (car (window-prev-buffers))))) (defun ap/org-agenda-switch-to-heading-in-indirect-buffer () (interactive) To me this is a very powerful and flexible way of working with Org files, one that I think deserves wider exposure. Org files can be thought of not only as outlined documents but as collections of individual, unrelated entries that can be viewed and edited independently. (I also confess that it gives me some peace of mind, because a few times I have accidentally hit the wrong keys and deleted parts of an Org file that I didn't mean to. Most of the time I immediately undo it and no harm is done, but one time I didn't realize it until days or weeks later, and I had to pull it out of an earlier commit in my org directory's git repo.) Hope this helps! Let me know if you have any other questions or ideas. :)