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

[Steven T. Hatton]

On Tuesday 14 June 2005 11:30, Stefan Monnier wrote:
> >> 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")"

Far more simple is the example of a PATH-like variable:

export PATH=$GNU_EMACS/bin\
:$ICECREAM_HOME/bin\
:$KDEDIR/bin\
:$QTDIR/bin\
:$NSS/bin\
:$NSPR/bin\
:$MONO_HOME/bin\
:$BOOST_HOME/bin\
:$XINE_HOME/bin\
:$XEMACS_HOME/bin\
:$JAVA_HOME/bin\
:$NETBEANS_HOME/bin\
:$JBUILDER_HOME/bin\
:/opt/gnome/bin


Select the region, and hit tab, and you no longer have a valid PATH.  You may 
ask why I don't just treat PATH as a string using '"'s.  The answer is that 
Emacs gives me an indication that the '\' really is the end of the line, and 
there are no non-printing characters hiding there.

Also, I have to defend my use of a single space in my previous example.

#!/bin/bash
pushd /download/org/gnu/emacs/emacs &&\
 cvs update -dPAC &&\
 pushd /download/org/gnu/emacs/emacs-build &&\
 make clean &&\
 ../emacs/configure --prefix=$GNU_EMACS &&\
 make -j8 &&\
 pushd lisp &&\
 make recompile EMACS=../src/emacs &&\
 popd &&\
 make install &&\
 popd

That says exactly what it should say.  I'm really not to concerned about the 
preservation of the space when I hit tab in this case.  I can live with the 
functionality I get with indent by 0.  if I really want to preserve the space 
I can simply put it before the '\' on the previous line.  That way all the 
continuation is left justified.  When I said the '\' is used to improve human 
readability, I did not intend to distinguish between my chosen form of 
expression, and 

#!/bin/bash
pushd /download/org/gnu/emacs/emacs &&\
    cvs update -dPAC &&\
    pushd /download/org/gnu/emacs/emacs-build &&\
    make clean &&\
    ../emacs/configure --prefix=$GNU_EMACS &&\
    make -j8 &&\
    pushd lisp &&\
    make recompile EMACS=../src/emacs &&\
    popd &&\
    make install &&\
    popd

I meant to distinguish between either of these and:
<word-wrap-off>
#!/bin/bash
pushd /download/org/gnu/emacs/emacs && cvs update -dPAC && 
pushd /download/org/gnu/emacs/emacs-build && make clean && ../emacs/configure 
--prefix=$GNU_EMACS && make -j8 && pushd lisp && make recompile 
EMACS=../src/emacs && popd && make install && popd
</word-wrap-off>

I find it utterly annoying when I encounter that kind of file format.

This horse is in critical, if not already dead.  I believe an option to leave 
a continuation untouched to be worth considering. For my purposes, the 
current default (which, until recently, was not the behavior of Emacs on my 
system) is inappropriate. The advantage to having some kind of indentation is 
evident in a case such as this:

#!/bin/bash
function silly
{
    test -d $PWD \
    && echo "$PWD is here" \
    || echo "$PWD is not here" \;
}

That, of course, will break my PATH example if it were put into a non-global 
block.
...
> 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.

This whole discussion got started because the behavior on my system changed, 
and I was under the impression that was due to a recent change in Emacs.  
After thinking things over, I now realize the value of a 'do nothing' option 
may be fairly limited.  The default '+' option is not the behavior I want, 
and seems mildly incorrect, but I can certainly live with it.  Ironically, 
had that been the behavior of Emacs on my system in the past, I probably 
would never have suspected I could change it to '0'.
-- 
Regards,
Steven