* Outline cycling does not preserve point's position
@ 2013-09-07 12:11 Sebastien Vauban
2013-09-07 14:17 ` Carsten Dominik
0 siblings, 1 reply; 74+ messages in thread
From: Sebastien Vauban @ 2013-09-07 12:11 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-07 12:11 Outline cycling does not preserve point's position Sebastien Vauban
@ 2013-09-07 14:17 ` Carsten Dominik
[not found] ` <BED1FBAA-8BB5-45D6-8328-11C0BB2DF015-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 74+ messages in thread
From: Carsten Dominik @ 2013-09-07 14:17 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
[not found] ` <BED1FBAA-8BB5-45D6-8328-11C0BB2DF015-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
@ 2013-09-07 19:28 ` Sebastien Vauban
2013-09-08 6:16 ` Carsten Dominik
` (2 more replies)
0 siblings, 3 replies; 74+ messages in thread
From: Sebastien Vauban @ 2013-09-07 19:28 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Sebastien Vauban, emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-07 19:28 ` Sebastien Vauban
@ 2013-09-08 6:16 ` Carsten Dominik
2013-09-09 7:57 ` Sebastien Vauban
2013-09-08 11:03 ` Eric Schulte
2013-09-08 16:23 ` Carsten Dominik
2 siblings, 1 reply; 74+ messages in thread
From: Carsten Dominik @ 2013-09-08 6:16 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-07 19:28 ` Sebastien Vauban
2013-09-08 6:16 ` Carsten Dominik
@ 2013-09-08 11:03 ` Eric Schulte
2013-09-09 8:39 ` Sebastien Vauban
2013-09-08 16:23 ` Carsten Dominik
2 siblings, 1 reply; 74+ messages in thread
From: Eric Schulte @ 2013-09-08 11:03 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: emacs-orgmode, Carsten Dominik
>
> 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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-07 19:28 ` Sebastien Vauban
2013-09-08 6:16 ` Carsten Dominik
2013-09-08 11:03 ` Eric Schulte
@ 2013-09-08 16:23 ` Carsten Dominik
2013-09-09 8:11 ` Sebastien Vauban
2 siblings, 1 reply; 74+ messages in thread
From: Carsten Dominik @ 2013-09-08 16:23 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-08 6:16 ` Carsten Dominik
@ 2013-09-09 7:57 ` Sebastien Vauban
0 siblings, 0 replies; 74+ messages in thread
From: Sebastien Vauban @ 2013-09-09 7:57 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-08 16:23 ` Carsten Dominik
@ 2013-09-09 8:11 ` Sebastien Vauban
2013-09-09 8:13 ` Carsten Dominik
0 siblings, 1 reply; 74+ messages in thread
From: Sebastien Vauban @ 2013-09-09 8:11 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 8:11 ` Sebastien Vauban
@ 2013-09-09 8:13 ` Carsten Dominik
2013-09-09 8:23 ` Sebastien Vauban
0 siblings, 1 reply; 74+ messages in thread
From: Carsten Dominik @ 2013-09-09 8:13 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 8:13 ` Carsten Dominik
@ 2013-09-09 8:23 ` Sebastien Vauban
2013-09-09 8:27 ` Carsten Dominik
0 siblings, 1 reply; 74+ messages in thread
From: Sebastien Vauban @ 2013-09-09 8:23 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 8:23 ` Sebastien Vauban
@ 2013-09-09 8:27 ` Carsten Dominik
2013-09-09 8:33 ` Sebastien Vauban
0 siblings, 1 reply; 74+ messages in thread
From: Carsten Dominik @ 2013-09-09 8:27 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 8:27 ` Carsten Dominik
@ 2013-09-09 8:33 ` Sebastien Vauban
2013-09-09 8:38 ` Bastien
2013-09-09 8:38 ` Carsten Dominik
0 siblings, 2 replies; 74+ messages in thread
From: Sebastien Vauban @ 2013-09-09 8:33 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 8:33 ` Sebastien Vauban
@ 2013-09-09 8:38 ` Bastien
2013-09-09 9:05 ` Carsten Dominik
2013-09-09 8:38 ` Carsten Dominik
1 sibling, 1 reply; 74+ messages in thread
From: Bastien @ 2013-09-09 8:38 UTC (permalink / raw)
To: Sebastien Vauban; +Cc: public-emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 8:33 ` Sebastien Vauban
2013-09-09 8:38 ` Bastien
@ 2013-09-09 8:38 ` Carsten Dominik
2013-09-09 11:30 ` Nicolas Goaziou
1 sibling, 1 reply; 74+ messages in thread
From: Carsten Dominik @ 2013-09-09 8:38 UTC (permalink / raw)
To: Sebastien Vauban, Nicolas Goaziou; +Cc: emacs-orgmode@gnu.org Mode
[-- 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 --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-08 11:03 ` Eric Schulte
@ 2013-09-09 8:39 ` Sebastien Vauban
0 siblings, 0 replies; 74+ messages in thread
From: Sebastien Vauban @ 2013-09-09 8:39 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 8:38 ` Bastien
@ 2013-09-09 9:05 ` Carsten Dominik
2013-09-09 11:32 ` Nicolas Goaziou
0 siblings, 1 reply; 74+ messages in thread
From: Carsten Dominik @ 2013-09-09 9:05 UTC (permalink / raw)
To: Bastien; +Cc: public-emacs-orgmode-mXXj517/zsQ, Sebastien Vauban
[-- 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 --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 8:38 ` Carsten Dominik
@ 2013-09-09 11:30 ` Nicolas Goaziou
0 siblings, 0 replies; 74+ messages in thread
From: Nicolas Goaziou @ 2013-09-09 11:30 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Sebastien Vauban, emacs-orgmode@gnu.org Mode
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 9:05 ` Carsten Dominik
@ 2013-09-09 11:32 ` Nicolas Goaziou
2013-09-09 11:49 ` Bastien
2013-09-09 14:23 ` Carsten Dominik
0 siblings, 2 replies; 74+ messages in thread
From: Nicolas Goaziou @ 2013-09-09 11:32 UTC (permalink / raw)
To: Carsten Dominik
Cc: Bastien, public-emacs-orgmode-mXXj517/zsQ, Sebastien Vauban
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 11:32 ` Nicolas Goaziou
@ 2013-09-09 11:49 ` Bastien
2013-09-09 15:27 ` Nicolas Goaziou
2013-09-09 14:23 ` Carsten Dominik
1 sibling, 1 reply; 74+ messages in thread
From: Bastien @ 2013-09-09 11:49 UTC (permalink / raw)
To: Nicolas Goaziou
Cc: public-emacs-orgmode-mXXj517/zsQ, Sebastien Vauban,
Carsten Dominik
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 11:32 ` Nicolas Goaziou
2013-09-09 11:49 ` Bastien
@ 2013-09-09 14:23 ` Carsten Dominik
2013-09-09 15:16 ` Jambunathan K
2013-09-09 15:41 ` Nicolas Goaziou
1 sibling, 2 replies; 74+ messages in thread
From: Carsten Dominik @ 2013-09-09 14:23 UTC (permalink / raw)
To: Nicolas Goaziou
Cc: Bastien, public-emacs-orgmode-mXXj517/zsQ, Sebastien Vauban
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 14:23 ` Carsten Dominik
@ 2013-09-09 15:16 ` Jambunathan K
2013-09-09 15:41 ` Nicolas Goaziou
1 sibling, 0 replies; 74+ messages in thread
From: Jambunathan K @ 2013-09-09 15:16 UTC (permalink / raw)
To: Carsten Dominik
Cc: Bastien, public-emacs-orgmode-mXXj517/zsQ, Sebastien Vauban,
Nicolas Goaziou
> 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!
----------------------------------------------------------------
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 11:49 ` Bastien
@ 2013-09-09 15:27 ` Nicolas Goaziou
0 siblings, 0 replies; 74+ messages in thread
From: Nicolas Goaziou @ 2013-09-09 15:27 UTC (permalink / raw)
To: Bastien; +Cc: public-emacs-orgmode-mXXj517/zsQ, Sebastien Vauban,
Carsten Dominik
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 14:23 ` Carsten Dominik
2013-09-09 15:16 ` Jambunathan K
@ 2013-09-09 15:41 ` Nicolas Goaziou
2013-09-09 17:42 ` Sebastien Vauban
` (3 more replies)
1 sibling, 4 replies; 74+ messages in thread
From: Nicolas Goaziou @ 2013-09-09 15:41 UTC (permalink / raw)
To: Carsten Dominik
Cc: Bastien, public-emacs-orgmode-mXXj517/zsQ, Sebastien Vauban
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 15:41 ` Nicolas Goaziou
@ 2013-09-09 17:42 ` Sebastien Vauban
2013-09-10 3:47 ` Carsten Dominik
` (2 subsequent siblings)
3 siblings, 0 replies; 74+ messages in thread
From: Sebastien Vauban @ 2013-09-09 17:42 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 15:41 ` Nicolas Goaziou
2013-09-09 17:42 ` Sebastien Vauban
@ 2013-09-10 3:47 ` Carsten Dominik
2013-09-10 6:03 ` Carsten Dominik
2013-09-10 5:06 ` Jambunathan K
2013-09-11 3:57 ` Jambunathan K
3 siblings, 1 reply; 74+ messages in thread
From: Carsten Dominik @ 2013-09-10 3:47 UTC (permalink / raw)
To: Nicolas Goaziou
Cc: Bastien, public-emacs-orgmode-mXXj517/zsQ, Sebastien Vauban
[-- 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 --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 15:41 ` Nicolas Goaziou
2013-09-09 17:42 ` Sebastien Vauban
2013-09-10 3:47 ` Carsten Dominik
@ 2013-09-10 5:06 ` Jambunathan K
2013-09-11 3:57 ` Jambunathan K
3 siblings, 0 replies; 74+ messages in thread
From: Jambunathan K @ 2013-09-10 5:06 UTC (permalink / raw)
To: Nicolas Goaziou
Cc: Bastien, public-emacs-orgmode-mXXj517/zsQ, Sebastien Vauban,
Carsten Dominik
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.
----------------------------------------------------------------
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 3:47 ` Carsten Dominik
@ 2013-09-10 6:03 ` Carsten Dominik
2013-09-10 6:48 ` Eric Abrahamsen
2013-09-10 7:32 ` Suvayu Ali
0 siblings, 2 replies; 74+ messages in thread
From: Carsten Dominik @ 2013-09-10 6:03 UTC (permalink / raw)
To: Nicolas Goaziou
Cc: Bastien, public-emacs-orgmode-mXXj517/zsQ, Sebastien Vauban
[-- 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 --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 6:03 ` Carsten Dominik
@ 2013-09-10 6:48 ` Eric Abrahamsen
2013-09-10 7:32 ` Suvayu Ali
1 sibling, 0 replies; 74+ messages in thread
From: Eric Abrahamsen @ 2013-09-10 6:48 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 6:03 ` Carsten Dominik
2013-09-10 6:48 ` Eric Abrahamsen
@ 2013-09-10 7:32 ` Suvayu Ali
2013-09-10 7:53 ` Suvayu Ali
1 sibling, 1 reply; 74+ messages in thread
From: Suvayu Ali @ 2013-09-10 7:32 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 7:32 ` Suvayu Ali
@ 2013-09-10 7:53 ` Suvayu Ali
2013-09-10 7:58 ` Carsten Dominik
0 siblings, 1 reply; 74+ messages in thread
From: Suvayu Ali @ 2013-09-10 7:53 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Nicolas Goaziou, Carsten Dominik
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 7:53 ` Suvayu Ali
@ 2013-09-10 7:58 ` Carsten Dominik
2013-09-10 8:16 ` Carsten Dominik
0 siblings, 1 reply; 74+ messages in thread
From: Carsten Dominik @ 2013-09-10 7:58 UTC (permalink / raw)
To: Suvayu Ali; +Cc: Nicolas Goaziou, emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 7:58 ` Carsten Dominik
@ 2013-09-10 8:16 ` Carsten Dominik
2013-09-10 8:50 ` Suvayu Ali
2013-09-10 20:16 ` Samuel Wales
0 siblings, 2 replies; 74+ messages in thread
From: Carsten Dominik @ 2013-09-10 8:16 UTC (permalink / raw)
To: Suvayu Ali; +Cc: Nicolas Goaziou, emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 8:16 ` Carsten Dominik
@ 2013-09-10 8:50 ` Suvayu Ali
2013-09-10 9:02 ` Carsten Dominik
2013-09-10 20:16 ` Samuel Wales
1 sibling, 1 reply; 74+ messages in thread
From: Suvayu Ali @ 2013-09-10 8:50 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Nicolas Goaziou, emacs-orgmode
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 8:50 ` Suvayu Ali
@ 2013-09-10 9:02 ` Carsten Dominik
2013-09-10 9:50 ` Suvayu Ali
0 siblings, 1 reply; 74+ messages in thread
From: Carsten Dominik @ 2013-09-10 9:02 UTC (permalink / raw)
To: Suvayu Ali; +Cc: Nicolas Goaziou, emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 9:02 ` Carsten Dominik
@ 2013-09-10 9:50 ` Suvayu Ali
2013-09-10 16:33 ` Nicolas Goaziou
0 siblings, 1 reply; 74+ messages in thread
From: Suvayu Ali @ 2013-09-10 9:50 UTC (permalink / raw)
To: Carsten Dominik; +Cc: Nicolas Goaziou, emacs-orgmode
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 9:50 ` Suvayu Ali
@ 2013-09-10 16:33 ` Nicolas Goaziou
2013-09-10 18:35 ` Jambunathan K
2013-09-10 18:58 ` Suvayu Ali
0 siblings, 2 replies; 74+ messages in thread
From: Nicolas Goaziou @ 2013-09-10 16:33 UTC (permalink / raw)
To: Suvayu Ali; +Cc: emacs-orgmode, Carsten Dominik
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 16:33 ` Nicolas Goaziou
@ 2013-09-10 18:35 ` Jambunathan K
2013-09-10 18:39 ` Nicolas Goaziou
2013-09-10 18:58 ` Suvayu Ali
1 sibling, 1 reply; 74+ messages in thread
From: Jambunathan K @ 2013-09-10 18:35 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode, Carsten Dominik
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 18:35 ` Jambunathan K
@ 2013-09-10 18:39 ` Nicolas Goaziou
2013-09-10 19:22 ` Jambunathan K
0 siblings, 1 reply; 74+ messages in thread
From: Nicolas Goaziou @ 2013-09-10 18:39 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-orgmode, Carsten Dominik
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 16:33 ` Nicolas Goaziou
2013-09-10 18:35 ` Jambunathan K
@ 2013-09-10 18:58 ` Suvayu Ali
2013-09-10 19:07 ` Suvayu Ali
2013-09-10 19:48 ` Nicolas Goaziou
1 sibling, 2 replies; 74+ messages in thread
From: Suvayu Ali @ 2013-09-10 18:58 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode, Carsten Dominik
[-- 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:
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 18:58 ` Suvayu Ali
@ 2013-09-10 19:07 ` Suvayu Ali
2013-09-10 19:48 ` Nicolas Goaziou
1 sibling, 0 replies; 74+ messages in thread
From: Suvayu Ali @ 2013-09-10 19:07 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode, Carsten Dominik
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 18:39 ` Nicolas Goaziou
@ 2013-09-10 19:22 ` Jambunathan K
2013-09-10 19:40 ` Jambunathan K
2013-09-10 19:52 ` Nicolas Goaziou
0 siblings, 2 replies; 74+ messages in thread
From: Jambunathan K @ 2013-09-10 19:22 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode, Carsten Dominik
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]].
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 19:22 ` Jambunathan K
@ 2013-09-10 19:40 ` Jambunathan K
2013-09-10 19:52 ` Nicolas Goaziou
1 sibling, 0 replies; 74+ messages in thread
From: Jambunathan K @ 2013-09-10 19:40 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode, Carsten Dominik
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 18:58 ` Suvayu Ali
2013-09-10 19:07 ` Suvayu Ali
@ 2013-09-10 19:48 ` Nicolas Goaziou
2013-09-10 20:13 ` Suvayu Ali
` (2 more replies)
1 sibling, 3 replies; 74+ messages in thread
From: Nicolas Goaziou @ 2013-09-10 19:48 UTC (permalink / raw)
To: Suvayu Ali; +Cc: emacs-orgmode, Carsten Dominik
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 19:22 ` Jambunathan K
2013-09-10 19:40 ` Jambunathan K
@ 2013-09-10 19:52 ` Nicolas Goaziou
1 sibling, 0 replies; 74+ messages in thread
From: Nicolas Goaziou @ 2013-09-10 19:52 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-orgmode, Carsten Dominik
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 19:48 ` Nicolas Goaziou
@ 2013-09-10 20:13 ` Suvayu Ali
2013-09-10 20:29 ` Nicolas Goaziou
2013-09-10 21:08 ` Carsten Dominik
2013-09-11 2:49 ` Jambunathan K
2 siblings, 1 reply; 74+ messages in thread
From: Suvayu Ali @ 2013-09-10 20:13 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode, Carsten Dominik
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 8:16 ` Carsten Dominik
2013-09-10 8:50 ` Suvayu Ali
@ 2013-09-10 20:16 ` Samuel Wales
1 sibling, 0 replies; 74+ messages in thread
From: Samuel Wales @ 2013-09-10 20:16 UTC (permalink / raw)
To: Carsten Dominik; +Cc: emacs-orgmode, Nicolas Goaziou
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 20:13 ` Suvayu Ali
@ 2013-09-10 20:29 ` Nicolas Goaziou
0 siblings, 0 replies; 74+ messages in thread
From: Nicolas Goaziou @ 2013-09-10 20:29 UTC (permalink / raw)
To: Suvayu Ali; +Cc: emacs-orgmode, Carsten Dominik
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 19:48 ` Nicolas Goaziou
2013-09-10 20:13 ` Suvayu Ali
@ 2013-09-10 21:08 ` Carsten Dominik
2013-09-11 12:24 ` Suvayu Ali
2013-09-11 2:49 ` Jambunathan K
2 siblings, 1 reply; 74+ messages in thread
From: Carsten Dominik @ 2013-09-10 21:08 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 19:48 ` Nicolas Goaziou
2013-09-10 20:13 ` Suvayu Ali
2013-09-10 21:08 ` Carsten Dominik
@ 2013-09-11 2:49 ` Jambunathan K
2013-09-11 11:09 ` Nicolas Goaziou
2 siblings, 1 reply; 74+ messages in thread
From: Jambunathan K @ 2013-09-11 2:49 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode, Carsten Dominik
[-- 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]].
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-09 15:41 ` Nicolas Goaziou
` (2 preceding siblings ...)
2013-09-10 5:06 ` Jambunathan K
@ 2013-09-11 3:57 ` Jambunathan K
2013-09-11 15:47 ` Nicolas Goaziou
3 siblings, 1 reply; 74+ messages in thread
From: Jambunathan K @ 2013-09-11 3:57 UTC (permalink / raw)
To: Nicolas Goaziou
Cc: Bastien, public-emacs-orgmode-mXXj517/zsQ, Sebastien Vauban,
Carsten Dominik
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.
----------------------------------------------------------------
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-11 2:49 ` Jambunathan K
@ 2013-09-11 11:09 ` Nicolas Goaziou
2013-09-11 11:34 ` Jambunathan K
2013-09-11 15:31 ` Jambunathan K
0 siblings, 2 replies; 74+ messages in thread
From: Nicolas Goaziou @ 2013-09-11 11:09 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-orgmode, Carsten Dominik
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-11 11:09 ` Nicolas Goaziou
@ 2013-09-11 11:34 ` Jambunathan K
2013-09-11 15:19 ` Nicolas Goaziou
2013-09-11 15:31 ` Jambunathan K
1 sibling, 1 reply; 74+ messages in thread
From: Jambunathan K @ 2013-09-11 11:34 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode, Carsten Dominik
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-10 21:08 ` Carsten Dominik
@ 2013-09-11 12:24 ` Suvayu Ali
2013-09-12 6:54 ` Jambunathan K
0 siblings, 1 reply; 74+ messages in thread
From: Suvayu Ali @ 2013-09-11 12:24 UTC (permalink / raw)
To: Carsten Dominik; +Cc: emacs-orgmode, Nicolas Goaziou
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-11 11:34 ` Jambunathan K
@ 2013-09-11 15:19 ` Nicolas Goaziou
2013-09-11 15:40 ` Jambunathan K
0 siblings, 1 reply; 74+ messages in thread
From: Nicolas Goaziou @ 2013-09-11 15:19 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-orgmode, Carsten Dominik
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-11 11:09 ` Nicolas Goaziou
2013-09-11 11:34 ` Jambunathan K
@ 2013-09-11 15:31 ` Jambunathan K
2013-09-11 15:40 ` Nicolas Goaziou
1 sibling, 1 reply; 74+ messages in thread
From: Jambunathan K @ 2013-09-11 15:31 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode, Carsten Dominik
[-- 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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-11 15:31 ` Jambunathan K
@ 2013-09-11 15:40 ` Nicolas Goaziou
2013-09-11 16:14 ` Jambunathan K
0 siblings, 1 reply; 74+ messages in thread
From: Nicolas Goaziou @ 2013-09-11 15:40 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-orgmode, Carsten Dominik
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-11 15:19 ` Nicolas Goaziou
@ 2013-09-11 15:40 ` Jambunathan K
0 siblings, 0 replies; 74+ messages in thread
From: Jambunathan K @ 2013-09-11 15:40 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode, Carsten Dominik
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-11 3:57 ` Jambunathan K
@ 2013-09-11 15:47 ` Nicolas Goaziou
0 siblings, 0 replies; 74+ messages in thread
From: Nicolas Goaziou @ 2013-09-11 15:47 UTC (permalink / raw)
To: Jambunathan K
Cc: Bastien, public-emacs-orgmode-mXXj517/zsQ, Sebastien Vauban,
Carsten Dominik
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-11 15:40 ` Nicolas Goaziou
@ 2013-09-11 16:14 ` Jambunathan K
2013-09-11 20:01 ` Nicolas Goaziou
0 siblings, 1 reply; 74+ messages in thread
From: Jambunathan K @ 2013-09-11 16:14 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode, Carsten Dominik
I am happy with whatever is the latest version. You may want to commit
it.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-11 16:14 ` Jambunathan K
@ 2013-09-11 20:01 ` Nicolas Goaziou
2013-09-11 22:11 ` Suvayu Ali
` (3 more replies)
0 siblings, 4 replies; 74+ messages in thread
From: Nicolas Goaziou @ 2013-09-11 20:01 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-orgmode, Carsten Dominik
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-11 20:01 ` Nicolas Goaziou
@ 2013-09-11 22:11 ` Suvayu Ali
2013-09-12 6:43 ` Jambunathan K
` (2 subsequent siblings)
3 siblings, 0 replies; 74+ messages in thread
From: Suvayu Ali @ 2013-09-11 22:11 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode, Jambunathan K, Carsten Dominik
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-11 20:01 ` Nicolas Goaziou
2013-09-11 22:11 ` Suvayu Ali
@ 2013-09-12 6:43 ` Jambunathan K
2013-09-12 9:07 ` Nicolas Goaziou
2013-09-12 7:17 ` Sebastien Vauban
2013-09-13 10:57 ` Carsten Dominik
3 siblings, 1 reply; 74+ messages in thread
From: Jambunathan K @ 2013-09-12 6:43 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode, Carsten Dominik
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---
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-11 12:24 ` Suvayu Ali
@ 2013-09-12 6:54 ` Jambunathan K
2013-09-12 9:11 ` Nicolas Goaziou
0 siblings, 1 reply; 74+ messages in thread
From: Jambunathan K @ 2013-09-12 6:54 UTC (permalink / raw)
To: Suvayu Ali; +Cc: Nicolas Goaziou, emacs-orgmode, Carsten Dominik
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-11 20:01 ` Nicolas Goaziou
2013-09-11 22:11 ` Suvayu Ali
2013-09-12 6:43 ` Jambunathan K
@ 2013-09-12 7:17 ` Sebastien Vauban
2013-09-13 10:57 ` Carsten Dominik
3 siblings, 0 replies; 74+ messages in thread
From: Sebastien Vauban @ 2013-09-12 7:17 UTC (permalink / raw)
To: emacs-orgmode-mXXj517/zsQ
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-12 6:43 ` Jambunathan K
@ 2013-09-12 9:07 ` Nicolas Goaziou
2013-09-12 10:12 ` Jambunathan K
0 siblings, 1 reply; 74+ messages in thread
From: Nicolas Goaziou @ 2013-09-12 9:07 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-orgmode, Carsten Dominik
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-12 6:54 ` Jambunathan K
@ 2013-09-12 9:11 ` Nicolas Goaziou
2013-09-12 9:28 ` Jambunathan K
0 siblings, 1 reply; 74+ messages in thread
From: Nicolas Goaziou @ 2013-09-12 9:11 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-orgmode, Carsten Dominik
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-12 9:11 ` Nicolas Goaziou
@ 2013-09-12 9:28 ` Jambunathan K
2013-09-12 9:47 ` Suvayu Ali
0 siblings, 1 reply; 74+ messages in thread
From: Jambunathan K @ 2013-09-12 9:28 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode, Carsten Dominik
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,
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-12 9:28 ` Jambunathan K
@ 2013-09-12 9:47 ` Suvayu Ali
0 siblings, 0 replies; 74+ messages in thread
From: Suvayu Ali @ 2013-09-12 9:47 UTC (permalink / raw)
To: Jambunathan K; +Cc: emacs-orgmode, Nicolas Goaziou, Carsten Dominik
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-12 9:07 ` Nicolas Goaziou
@ 2013-09-12 10:12 ` Jambunathan K
0 siblings, 0 replies; 74+ messages in thread
From: Jambunathan K @ 2013-09-12 10:12 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode, Carsten Dominik
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-11 20:01 ` Nicolas Goaziou
` (2 preceding siblings ...)
2013-09-12 7:17 ` Sebastien Vauban
@ 2013-09-13 10:57 ` Carsten Dominik
2013-09-13 22:29 ` Nicolas Goaziou
3 siblings, 1 reply; 74+ messages in thread
From: Carsten Dominik @ 2013-09-13 10:57 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode@gnu.org Mode
[-- 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 --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-13 10:57 ` Carsten Dominik
@ 2013-09-13 22:29 ` Nicolas Goaziou
2013-09-14 5:33 ` Carsten Dominik
2013-09-14 17:16 ` Suvayu Ali
0 siblings, 2 replies; 74+ messages in thread
From: Nicolas Goaziou @ 2013-09-13 22:29 UTC (permalink / raw)
To: Carsten Dominik; +Cc: emacs-orgmode@gnu.org Mode
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
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-13 22:29 ` Nicolas Goaziou
@ 2013-09-14 5:33 ` Carsten Dominik
2013-09-14 17:16 ` Suvayu Ali
1 sibling, 0 replies; 74+ messages in thread
From: Carsten Dominik @ 2013-09-14 5:33 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode@gnu.org Mode
[-- 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 --]
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-13 22:29 ` Nicolas Goaziou
2013-09-14 5:33 ` Carsten Dominik
@ 2013-09-14 17:16 ` Suvayu Ali
2013-09-15 4:39 ` Carsten Dominik
1 sibling, 1 reply; 74+ messages in thread
From: Suvayu Ali @ 2013-09-14 17:16 UTC (permalink / raw)
To: Nicolas Goaziou; +Cc: emacs-orgmode@gnu.org Mode, Carsten Dominik
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.
^ permalink raw reply [flat|nested] 74+ messages in thread
* Re: Outline cycling does not preserve point's position
2013-09-14 17:16 ` Suvayu Ali
@ 2013-09-15 4:39 ` Carsten Dominik
0 siblings, 0 replies; 74+ messages in thread
From: Carsten Dominik @ 2013-09-15 4:39 UTC (permalink / raw)
To: Suvayu Ali; +Cc: emacs-orgmode@gnu.org Mode, Nicolas Goaziou
[-- 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 --]
^ permalink raw reply [flat|nested] 74+ messages in thread
end of thread, other threads:[~2013-09-15 4:39 UTC | newest]
Thread overview: 74+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-07 12:11 Outline cycling does not preserve point's position Sebastien Vauban
2013-09-07 14:17 ` Carsten Dominik
[not found] ` <BED1FBAA-8BB5-45D6-8328-11C0BB2DF015-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2013-09-07 19:28 ` Sebastien Vauban
2013-09-08 6:16 ` Carsten Dominik
2013-09-09 7:57 ` Sebastien Vauban
2013-09-08 11:03 ` Eric Schulte
2013-09-09 8:39 ` Sebastien Vauban
2013-09-08 16:23 ` Carsten Dominik
2013-09-09 8:11 ` Sebastien Vauban
2013-09-09 8:13 ` Carsten Dominik
2013-09-09 8:23 ` Sebastien Vauban
2013-09-09 8:27 ` Carsten Dominik
2013-09-09 8:33 ` Sebastien Vauban
2013-09-09 8:38 ` Bastien
2013-09-09 9:05 ` Carsten Dominik
2013-09-09 11:32 ` Nicolas Goaziou
2013-09-09 11:49 ` Bastien
2013-09-09 15:27 ` Nicolas Goaziou
2013-09-09 14:23 ` Carsten Dominik
2013-09-09 15:16 ` Jambunathan K
2013-09-09 15:41 ` Nicolas Goaziou
2013-09-09 17:42 ` Sebastien Vauban
2013-09-10 3:47 ` Carsten Dominik
2013-09-10 6:03 ` Carsten Dominik
2013-09-10 6:48 ` Eric Abrahamsen
2013-09-10 7:32 ` Suvayu Ali
2013-09-10 7:53 ` Suvayu Ali
2013-09-10 7:58 ` Carsten Dominik
2013-09-10 8:16 ` Carsten Dominik
2013-09-10 8:50 ` Suvayu Ali
2013-09-10 9:02 ` Carsten Dominik
2013-09-10 9:50 ` Suvayu Ali
2013-09-10 16:33 ` Nicolas Goaziou
2013-09-10 18:35 ` Jambunathan K
2013-09-10 18:39 ` Nicolas Goaziou
2013-09-10 19:22 ` Jambunathan K
2013-09-10 19:40 ` Jambunathan K
2013-09-10 19:52 ` Nicolas Goaziou
2013-09-10 18:58 ` Suvayu Ali
2013-09-10 19:07 ` Suvayu Ali
2013-09-10 19:48 ` Nicolas Goaziou
2013-09-10 20:13 ` Suvayu Ali
2013-09-10 20:29 ` Nicolas Goaziou
2013-09-10 21:08 ` Carsten Dominik
2013-09-11 12:24 ` Suvayu Ali
2013-09-12 6:54 ` Jambunathan K
2013-09-12 9:11 ` Nicolas Goaziou
2013-09-12 9:28 ` Jambunathan K
2013-09-12 9:47 ` Suvayu Ali
2013-09-11 2:49 ` Jambunathan K
2013-09-11 11:09 ` Nicolas Goaziou
2013-09-11 11:34 ` Jambunathan K
2013-09-11 15:19 ` Nicolas Goaziou
2013-09-11 15:40 ` Jambunathan K
2013-09-11 15:31 ` Jambunathan K
2013-09-11 15:40 ` Nicolas Goaziou
2013-09-11 16:14 ` Jambunathan K
2013-09-11 20:01 ` Nicolas Goaziou
2013-09-11 22:11 ` Suvayu Ali
2013-09-12 6:43 ` Jambunathan K
2013-09-12 9:07 ` Nicolas Goaziou
2013-09-12 10:12 ` Jambunathan K
2013-09-12 7:17 ` Sebastien Vauban
2013-09-13 10:57 ` Carsten Dominik
2013-09-13 22:29 ` Nicolas Goaziou
2013-09-14 5:33 ` Carsten Dominik
2013-09-14 17:16 ` Suvayu Ali
2013-09-15 4:39 ` Carsten Dominik
2013-09-10 20:16 ` Samuel Wales
2013-09-10 5:06 ` Jambunathan K
2013-09-11 3:57 ` Jambunathan K
2013-09-11 15:47 ` Nicolas Goaziou
2013-09-09 8:38 ` Carsten Dominik
2013-09-09 11:30 ` Nicolas Goaziou
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).