On 14.9.2013, at 19:16, Suvayu Ali wrote:
> Hi Nicolas,
>
> On Sat, Sep 14, 2013 at 12:29:00AM +0200, Nicolas Goaziou wrote:
>> Hello,
>>
>> Carsten Dominik writes:
>>
>>> When the functions are done, please go ahead and commit them and bind
>>> them to C-up/down.
>>
>> Done.
>
> Do you th
Hi Nicolas,
On Sat, Sep 14, 2013 at 12:29:00AM +0200, Nicolas Goaziou wrote:
> Hello,
>
> Carsten Dominik 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 argument
Nicolas Goaziou 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
Hello Nicolas,
thank you!
- Carsten
On 14.9.2013, at 00:29, Nicolas Goaziou wrote:
> Hello,
>
> Carsten Dominik writes:
>
>> When the functions are done, please go ahead and commit them and bind
>> them to C-up/down.
>
> Done.
>
>
> Regards,
>
> --
> Nicolas Goaziou
signature.asc
De
Hello,
Carsten Dominik writes:
> When the functions are done, please go ahead and commit them and bind
> them to C-up/down.
Done.
Regards,
--
Nicolas Goaziou
Hi Nicolas,
thanks for these. Please see the two comments below.
On Sep 11, 2013, at 10:01 PM, Nicolas Goaziou wrote:
> Jambunathan K 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
Nicolas Goaziou writes:
> Jambunathan K writes:
>
>> Suvayu Ali 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
>>
Nicolas Goaziou 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, fo
Nicolas Goaziou 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 s
Suvayu Ali 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 yourse
Nicolas Goaziou 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
I am happy with whatever is the latest version. You may want to commit
it.
Jambunathan K 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 becomes easy.
Whatever could be:
1. editing.
2. Surgical motion with sexp comman
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
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 pa
Nicolas Goaziou 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
Nicolas Goaziou 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 active
Nicolas Goaziou writes:
> Here's a first draft for the linear forward motion.
cond: Symbol's function definition is void: org-forward-and-down-element
Hi Jambu,
On Thu, Sep 12, 2013 at 02:58:02PM +0530, Jambunathan K wrote:
> Nicolas Goaziou writes:
>
> > Jambunathan K writes:
> >
> >> Suvayu Ali writes:
> >>
> And I agree with you, beginning of line is a good target column.
> >>>
> >>> On reading Nicolas's explanation, I agree too. Th
Jambunathan K writes:
> Suvayu Ali 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
Hello,
Jambunathan K writes:
> Nicolas Goaziou 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 line
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
Hi Nicolas,
On Wed, Sep 11, 2013 at 10:01:31PM +0200, Nicolas Goaziou wrote:
> Jambunathan K 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 point
Jambunathan K 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
Jambunathan K 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 basi
Jambunathan K writes:
> Nicolas Goaziou 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 re
Jambunathan K 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 functi
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.
Hello,
Jambunathan K 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 "Should
On 10.9.2013, at 21:48, Nicolas Goaziou wrote:
> Hello,
>
> Suvayu Ali 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 head
Suvayu Ali 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 d
Jambunathan K writes:
> Nicolas Goaziou 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
On 9/10/13, Carsten Dominik 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 sa
Hello,
Jambunathan K writes:
> Nicolas Goaziou 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 t
Hello,
Suvayu Ali 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
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.
Hi Nicolas,
On Tue, Sep 10, 2013 at 06:33:16PM +0200, Nicolas Goaziou wrote:
>
> Suvayu Ali 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
Hi Nicolas,
On Tue, Sep 10, 2013 at 09:48:53PM +0200, Nicolas Goaziou wrote:
> Suvayu Ali 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
Hello,
Suvayu Ali writes:
> On Tue, Sep 10, 2013 at 11:02:35AM +0200, Carsten Dominik wrote:
>>
>> On 10.9.2013, at 10:50, Suvayu Ali wrote:
>>
>> > On Tue, Sep 10, 2013 at 10:16:06AM +0200, Carsten Dominik wrote:
>> >>
>> >> The question is: What are people using C-arrow for?
>> >>
>> >>
Nicolas Goaziou 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
On Tue, Sep 10, 2013 at 11:02:35AM +0200, Carsten Dominik wrote:
>
> On 10.9.2013, at 10:50, Suvayu Ali 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 reasona
On 10.9.2013, at 10:50, Suvayu Ali 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 peopl
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
On 10.9.2013, at 09:58, Carsten Dominik wrote:
>
> On 10.9.2013, at 09:53, Suvayu Ali 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 command
On 10.9.2013, at 09:53, Suvayu Ali 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
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,
> >
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 paragr
Carsten Dominik writes:
> On 10.9.2013, at 05:47, Carsten Dominik wrote:
>
>>
>> On 9.9.2013, at 17:41, Nicolas Goaziou wrote:
>>
>>> Carsten Dominik writes:
>>>
It is extremely predictable if you know about the structure of an Org
document and if you think in elements.
>>>
>>> I
On 10.9.2013, at 05:47, Carsten Dominik wrote:
>
> On 9.9.2013, at 17:41, Nicolas Goaziou wrote:
>
>> Carsten Dominik writes:
>>
>>> It is extremely predictable if you know about the structure of an Org
>>> document and if you think in elements.
>>
>> It's a Sexp motion.
>>
>>> It is unex
On 9.9.2013, at 17:41, Nicolas Goaziou wrote:
> Carsten Dominik writes:
>
>> It is extremely predictable if you know about the structure of an Org
>> document and if you think in elements.
>
> It's a Sexp motion.
>
>> It is unexpected for a user who is used to C-arrow doing paragraph
>> moti
Hello Nicolas,
Nicolas Goaziou wrote:
> Carsten Dominik writes:
>
>> It is extremely predictable if you know about the structure of an Org
>> document and if you think in elements.
>
> It's a Sexp motion.
>
>> It is unexpected for a user who is used to C-arrow doing paragraph
>> motion. In Org, o
Carsten Dominik writes:
> It is extremely predictable if you know about the structure of an Org
> document and if you think in elements.
It's a Sexp motion.
> It is unexpected for a user who is used to C-arrow doing paragraph
> motion. In Org, org-backward-element climbs out if a hierarchy. T
Hello,
Bastien 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, wh
> 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.
---
On 9.9.2013, at 13:32, Nicolas Goaziou wrote:
> Hello,
>
> Carsten Dominik writes:
>
>> On 9.9.2013, at 10:38, Bastien 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 eleme
Hi Nicolas,
Nicolas Goaziou 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 _al
Hello,
Carsten Dominik writes:
> This might be difficult, but not impossible.
> I think this might be a question for Nicolas to answer?
It boils down to something like:
(if (eq (org-element-type (org-element-at-point)) 'src-block)
;; Do forward-paragraph according to language.
..
Hello,
Carsten Dominik writes:
> On 9.9.2013, at 10:38, Bastien 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 mak
On 9.9.2013, at 10:38, Bastien wrote:
>
>
> Hi Sébastien,
>
> "Sebastien Vauban"
> 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 o
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
On 9.9.2013, at 10:33, "Sebastien Vauban" wrote:
> Hi Carsten,
>
> Carsten Dominik wrote:
>> On 9.9.2013, at 10:23, Sebastien Vauban wrote:
>>> Carsten Dominik wrote:
On 9.9.2013, at 10:11, "Sebastien Vauban" wrote:
> Carsten Dominik wrote:
>>> - not possible anymore to use C-a o
Hi Sébastien,
"Sebastien Vauban"
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*
comman
Hi Carsten,
Carsten Dominik wrote:
> On 9.9.2013, at 10:23, Sebastien Vauban wrote:
>> Carsten Dominik wrote:
>>> On 9.9.2013, at 10:11, "Sebastien Vauban" wrote:
Carsten Dominik wrote:
>> - not possible anymore to use C-a or C-e in code blocks to select
>> regions; not reported yet
On 9.9.2013, at 10:23, Sebastien Vauban wrote:
> Hi Carsten,
>
> Carsten Dominik wrote:
>> On 9.9.2013, at 10:11, "Sebastien Vauban" 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 simi
Hi Carsten,
Carsten Dominik wrote:
> On 9.9.2013, at 10:11, "Sebastien Vauban" 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 chang
On 9.9.2013, at 10:11, "Sebastien Vauban" 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 official
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 blo
Hi Carsten,
Carsten Dominik wrote:
> On 7.9.2013, at 21:28, Sebastien Vauban wrote:
>> Carsten Dominik wrote:
>>> On 7.9.2013, at 14:11, "Sebastien Vauban" wrote:
>>>
Since a little while, I've observed that point's position is not anymore
preserved when cycling buffer's view with S-T
On 7.9.2013, at 21:28, Sebastien Vauban wrote:
> Hi Carsten,
>
> Carsten Dominik wrote:
>> On 7.9.2013, at 14:11, "Sebastien Vauban" 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,
>
> 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;
>
Hi Sebastien,
On 7.9.2013, at 21:28, Sebastien Vauban wrote:
> Hi Carsten,
>
> Carsten Dominik wrote:
>> On 7.9.2013, at 14:11, "Sebastien Vauban" wrote:
>>
>>> Since a little while, I've observed that point's position is not anymore
>>> preserved when cycling buffer's view with S-TAB.
>>>
>
Hi Carsten,
Carsten Dominik wrote:
> On 7.9.2013, at 14:11, "Sebastien Vauban" 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);
>>
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 be
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
74 matches
Mail list logo
