Re: Defining functions on the fly

["Andreas Röhler" <andreas.roehler@easy-emacs.de>]

Am 16.06.2015 um 13:12 schrieb Tassilo Horn:

>> ###
>>
>> vorhanden() {
>>      for i in "blah" "blub";
>>      do
>>          # some comment (note: for compatibility)
>>      if [ ! -x $i ]; then
>>
>> ###
>>
>> with cursor last line "if", C-M-b jumps to "for", but should end at
>> "do"
> No.  `do ... done' is no valid expression, i.e., it cannot stand on its
> own but is only valid together with for, while, until, or repeat.

It's not the point to care for that.

It's about editing, reading, understanding the source.

What about a single "return" statement in code?

Nonetheless, will reflect this case again WRT the mode in question.


>
>>  From "for" ->
>>
>> Debugger entered--Lisp error: (scan-error "Containing expression ends
>> prematurely" 13 13)
>>    signal(scan-error ("Containing expression ends prematurely" 13 13))
>>    smie-forward-sexp-command(-1)
>>    forward-sexp(-1)
>>    backward-sexp(1)
>>    call-interactively(backward-sexp nil nil)
>>    command-execute(backward-sexp)
> Indeed, here I'd expect it to move to the beginning of the function
> definition.
>
>> Or take this:
>>
>> ###
>>
>> if [ $# == 0 ]; then
>>      # some comment (note: for compatibility)
>>      set "" `find .  -maxdepth 1 -type f -name "*.txt" | sed 's/..\(.*\)/\1/'`
>>
>>      for i in $*; do
>>          # some comment (note: for compatibility)
>>      pass
>>      done
>>
>> fi
>>
>> ###
>>
>> With cursor at third line, "set", expression is not recognised at all,
>> C-M-f stops at the end of symbol "set"
> Well, "command arg arg arg" in shell scripts is equivalent to (command
> arg arg arg) in lisp with the distinction that with the lisp syntax's
> parentheses you have a choice to move over the complete expression (when
> point is on the opening paren) or inside it (when point is on the
> "command").  Because the shell syntax doesn't have delimiters for the
> funcall or at least the argument list, there's not much you can do.

Wrong. We have the language's syntax and may follow it.
Also these languages often are quite similar, thus aiming for some generics.


>
>> That's a fakir's mode :)
> Well, you can extend it quite easily and declaratively by modifying
> `sh-smie-sh-grammar', and then your improvements are transparently
> available to anything which uses sexp-based motion.

I'll look for that. For the moment see a couple of mode's out there with 
open smie-related bugs.
See at elixir-mode or tuareg-mode for example.

>   I don't see how you
> can get the same benefits with tons and tons of special-case functions.
>
>

These tons are not written by me but by the folks in language-modes.
Auto-generating some stuff would reduce the costs.