On 2022-10-11 11:39:07 +0100, Bram Moolenaar wrote:
> 
> > Currently else is indented like this:
> > 
> >   (cond (else
> >           foo))
> > 
> > That does not match typical indentation used, which would be:
> > 
> >   (cond (else
> >          foo))
> > 
> > This commit special-cases "(else" to indent like it would be expected to
> > indent. It also tweaks lisp_match to accept not only "(else ", but also
> > "(else\x00". That means that old behaviour can mostly be restored by
> > adding "else" into lispwords.
> > ---
> > If you are not willing to accept this change in behavior, I can try to
> > make it configurable. Currently I do not know of a way to work around
> > this in .vimrc, so code change seems necessary, but (if desired), I can
> > send another patch that keeps the default behavior and only makes this
> > opt-in.
> > 
> >  src/indent.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/src/indent.c b/src/indent.c
> > index 95fc74ee4..8e21f20ce 100644
> > --- a/src/indent.c
> > +++ b/src/indent.c
> > @@ -1907,7 +1907,7 @@ lisp_match(char_u *p)
> >      {
> >     (void)copy_option_part(&word, buf, LSIZE, ",");
> >     len = (int)STRLEN(buf);
> > -   if (STRNCMP(buf, p, len) == 0 && p[len] == ' ')
> > +   if (STRNCMP(buf, p, len) == 0 && (p[len] == ' ' || !p[len]))
> >         return TRUE;
> 
> This makes a lot of sense.  How can we test the effect?  The example
> above does not appear to be affected.  The lispwords test doesn't fail.

Right, this change is technically not necessary for what I want to do
(changing the indent of consequent from 2 to 1). But while I cannot
imagine why someone would want the original behavior (indent of 2), I
still think it would be nice to have an option to restore it.

That can be done by lw+=else, however original code here does not handle
else\x00 (else\x20 does work, but having to put the space there is
annoying). Therefore this change.

> Perhaps IS_WHITE_OR_NUL() should be used here.

I did not know this is a thing, should I send a version 2 of the patch
or is it faster for you to change on your end? I've tested locally that
it seems to work.

> >      }
> >      return FALSE;
> > @@ -2039,6 +2039,8 @@ get_lisp_indent(void)
> >             if (!vi_lisp && (*that == '(' || *that == '[')
> >                                                   && lisp_match(that + 1))
> >                 amount += 2;
> > +           else if (!vi_lisp && STRICMP(that, "(else") == 0)
> > +               amount += 1;
> >             else
> >             {
> >                 that++;
> 
> Is the example at the top a good test for this change?  Does it affect
> other situations?

Yes, I think it is a good example. I've tried it on few pieces of
guile's source code and it seems to work even on more complex ones. I'm
not aware of any side effects.

W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/Y0ae1GS9DhSUDda9%40ws.

Attachment: signature.asc
Description: PGP signature

Raspunde prin e-mail lui