Re: Shell-script[bash] indention broken (or fixed?)

[Stefan Monnier]

>> In Lisp mode, TAB leaves continuation lines unchanged.
>> It seems to me that that is the right thing to do.
>> What do people think of changing sh-script.el to do that?

>     I think it would be good as an option, but the default should stay as
>     it is.  Continuation lines in sh are used in many more cases than in
>     Lisp.  Quite often they're used to spread command arguments on several
>     lines, in which case indentation is really what you want.

> Often it is ok, but if it cannot tell WHEN this is ok, it is likely to
> turn correct shell code into incorrect shell code.  I don't think that
> is a good idea.

In theory, it can happen.  It practice it has *never* been a problem for me.
I'd find a "don't touch" default to be very inconvenient and I expect many
other users would agree.

Note that I'd be surprised if there aren't several other cases where the
current indentation code could mess things up.  E.g. the following is
correct sh code AFAIK:

        #!/bin/sh

        echo "$(foo bar "hello
        there
        here we are")"

Now changing the indentation of `there' will change the second argument
passed to `foo' and is thus wrong, but thanks to the funky quotation rules
of sh, sh-mode can't tell with 100% certainty when a \n is within a quoted
string or not.

>     Maybe a compromise would be to do the following: if the "\\\n" is
>     preceded by a space or a tab, then the following line should be
>     indented, otherwise it should be left untouched.

> This might make it safe most of the time, but I think there will still
> be cases of strings where it gets fooled.

The idea is not to use a heuristic to figure out what the user wants, but to
setup a convention that the user can follow.


        Stefan