moving in js

moving in js

[Andreas Röhler]

Hi,

when looking in javascript modes, can't see mode-specific commands for moves onto beg/end of function, block, statement etc.

Maybe I miss something...

Thanks,

Andreas

Re: moving in js

[Peter Dyballa]

Am 07.08.2012 um 21:11 schrieb Andreas Röhler:

> when looking in javascript modes, can't see mode-specific commands for moves onto beg/end of function, block, statement etc.

Is there no forward- or backward-sexp available?

--
Mit friedvollen Grüßen

  Pete

Ce qui a été compris n'existe plus.
				(Paul Eluard)

Re: moving in js

[Andreas Röhler]

Am 07.08.2012 22:33, schrieb Peter Dyballa:
>
> Am 07.08.2012 um 21:11 schrieb Andreas Röhler:
>
>> when looking in javascript modes, can't see mode-specific commands for moves onto beg/end of function, block, statement etc.
>
> Is there no forward- or backward-sexp available?


unfortunatly that command  raises deliberatly errors or tends to unpredictable moves

Example in python-mode, but similar in lisp:

with file("roulette-" + zeit + ".csv", 'w') as datei:
     for i in range(anzahl):
         klauf.pylauf()
         datei.write(str(spiel[i]) + "\n")

Go inside "\n" in last line and call C-M-b

it jumps one char backward, resp. up to ".csv"

Cursor on "i" in (spiel[i])

C-M-b -->

Debugger entered--Lisp error: (scan-error "Containing expression ends prematurely" 349 349)
   scan-sexps(350 -1)
   forward-sexp(-1)
   backward-sexp(1)
   call-interactively(backward-sexp nil nil)


Reported years ago...

Cheers,

Andreas

>
> --
> Mit friedvollen Grüßen
>
>    Pete
>
> Ce qui a été compris n'existe plus.
> 				(Paul Eluard)
>
>

Re: moving in js

[João Távora]

On Wed, Aug 8, 2012 at 6:37 AM, Andreas Röhler
<andreas.roehler@easy-emacs.de> wrote:

> Cursor on "i" in (spiel[i])
>
> C-M-b -->
>
> Debugger entered--Lisp error: (scan-error "Containing expression ends
> prematurely" 349 349)

The "\n" case moving to ".csv" is indeed an unexpected move, but I
would say this error
error is the expected behaviour. I mean, you can't `backward-sexp` there to go
back one balanced sexp from 'i', so an error is expected, and the character
positions are useful.

--
João

Re: moving in js

[Andreas Röhler]

Am 08.08.2012 19:37, schrieb João Távora:
> On Wed, Aug 8, 2012 at 6:37 AM, Andreas Röhler
> <andreas.roehler@easy-emacs.de> wrote:
>
>> Cursor on "i" in (spiel[i])
>>
>> C-M-b -->
>>
>> Debugger entered--Lisp error: (scan-error "Containing expression ends
>> prematurely" 349 349)
>
> The "\n" case moving to ".csv" is indeed an unexpected move, but I
> would say this error
> error is the expected behaviour. I mean, you can't `backward-sexp` there to go
> back one balanced sexp from 'i', so an error is expected, and the character
> positions are useful.
>
> --
> João
>

"\n" composes a balanced expression, obviously doublequotes are a matching pair of delimiters:

  Balanced expressions typically include individual symbols, numbers, and string constants, as well as pieces of code enclosed in a matching pair of delimiters.
http://www.gnu.org/software/emacs/manual/html_node/emacs/Expressions.html

also seen from usage, that command should never fail, unless beginning or end of buffers are reached.

backward-sexp can't deal with it, but that's just a bug.

Andreas

Re: moving in js

[Andreas Röhler]

Am 09.08.2012 17:04, schrieb João Távora:
>> also seen from usage, that command should never fail, unless beginning or
>> end of buffers are reached.
>>
>
> I don't understand this part. Why should it not fail?

Well, that's a matter of taste maybe. IMO expression have the part of words in natural language.
Not exactly, as common words don't nest, but similar. Will you ever get an error from "forward-word" unless at the EOB?

  In your opinion,
> what is backward-sexp suppose to do on its second invocation in a lisp-mode
> buffer containing
>
> (foo (bar baz) quux)
>
> with the cursor in the innermost list between "bar" and "baz"??
>

it would reach the beginning of the innermost list, "(bar"

a second invocation would reach "foo"

Re: moving in js

[Andreas Röhler]

Am 09.08.2012 18:44, schrieb João Távora:
>> Not exactly, as common words don't nest, but similar. Will you ever get an
>> error from "forward-word" unless at the EOB?
>
> No, because words don't nest :-) Lisp sexp's do (as do many other programming
> language constructs)
>
>> a second invocation would reach "foo"
>
> Then, on the second invocation, backward-sexp would not have "moved backward
> across one balanced expression", as its doc states.

hmm, so let's ask what such a balanced expression should be.

If we have the terminus of balanced expression, what will be the non-balanced?

A single operator for example "+"

while "4 + 5" might establish a balanced one. Agreed?

Single words and symbols also are not balanced expressions IMO.

When on ba|z

(foo (bar ba|z) quux)

C-M-b would reach |baz

(foo (bar |baz) quux)

i.e, it would do backward-word
a repeat would do backward-word again, a third would error

Can't see any relation to stipulated move over balanced expression here.

Looks fairly arbitrary.

CC to help, as it might be of some interest for others to.

>
> I think you might be looking for "scan-lists", it lets you move whithin the same
> level and pop out and in of lists. Uses the syntax tables. I used it in
> http://github.com/capitaomorte/autopair
>

Re: moving in js

[João Távora]

> Single words and symbols also are not balanced expressions IMO.
> When on ba|z
>
> (foo (bar ba|z) quux)
>
> C-M-b would reach |baz
>
> (foo (bar |baz) quux)
>
> i.e, it would do backward-word

No, it's doing backward-sexp. "baz" happens to also be a sexp (an
atomic), and it's not a question of opinion (see below).

> a repeat would do backward-word again, a third would error
>
> Can't see any relation to stipulated move over balanced expression here.
>
> Looks fairly arbitrary.

It's not. In lisp-mode, where this is clearer (but as we have seen it
can and has been generalized to other programming modes), a word and a
symbol are also sexp's. See http://en.wikipedia.org/wiki/S-expression:
a sexp can be an atom or a list ( a . b ) where a and b are themselves
sexp's. As you have found, backward-word doesn't error,  because it
doesn't care about sexp's. But backward-sexp does :-) , indeed it
*must* error to tell you there are no more sexp's backwards at that
level.

IMO this is one of the best designed features in Emacs, and one many
non-Emacs users envy. When I move and delete with the C-M-* keys, I
get structured editing for free. And (shameless plug) if I add
autopair.el to that, I don't need paredit.el at all.  Furthermore,
because Emacs generalizes the sexp concept to other modes via
syntax-tables,  structured editing (and autopair) "just work" in
almost every programming mode that defines delimiters.

> CC to help, as it might be of some interest for others to.

of course, I forgot to send my previous message to the list.

-- 
João Távora

Re: moving in js

[Andreas Röhler]

Am 10.08.2012 03:14, schrieb João Távora:
>> Single words and symbols also are not balanced expressions IMO.
>> When on ba|z
>>
>> (foo (bar ba|z) quux)
>>
>> C-M-b would reach |baz
>>
>> (foo (bar |baz) quux)
>>
>> i.e, it would do backward-word
>
> No, it's doing backward-sexp. "baz" happens to also be a sexp (an
> atomic), and it's not a question of opinion (see below).
>
>> a repeat would do backward-word again, a third would error
>>
>> Can't see any relation to stipulated move over balanced expression here.
>>
>> Looks fairly arbitrary.
>
> It's not. In lisp-mode, where this is clearer (but as we have seen it
> can and has been generalized to other programming modes), a word and a
> symbol are also sexp's. See http://en.wikipedia.org/wiki/S-expression:

Thanks pointing at.

IMO we have a conflict of notion between "symbolic expression" and "balanced expression", the latter stated in Emacs lisp info.

An atom is an symbolic expression. But where is the balance in singularity established by atom? For a balance you need a counterpart.

> a sexp can be an atom or a list ( a . b ) where a and b are themselves
> sexp's. As you have found, backward-word doesn't error,  because it
> doesn't care about sexp's. But backward-sexp does :-) , indeed it
> *must* error to tell you there are no more sexp's backwards at that
> level.
>

let's go on with a example from link given

"((milk juice) (honey marmalade))

is a two-element S-expression whose elements are also two-element S-expressions"

Go at beginning of honey and do backward-sexp --> error

A move command should look for a next element - preferably in same level.
But don't expect a kind of validation from, saying: oh, this list ends here.

It should just pick the next suitable element than.


> IMO this is one of the best designed features in Emacs, and one many
> non-Emacs users envy. When I move and delete with the C-M-* keys, I
> get structured editing for free. And (shameless plug) if I add
> autopair.el to that, I don't need paredit.el at all.  Furthermore,
> because Emacs generalizes the sexp concept to other modes via
> syntax-tables,  structured editing (and autopair) "just work" in
> almost every programming mode that defines delimiters.

okay, a use-case is an argument
Will look there, maybe get a clue.


>
>> CC to help, as it might be of some interest for others to.
>
> of course, I forgot to send my previous message to the list.
>

Re: moving in js

[Andreas Röhler]

Am 10.08.2012 11:16, schrieb João Távora:
>> But don't expect a kind of validation from, saying: oh, this list ends here.
>> It should just pick the next suitable element than.
>
> I do understand the expectation that a move command should do "the
> next best thing" and never error. But that is already what C-b and M-b
> do.

which is okay for natural languages.
What's needed still is the respective thing for programs: moving over expressions.

BTW all this "balanced" or "symbolic" qualifications are futil IMO.

Programs are composed of expressions, Emacs modes should be able to deal with it,

nonwithstanding if "4 + 4", "asdf" or "(foo . bar)" are at cursor pos.

As syntax differs, certainly Emacs' move commands can't use a single forward-expression implementation for all alike.

So let's start with Emacs lisp, implementing a move-command at finest grain.


(defun foo ()
   (interactive "*")
   nil)

If cursor at the interactive  code characters "*",
C-M-b should not error, but go to the beginning of string first, than at word-start interactive, than at
interactive spec (list-beginning).

Agreed?

> I'm quite used (and fond of) the errors C-M-b raises, it informs
> me about the quality of my code: if I didn't expect an error, it's
> because code wasn't structured the way I expected it to be.
>
> I think you would want some kind of command that backward-sexp's when
> it can, and when it can't pops *out* of a sexp.
>
> Whereas I wouldn't mind this: a command that backward-sexp's when it
> can, and when it can't raises the error. But calling it again
> immediately afterwards would pop out of the sexp. A bit like
> isearch-forward at the last match.
>
> Maybe I'll try to hack these post them here, I think they can be done
> easily with some defadvice.
>

IMHO its easier to start from scratch.
Happily some wise person provided a forward-sexp-function variable, so
hacking must not interfere with original code.

BTW I'm on it at python-mode.el, using py-expression for the purpose.
Not ready yet, solution is scheduled for 2012-09-04

https://launchpad.net/python-mode/+milestone/6.0.12

Cheers,

Andreas