Re: command-separator char

Re: command-separator char

[Stefan Monnier]

> Reflecting a generic level of navigations, it would be helpful if the
> language-modes would set such a constant.
> Maybe it exists already?

As you can expect, SMIE does do that.  E.g. when right in front of
a semi-colon, C-M-f will skip over the following instruction, and when
right after a semi-colon C-M-b will skip over the preceding instruction.
And M-C-t will swap the two instructions.


        Stefan

Re: command-separator char

[Andreas Röhler]

Am 21.06.2015 um 19:29 schrieb Stefan Monnier:
>> Reflecting a generic level of navigations, it would be helpful if the
>> language-modes would set such a constant.
>> Maybe it exists already?
> As you can expect, SMIE does do that.
May you tell me how it is named there?

>    E.g. when right in front of
> a semi-colon, C-M-f will skip over the following instruction, and when
> right after a semi-colon C-M-b will skip over the preceding instruction.
> And M-C-t will swap the two instructions.
>
>
>          Stefan

Hmm, in python-mode, C-M-f at beginning of

import time; import os

ends after "os", but should stop at semi-colon.

Thanks,

Andreas

Re: command-separator char

[Stefan Monnier]

> Hmm, in python-mode, C-M-f at beginning of
> import time; import os
> ends after "os", but should stop at semi-colon.

I was only talking about modes using SMIE.


        Stefan

Re: command-separator char

[Andreas Röhler]

Am 22.06.2015 um 22:00 schrieb Stefan Monnier:
>> Hmm, in python-mode, C-M-f at beginning of
>> import time; import os
>> ends after "os", but should stop at semi-colon.
> I was only talking about modes using SMIE.
>
>
>          Stefan

Any example?

Re: command-separator char

[Stefan Monnier]

>>> Hmm, in python-mode, C-M-f at beginning of
>>> import time; import os
>>> ends after "os", but should stop at semi-colon.
>> I was only talking about modes using SMIE.
> Any example?

Prolog, sh, css, Ruby, Tuareg, SML, Coq, Octave, Postscript, Modula-2?
"grep smie-setup" is a good way to find out.


        Stefan

Re: command-separator char

[Andreas Röhler]

Am 23.06.2015 um 14:45 schrieb Stefan Monnier:
>>>> Hmm, in python-mode, C-M-f at beginning of
>>>> import time; import os
>>>> ends after "os", but should stop at semi-colon.
>>> I was only talking about modes using SMIE.
>> Any example?
> Prolog, sh, css, Ruby, Tuareg, SML, Coq, Octave, Postscript, Modula-2?
> "grep smie-setup" is a good way to find out.
>
>
>          Stefan

With buffer sh-mode,

Same inconsistencies as common forward-sexp:

echo "foo"; echo "asdf";

With cursor at first word --> end of first word

With cursor inside first string --> end of first string

With cursor at end of first string --> inside second string

With cursor after first semicolon --> after second "echo"

etc.

Seems still no idea or definition what a sexp should be.

Unusable...

Re: command-separator char

[Stefan Monnier]

> Seems still no idea or definition what a sexp should be.

Nope.  It's only a UI issue.

Sexp navigation is basically navigation within the AST, but a given
buffer position corresponds to several different spots in the AST, so
there's an ambiguity.  Take your example line:

    echo "foo"; echo "asdf";

the AST looks like

           echo      
         /
     cmd
    /    \
   /       "foo"
  ;
   \       echo
    \     /
      cmd
         \
           "asdf"

The position at BOL can be take to be right before the "echo" node, or
right before the first "cmd" node or right before the toplevel composite
instruction that comprises the whole line.

You can mostly tell SMIE which one you want if you call smie-forward-sexp,
by passing it a token explaining the level you care about.

But forward-sexp is called by the user without any extra info, so it has
to make an arbitrary choice.  For compatibility with the usual
forward-sexp semantics, the choice it makes is to consider the "deepest"
position in the tree.

But as explained earlier, if you put point *before* a semi-colon, and then use
M-C-f, then SMIE's forward-sexp will take this as a clue that you want
to skip over whatever belongs to the right-hand of this semi-colon.
So with point right after "foo", C-M-f will jump to right after "asdf".

Along the same lines, you say:

  With cursor inside first string --> end of first string

meaning that this is inconsistent, but it's perfectly consistent, since
forward-sexp does not jump to "the end of the currently enclosing
entity" but instead to "the end of the entity that starts right after
point".

SMIE's forward-sexp could very well check syntax-ppss to see we're
inside a string (or comment) and move outside of that string, but then
it would be a different command.


        Stefan


PS: That doesn't mean that it always works right either, of course.
M-C-f with point right after the second "o" of "foo" (i.e. right before
the closing double quotes) should signal an error but will instead jump
to right after the opening double quotes of "asdf".
PPS: And `up-list' doesn't use SMIE quite right either.

Re: command-separator char

[Andreas Röhler]

Am 23.06.2015 um 19:00 schrieb Stefan Monnier:
>> Seems still no idea or definition what a sexp should be.
> Nope.  It's only a UI issue.
>
> Sexp navigation is basically navigation within the AST, but a given
> buffer position corresponds to several different spots in the AST, so
> there's an ambiguity.  Take your example line:
>
>      echo "foo"; echo "asdf";
>
> the AST looks like
>
>             echo
>           /
>       cmd
>      /    \
>     /       "foo"
>    ;
>     \       echo
>      \     /
>        cmd
>           \
>             "asdf"

Thanks a lot for your care!

> The position at BOL can be take to be right before the "echo" node, or
> right before the first "cmd" node or right before the toplevel composite
> instruction that comprises the whole line.
>
> You can mostly tell SMIE which one you want if you call smie-forward-sexp,
> by passing it a token explaining the level you care about.
>
> But forward-sexp is called by the user without any extra info, so it has
> to make an arbitrary choice.  For compatibility with the usual
> forward-sexp semantics, the choice it makes is to consider the "deepest"
> position in the tree.

That would be plausible. Unfortunatly can't see that.
 From end of first string jumps into second string. While there is an 
expression of three minor expressions:

echo _ "foo"_ ;

WRT to deepest it should keep the level and end after ";"


> But as explained earlier, if you put point *before* a semi-colon, and then use
> M-C-f, then SMIE's forward-sexp will take this as a clue that you want
> to skip over whatever belongs to the right-hand of this semi-colon.
> So with point right after "foo", C-M-f will jump to right after "asdf".
>
> Along the same lines, you say:
>
>    With cursor inside first string --> end of first string
>
> meaning that this is inconsistent,

No, didn't say that. That behaviour is expected - inconsistence was 
shown by the relation of examples.


> but it's perfectly consistent, since
> forward-sexp does not jump to "the end of the currently enclosing
> entity" but instead to "the end of the entity that starts right after
> point".
>
> SMIE's forward-sexp could very well check syntax-ppss to see we're
> inside a string (or comment) and move outside of that string, but then
> it would be a different command.
>

IMHO a much more usefull one :)


>          Stefan
>
>
> PS: That doesn't mean that it always works right either, of course.
> M-C-f with point right after the second "o" of "foo" (i.e. right before
> the closing double quotes) should signal an error

Think navigation shouldn't signal an error. Rather return nil - as at EOB.


> but will instead jump
> to right after the opening double quotes of "asdf".
> PPS: And `up-list' doesn't use SMIE quite right either.

IMO grammar oriented commands are needed - starting with token maybe.

Languages commonly know expressions, compositions of them - and so upwards.

Thanks,

Andreas

Re: command-separator char

[Stefan Monnier]

> From end of first string jumps into second string.

Yes, that's the problem I mentioned in my "PS".

> While there is an expression of three minor expressions:

I don't know what you mean by that.

> echo _ "foo"_ ;
> WRT to deepest it should keep the level and end after ";"

Not sure what you mean by "keep the level".

>> SMIE's forward-sexp could very well check syntax-ppss to see we're
>> inside a string (or comment) and move outside of that string, but then
>> it would be a different command.
> IMHO a much more usefull one :)

`up-list' is aiming to do this.  It currently fails miserably at that, tho.

>> PS: That doesn't mean that it always works right either, of course.
>> M-C-f with point right after the second "o" of "foo" (i.e. right before
>> the closing double quotes) should signal an error
> Think navigation shouldn't signal an error. Rather return nil - as at EOB.

C-M-f when right before of a close paren signals an error, and it
would make a lot of sense to do the same when right before of
a closing quote.


        Stefan

Re: command-separator char

[Andreas Röhler]

> `up-list' is aiming to do this.  It currently fails miserably at that, tho.

That would work if in-comment resp. in-string is treated accordingly. 
i.e. at time.


>
>>> PS: That doesn't mean that it always works right either, of course.
>>> M-C-f with point right after the second "o" of "foo" (i.e. right before
>>> the closing double quotes) should signal an error
>> Think navigation shouldn't signal an error. Rather return nil - as at EOB.
> C-M-f when right before of a close paren signals an error, and it
> would make a lot of sense to do the same when right before of
> a closing quote.
>

Or do a "level-up" than...

Re: command-separator char

[Stefan Monnier]

>> `up-list' is aiming to do this.  It currently fails miserably at that, tho.
> That would work if in-comment resp. in-string is treated
> accordingly. i.e. at time.

Not sure what you mean by "at time", but I think we agree.

> Or do a "level-up" than...

I'm not sure it'd be better.  It wouldn't be worse either, I guess, but
it's still hard to argue in favor of this change.


        Stefan

Re: command-separator char

[Emanuel Berg]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> several languages know about a character separating
> expressions resp. commands: ";" for example.
>
> Reflecting a generic level of navigations, it would
> be helpful if the language-modes would set such
> a constant.

This seems like a good idea - but is it?

If you use Emacs long enough which I think you have
isn't it better to just use the common point-moving
keys? G*d knows there are alot of them by now.
Also combine them with the M-{1..9} to move say three
`forward-word'. (Or use the otherwise `digit-argument'
keys which include C-{1..9} for you non-Linux VT user.
- or use C-u.)

Also write code to fit the style: Short words that are
simple to type and navigate, with short lines.

If you intend to use Emacs for a variety of
programming modes this seems like good money to start
putting in the bank early on. It makes sense being an
accordion player only because those chords will appear
over and over... Remember, "what you once feared, now
makes you free."

On the other "hand", if you will just use but a few
programming modes, say for Lisp and C, apart from
still being much helped by the first approach, you can
use the mode-specific functions on top of that:
`forward-sexp', for example.

What I see you are trying to do is put a third level
in-between then mode-specific and then all-out general
Emacs point-movement commands. It is a good idea on
the drawing board but a don't see myself ever using
it. But of course, I am not you.

-- 
underground experts united
http://user.it.uu.se/~embe8573

command-separator char

[Andreas Röhler]

Hi,

several languages know about a character separating expressions resp. 
commands: ";" for example.

Reflecting a generic level of navigations, it would be helpful if the 
language-modes would set such a constant.

Maybe it exists already?

Thanks,

Andreas