Outline cycling does not preserve point's position

Outline cycling does not preserve point's position

[Sebastien Vauban]

Hello,

Since a little while, I've observed that point's position is not anymore
preserved when cycling buffer's view with S-TAB.

Sometimes, point stays where it was (even when in the body of entries);
sometimes, not.

See http://screencast.com/t/1sr6Lezk:

- when on the first letter of "From", in that example, point's location is
  preserved;

- when on the second letter of it, point's location is lost: new position is
  at the end of the level 1 parent...

That's very annoying when you want to just look at your tree structure, but
don't expect to land somewhere else by doing so.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Outline cycling does not preserve point's position

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]

Hi Sebastien,

you say "since a little while".  Have you tried to bisect?
Or has it been like this always?

Also, I am not convinced that staying in invisible places is the
right behavior at all.  Even though I would agree that three S-TAB
in a row should be a null operation.

May be it would be better to use something like

   (org-display-outline-path nil t)

to see where you are?

- Carsten

On 7.9.2013, at 14:11, "Sebastien Vauban" <sva-news@mygooglest.com> wrote:

> Hello,
> 
> Since a little while, I've observed that point's position is not anymore
> preserved when cycling buffer's view with S-TAB.
> 
> Sometimes, point stays where it was (even when in the body of entries);
> sometimes, not.
> 
> See http://screencast.com/t/1sr6Lezk:
> 
> - when on the first letter of "From", in that example, point's location is
>  preserved;
> 
> - when on the second letter of it, point's location is lost: new position is
>  at the end of the level 1 parent...
> 
> That's very annoying when you want to just look at your tree structure, but
> don't expect to land somewhere else by doing so.
> 
> Best regards,
>  Seb
> 
> -- 
> Sebastien Vauban
> 
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: Outline cycling does not preserve point's position

[Sebastien Vauban]

Hi Carsten,

Carsten Dominik wrote:
> On 7.9.2013, at 14:11, "Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org> wrote:
>
>> Since a little while, I've observed that point's position is not anymore
>> preserved when cycling buffer's view with S-TAB.
>> 
>> Sometimes, point stays where it was (even when in the body of entries);
>> sometimes, not.
>> 
>> See http://screencast.com/t/1sr6Lezk:
>> 
>> - when on the first letter of "From", in that example, point's location is
>>  preserved;
>> 
>> - when on the second letter of it, point's location is lost: new position is
>>  at the end of the level 1 parent...
>> 
>> That's very annoying when you want to just look at your tree structure, but
>> don't expect to land somewhere else by doing so.
>
> you say "since a little while".  Have you tried to bisect?

Not yet. I have many Chinese plates turning at the moment, but I'll try to do
that very soon. And I have other problems to report or bisect:

- not possible anymore to "cut" a code snippet in two parts with C-c C-v C-d
  (demarcate block); already reported (without bisect), no answer;

- not possible anymore to use C-a or C-e in code blocks to select regions; not
  reported yet, though I reported similar problems with C-arrows (apparently
  due to a change which is now officially part of 8.1). IMO, that renders
  editing of code block in the original buffer much more annoying.

> Or has it been like this always?

In my mind, this did work before; or, at least, in (many) more cases than it
now does.

> Also, I am not convinced that staying in invisible places is the
> right behavior at all.  Even though I would agree that three S-TAB
> in a row should be a null operation.

At the very least, we could agree that point should always be part of the
entry we were on; so never go up to the *parent* entry.

> May be it would be better to use something like
>
>    (org-display-outline-path nil t)
>
> to see where you are?

I know where I am: I'm using that. But, sometimes (in fact, often), I want to
see the rest of the entries (brothers, parents, etc.) in the outline view.

I simply expect to land back at the entry I was at, when having cycled
3 times.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Outline cycling does not preserve point's position

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 2591 bytes --]

Hi Sebastien,

On 7.9.2013, at 21:28, Sebastien Vauban <sva-news@mygooglest.com> wrote:

> Hi Carsten,
> 
> Carsten Dominik wrote:
>> On 7.9.2013, at 14:11, "Sebastien Vauban" <sva-news@mygooglest.com> wrote:
>> 
>>> Since a little while, I've observed that point's position is not anymore
>>> preserved when cycling buffer's view with S-TAB.
>>> 
>>> Sometimes, point stays where it was (even when in the body of entries);
>>> sometimes, not.
>>> 
>>> See http://screencast.com/t/1sr6Lezk:
>>> 
>>> - when on the first letter of "From", in that example, point's location is
>>> preserved;
>>> 
>>> - when on the second letter of it, point's location is lost: new position is
>>> at the end of the level 1 parent...
>>> 
>>> That's very annoying when you want to just look at your tree structure, but
>>> don't expect to land somewhere else by doing so.
>> 
>> you say "since a little while".  Have you tried to bisect?
> 
> Not yet. I have many Chinese plates turning at the moment, but I'll try to do
> that very soon. And I have other problems to report or bisect:
> 
> - not possible anymore to "cut" a code snippet in two parts with C-c C-v C-d
>  (demarcate block); already reported (without bisect), no answer;
> 
> - not possible anymore to use C-a or C-e in code blocks to select regions; not
>  reported yet, though I reported similar problems with C-arrows (apparently
>  due to a change which is now officially part of 8.1). IMO, that renders
>  editing of code block in the original buffer much more annoying.

I have asked Eric about this.

> 
>> Or has it been like this always?
> 
> In my mind, this did work before; or, at least, in (many) more cases than it
> now does.
> 
>> Also, I am not convinced that staying in invisible places is the
>> right behavior at all.  Even though I would agree that three S-TAB
>> in a row should be a null operation.
> 
> At the very least, we could agree that point should always be part of the
> entry we were on; so never go up to the *parent* entry.

I have fixed this now, point does now completely stay put during global cycling.

> 
>> May be it would be better to use something like
>> 
>>   (org-display-outline-path nil t)
>> 
>> to see where you are?
> 
> I know where I am: I'm using that. But, sometimes (in fact, often), I want to
> see the rest of the entries (brothers, parents, etc.) in the outline view.
> 
> I simply expect to land back at the entry I was at, when having cycled
> 3 times.
> 
> Best regards,
>  Seb
> 
> -- 
> Sebastien Vauban


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: Outline cycling does not preserve point's position

[Eric Schulte]

>
> Not yet. I have many Chinese plates turning at the moment, but I'll try to do
> that very soon. And I have other problems to report or bisect:
>
> - not possible anymore to "cut" a code snippet in two parts with C-c C-v C-d
>   (demarcate block); already reported (without bisect), no answer;
>

This works for me, could you report a minimal recipe for reproduction,
and maybe a git bisect commit?

Thanks,

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: Outline cycling does not preserve point's position

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 2508 bytes --]


On 7.9.2013, at 21:28, Sebastien Vauban <sva-news@mygooglest.com> wrote:

> Hi Carsten,
> 
> Carsten Dominik wrote:
>> On 7.9.2013, at 14:11, "Sebastien Vauban" <sva-news@mygooglest.com> wrote:
>> 
>>> Since a little while, I've observed that point's position is not anymore
>>> preserved when cycling buffer's view with S-TAB.
>>> 
>>> Sometimes, point stays where it was (even when in the body of entries);
>>> sometimes, not.
>>> 
>>> See http://screencast.com/t/1sr6Lezk:
>>> 
>>> - when on the first letter of "From", in that example, point's location is
>>> preserved;
>>> 
>>> - when on the second letter of it, point's location is lost: new position is
>>> at the end of the level 1 parent...
>>> 
>>> That's very annoying when you want to just look at your tree structure, but
>>> don't expect to land somewhere else by doing so.
>> 
>> you say "since a little while".  Have you tried to bisect?
> 
> Not yet. I have many Chinese plates turning at the moment, but I'll try to do
> that very soon. And I have other problems to report or bisect:
> 
> - not possible anymore to "cut" a code snippet in two parts with C-c C-v C-d
>  (demarcate block); already reported (without bisect), no answer;
> 
> - not possible anymore to use C-a or C-e in code blocks to select regions; not
>  reported yet, though I reported similar problems with C-arrows (apparently
>  due to a change which is now officially part of 8.1). IMO, that renders
>  editing of code block in the original buffer much more annoying.

Also this is now fixed.

Regards

- Carsten

> 
>> Or has it been like this always?
> 
> In my mind, this did work before; or, at least, in (many) more cases than it
> now does.
> 
>> Also, I am not convinced that staying in invisible places is the
>> right behavior at all.  Even though I would agree that three S-TAB
>> in a row should be a null operation.
> 
> At the very least, we could agree that point should always be part of the
> entry we were on; so never go up to the *parent* entry.
> 
>> May be it would be better to use something like
>> 
>>   (org-display-outline-path nil t)
>> 
>> to see where you are?
> 
> I know where I am: I'm using that. But, sometimes (in fact, often), I want to
> see the rest of the entries (brothers, parents, etc.) in the outline view.
> 
> I simply expect to land back at the entry I was at, when having cycled
> 3 times.
> 
> Best regards,
>  Seb
> 
> -- 
> Sebastien Vauban


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: Outline cycling does not preserve point's position

[Sebastien Vauban]

Hi Carsten,

Carsten Dominik wrote:
> On 7.9.2013, at 21:28, Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org> wrote:
>> Carsten Dominik wrote:
>>> On 7.9.2013, at 14:11, "Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org> wrote:
>>> 
>>>> Since a little while, I've observed that point's position is not anymore
>>>> preserved when cycling buffer's view with S-TAB.
>>>> 
>>>> That's very annoying when you want to just look at your tree structure,
>>>> but don't expect to land somewhere else by doing so.
>> 
>> At the very least, we could agree that point should always be part of the
>> entry we were on; so never go up to the *parent* entry.
>
> I have fixed this now, point does now completely stay put during global
> cycling.

Simply perfect!

And the fact that the blinking cursor stays at the end of the closest headling
displayed (outline level 1, then outline level N) just shows where your point
is in the real contents. Great...

See http://screencast.com/t/dEbKjNlk

Thanks!

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Outline cycling does not preserve point's position

[Sebastien Vauban]

Hi Carsten,

Carsten Dominik wrote:
>> - not possible anymore to use C-a or C-e in code blocks to select regions;
>>   not reported yet, though I reported similar problems with C-arrows
>>   (apparently due to a change which is now officially part of 8.1). IMO,
>>   that renders editing of code block in the original buffer much more
>>   annoying.
>
> Also this is now fixed.

Regarding C-a/e, same remark: perfect!  Thanks a lot for these quick fixes...

Regarding C-down, is it possible to get it back working for selecting parts of
code?

In the video captured at http://screencast.com/t/1WjWohviyjE, we see that we
can move from an heading to the next with C-down (which is a nice extra
addition to the already existing speed commands), but also select subelements
in a region (paragraphs or list items).

Though, in the code block, C-down still looses the region...

Best regards,
  Seb

--
Sebastien Vauban

Re: Outline cycling does not preserve point's position

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]


On 9.9.2013, at 10:11, "Sebastien Vauban" <sva-news@mygooglest.com> wrote:

> Hi Carsten,
> 
> Carsten Dominik wrote:
>>> - not possible anymore to use C-a or C-e in code blocks to select regions;
>>>  not reported yet, though I reported similar problems with C-arrows
>>>  (apparently due to a change which is now officially part of 8.1). IMO,
>>>  that renders editing of code block in the original buffer much more
>>>  annoying.
>> 
>> Also this is now fixed.
> 
> Regarding C-a/e, same remark: perfect!  Thanks a lot for these quick fixes...
> 
> Regarding C-down, is it possible to get it back working for selecting parts of
> code?
> 
> In the video captured at http://screencast.com/t/1WjWohviyjE, we see that we
> can move from an heading to the next with C-down (which is a nice extra
> addition to the already existing speed commands), but also select subelements
> in a region (paragraphs or list items).
> 
> Though, in the code block, C-down still looses the region...

Hi Sebastien,

is this about loosing the active mark, or about the effect that C-down now jumps elements, not paragraphs?

- Carsten

> 
> Best regards,
>  Seb
> 
> --
> Sebastien Vauban
> 
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: Outline cycling does not preserve point's position

[Sebastien Vauban]

Hi Carsten,

Carsten Dominik wrote:
> On 9.9.2013, at 10:11, "Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org> wrote:
>> Carsten Dominik wrote:
>>>> - not possible anymore to use C-a or C-e in code blocks to select regions;
>>>>  not reported yet, though I reported similar problems with C-arrows
>>>>  (apparently due to a change which is now officially part of 8.1). IMO,
>>>>  that renders editing of code block in the original buffer much more
>>>>  annoying.
>> 
>> Regarding C-down, is it possible to get it back working for selecting parts of
>> code?
>> 
>> In the video captured at http://screencast.com/t/1WjWohviyjE, we see that we
>> can move from an heading to the next with C-down (which is a nice extra
>> addition to the already existing speed commands), but also select subelements
>> in a region (paragraphs or list items).
>> 
>> Though, in the code block, C-down still looses the region...
>
> is this about loosing the active mark, or about the effect that C-down now
> jumps elements, not paragraphs?

In fact, both... If we wanna still allow nice editing of code blocks, without
forcing the users to use the indirect buffer, one must be able to quickly
select, let's say a defvar, and copy it somewhere else; like we would do in
the programming mode buffer (and like we did in the Org buffer, up to the
change with C-down).

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Outline cycling does not preserve point's position

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]


On 9.9.2013, at 10:23, Sebastien Vauban <sva-news@mygooglest.com> wrote:

> Hi Carsten,
> 
> Carsten Dominik wrote:
>> On 9.9.2013, at 10:11, "Sebastien Vauban" <sva-news@mygooglest.com> wrote:
>>> Carsten Dominik wrote:
>>>>> - not possible anymore to use C-a or C-e in code blocks to select regions;
>>>>> not reported yet, though I reported similar problems with C-arrows
>>>>> (apparently due to a change which is now officially part of 8.1). IMO,
>>>>> that renders editing of code block in the original buffer much more
>>>>> annoying.
>>> 
>>> Regarding C-down, is it possible to get it back working for selecting parts of
>>> code?
>>> 
>>> In the video captured at http://screencast.com/t/1WjWohviyjE, we see that we
>>> can move from an heading to the next with C-down (which is a nice extra
>>> addition to the already existing speed commands), but also select subelements
>>> in a region (paragraphs or list items).
>>> 
>>> Though, in the code block, C-down still looses the region...
>> 
>> is this about loosing the active mark, or about the effect that C-down now
>> jumps elements, not paragraphs?
> 
> In fact, both... If we wanna still allow nice editing of code blocks, without
> forcing the users to use the indirect buffer, one must be able to quickly
> select, let's say a defvar, and copy it somewhere else; like we would do in
> the programming mode buffer (and like we did in the Org buffer, up to the
> change with C-down).

So maybe you just want to bing C-down to forward-paragraph again?

- Carsten

> 
> Best regards,
>  Seb
> 
> -- 
> Sebastien Vauban
> 
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: Outline cycling does not preserve point's position

[Sebastien Vauban]

Hi Carsten,

Carsten Dominik wrote:
> On 9.9.2013, at 10:23, Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org> wrote:
>> Carsten Dominik wrote:
>>> On 9.9.2013, at 10:11, "Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org> wrote:
>>>> Carsten Dominik wrote:
>>>>>> - not possible anymore to use C-a or C-e in code blocks to select
>>>>>> regions; not reported yet, though I reported similar problems with
>>>>>> C-arrows (apparently due to a change which is now officially part of
>>>>>> 8.1). IMO, that renders editing of code block in the original buffer
>>>>>> much more annoying.
>>>> 
>>>> Regarding C-down, is it possible to get it back working for selecting
>>>> parts of code?
>>>> 
>>>> In the video captured at http://screencast.com/t/1WjWohviyjE, we see that
>>>> we can move from an heading to the next with C-down (which is a nice
>>>> extra addition to the already existing speed commands), but also select
>>>> subelements in a region (paragraphs or list items).
>>>> 
>>>> Though, in the code block, C-down still looses the region...
>>> 
>>> is this about loosing the active mark, or about the effect that C-down now
>>> jumps elements, not paragraphs?
>> 
>> In fact, both... If we wanna still allow nice editing of code blocks,
>> without forcing the users to use the indirect buffer, one must be able to
>> quickly select, let's say a defvar, and copy it somewhere else; like we
>> would do in the programming mode buffer (and like we did in the Org buffer,
>> up to the change with C-down).
>
> So maybe you just want to bing C-down to forward-paragraph again?

This is a possibility, yes, but it completely defeats the nice `C-down' add-on
(when outside of code block), and I guess I won't be the only one with that
"problem".

Of course, the nicest would be to have both: the current `C-down' for text,
and the "programmatic" behavior when _in code blocks_. Maybe, that's not
possible, though...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Outline cycling does not preserve point's position

[Bastien]

Hi Sébastien,

"Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

> Of course, the nicest would be to have both: the current `C-down' for text,
> and the "programmatic" behavior when _in code blocks_. Maybe, that's not
> possible, though...

We could have org-ctrldown and friends the same way we have org-shift*
commands.  org-ctrldown would use `org-forward-element' when on some
Org element, and `forward-paragraph' elsewhere.

I acknowledge binding C-down to `org-forward-element' instead of
`forward-paragraph' is a bit disruptive, and maybe not ideal in all
situations.

-- 
 Bastien

Re: Outline cycling does not preserve point's position

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 2269 bytes --]


On 9.9.2013, at 10:33, "Sebastien Vauban" <sva-news@mygooglest.com> wrote:

> Hi Carsten,
> 
> Carsten Dominik wrote:
>> On 9.9.2013, at 10:23, Sebastien Vauban <sva-news@mygooglest.com> wrote:
>>> Carsten Dominik wrote:
>>>> On 9.9.2013, at 10:11, "Sebastien Vauban" <sva-news@mygooglest.com> wrote:
>>>>> Carsten Dominik wrote:
>>>>>>> - not possible anymore to use C-a or C-e in code blocks to select
>>>>>>> regions; not reported yet, though I reported similar problems with
>>>>>>> C-arrows (apparently due to a change which is now officially part of
>>>>>>> 8.1). IMO, that renders editing of code block in the original buffer
>>>>>>> much more annoying.
>>>>> 
>>>>> Regarding C-down, is it possible to get it back working for selecting
>>>>> parts of code?
>>>>> 
>>>>> In the video captured at http://screencast.com/t/1WjWohviyjE, we see that
>>>>> we can move from an heading to the next with C-down (which is a nice
>>>>> extra addition to the already existing speed commands), but also select
>>>>> subelements in a region (paragraphs or list items).
>>>>> 
>>>>> Though, in the code block, C-down still looses the region...
>>>> 
>>>> is this about loosing the active mark, or about the effect that C-down now
>>>> jumps elements, not paragraphs?
>>> 
>>> In fact, both... If we wanna still allow nice editing of code blocks,
>>> without forcing the users to use the indirect buffer, one must be able to
>>> quickly select, let's say a defvar, and copy it somewhere else; like we
>>> would do in the programming mode buffer (and like we did in the Org buffer,
>>> up to the change with C-down).
>> 
>> So maybe you just want to bing C-down to forward-paragraph again?
> 
> This is a possibility, yes, but it completely defeats the nice `C-down' add-on
> (when outside of code block), and I guess I won't be the only one with that
> "problem".
> 
> Of course, the nicest would be to have both: the current `C-down' for text,
> and the "programmatic" behavior when _in code blocks_. Maybe, that's not
> possible, though...

This might be difficult, but not impossible.
I think this might be a question for Nicolas to answer?

- Carsten

> 
> Best regards,
>  Seb
> 
> -- 
> Sebastien Vauban
> 
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: Outline cycling does not preserve point's position

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
>> not possible anymore to "cut" a code snippet in two parts with C-c C-v C-d
>> (demarcate block); already reported (without bisect), no answer;
>
> This works for me, could you report a minimal recipe for reproduction, and
> maybe a git bisect commit?

This does work again for me in the current Org version (Org-mode version
8.1.1, release_8.1.1-7-gaecdf5).

Case closed!  Thanks.

Best regards,
  Seb

--
Sebastien Vauban

Re: Outline cycling does not preserve point's position

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 801 bytes --]


On 9.9.2013, at 10:38, Bastien <bzg@gnu.org> wrote:

> 
> 
> Hi Sébastien,
> 
> "Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
> writes:
> 
>> Of course, the nicest would be to have both: the current `C-down' for text,
>> and the "programmatic" behavior when _in code blocks_. Maybe, that's not
>> possible, though...
> 
> We could have org-ctrldown and friends the same way we have org-shift*
> commands.  org-ctrldown would use `org-forward-element' when on some
> Org element, and `forward-paragraph' elsewhere.
> 
> I acknowledge binding C-down to `org-forward-element' instead of
> `forward-paragraph' is a bit disruptive, and maybe not ideal in all
> situations.

Yes, it produces unexpected results.

- Carsten

> 
> -- 
> Bastien
> 
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: Outline cycling does not preserve point's position

[Nicolas Goaziou]

Hello,

Carsten Dominik <carsten.dominik@gmail.com> 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'.


Regards,

-- 
Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Nicolas Goaziou]

Hello,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> On 9.9.2013, at 10:38, Bastien <bzg@gnu.org> wrote:

>> We could have org-ctrldown and friends the same way we have org-shift*
>> commands.  org-ctrldown would use `org-forward-element' when on some
>> Org element, and `forward-paragraph' elsewhere.

"elsewhere" doesn't make sense here since point is _always_ on an element
(except on the first blank lines in a buffer).

>> I acknowledge binding C-down to `org-forward-element' instead of
>> `forward-paragraph' is a bit disruptive, and maybe not ideal in all
>> situations.
>
> Yes, it produces unexpected results.

I find it pretty predictable. May you elaborate on that?


Regards,

-- 
Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Bastien]

Hi Nicolas,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

>>> We could have org-ctrldown and friends the same way we have org-shift*
>>> commands.  org-ctrldown would use `org-forward-element' when on some
>>> Org element, and `forward-paragraph' elsewhere.
>
> "elsewhere" doesn't make sense here since point is _always_ on an element
> (except on the first blank lines in a buffer).

Right.  

But you got the idea: use `org-forward-element' when moving
within structural elements of various kinds make sense and use
`forward-paragraph' otherwise.

>>> I acknowledge binding C-down to `org-forward-element' instead of
>>> `forward-paragraph' is a bit disruptive, and maybe not ideal in all
>>> situations.
>>
>> Yes, it produces unexpected results.
>
> I find it pretty predictable. May you elaborate on that?

It is predictable, but sometimes counter-intuitive: for example, when
on the first headline, C-up will throw an error instead of moving to
the top of the buffer.

Also, it is predictable but not reversible: hitting C-down three times
then C-up three times will not always go back to the point where the
user was at the beginning.

-- 
 Bastien

Re: Outline cycling does not preserve point's position

[Carsten Dominik]

On 9.9.2013, at 13:32, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Hello,
> 
> Carsten Dominik <carsten.dominik@gmail.com> writes:
> 
>> On 9.9.2013, at 10:38, Bastien <bzg@gnu.org> wrote:
> 
>>> We could have org-ctrldown and friends the same way we have org-shift*
>>> commands.  org-ctrldown would use `org-forward-element' when on some
>>> Org element, and `forward-paragraph' elsewhere.
> 
> "elsewhere" doesn't make sense here since point is _always_ on an element
> (except on the first blank lines in a buffer).
> 
>>> I acknowledge binding C-down to `org-forward-element' instead of
>>> `forward-paragraph' is a bit disruptive, and maybe not ideal in all
>>> situations.
>> 
>> Yes, it produces unexpected results.
> 
> I find it pretty predictable. May you elaborate on that?

Hi Nicolas,

It is extremely predictable if you know about the structure of an Org document and if you think in elements.

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.

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?

Regards

- Carsten

Re: Outline cycling does not preserve point's position

[Jambunathan K]

> It is extremely predictable if you know about the structure of an Org
> document and if you think in elements.

Move over the smart navigation to C-M-f and friends.

    (info "(emacs) Expressions")

Programmers among us can exploit it.

----------------------------------------------------------------

Org mode is essentially a text mode.  The paragraph movement commands
should more or less behave right like what it would do in a text-mode
document.

----------------------------------------------------------------

One lane for Programmers to move around.  Another lane for Text-Mode
folks to around.  Minimal collision.  Smoother traffic.  Everyone happy,
happy!

----------------------------------------------------------------

Re: Outline cycling does not preserve point's position

[Nicolas Goaziou]

Hello,

Bastien <bzg@gnu.org> writes:

> But you got the idea: use `org-forward-element' when moving
> within structural elements of various kinds make sense and use
> `forward-paragraph' otherwise.

No, I still don't get the idea, really.

> It is predictable, but sometimes counter-intuitive: for example, when
> on the first headline, C-up will throw an error instead of moving to
> the top of the buffer.

Sure, but otherwise it would conflict with your point below.

> Also, it is predictable but not reversible: hitting C-down three times
> then C-up three times will not always go back to the point where the
> user was at the beginning.

You need to return an error when there is no element at the same level.
IIRC, it was initially the case. But then a user complained that, in the
following example, X being the point:

  :PROPERTIES:
  X:PROP1: value
  :END:

`org-forward-element' would return an error "Cannot move further down",
which was difficult to understand.

predictable, intuitive, reversible, pick two.


Regards,

-- 
Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Nicolas Goaziou]

Carsten Dominik <carsten.dominik@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)?

> 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".


Regards,

-- 
Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Sebastien Vauban]

Hello Nicolas,

Nicolas Goaziou wrote:
> Carsten Dominik <carsten.dominik-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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 <n.goaziou-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> Date: Mon, 09 Sep 2013 13:30:33 +0200 (6 hours, 7 minutes, 27 seconds ago)
>>>
>>> Hello,
>>>
>>> Carsten Dominik <carsten.dominik-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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

Re: Outline cycling does not preserve point's position

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]


On 9.9.2013, at 17:41, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Carsten Dominik <carsten.dominik@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.

Thank you.

- Carsten

> 
>> 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".
> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: Outline cycling does not preserve point's position

[Jambunathan K]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> When depth isn't involved

When I am within a nested list (any arbitray position) and I C-down what
should happen?

----------------------------------------------------------------

When I am on an headline and I C-down, I find it disconcerting that
cursor takes a far jump.  

There are specialized commands to jump between headlines and I don't
want a 'paragraph' motion command to do anything fancy.  I would much
prefer that the paragraph motion commands be really dumbed down.  

----------------------------------------------------------------

I really wouldn't mind if paragraph motion commands lands /within/ a src
block or I will be surprised if a table, IRL, is not guarded on either
sides by blank lines.  In the few years, that I have been on this list
not a single complained that his cursor ended up within a src block.

----------------------------------------------------------------

I think sexp motion commands - for example, C-M-d - can help me
precisely move in to the inner sexps with little thought.  This could be
useful when I want to surgically move - thinkg, tree traversal - within
nested lists (or nested structure) but with little effort.

----------------------------------------------------------------

Bottomline: It is difficult to unlearn.  But easier to learn.  

So, don't "overload" existing paragraph motion commands.  

Instead, introduce sexp motion and mimic what emacs-lisp-mode does.  Try
C-down while within a defun and see what happens.

----------------------------------------------------------------

Re: Outline cycling does not preserve point's position

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 2479 bytes --]


On 10.9.2013, at 05:47, Carsten Dominik <carsten.dominik@gmail.com> wrote:

> 
> On 9.9.2013, at 17:41, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> 
>> Carsten Dominik <carsten.dominik@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

> 
> Thank you.
> 
> - Carsten
> 
>> 
>>> 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".
>> 
>> 
>> Regards,
>> 
>> -- 
>> Nicolas Goaziou
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: Outline cycling does not preserve point's position

[Eric Abrahamsen]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> On 10.9.2013, at 05:47, Carsten Dominik <carsten.dominik@gmail.com> wrote:
>
>> 
>> On 9.9.2013, at 17:41, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>> 
>>> Carsten Dominik <carsten.dominik@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

Re: Outline cycling does not preserve point's position

[Suvayu Ali]

On Tue, Sep 10, 2013 at 08:03:32AM +0200, Carsten Dominik wrote:
> 
> 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.

This is a great suggestion!

-- 
Suvayu

Open source is the future. It sets us free.

Re: Outline cycling does not preserve point's position

[Suvayu Ali]

On Tue, Sep 10, 2013 at 09:32:57AM +0200, Suvayu Ali wrote:
> On Tue, Sep 10, 2013 at 08:03:32AM +0200, Carsten Dominik wrote:
> > 
> > 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.
> 
> This is a great suggestion!

Actually it is not trivial to do this I think.  It requires a lot of
special handling.  Effectively you have to "flatten" the element tree
(since there are greater elements, and more fundamental elements).  One
might then say: aha, just use the leaf nodes.  But again that does not
work.

A few examples: although a regular paragraph (whatever that might
be :-p) could be a leaf, what about a list?  Do we want traversing list
items or entire lists with this new implementation?  For a list with one
line entries, going over entire lists might be desired, on the other
hand a user might expect to traverse entries when going through a list
with multi-line or multi-paragraph entries.  Then there are tables, do
you traverse rows (which are elements AFAIU) or entire tables; and so
on.

As you see this is a rather subjective issue.  I have a few thoughts
though.  We could discuss this on the list and give a default
implementation based on the consensus, but it would be nice to give an
easy way to _write_ a custom paragraph motion command using elements.  I
am not sure what that might be though :-p.  I will try to think about
this some more.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Outline cycling does not preserve point's position

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]


On 10.9.2013, at 09:53, Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote:

> On Tue, Sep 10, 2013 at 09:32:57AM +0200, Suvayu Ali wrote:
>> On Tue, Sep 10, 2013 at 08:03:32AM +0200, Carsten Dominik wrote:
>>> 
>>> 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.
>> 
>> This is a great suggestion!
> 
> Actually it is not trivial to do this I think.  It requires a lot of
> special handling.  Effectively you have to "flatten" the element tree
> (since there are greater elements, and more fundamental elements).  One
> might then say: aha, just use the leaf nodes.  But again that does not
> work.
> 
> A few examples: although a regular paragraph (whatever that might
> be :-p) could be a leaf, what about a list?  Do we want traversing list
> items or entire lists with this new implementation?

Individual items

>  For a list with one
> line entries, going over entire lists might be desired, on the other
> hand a user might expect to traverse entries when going through a list
> with multi-line or multi-paragraph entries.  Then there are tables, do
> you traverse rows (which are elements AFAIU) or entire tables;

entire tables.

> and so
> on.

I do not think this is is difficult as you are saying.

Cheers

- Carsten

> 
> As you see this is a rather subjective issue.  I have a few thoughts
> though.  We could discuss this on the list and give a default
> implementation based on the consensus, but it would be nice to give an
> easy way to _write_ a custom paragraph motion command using elements.  I
> am not sure what that might be though :-p.  I will try to think about
> this some more.
> 
> Cheers,
> 
> -- 
> Suvayu
> 
> Open source is the future. It sets us free.


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: Outline cycling does not preserve point's position

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 2582 bytes --]


On 10.9.2013, at 09:58, Carsten Dominik <carsten.dominik@gmail.com> wrote:

> 
> On 10.9.2013, at 09:53, Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote:
> 
>> On Tue, Sep 10, 2013 at 09:32:57AM +0200, Suvayu Ali wrote:
>>> On Tue, Sep 10, 2013 at 08:03:32AM +0200, Carsten Dominik wrote:
>>>> 
>>>> 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.
>>> 
>>> This is a great suggestion!
>> 
>> Actually it is not trivial to do this I think.  It requires a lot of
>> special handling.  Effectively you have to "flatten" the element tree
>> (since there are greater elements, and more fundamental elements).  One
>> might then say: aha, just use the leaf nodes.  But again that does not
>> work.
>> 
>> A few examples: although a regular paragraph (whatever that might
>> be :-p) could be a leaf, what about a list?  Do we want traversing list
>> items or entire lists with this new implementation?
> 
> Individual items
> 
>> For a list with one
>> line entries, going over entire lists might be desired, on the other
>> hand a user might expect to traverse entries when going through a list
>> with multi-line or multi-paragraph entries.  Then there are tables, do
>> you traverse rows (which are elements AFAIU) or entire tables;
> 
> entire tables.
> 
>> and so
>> on.
> 
> I do not think this is is difficult as you are saying.


Sorry for replying to myself.  I want to put a different light on this.

The question is:  What are people using C-arrow for?

I think the main application is reasonably fast motion
and selection in a *linear* way.  Is this correct, or do people
disagree here with me?

The amazing element motion commands Nicolas has implement
correspond to sexp motion, as he has said himself.
Maybe C-M-f and C-M-b are the better binding match for these?

- Carsten

> 
> Cheers
> 
> - Carsten
> 
>> 
>> As you see this is a rather subjective issue.  I have a few thoughts
>> though.  We could discuss this on the list and give a default
>> implementation based on the consensus, but it would be nice to give an
>> easy way to _write_ a custom paragraph motion command using elements.  I
>> am not sure what that might be though :-p.  I will try to think about
>> this some more.
>> 
>> Cheers,
>> 
>> -- 
>> Suvayu
>> 
>> Open source is the future. It sets us free.
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: Outline cycling does not preserve point's position

[Suvayu Ali]

On Tue, Sep 10, 2013 at 10:16:06AM +0200, Carsten Dominik wrote:
> 
> The question is:  What are people using C-arrow for?
> 
> I think the main application is reasonably fast motion
> and selection in a *linear* way.  Is this correct, or do people
> disagree here with me?

I use it for navigating a buffer (not necessarily Org) linearly; i.e. go
back and forth between parts I'm working on or to peruse the contents of
a file.  That said, often I feel the need for a navigation command which
allows me to navigate the semantics of the buffer (which exactly what
Nicolas's elements based navigation does).

> The amazing element motion commands Nicolas has implement
> correspond to sexp motion, as he has said himself.
> Maybe C-M-f and C-M-b are the better binding match for these?

I think you are right here.  There is a need for both.  For me, I use
linear navigation more commonly; so I would prefer C-<up/down> for
linear navigation and some other bindings (like C-M-f/b, as you suggest)
for the elements based motion.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Outline cycling does not preserve point's position

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]


On 10.9.2013, at 10:50, Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote:

> On Tue, Sep 10, 2013 at 10:16:06AM +0200, Carsten Dominik wrote:
>> 
>> The question is:  What are people using C-arrow for?
>> 
>> I think the main application is reasonably fast motion
>> and selection in a *linear* way.  Is this correct, or do people
>> disagree here with me?
> 
> I use it for navigating a buffer (not necessarily Org) linearly; i.e. go
> back and forth between parts I'm working on or to peruse the contents of
> a file.  That said, often I feel the need for a navigation command which
> allows me to navigate the semantics of the buffer (which exactly what
> Nicolas's elements based navigation does).
> 
>> The amazing element motion commands Nicolas has implement
>> correspond to sexp motion, as he has said himself.
>> Maybe C-M-f and C-M-b are the better binding match for these?
> 
> I think you are right here.  There is a need for both.  For me, I use
> linear navigation more commonly; so I would prefer C-<up/down> for
> linear navigation and some other bindings (like C-M-f/b, as you suggest)
> for the elements based motion.

And by linear, I think we don't mean strictly linear, but on a paragraph/table/item scale, ignoring hierarchy.

Cheers

- Carsten

> 
> Cheers,
> 
> -- 
> Suvayu
> 
> Open source is the future. It sets us free.


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: Outline cycling does not preserve point's position

[Suvayu Ali]

On Tue, Sep 10, 2013 at 11:02:35AM +0200, Carsten Dominik wrote:
> 
> On 10.9.2013, at 10:50, Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote:
> 
> > On Tue, Sep 10, 2013 at 10:16:06AM +0200, Carsten Dominik wrote:
> >> 
> >> The question is:  What are people using C-arrow for?
> >> 
> >> I think the main application is reasonably fast motion
> >> and selection in a *linear* way.  Is this correct, or do people
> >> disagree here with me?
> > 
> > I use it for navigating a buffer (not necessarily Org) linearly; i.e. go
> > back and forth between parts I'm working on or to peruse the contents of
> > a file.  That said, often I feel the need for a navigation command which
> > allows me to navigate the semantics of the buffer (which exactly what
> > Nicolas's elements based navigation does).
> > 
> >> The amazing element motion commands Nicolas has implement
> >> correspond to sexp motion, as he has said himself.
> >> Maybe C-M-f and C-M-b are the better binding match for these?
> > 
> > I think you are right here.  There is a need for both.  For me, I use
> > linear navigation more commonly; so I would prefer C-<up/down> for
> > linear navigation and some other bindings (like C-M-f/b, as you suggest)
> > for the elements based motion.
> 
> And by linear, I think we don't mean strictly linear, but on a
> paragraph/table/item scale, ignoring hierarchy.

Yes.  However I think I differ a bit on items.  For me in a list like
the following, I would call moving by paragraphs _within_ the list items
linear; so, "Lorem..." → "Cras..." → "Integer..." → "Aenean..." →
"Pellentesque...", and so on.

- Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse
  interdum venenatis consectetur. Nulla facilisi. Pellentesque rhoncus
  et est vitae lacinia. Quisque molestie justo nisl, quis dictum dui
  varius id.

  Cras scelerisque accumsan risus ut fringilla. Sed pharetra,
  purus sit amet suscipit sagittis, magna quam commodo ligula, vel
  aliquam diam lectus vel lacus.

  Integer congue felis at enim fermentum pellentesque. Sed eu est
  dictum, rhoncus nulla ac, placerat est. Pellentesque nec ultricies
  sapien. Morbi ac dictum dui.

- Aenean vitae arcu accumsan, aliquam ipsum vitae, laoreet erat. Vivamus
  dapibus libero a felis dignissim, et porttitor elit
  vulputate. Suspendisse mattis lectus quis ante convallis
  pellentesque.

  Pellentesque malesuada massa at eros lobortis
  pharetra. Vestibulum et egestas mauris. Pellentesque justo magna,
  ultrices in faucibus viverra, hendrerit eget justo.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Outline cycling does not preserve point's position

[Nicolas Goaziou]

Hello,

Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:

> On Tue, Sep 10, 2013 at 11:02:35AM +0200, Carsten Dominik wrote:
>> 
>> On 10.9.2013, at 10:50, Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote:
>> 
>> > On Tue, Sep 10, 2013 at 10:16:06AM +0200, Carsten Dominik wrote:
>> >> 
>> >> The question is:  What are people using C-arrow for?
>> >> 
>> >> I think the main application is reasonably fast motion
>> >> and selection in a *linear* way.  Is this correct, or do people
>> >> disagree here with me?
>> > 
>> > I use it for navigating a buffer (not necessarily Org) linearly; i.e. go
>> > back and forth between parts I'm working on or to peruse the contents of
>> > a file.  That said, often I feel the need for a navigation command which
>> > allows me to navigate the semantics of the buffer (which exactly what
>> > Nicolas's elements based navigation does).
>> > 
>> >> The amazing element motion commands Nicolas has implement
>> >> correspond to sexp motion, as he has said himself.
>> >> Maybe C-M-f and C-M-b are the better binding match for these?
>> > 
>> > I think you are right here.  There is a need for both.  For me, I use
>> > linear navigation more commonly; so I would prefer C-<up/down> for
>> > linear navigation and some other bindings (like C-M-f/b, as you suggest)
>> > for the elements based motion.
>> 
>> And by linear, I think we don't mean strictly linear, but on a
>> paragraph/table/item scale, ignoring hierarchy.
>
> Yes.  However I think I differ a bit on items.  For me in a list like
> the following, I would call moving by paragraphs _within_ the list items
> linear; so, "Lorem..." → "Cras..." → "Integer..." → "Aenean..." →
> "Pellentesque...", and so on.

Here's a first draft for the linear forward motion. Disclaimer: I didn't
test it thoroughly.

  (defun org-forward-linear-element ()
    (interactive)
    (when (eobp) (user-error "Cannot move further down"))
    (let* ((origin (point))
           (element (org-element-at-point))
           (type (org-element-type element))
           (contents-begin (org-element-property :contents-begin element))
           (contents-end (org-element-property :contents-end element))
           (end (let ((end (org-element-property :end element)) (parent element))
                  (while (and (setq parent (org-element-property :parent parent))
                              (= (org-element-property :contents-end parent) end))
                    (setq end (org-element-property :end parent)))
                  end)))
      (skip-chars-forward " \r\t\n")
      (or (eobp) (goto-char (max (line-beginning-position) origin)))
      (cond ((or (eobp) (= (point) end)))
            ((not contents-begin) (goto-char end))
            ((< (point) contents-begin)
             (cond ((eq type 'item)
                    (end-of-line)
                    (org-forward-and-down-element))
                   ((eq type 'table-row) (goto-char end))
                   (t (goto-char contents-begin))))
            ((>= (point) contents-end) (goto-char end))
            ((eq type 'paragraph) (goto-char end))
            ((eq type 'plain-list)
             (end-of-line)
             (org-forward-and-down-element))
            ((eq type 'table)
             (forward-line)
             (when (>= (point) contents-end) (goto-char end)))
            ((eq type 'verse-block)
             (or (re-search-forward "^[ \t]*$" contents-end t)
                 (goto-char end)))
            (t (error "This shouldn't happen")))
      (when (org-invisible-p2) (goto-char end))))

WDYT?


Regards,

-- 
Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Jambunathan K]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Here's a first draft for the linear forward motion.

cond: Symbol's function definition is void: org-forward-and-down-element

Re: Outline cycling does not preserve point's position

[Nicolas Goaziou]

Hello,

Jambunathan K <kjambunathan@gmail.com> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> Here's a first draft for the linear forward motion.
>
> cond: Symbol's function definition is void:
> org-forward-and-down-element

Hmm. That's a silly mistake (few aren't): I changed its name as a second
thought and forgot to update the recursive calls. Thanks. Take 2:

  (defun org-forward-linear-element ()
    (interactive)
    (when (eobp) (user-error "Cannot move further down"))
    (let* ((origin (point))
           (element (org-element-at-point))
           (type (org-element-type element))
           (contents-begin (org-element-property :contents-begin element))
           (contents-end (org-element-property :contents-end element))
           (end (let ((end (org-element-property :end element)) (parent element))
                  (while (and (setq parent (org-element-property :parent parent))
                              (= (org-element-property :contents-end parent) end))
                    (setq end (org-element-property :end parent)))
                  end)))
      (skip-chars-forward " \r\t\n")
      (or (eobp) (goto-char (max (line-beginning-position) origin)))
      (cond ((or (eobp) (= (point) end)))
            ((not contents-begin) (goto-char end))
            ((< (point) contents-begin)
             (cond ((eq type 'item)
                    (end-of-line)
                    (org-forward-linear-element))
                   ((eq type 'table-row) (goto-char end))
                   (t (goto-char contents-begin))))
            ((>= (point) contents-end) (goto-char end))
            ((eq type 'paragraph) (goto-char end))
            ((eq type 'plain-list)
             (end-of-line)
             (org-forward-linear-element))
            ((eq type 'table)
             (forward-line)
             (when (>= (point) contents-end) (goto-char end)))
            ((eq type 'verse-block)
             (or (re-search-forward "^[ \t]*$" contents-end t)
                 (goto-char end)))
            (t (error "This shouldn't happen")))
      (when (org-invisible-p2) (goto-char end))))


Regards,

-- 
Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Suvayu Ali]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

Hi Nicolas,

On Tue, Sep 10, 2013 at 06:33:16PM +0200, Nicolas Goaziou wrote:
> 
> Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
> 
> > On Tue, Sep 10, 2013 at 11:02:35AM +0200, Carsten Dominik wrote:
> >>
> >> And by linear, I think we don't mean strictly linear, but on a
> >> paragraph/table/item scale, ignoring hierarchy.
> >
> > Yes.  However I think I differ a bit on items.  For me in a list like
> > the following, I would call moving by paragraphs _within_ the list items
> > linear; so, "Lorem..." → "Cras..." → "Integer..." → "Aenean..." →
> > "Pellentesque...", and so on.
> 
> Here's a first draft for the linear forward motion. Disclaimer: I didn't
> test it thoroughly.
> 
>   (defun org-forward-linear-element ()


Some comments and a backtrace (I used the corrected 2nd revision):

1. When traversing the file header, goes one line at a time.  I would
   expect to go to the next blank line.  In the attached Org file, from
   somewhere on #+TITLE to the blank line before the first headline.

2. Skips whole source block even if there are blank lines.  So can't
   navigate large source blocks for small edits.  Try on the python
   source block under the first headline.

3. Goes through each row of a table instead of going over the table in
   one go.  Start with cursor on "From ConDBBrowser:".

4. Skips the whole body under a headline when followed by link.  Try
   putting point on the headline "Important points" and move; you will
   jump to "Tagging Issues" instead of the link and the list after.


How can I test going backward?

-- 
Suvayu

Open source is the future. It sets us free.

[-- Attachment #2: linear-paragraph-motion-test.org --]
[-- Type: text/plain, Size: 2446 bytes --]

#+TITLE:     B-physics stuff
#+AUTHOR:    Suvayu Ali
#+EMAIL:     Suvayu dot Ali at cern dot ch
#+LANGUAGE:  en
#+OPTIONS:   H:3 num:nil toc:nil \n:nil @:t ::t |:t ^:{} -:t f:t *:t <:t
#+OPTIONS:   TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:nil
#+EXPORT_SELECT_TAGS: export
#+EXPORT_EXCLUDE_TAGS: noexport


* Parameters
A random source block
#+begin_src python
  print 'Hello'
  
  print 'Hello again!'

  print 'Hello again, again!'
#+end_src

From ConDBBrowser:
| PARTICLE | GEANTID | PDGID |  MASS(GeV) |      TLIFE(s) | EVTGENNAME |
|----------+---------+-------+------------+---------------+------------|
| B_s0     |      75 |   531 | 5.36630000 | 1.472000e-012 | B_s0       |
| B_s~0    |      76 |  -531 | 5.36630000 | 1.472000e-012 | anti-B_s0  |
| B_s0H    |   99996 |   530 | 5.36630000 | 1.536875e-012 | B_s0H      |
| B_s0L    |   99997 |   350 | 5.36630000 | 1.407125e-012 | B_s0L      |


* Bachelor particle opening angle as PID
  :PROPERTIES:
  :CUSTOM_ID: opening-angle
  :END:

** Important points
[[notmuch:id:20120102164039.2827616d@nikhef.nl][Notmuch email thread with comments]]

1. Bs⁰ is pseudo-scalar meson: decays isotropically in its rest frame,
   idea is to exploit this fact to better separate Bs⁰→Dsπ and Bs⁰→DsK
   crossfeed
2. Dependence on mass hypotheses:
   - Opening angle in lab frame (does not depend on mass hyp.)
   - Boost back to Bs⁰ rest frame (depends on mass hyp.)
   - if mass hyp. correct, cos(θ*) must be flat (isotropic decay of
     scalar!), mass must be Bs⁰ mass within resolution

     some modification to flat cos(θ*) distribution due to /detector
     acceptance/ effects


* Tagging Issues
  :PROPERTIES:
  :CUSTOM_ID: tagging
  :END:

How should SS and OS tagging decisions be combined?  What do we do in
overlap regions b/w the two taggers?
#+begin_example
  +----------------------------------+
  |                                  |
  |    +---------------+             |
  |    |               |             |
  |    |  OST    +-+-+-+--------+    |
  |    |         |/ / /|        |    |
  |    |         | / / |        |    |
  |    +---------++-+-++        |    |
  |              |        SSK   |    |
  |  All events  |              |    |
  |              +--------------+    |
  |                                  |
  +----------------------------------+
#+end_example


# Local Variables:
# org-export-allow-BIND: t
# default-input-method: TeX
# End:

Re: Outline cycling does not preserve point's position

[Suvayu Ali]

On Tue, Sep 10, 2013 at 08:58:43PM +0200, Suvayu Ali wrote:
> 
> Some comments and a backtrace (I used the corrected 2nd revision):

Forgot to edit that out, no backtrace.  :)

-- 
Suvayu

Open source is the future. It sets us free.

Re: Outline cycling does not preserve point's position

[Jambunathan K]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Thanks. Take 2:

Looks good.  Less surprises.  Some open questions...  I have no
preference one way or the other.

1. Seems to like beginning of line.  May be it should do a
   back-to-indentation.  It is disconcerting to have cursor rest on
   margins.  It should actively rest on the "active" content.

2. Goes through the table row by row.  I thought the tables are escaped
   altogether!

3. In the example below, the cursor stops at #+caption, but not #+name
   It also stops at ./org-mode-unicorn.png.  

   But it doesn't stop at the beginning of \begin{equation*}.  It should
   stop at first line of "content" for consistency.

   Should it stop at each line of "#+"?

4. Put the cursor in a table cell and C-Down and I get "This shouldn't
   happen".  But if I am within a table.el table cell, the table is
   escaped.

5. The only exception to "I like bol" is while visiting footnotes where
   the cursor skips past the label in to content.  Should the cursor
   make a stop at description term and description defintion.

6. Should it stop at each line of "#" line?

----------------------------------------------------------------


**** A simple image with caption and label

#+caption: Unicorn Logo
#+name: fig:1024
  [[./org-mode-unicorn.png]]


**** LaTeX Fragment1
#   See org-format-latex-options

     The equation down below has both a caption and a label.

#+caption: Kinetic Energy
#+name: Equation:1
   \begin{equation*}
     e = \frac{1}{2}mv^2
   \end{equation*}


[fn:XYZ] There is a link to [[http://Orgmode.org][Orgmode.org]].

Re: Outline cycling does not preserve point's position

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

> Seems to like beginning of line.

For repated C-down motion, where the cursor "rests" within the element
is immaterial.  So the question is at what position the cursor should
rest so that <whatever> becomes easy.

Whatever could be:

1. editing.  
2. Surgical motion with sexp commands.  If sexp commands are taken up.

Re: Outline cycling does not preserve point's position

[Nicolas Goaziou]

Hello,

Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:

> 1. When traversing the file header, goes one line at a time.  I would
>    expect to go to the next blank line.  In the attached Org file, from
>    somewhere on #+TITLE to the blank line before the first headline.

There no such thing as a "file header". I think that navigating through
(regular) keywords is better, so that's a feature.

> 2. Skips whole source block even if there are blank lines.  So can't
>    navigate large source blocks for small edits.  Try on the python
>    source block under the first headline.

I concentrate on Org syntax for now.
>
> 3. Goes through each row of a table instead of going over the table in
>    one go.  Start with cursor on "From ConDBBrowser:".

OK. Rows should be skipped now.
>
> 4. Skips the whole body under a headline when followed by link.  Try
>    putting point on the headline "Important points" and move; you will
>    jump to "Tagging Issues" instead of the link and the list after.

That was a bug. Should be fixed.

> How can I test going backward?

It is not written yet.

New version:

(defun org-forward-linear-element ()
  (interactive)
  (when (eobp) (user-error "Cannot move further down"))
  (let* ((origin (point))
         (element (org-element-at-point))
         (type (org-element-type element))
         (post-affiliated (org-element-property :post-affiliated element))
         (contents-begin (org-element-property :contents-begin element))
         (contents-end (org-element-property :contents-end element))
         (end (let ((end (org-element-property :end element)) (parent element))
                (while (and (setq parent (org-element-property :parent parent))
                            (= (org-element-property :contents-end parent) end))
                  (setq end (org-element-property :end parent)))
                end)))
    (skip-chars-forward " \r\t\n")
    (or (eobp) (goto-char (max (line-beginning-position) origin)))
    (cond ((or (eobp) (= (point) end)))
          ;; At a table row, move to the end of the table.
          ((eq type 'table-row)
           (goto-char (org-element-property
                       :end (org-element-property :parent element))))
          ((and post-affiliated (< (point) post-affiliated))
           (goto-char post-affiliated))
          ((eq type 'table) (goto-char end))
          ((not contents-begin) (goto-char end))
          ((< (point) contents-begin)
           (if (not (memq type '(footnote-definition item)))
               (goto-char contents-begin)
             (end-of-line)
             (org-forward-linear-element)))
          ((>= (point) contents-end) (goto-char end))
          ((eq type 'paragraph) (goto-char end))
          ((eq type 'plain-list)
           (end-of-line)
           (org-forward-linear-element))
          ((eq type 'verse-block)
           (or (re-search-forward "^[ \t]*$" contents-end t)
               (goto-char end)))
          (t (error "This shouldn't happen")))
    (when (memq (org-invisible-p2) '(org-hide-block outline))
      (goto-char end))))


Regards,

-- 
Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Nicolas Goaziou]

Jambunathan K <kjambunathan@gmail.com> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> Thanks. Take 2:
>
> Looks good.  Less surprises.  Some open questions...  I have no
> preference one way or the other.
>
> 1. Seems to like beginning of line.  May be it should do a
>    back-to-indentation.  It is disconcerting to have cursor rest on
>    margins.  It should actively rest on the "active" content.

Beginning of line is better for killing and yanking. Also, it's easy to
move back to indentation with M-m.

> 2. Goes through the table row by row.  I thought the tables are escaped
>    altogether!

This is not the case anymore in the new version (see my answer to
Suvayu Ali).

>
> 3. In the example below, the cursor stops at #+caption, but not #+name
>    It also stops at ./org-mode-unicorn.png.  

Affiliated keywords are skipped altogether.
>
>    But it doesn't stop at the beginning of \begin{equation*}.  It should
>    stop at first line of "content" for consistency.

Done.

>    Should it stop at each line of "#+"?

Not each line starting with "#+" is an element.

> 4. Put the cursor in a table cell and C-Down and I get "This shouldn't
>    happen".  But if I am within a table.el table cell, the table is
>    escaped.

This shouldn't happen (anymore).

> 5. The only exception to "I like bol" is while visiting footnotes where
>    the cursor skips past the label in to content.  Should the cursor
>    make a stop at description term and description defintion.

I removed that exception. It should behave like lists there.



Regards,

-- 
Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Suvayu Ali]

Hi Nicolas,

On Tue, Sep 10, 2013 at 09:48:53PM +0200, Nicolas Goaziou wrote:
> Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
> 
> > 1. When traversing the file header, goes one line at a time.  I would
> >    expect to go to the next blank line.  In the attached Org file, from
> >    somewhere on #+TITLE to the blank line before the first headline.
> 
> There no such thing as a "file header". I think that navigating through
> (regular) keywords is better, so that's a feature.
> 

Okay agreed there is nothing called "file header", but would be nice to
skip all the setup stuff (wherever in the file) and get to the content.

> > 2. Skips whole source block even if there are blank lines.  So can't
> >    navigate large source blocks for small edits.  Try on the python
> >    source block under the first headline.
> 
> I concentrate on Org syntax for now.

Okay.

> > 3. Goes through each row of a table instead of going over the table in
> >    one go.  Start with cursor on "From ConDBBrowser:".
> 
> OK. Rows should be skipped now.

Confirmed.

> >
> > 4. Skips the whole body under a headline when followed by link.  Try
> >    putting point on the headline "Important points" and move; you will
> >    jump to "Tagging Issues" instead of the link and the list after.
> 
> That was a bug. Should be fixed.

Confirmed.

Apart from this I think I agree with Jambunathan, it would be nice if
the cursor was at some "reasonable" part of the line (probably at a
column closest to the column it was on before).  Otherwise, things look
good already :).

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Outline cycling does not preserve point's position

[Samuel Wales]

On 9/10/13, Carsten Dominik <carsten.dominik@gmail.com> wrote:
> I think the main application is reasonably fast motion
> and selection in a *linear* way.  Is this correct, or do people
> disagree here with me?

Agreed, C-down is next paragraph.

Also C-M-arrow for headlines, with up/down being linear and left/right
being same-level and RET being up.

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

The disease DOES progress.  MANY people have died from it.  ANYBODY can get it.

Denmark: free Karina Hansen NOW.

Re: Outline cycling does not preserve point's position

[Nicolas Goaziou]

Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:

> Okay agreed there is nothing called "file header", but would be nice to
> skip all the setup stuff (wherever in the file) and get to the
> content.

It's really out of the scope of this function. There are other solutions
to ignore large "file headers", e.g. stuff them in a drawer.

> Apart from this I think I agree with Jambunathan, it would be nice if
> the cursor was at some "reasonable" part of the line (probably at a
> column closest to the column it was on before).  Otherwise, things look
> good already :).

Usual `forward-paragraph' command doesn't do anything fancy with point.
AFAICT, it always ends up at the beginning of a line.

Also, as stated before, beginning of line is good for killing and
yanking.


Regards,

-- 
Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Carsten Dominik]

On 10.9.2013, at 21:48, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Hello,
> 
> Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
> 
>> 1. When traversing the file header, goes one line at a time.  I would
>>   expect to go to the next blank line.  In the attached Org file, from
>>   somewhere on #+TITLE to the blank line before the first headline.
> 
> There no such thing as a "file header". I think that navigating through
> (regular) keywords is better, so that's a feature.
> 
>> 2. Skips whole source block even if there are blank lines.  So can't
>>   navigate large source blocks for small edits.  Try on the python
>>   source block under the first headline.
> 
> I concentrate on Org syntax for now.
>> 
>> 3. Goes through each row of a table instead of going over the table in
>>   one go.  Start with cursor on "From ConDBBrowser:".
> 
> OK. Rows should be skipped now.
>> 
>> 4. Skips the whole body under a headline when followed by link.  Try
>>   putting point on the headline "Important points" and move; you will
>>   jump to "Tagging Issues" instead of the link and the list after.
> 
> That was a bug. Should be fixed.

Hi Nicolas,

this looks very good already, thank you!

And I agree with you, beginning of line is a good target column.

Cheers

- Carsten

> 
>> How can I test going backward?
> 
> It is not written yet.
> 
> New version:
> 
> (defun org-forward-linear-element ()
>  (interactive)
>  (when (eobp) (user-error "Cannot move further down"))
>  (let* ((origin (point))
>         (element (org-element-at-point))
>         (type (org-element-type element))
>         (post-affiliated (org-element-property :post-affiliated element))
>         (contents-begin (org-element-property :contents-begin element))
>         (contents-end (org-element-property :contents-end element))
>         (end (let ((end (org-element-property :end element)) (parent element))
>                (while (and (setq parent (org-element-property :parent parent))
>                            (= (org-element-property :contents-end parent) end))
>                  (setq end (org-element-property :end parent)))
>                end)))
>    (skip-chars-forward " \r\t\n")
>    (or (eobp) (goto-char (max (line-beginning-position) origin)))
>    (cond ((or (eobp) (= (point) end)))
>          ;; At a table row, move to the end of the table.
>          ((eq type 'table-row)
>           (goto-char (org-element-property
>                       :end (org-element-property :parent element))))
>          ((and post-affiliated (< (point) post-affiliated))
>           (goto-char post-affiliated))
>          ((eq type 'table) (goto-char end))
>          ((not contents-begin) (goto-char end))
>          ((< (point) contents-begin)
>           (if (not (memq type '(footnote-definition item)))
>               (goto-char contents-begin)
>             (end-of-line)
>             (org-forward-linear-element)))
>          ((>= (point) contents-end) (goto-char end))
>          ((eq type 'paragraph) (goto-char end))
>          ((eq type 'plain-list)
>           (end-of-line)
>           (org-forward-linear-element))
>          ((eq type 'verse-block)
>           (or (re-search-forward "^[ \t]*$" contents-end t)
>               (goto-char end)))
>          (t (error "This shouldn't happen")))
>    (when (memq (org-invisible-p2) '(org-hide-block outline))
>      (goto-char end))))
> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Jambunathan K]

[-- Attachment #1: Type: text/plain, Size: 3716 bytes --]


Some suggestions:

1. Give a better name.  Say "pre-order" traversal of element in the
   parse tree. [1]

2. Now if I 

       M-h, C-x C-x and Deactivate mark, 

   I essentially short-circuit the traversal of whole subtree rooted at
   point.  There should be a convenient binding for it.  Same as
   forward-sexp?

3. When you say "Shouldn't be here", it means that point is NOT at the
   canonical C-down position.  But you do seem to "adjust" it to the
   canonical position down below.

   May be you want to remove it or say something more positive like - In
   the middle of nowhere.  Trying to get to the assembly point.

> New version:

Couple of issues.

1. Visit the attached file.  Make sure everything is visible.
2. M-<
3. C-down gives a stacktrace.  See below.

----------------------------------------------------------------

Within the same file, 

1. Move to bol of the empty line that is in <<<Radioed Target>>> section.  That
   is not an empty line but has spaces.

2. C-down

3. Cursor does NOT do a stop over at "References" headline but skips
   past to References to Fuzzy Target

----------------------------------------------------------------


Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  =(2 nil)
  (or (eobp) (= (point) end))
  (cond ((or (eobp) (= (point) end))) ((eq type (quote table-row)) (goto-char (org-element-property :end (org-element-property :parent element)))) ((and post-affiliated (< (point) post-affiliated)) (goto-char post-affiliated)) ((eq type (quote table)) (goto-char end)) ((not contents-begin) (goto-char end)) ((< (point) contents-begin) (if (not (memq type (quote (footnote-definition item)))) (goto-char contents-begin) (end-of-line) (org-forward-linear-element))) ((>= (point) contents-end) (goto-char end)) ((eq type (quote paragraph)) (goto-char end)) ((eq type (quote plain-list)) (end-of-line) (org-forward-linear-element)) ((eq type (quote verse-block)) (or (re-search-forward "^[ 	]*$" contents-end t) (goto-char end))) (t (error "This shouldn't happen")))
  (let* ((origin (point)) (element (org-element-at-point)) (type (org-element-type element)) (post-affiliated (org-element-property :post-affiliated element)) (contents-begin (org-element-property :contents-begin element)) (contents-end (org-element-property :contents-end element)) (end (let ((end (org-element-property :end element)) (parent element)) (while (and (setq parent (org-element-property :parent parent)) (= (org-element-property :contents-end parent) end)) (setq end (org-element-property :end parent))) end))) (skip-chars-forward " 	\n") (or (eobp) (goto-char (max (line-beginning-position) origin))) (cond ((or (eobp) (= (point) end))) ((eq type (quote table-row)) (goto-char (org-element-property :end (org-element-property :parent element)))) ((and post-affiliated (< (point) post-affiliated)) (goto-char post-affiliated)) ((eq type (quote table)) (goto-char end)) ((not contents-begin) (goto-char end)) ((< (point) contents-begin) (if (not (memq type (quote (footnote-definition item)))) (goto-char contents-begin) (end-of-line) (org-forward-linear-element))) ((>= (point) contents-end) (goto-char end)) ((eq type (quote paragraph)) (goto-char end)) ((eq type (quote plain-list)) (end-of-line) (org-forward-linear-element)) ((eq type (quote verse-block)) (or (re-search-forward "^[ 	]*$" contents-end t) (goto-char end))) (t (error "This shouldn't happen"))) (if (memq (org-invisible-p2) (quote (org-hide-block outline))) (progn (goto-char end))))
  org-forward-linear-element()
  call-interactively(org-forward-linear-element nil nil)
  command-execute(org-forward-linear-element)




[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: cdown.org --]
[-- Type: text/x-org, Size: 125 bytes --]


**** <<<Radioed Target>>>
     
***  References
**** References to Fuzzy Target

     This is a link to [[Fuzzy Target]].

Re: Outline cycling does not preserve point's position

[Jambunathan K]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> It's a Sexp motion.

Good opportunity to review the following bindings.

C-c C-^		org-up-element
C-c C-_		org-down-element

----------------------------------------------------------------

Btw, C-M-p and C-M-n actually traverses the various org-links, footnotes
and timestamps (This is not definitely intended.  But could be useful.)
C-M-n is easier to type than C-c C-x C-n.

----------------------------------------------------------------

I am confused about the subtle difference between C-M-f and C-M-p and
likewise for their backward counterparts.

----------------------------------------------------------------

Hmmm... Object traversal.  

Now there should be a way to move between objects: Move to the next
object of the same type the cursor is on.

----------------------------------------------------------------

Re: Outline cycling does not preserve point's position

[Nicolas Goaziou]

Hello,

Jambunathan K <kjambunathan@gmail.com> writes:

> Some suggestions:
>
> 1. Give a better name.  Say "pre-order" traversal of element in the
>    parse tree. [1]

I don't know what "pre-order" means. What about
`org-flat-forward-element' or simply (but misleading) `org-forward-paragraph'?

> 3. When you say "Shouldn't be here", it means that point is NOT at the
>    canonical C-down position.  But you do seem to "adjust" it to the
>    canonical position down below.
>
>    May be you want to remove it or say something more positive like - In
>    the middle of nowhere.  Trying to get to the assembly point.

I don't understand. Are you talking about the error message? There is no
"canonical" C-down position, so I'm a bit confused.

>> New version:
>
> Couple of issues.
>
> 1. Visit the attached file.  Make sure everything is visible.
> 2. M-<
> 3. C-down gives a stacktrace.  See below.

Fixed.

> 1. Move to bol of the empty line that is in <<<Radioed Target>>> section.  That
>    is not an empty line but has spaces.
>
> 2. C-down
>
> 3. Cursor does NOT do a stop over at "References" headline but skips
>    past to References to Fuzzy Target

That was a bug in `org-element-at-point', which is now fixed. Thank you.
You'll need to update Org.


New version, with comments and docstring:

(defun org-forward-linear-element ()
  "Move forward to next element, ignoring depth.
The function implements some special moves for convenience:
  - On an affiliated keyword, jump to the beginning of the
    relative element.
  - On an item or a footnote definition, move to the second
    element inside, if any.
  - On a table, jump after it.
  - On a verse block, stop after each blank line."
  (interactive)
  (when (eobp) (user-error "Cannot move further down"))
  (let* ((origin (point))
         (element (org-element-at-point))
         (type (org-element-type element))
         (post-affiliated (org-element-property :post-affiliated element))
         (contents-begin (org-element-property :contents-begin element))
         (contents-end (org-element-property :contents-end element))
         (end (let ((end (org-element-property :end element)) (parent element))
                (while (and (setq parent (org-element-property :parent parent))
                            (= (org-element-property :contents-end parent) end))
                  (setq end (org-element-property :end parent)))
                end)))
    (skip-chars-forward " \r\t\n")
    (or (eobp) (goto-char (max (line-beginning-position) origin)))
    (cond ((or (eobp) (not end) (= (point) end)))
          ;; On affiliated keywords, move to element's beginning.
          ((and post-affiliated (< (point) post-affiliated))
           (goto-char post-affiliated))
          ;; At a table row, move to the end of the table.
          ((eq type 'table-row)
           (goto-char (org-element-property
                       :end (org-element-property :parent element))))
          ((eq type 'table) (goto-char end))
          ((not contents-begin) (goto-char end))
          ;; If current element contents are invisible, skip the
          ;; element.
          ((outline-invisible-p (line-end-position))
           (if (not (eq type 'plain-list)) (goto-char end)
             ;; At a plain list, make sure we move to the next item
             ;; instead of skipping the whole list.
             (forward-char)
             (org-forward-linear-element)))
          ((< (point) contents-begin)
           (if (not (memq type '(footnote-definition item)))
               (goto-char contents-begin)
             ;; At footnote definitions and items, move to second
             ;; element, if any, or to next element otherwise.
             (end-of-line)
             (org-forward-linear-element)))
          ((>= (point) contents-end) (goto-char end))
          ((eq type 'paragraph) (goto-char end))
          ((eq type 'plain-list)
           (end-of-line)
           (org-forward-linear-element))
          ;; Verse blocks cannot contain paragraphs.  Though, we
          ;; emulate them with blank lines separators to ease
          ;; editing.
          ((eq type 'verse-block)
           (or (re-search-forward "^[ \t]*$" contents-end t)
               (goto-char end)))
          (t (error "This shouldn't happen")))))


Regards,

-- 
Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Jambunathan K]

I will try out your changes later in the day...

Meanwhile,

> I don't know what "pre-order" means. What about
> `org-flat-forward-element' 

By, flat or linear you really mean a serialized (or stringified) version
of parse-tree.  i.e., An Org buffer is really a serialized
representation of the parse tree.

> or simply (but misleading) `org-forward-paragraph'?

http://en.wikipedia.org/wiki/Pre-order_traversal

Even pre-order could be misleading.  

`org-forward-paragraph' is much better.  As long as the docstring or
comments mention that Org's notion of paragraph is much more nuanced or
richer than a text-mode's notion of paragraph.  

I insist on this, only because description (even if exhaustive) could be
misleading and restrictive.  But an Imagery (or a mental model) is
usually richer and generative.

Re: Outline cycling does not preserve point's position

[Suvayu Ali]

On Tue, Sep 10, 2013 at 11:08:23PM +0200, Carsten Dominik wrote:
> 
> And I agree with you, beginning of line is a good target column.

On reading Nicolas's explanation, I agree too.  This is better.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Outline cycling does not preserve point's position

[Nicolas Goaziou]

Jambunathan K <kjambunathan@gmail.com> writes:

> `org-forward-paragraph' is much better.  As long as the docstring or
> comments mention that Org's notion of paragraph is much more nuanced or
> richer than a text-mode's notion of paragraph.  

OK. Suggestions welcome.

Meanwhile, here is an updated version for the function:

(defun org-forward-linear-element ()
  "Move forward to next element, ignoring depth.
The function implements some special moves for convenience:
  - On an affiliated keyword, jump to the beginning of the
    relative element.
  - On an item or a footnote definition, move to the second
    element inside, if any.
  - On a table, jump after it.
  - On a verse block, stop after each blank line."
  (interactive)
  (when (eobp) (user-error "Cannot move further down"))
  (let* ((element (org-element-at-point))
         (type (org-element-type element))
         (post-affiliated (org-element-property :post-affiliated element))
         (contents-begin (org-element-property :contents-begin element))
         (contents-end (org-element-property :contents-end element))
         (end (let ((end (org-element-property :end element)) (parent element))
                (while (and (setq parent (org-element-property :parent parent))
                            (= (org-element-property :contents-end parent) end))
                  (setq end (org-element-property :end parent)))
                end)))
    (cond ((not element)
           (skip-chars-forward " \r\t\n")
           (or (eobp) (beginning-of-line)))
          ;; On affiliated keywords, move to element's beginning.
          ((and post-affiliated (< (point) post-affiliated))
           (goto-char post-affiliated))
          ;; At a table row, move to the end of the table.
          ((eq type 'table-row)
           (goto-char (org-element-property
                       :end (org-element-property :parent element))))
          ((eq type 'table) (goto-char end))
          ((not contents-begin) (goto-char end))
          ;; If current element contents are invisible, skip the
          ;; element altogether.
          ((outline-invisible-p (line-end-position))
           (if (not (eq type 'plain-list)) (goto-char end)
             ;; At a plain list, make sure we move to the next item
             ;; instead of skipping the whole list.
             (forward-char)
             (org-forward-linear-element)))
          ((>= (point) contents-end) (goto-char end))
          ((>= (point) contents-begin)
           ;; Handle special cases.  In all other situations, point
           ;; is where it should be.
           (case type
             (paragraph (goto-char end))
             ;; At a plain list, try to move to second element in
             ;; first item, if possible.
             (plain-list (end-of-line)
                         (org-forward-linear-element))
             ;; Consider blank lines as separators in verse blocks to
             ;; ease editing.
             (verse-block
              (beginning-of-line)
              (if (not (re-search-forward "^[ \t]*$" contents-end t))
                  (goto-char end)
                (skip-chars-forward " \r\t\n")
                (if (= (point) contents-end) (goto-char contents)
                  (beginning-of-line))))))
          ;; When contents start on the middle of a line (e.g. in
          ;; items and footnote definitions), try to reach first
          ;; element starting after current line.
          ((> (line-end-position) contents-begin)
           (end-of-line)
           (org-forward-linear-element))
          (t (goto-char contents-begin)))))


Regards,

-- 
Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Jambunathan K]

[-- Attachment #1: Type: text/plain, Size: 953 bytes --]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> I don't understand. Are you talking about the error message? There is no
> "canonical" C-down position, so I'm a bit confused.

Put your cursor on the blank line between.  Do a C-down.  You will see
the cursor moving and also an error reported.  So, the "empty line" is a
position where a C-down operation would land you in.  It is a position
from nowhere.

----------------------------------------------------------------

I see some issues when the point is position some where deep inside
invisible parts of the tree.

For example, visit

    "~/src/worg/org-tutorials/org-reference-guide-es.org"

Get in to a state where ALL headlines are visible but none of body text
is visible.

Position your cursor randomly, like so.

   M-: (goto-char (mod (random) (point-max)))

Then C-down.

Within let's say 10 attempts, you will see that a headline is skipped
and the cursor lands on subsequent headline.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: cdown.org --]
[-- Type: text/x-org, Size: 84 bytes --]

* Footnotes

[fn:1] http://www.mail-archive.com/emacs-orgmode@gnu.org/msg08669.html

Re: Outline cycling does not preserve point's position

[Nicolas Goaziou]

Jambunathan K <kjambunathan@gmail.com> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> I don't understand. Are you talking about the error message? There is no
>> "canonical" C-down position, so I'm a bit confused.
>
> Put your cursor on the blank line between.  Do a C-down.  You will see
> the cursor moving and also an error reported.  So, the "empty line" is a
> position where a C-down operation would land you in.  It is a position
> from nowhere.

I don't think it happens in latest version.

> I see some issues when the point is position some where deep inside
> invisible parts of the tree.
>
> For example, visit
>
>     "~/src/worg/org-tutorials/org-reference-guide-es.org"
>
> Get in to a state where ALL headlines are visible but none of body text
> is visible.
>
> Position your cursor randomly, like so.
>
>    M-: (goto-char (mod (random) (point-max)))
>
> Then C-down.
>
> Within let's say 10 attempts, you will see that a headline is skipped
> and the cursor lands on subsequent headline.

Fixed. This deserves a new version:

(defun org-forward-linear-element ()
  "Move forward to next element, ignoring depth.
The function implements some special moves for convenience:
  - On an affiliated keyword, jump to the beginning of the
    relative element.
  - On an item or a footnote definition, move to the second
    element inside, if any.
  - On a table, jump after it.
  - On a verse block, stop after each blank line."
  (interactive)
  (when (eobp) (user-error "Cannot move further down"))
  (let* ((element (org-element-at-point))
         (type (org-element-type element))
         (post-affiliated (org-element-property :post-affiliated element))
         (contents-begin (org-element-property :contents-begin element))
         (contents-end (org-element-property :contents-end element))
         (end (let ((end (org-element-property :end element)) (parent element))
                (while (and (setq parent (org-element-property :parent parent))
                            (= (org-element-property :contents-end parent) end))
                  (setq end (org-element-property :end parent)))
                end)))
    (cond ((not element)
           (skip-chars-forward " \r\t\n")
           (or (eobp) (beginning-of-line)))
          ;; On affiliated keywords, move to element's beginning.
          ((and post-affiliated (< (point) post-affiliated))
           (goto-char post-affiliated))
          ;; At a table row, move to the end of the table.
          ((eq type 'table-row)
           (goto-char (org-element-property
                       :end (org-element-property :parent element))))
          ((eq type 'table) (goto-char end))
          ((not contents-begin) (goto-char end))
          ;; If current element contents are invisible, skip the
          ;; element altogether.
          ((outline-invisible-p (line-end-position))
           (case type
             (headline
              (org-with-limited-levels (outline-next-visible-heading 1)))
             ;; At a plain list, make sure we move to the next item
             ;; instead of skipping the whole list.
             (plain-list (forward-char)
                         (org-forward-linear-element))
             (otherwise (goto-char end))))
          ((>= (point) contents-end) (goto-char end))
          ((>= (point) contents-begin)
           ;; Handle special cases.  In all other situations, point
           ;; is where it should be.
           (case type
             (paragraph (goto-char end))
             ;; At a plain list, try to move to second element in
             ;; first item, if possible.
             (plain-list (end-of-line)
                         (org-forward-linear-element))
             ;; Consider blank lines as separators in verse blocks to
             ;; ease editing.
             (verse-block
              (beginning-of-line)
              (if (not (re-search-forward "^[ \t]*$" contents-end t))
                  (goto-char end)
                (skip-chars-forward " \r\t\n")
                (if (= (point) contents-end) (goto-char contents)
                  (beginning-of-line))))))
          ;; When contents start on the middle of a line (e.g. in
          ;; items and footnote definitions), try to reach first
          ;; element starting after current line.
          ((> (line-end-position) contents-begin)
           (end-of-line)
           (org-forward-linear-element))
          (t (goto-char contents-begin)))))


Regards,

-- 
Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Jambunathan K]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

>> `org-forward-paragraph' is much better.  As long as the docstring or
>> comments mention that Org's notion of paragraph is much more nuanced or
>> richer than a text-mode's notion of paragraph.  
>
> OK. Suggestions welcome.
>
> Meanwhile, here is an updated version for the function:

The invisibility + headlines getting skipped happens with this version
as well.  

A quick examination shows there is a simple recipe.

Put the cursor at bol of a level-2 headline in (*-es.org) and press
C-down.  The level-3 headline gets skipped altogether and point lands in
level-2 headline.

From Las Teclas it goes directly to ¿Qué es Org? skipping Referencias

Re: Outline cycling does not preserve point's position

[Nicolas Goaziou]

Jambunathan K <kjambunathan@gmail.com> writes:

> Hmmm... Object traversal.  
>
> Now there should be a way to move between objects: Move to the next
> object of the same type the cursor is on.

This is interesting but not really possible at the moment. Currently
Elements implement "successors" functions, which are basically
a `re-search-forward' on some hard coded regexp and a predicate to check
if we're really where we think we are. So moving to the next object is
easy, but moving to the previous one would be awkward.

In order to allow this, we should first change the innards of Elements
and split "successors" in two parts:

  1. an association list between object types and regexp
  2. a predicate

Then we would be able to move either way.

If there's some real interest in it, I can have a look, but not right
now.


Regards,

-- 
Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Jambunathan K]

I am happy with whatever is the latest version.  You may want to commit
it.

Re: Outline cycling does not preserve point's position

[Nicolas Goaziou]

Jambunathan K <kjambunathan@gmail.com> writes:

> I am happy with whatever is the latest version.  You may want to commit
> it.

I copy here[fn:1] the current version, for the record, along with its backward
counterpart. Some points are still to be discussed:

  1. What to do on node properties?
  2. What to do on source blocks?


[fn:1] Here is the code:

(defun org-forward-linear-element ()
  "Move forward to beginning of next element, ignoring depth.
The function implements some special moves for convenience:
  - On an affiliated keyword, jump to the beginning of the
    relative element.
  - On an item or a footnote definition, move to the second
    element inside, if any.
  - On a table, jump after it.
  - On a verse block, stop after each blank line."
  (interactive)
  (when (eobp) (user-error "Cannot move further down"))
  (let* ((element (org-element-at-point))
         (type (org-element-type element))
         (post-affiliated (org-element-property :post-affiliated element))
         (contents-begin (org-element-property :contents-begin element))
         (contents-end (org-element-property :contents-end element))
         (end (let ((end (org-element-property :end element)) (parent element))
                (while (and (setq parent (org-element-property :parent parent))
                            (= (org-element-property :contents-end parent) end))
                  (setq end (org-element-property :end parent)))
                end)))
    (cond ((not element)
           (skip-chars-forward " \r\t\n")
           (or (eobp) (beginning-of-line)))
          ;; On affiliated keywords, move to element's beginning.
          ((and post-affiliated (< (point) post-affiliated))
           (goto-char post-affiliated))
          ;; At a table row, move to the end of the table.
          ((eq type 'table-row)
           (goto-char (org-element-property
                       :end (org-element-property :parent element))))
          ((eq type 'table) (goto-char end))
          ((not contents-begin) (goto-char end))
          ;; If current element contents are invisible, skip the
          ;; element altogether.
          ((outline-invisible-p (line-end-position))
           (case type
             (headline
              (org-with-limited-levels (outline-next-visible-heading 1)))
             ;; At a plain list, make sure we move to the next item
             ;; instead of skipping the whole list.
             (plain-list (forward-char)
                         (org-forward-linear-element))
             (otherwise (goto-char end))))
          ((>= (point) contents-end) (goto-char end))
          ((>= (point) contents-begin)
           ;; Handle special cases.  In all other situations, point is
           ;; where it should be.
           (case type
             (paragraph (goto-char end))
             ;; At a plain list, try to move to second element in
             ;; first item, if possible.
             (plain-list (end-of-line)
                         (org-forward-linear-element))
             ;; Consider blank lines as separators in verse blocks to
             ;; ease editing.
             (verse-block
              (beginning-of-line)
              (if (not (re-search-forward "^[ \t]*$" contents-end t))
                  (goto-char end)
                (skip-chars-forward " \r\t\n")
                (if (= (point) contents-end) (goto-char contents)
                  (beginning-of-line))))))
          ;; When contents start on the middle of a line (e.g. in
          ;; items and footnote definitions), try to reach first
          ;; element starting after current line.
          ((> (line-end-position) contents-begin)
           (end-of-line)
           (org-forward-linear-element))
          (t (goto-char contents-begin)))))

(defun org-backward-linear-element ()
  "Move backward to start of previous element, ignoring depth."
  (interactive)
  (when (bobp) (user-error "Cannot move further up"))
  (let* ((element (org-element-at-point))
         (type (org-element-type element))
         (contents-begin (org-element-property :contents-begin element))
         (contents-end (org-element-property :contents-end element))
         (post-affiliated (org-element-property :post-affiliated element))
         (begin (org-element-property :begin element)))
    (cond ((not element) (goto-char (point-min)))
          ((= (point) begin)
           (backward-char)
           (org-backward-linear-element))
          ((and post-affiliated (<= (point) post-affiliated)) (goto-char begin))
          ((eq type 'table-row)
           (goto-char (org-element-property
                       :contents-begin (org-element-property :parent element))))
          ((eq type 'table) (goto-char begin))
          ((not contents-begin)
           (goto-char (or post-affiliated begin)))
          ((eq type 'paragraph)
           (goto-char contents-begin)
           ;; When at first paragraph in an item or a footnote
           ;; definition, move directly to beginning of line.
           (let ((parent-contents
                  (org-element-property
                   :contents-begin (org-element-property :parent element))))
             (when (and parent-contents (= parent-contents contents-begin))
               (beginning-of-line))))
          ((eq type 'verse-block)
           (if (= (point) contents-begin)
               (goto-char (or post-affiliated begin))
             ;; Inside a verse block, see blank lines as paragraph
             ;; separators.
             (let ((origin (point)))
               (skip-chars-backward " \r\t\n" contents-begin)
               (when (re-search-backward "^[ \t]*$" contents-begin 'move)
                 (skip-chars-forward " \r\t\n" origin)
                 (if (= (point) origin) (goto-char contents-begin)
                   (beginning-of-line))))))
          ;; At the end of a greater element, move to the beginning of
          ;; the last element within.
          ((>= (point) contents-end)
           (goto-char (1- contents-end))
           (org-backward-linear-element))
          (t (goto-char (or post-affiliated begin))))
    ;; Ensure we never leave point invisible.
    (when (outline-invisible-p (point)) (beginning-of-visual-line))))


Regards,

-- 
Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Suvayu Ali]

Hi Nicolas,

On Wed, Sep 11, 2013 at 10:01:31PM +0200, Nicolas Goaziou wrote:
> Jambunathan K <kjambunathan@gmail.com> writes:
> 
> > I am happy with whatever is the latest version.  You may want to commit
> > it.
> 
> I copy here[fn:1] the current version, for the record, along with its backward
> counterpart. Some points are still to be discussed:

Looks good.  I'll use it full-time for the next few days and report back.

>   1. What to do on node properties?

You mean property drawers after headlines?  I would think skipping them
would seem pertinent?  After all properties are usually hidden away.

>   2. What to do on source blocks?

One thing I feel the need for is to be able to navigate longer source
blocks as if they were simple text: either for perusal, or for minor
editing.  So my personal preference is empty lines end a "paragraph".

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Outline cycling does not preserve point's position

[Jambunathan K]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Some points are still to be discussed:
>
>   1. What to do on node properties?
>   2. What to do on source blocks?

Looks good to me.

Should there be a pit-stop at #+END in the segment below.

--8<---------------cut here---------------start------------->8---

That one source table contains the documentation in the first and third
column:

#+BEGIN RECEIVE ORGTBL exdoc
| Name    | Description     |
|---------+-----------------|
| =normx= | norm(x, \infty) |
| =normb= | norm(b, \infty) |
| =normA= | norm(A, \infty) |
#+END RECEIVE ORGTBL exdoc

--8<---------------cut here---------------end--------------->8---

Re: Outline cycling does not preserve point's position

[Jambunathan K]

Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:

>> And I agree with you, beginning of line is a good target column.
>
> On reading Nicolas's explanation, I agree too.  This is better.

The decision should be based on what the user would do after doing a
C-down and C-up.  

If *you* use C-down and C-up for persusal (as yourself say), I don't
think you will use C-k immediately.  I sense that you are not
representing yourself in a consistent way.

----------------------------------------------------------------

Speaking for myself, I ran C-down and C-up on unit test file for ODT
export.  It is not a representative text.  It contains (deeply) indented
lists and multiple headline levels etc.  When the cursor is on a bol, it
is difficult to get a quick feedback on where exactly the cursor is.
i.e., I was forced to use hl-line-mode.

Re: Outline cycling does not preserve point's position

[Sebastien Vauban]

Hello Nicolas,

Nicolas Goaziou wrote:
> Some points are still to be discussed:
>
>   1. What to do on node properties?

I would opt for `forward-paragraph', to have something different than
`next-line'. Otherwise, `C-down' and `down' would simply do the same thing.
Not forbidden, but seems useless...

>   2. What to do on source blocks?

There, I'd simply "clone" what happens in the real source code buffers. I've
tested `C-down' in Emacs Lisp, Shell and C++ modes. In all of them, `C-down'
runs the command `forward-paragraph'. So, this seems to be the obvious choice
to me.

Best regards,
  Seb

--
Sebastien Vauban

Re: Outline cycling does not preserve point's position

[Nicolas Goaziou]

Hello,

Jambunathan K <kjambunathan@gmail.com> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> Some points are still to be discussed:
>>
>>   1. What to do on node properties?
>>   2. What to do on source blocks?
>
> Looks good to me.
>
> Should there be a pit-stop at #+END in the segment below.

Point never ends of closing lines. It is moved to the beginning of the
next element. Reminder: this is a dumb forward paragraph.

You can use `org-forward-element' to go there.


Regards,

-- 
Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Nicolas Goaziou]

Jambunathan K <kjambunathan@gmail.com> writes:

> Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
>
>>> And I agree with you, beginning of line is a good target column.
>>
>> On reading Nicolas's explanation, I agree too.  This is better.
>
> The decision should be based on what the user would do after doing a
> C-down and C-up.  
>
> If *you* use C-down and C-up for persusal (as yourself say), I don't
> think you will use C-k immediately.  I sense that you are not
> representing yourself in a consistent way.

I don't think regular `forward-paragraph' cares about what the user do
with it. It puts point at beginning of lines and that's it.

`org-forward-linear-element' exists because some users want C-down with
a more intense `forward-paragraph' flavour.


Regards,

-- 
Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Jambunathan K]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
>>
>>>> And I agree with you, beginning of line is a good target column.
>>>
>>> On reading Nicolas's explanation, I agree too.  This is better.
>>
>> The decision should be based on what the user would do after doing a
>> C-down and C-up.  
>>
>> If *you* use C-down and C-up for persusal (as yourself say), I don't
>> think you will use C-k immediately.  I sense that you are not
>> representing yourself in a consistent way.
>
> I don't think regular `forward-paragraph' cares about what the user do
> with it. It puts point at beginning of lines and that's it.

I am provoking Suvayu to defend himself, if that's not already clear to
you :-).  

> `org-forward-linear-element' exists because some users want C-down with
> a more intense `forward-paragraph' flavour.

Let me provoke you a bit :-).

What is the difference between forward and linear.  

Is it linear only because it stays in column 0 always?

 OR

Is it linear because it is monotonic in how the cursor moves.

If you side with latter explanation, then I would argue that this notion
of linearity is no different from what is implied by forward.

Btw, I have no issues if you don't want to support
`org-forward-nonlinear-element'.  Yes, if the command does M-m
automatically at end, the cursor position will become curvilinear.

> Regards,

Re: Outline cycling does not preserve point's position

[Suvayu Ali]

Hi Jambu,

On Thu, Sep 12, 2013 at 02:58:02PM +0530, Jambunathan K wrote:
> Nicolas Goaziou <n.goaziou@gmail.com> writes:
> 
> > Jambunathan K <kjambunathan@gmail.com> writes:
> >
> >> Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
> >>
> >>>> And I agree with you, beginning of line is a good target column.
> >>>
> >>> On reading Nicolas's explanation, I agree too.  This is better.
> >>
> >> The decision should be based on what the user would do after doing a
> >> C-down and C-up.  
> >>
> >> If *you* use C-down and C-up for persusal (as yourself say), I don't
> >> think you will use C-k immediately.  I sense that you are not
> >> representing yourself in a consistent way.
> >
> > I don't think regular `forward-paragraph' cares about what the user do
> > with it. It puts point at beginning of lines and that's it.
> 
> I am provoking Suvayu to defend himself, if that's not already clear to
> you :-).  

You are right I was not being consistent.  On some thought, I still
think column 0 is good.  I care about the column only when I'm editing.
And it is a "surprise" only after the first C-<down>, for subsequent
uses my eyes get used to it.  Actually I think the only time I want the
cursor to retain its relative position is when I'm transposing
lines/paragraphs/list items/etc.

> > `org-forward-linear-element' exists because some users want C-down with
> > a more intense `forward-paragraph' flavour.
> 
> Let me provoke you a bit :-).
> 
> What is the difference between forward and linear.  
> 
> Is it linear only because it stays in column 0 always?
> 
>  OR
> 
> Is it linear because it is monotonic in how the cursor moves.

I would say it is linear because it doesn't respect the element tree.

> If you side with latter explanation, then I would argue that this notion
> of linearity is no different from what is implied by forward.
> 
> Btw, I have no issues if you don't want to support
> `org-forward-nonlinear-element'.  Yes, if the command does M-m
> automatically at end, the cursor position will become curvilinear.

Very funny :)

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Outline cycling does not preserve point's position

[Jambunathan K]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

>> Should there be a pit-stop at #+END in the segment below.

> You can use `org-forward-element' to go there.

It makes no difference if I use `org-forward-element' or
`org-forward-linear-element'.  The reason is clear if one examines the
parser output.

#+BEGIN and #+END are considered NOT as a pair but as standalone
 paragraphs.

	   (paragraph
	    ()
	    #("#+BEGIN RECEIVE ORGTBL exdoc\n" 0 29
	      ()))

	   (paragraph
	    ()
	    #("#+END RECEIVE ORGTBL exdoc\n" 0 27
	      ()))


I just picked up a random worg file to take a real-world test drive.

Speaking of expectations, cursor's stop points within #+BEGIN_BACKEND
and #+END_BACKEND are decided based on whether the respective backend is
loaded.  So is the case with inlinetasks.

I am just making a note of behaviour that is surprising.  Surprising
only if the underlying mechanics aren't sufficiently understood or
known.

Re: Outline cycling does not preserve point's position

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 7217 bytes --]

Hi Nicolas,

thanks for these.  Please see the two comments below.

On Sep 11, 2013, at 10:01 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Jambunathan K <kjambunathan@gmail.com> writes:
> 
>> I am happy with whatever is the latest version.  You may want to commit
>> it.
> 
> I copy here[fn:1] the current version, for the record, along with its backward
> counterpart. Some points are still to be discussed:
> 
>  1. What to do on node properties?

I think they should be covered with a single C-down, so treated like a single paragraph.

>  2. What to do on source blocks?

At the beginning of the block (at the src line)  I think it should jump over the full src block.
Inside the block, it can use text-modes forward paragraph.

At lease these would be my suggestions.
Thank you for all your work around this issue!

When the functions are done, please go ahead and commit them and bind them to C-up/down.

Regards

- Carsten

> 
> 
> [fn:1] Here is the code:
> 
> (defun org-forward-linear-element ()
>  "Move forward to beginning of next element, ignoring depth.
> The function implements some special moves for convenience:
>  - On an affiliated keyword, jump to the beginning of the
>    relative element.
>  - On an item or a footnote definition, move to the second
>    element inside, if any.
>  - On a table, jump after it.
>  - On a verse block, stop after each blank line."
>  (interactive)
>  (when (eobp) (user-error "Cannot move further down"))
>  (let* ((element (org-element-at-point))
>         (type (org-element-type element))
>         (post-affiliated (org-element-property :post-affiliated element))
>         (contents-begin (org-element-property :contents-begin element))
>         (contents-end (org-element-property :contents-end element))
>         (end (let ((end (org-element-property :end element)) (parent element))
>                (while (and (setq parent (org-element-property :parent parent))
>                            (= (org-element-property :contents-end parent) end))
>                  (setq end (org-element-property :end parent)))
>                end)))
>    (cond ((not element)
>           (skip-chars-forward " \r\t\n")
>           (or (eobp) (beginning-of-line)))
>          ;; On affiliated keywords, move to element's beginning.
>          ((and post-affiliated (< (point) post-affiliated))
>           (goto-char post-affiliated))
>          ;; At a table row, move to the end of the table.
>          ((eq type 'table-row)
>           (goto-char (org-element-property
>                       :end (org-element-property :parent element))))
>          ((eq type 'table) (goto-char end))
>          ((not contents-begin) (goto-char end))
>          ;; If current element contents are invisible, skip the
>          ;; element altogether.
>          ((outline-invisible-p (line-end-position))
>           (case type
>             (headline
>              (org-with-limited-levels (outline-next-visible-heading 1)))
>             ;; At a plain list, make sure we move to the next item
>             ;; instead of skipping the whole list.
>             (plain-list (forward-char)
>                         (org-forward-linear-element))
>             (otherwise (goto-char end))))
>          ((>= (point) contents-end) (goto-char end))
>          ((>= (point) contents-begin)
>           ;; Handle special cases.  In all other situations, point is
>           ;; where it should be.
>           (case type
>             (paragraph (goto-char end))
>             ;; At a plain list, try to move to second element in
>             ;; first item, if possible.
>             (plain-list (end-of-line)
>                         (org-forward-linear-element))
>             ;; Consider blank lines as separators in verse blocks to
>             ;; ease editing.
>             (verse-block
>              (beginning-of-line)
>              (if (not (re-search-forward "^[ \t]*$" contents-end t))
>                  (goto-char end)
>                (skip-chars-forward " \r\t\n")
>                (if (= (point) contents-end) (goto-char contents)
>                  (beginning-of-line))))))
>          ;; When contents start on the middle of a line (e.g. in
>          ;; items and footnote definitions), try to reach first
>          ;; element starting after current line.
>          ((> (line-end-position) contents-begin)
>           (end-of-line)
>           (org-forward-linear-element))
>          (t (goto-char contents-begin)))))
> 
> (defun org-backward-linear-element ()
>  "Move backward to start of previous element, ignoring depth."
>  (interactive)
>  (when (bobp) (user-error "Cannot move further up"))
>  (let* ((element (org-element-at-point))
>         (type (org-element-type element))
>         (contents-begin (org-element-property :contents-begin element))
>         (contents-end (org-element-property :contents-end element))
>         (post-affiliated (org-element-property :post-affiliated element))
>         (begin (org-element-property :begin element)))
>    (cond ((not element) (goto-char (point-min)))
>          ((= (point) begin)
>           (backward-char)
>           (org-backward-linear-element))
>          ((and post-affiliated (<= (point) post-affiliated)) (goto-char begin))
>          ((eq type 'table-row)
>           (goto-char (org-element-property
>                       :contents-begin (org-element-property :parent element))))
>          ((eq type 'table) (goto-char begin))
>          ((not contents-begin)
>           (goto-char (or post-affiliated begin)))
>          ((eq type 'paragraph)
>           (goto-char contents-begin)
>           ;; When at first paragraph in an item or a footnote
>           ;; definition, move directly to beginning of line.
>           (let ((parent-contents
>                  (org-element-property
>                   :contents-begin (org-element-property :parent element))))
>             (when (and parent-contents (= parent-contents contents-begin))
>               (beginning-of-line))))
>          ((eq type 'verse-block)
>           (if (= (point) contents-begin)
>               (goto-char (or post-affiliated begin))
>             ;; Inside a verse block, see blank lines as paragraph
>             ;; separators.
>             (let ((origin (point)))
>               (skip-chars-backward " \r\t\n" contents-begin)
>               (when (re-search-backward "^[ \t]*$" contents-begin 'move)
>                 (skip-chars-forward " \r\t\n" origin)
>                 (if (= (point) origin) (goto-char contents-begin)
>                   (beginning-of-line))))))
>          ;; At the end of a greater element, move to the beginning of
>          ;; the last element within.
>          ((>= (point) contents-end)
>           (goto-char (1- contents-end))
>           (org-backward-linear-element))
>          (t (goto-char (or post-affiliated begin))))
>    ;; Ensure we never leave point invisible.
>    (when (outline-invisible-p (point)) (beginning-of-visual-line))))
> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: Outline cycling does not preserve point's position

[Nicolas Goaziou]

Hello,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> When the functions are done, please go ahead and commit them and bind
> them to C-up/down.

Done.


Regards,

-- 
Nicolas Goaziou

Re: Outline cycling does not preserve point's position

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 329 bytes --]

Hello Nicolas,

thank you!

- Carsten

On 14.9.2013, at 00:29, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Hello,
> 
> Carsten Dominik <carsten.dominik@gmail.com> writes:
> 
>> When the functions are done, please go ahead and commit them and bind
>> them to C-up/down.
> 
> Done.
> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: Outline cycling does not preserve point's position

[Suvayu Ali]

Hi Nicolas,

On Sat, Sep 14, 2013 at 12:29:00AM +0200, Nicolas Goaziou wrote:
> Hello,
> 
> Carsten Dominik <carsten.dominik@gmail.com> writes:
> 
> > When the functions are done, please go ahead and commit them and bind
> > them to C-up/down.
> 
> Done.

Do you think it would be nicer if org-forward-paragraph takes arguments
like forward-paragraph?  Would be more consistent, specially if someone
writes wrappers (confession: I'm actually writing one myself).

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: Outline cycling does not preserve point's position

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]


On 14.9.2013, at 19:16, Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote:

> Hi Nicolas,
> 
> On Sat, Sep 14, 2013 at 12:29:00AM +0200, Nicolas Goaziou wrote:
>> Hello,
>> 
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>> 
>>> When the functions are done, please go ahead and commit them and bind
>>> them to C-up/down.
>> 
>> Done.
> 
> Do you think it would be nicer if org-forward-paragraph takes arguments
> like forward-paragraph?  Would be more consistent, specially if someone
> writes wrappers (confession: I'm actually writing one myself).

Hi,

while I never use these commands with arguments, I think it
would be nice if they had this ability.

Regards

- Carsten

> 
> Cheers,
> 
> -- 
> Suvayu
> 
> Open source is the future. It sets us free.


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]