From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sebastien Vauban" Subject: Re: Outline cycling does not preserve point's position Date: Mon, 09 Sep 2013 19:42:37 +0200 Message-ID: <86y575nb76.fsf@somewhere.org> References: <868uz8sufg.fsf@somewhere.org> <86vc2cqvnb.fsf@somewhere.org> <86y57676t1.fsf@somewhere.org> <89E7FDB6-0F5A-4362-959C-C4B9844A235C@gmail.com> <86txhu7696.fsf@somewhere.org> <0A62C6DE-B3AD-458A-9AB4-92B61A6D3D63@gmail.com> <86ppsi75st.fsf@somewhere.org> <87eh8yo0el.fsf@bzg.ath.cx> <87li365ixg.fsf@gmail.com> <87d2oi57fg.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: 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-mXXj517/zsQ@public.gmane.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org To: emacs-orgmode-mXXj517/zsQ@public.gmane.org Hello Nicolas, Nicolas Goaziou wrote: > Carsten Dominik writes: > >> It is extremely predictable if you know about the structure of an Org >> document and if you think in elements. > > It's a Sexp motion. > >> It is unexpected for a user who is used to C-arrow doing paragraph >> motion. In Org, org-backward-element climbs out if a hierarchy. This >> is not what happens in other modes with this command. That is what >> I mean with unexpected. > > OK. Do you want it to return an error if there's no element at the same > level above (or below for the forward counterpart)? > >> Don't get me wrong. I love the element motion stuff. But I am >> satisfied for it to be available on M-{ and M-}. >> >> I like your proposal to introduce a variable for special src behavior. >> I personally would also like a variable that allows me to keep the >> paragraph commands on C-arrow (because I have almost equally >> convenient bindings with M-{}) - but maybe that is just me? > > But `org-forward-element'/`org-backward-element' are the paragraph > commands for Org. Unlike to Text mode, contents in Org have a depth. So > it's not just about stopping at blank lines. Even stopping at blank > lines is not satisfying: > > XParagraph > | a | table | > > Another paragraph > > A decent forward paragraph command should stop at the table here. On the > other hand, it doesn't make much sense to stop at the blank line below: > > X#+begin_src emacs-lisp > ;; line 1 > > ;; line 2 > #+end_src > Another paragraph > > When depth isn't involved, I think that `org-forward-element' is as good > as it can get as a paragraph motion command, and far better than > `forward-paragraph' from "paragraphs.el". I think everybody would be happy if what you proposed at 13:32 can be implemented: >>> From: Nicolas Goaziou >>> Date: Mon, 09 Sep 2013 13:30:33 +0200 (6 hours, 7 minutes, 27 seconds ago) >>> >>> Hello, >>> >>> Carsten Dominik writes: >>> >>>> This might be difficult, but not impossible. >>>> I think this might be a question for Nicolas to answer? >>> >>> It boils down to something like: >>> >>> (if (eq (org-element-type (org-element-at-point)) 'src-block) >>> ;; Do forward-paragraph according to language. >>> ... >>> (org-forward-element)) >>> >>> Though, I suggest to introduce a variable similar to >>> `org-src-tab-acts-natively', or group both features in the same variable >>> like `org-act-natively-on-src-block'. That way, one has `org-forward-element' for moving inside most elements of the documents, but, inside code blocks, the behavior is similar to the one we would get if we were editing the code in an indirect buffer. Eventually, this behavior can be controlled, as you suggested, by a variable. I guess this is very good, and would content most, if not all, of us! Best regards, Seb -- Sebastien Vauban