From: "Andreas Röhler" <andreas.roehler@easy-emacs.de>
To: "João Távora" <joaotavora@gmail.com>
Cc: "help-gnu-emacs@gnu.org List" <help-gnu-emacs@gnu.org>
Subject: Re: moving in js
Date: Fri, 10 Aug 2012 13:15:03 +0200 [thread overview]
Message-ID: <5024ED37.6060501@easy-emacs.de> (raw)
In-Reply-To: <CALDnm52urB5ZD7gkDeGE4irOn+J-EWzLVcDfEetZVrf95ZESEA@mail.gmail.com>
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
prev parent reply other threads:[~2012-08-10 11:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-07 19:11 moving in js Andreas Röhler
2012-08-07 20:33 ` Peter Dyballa
2012-08-08 5:37 ` Andreas Röhler
2012-08-08 17:37 ` João Távora
2012-08-09 5:45 ` Andreas Röhler
[not found] ` <CALDnm512KSuJw+ZScjnn59x7OZLnWOfyZzLVBe_4CiLqdKTAkA@mail.gmail.com>
2012-08-09 16:20 ` Andreas Röhler
[not found] ` <CALDnm537EEG=6s9KJrqSZN35zBTg=GLcE7OBJy8h=N4zAD03cA@mail.gmail.com>
2012-08-09 17:19 ` Andreas Röhler
2012-08-10 1:14 ` João Távora
2012-08-10 6:45 ` Andreas Röhler
[not found] ` <CALDnm52urB5ZD7gkDeGE4irOn+J-EWzLVcDfEetZVrf95ZESEA@mail.gmail.com>
2012-08-10 11:15 ` Andreas Röhler [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5024ED37.6060501@easy-emacs.de \
--to=andreas.roehler@easy-emacs.de \
--cc=help-gnu-emacs@gnu.org \
--cc=joaotavora@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).