[PATCH] lisp: improve indentation rule for else

[Wolf]

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;
}
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++;
--
2.36.2

[Wolf]

> 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.

[ben.k...@gmail.com]

On Tuesday, October 11, 2022 at 4:58:02 AM UTC-4 Wolf wrote:

Currently else is indented like this:

(cond (else
foo)) 

That does not match typical indentation used, which would be:

(cond (else
foo))

(Using the groups.google client) I cannot see the difference; probably some leading spaces were eaten.

Can you show the difference in such a way that the spaces are not eaten?

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.

What if (I can't think of a specific Lisp for which this is true, but bare with me) "(else" should not be handled this way for a filetype? Then you would have to go to extra lengths to make that work (since you say "mostly […] restored"). As a bizarre but possible example, consider defining "else" as a function; now calls to it trigger this special case, when they shouldn't.