Carsten Dominik <carsten.domi...@gmail.com> writes: > On 10.9.2013, at 05:47, Carsten Dominik <carsten.domi...@gmail.com> wrote: > >> >> On 9.9.2013, at 17:41, Nicolas Goaziou <n.goaz...@gmail.com> wrote: >> >>> Carsten Dominik <carsten.domi...@gmail.com> 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)? >> >> No, I guess not. Lets just leave it the way it is, but implement >> alternative behavior in source code blocks. I agree with the arguments you >> make below. > > One more thought: What if the paragraph motion commands did use elements, but > ignored the hierarchy. So they jump to the next headline, paragraph, table, > src block, item? > > I think this would feel similar to what paragraph motion does in text mode. > > - Carsten
I once got halfway through implementing a pair of functions, org-next-element and org-previous-element, that would do just that (and for this very reason -- I still feel like the present behavior of "M-}" and "M-{" is surprising and inconvenient). org-next-element sort of went: 1. Check if org-element-at-point has a :contents-begin, and if it does, and we're not there yet, then go to it (then skip over property drawers). 2. If it doesn't, or we're already there, call org-forward-element. I can't remember why I didn't finish it. I think there were weird edge cases, and org-previous-element turned out to be more complicated, and I got distracted. I do think these would be better options for M-{ and M-}, though... E