[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#24766: 26.0.50: [PATCH] Confusing behaviour for indent-relative-mayb
From: |
Alex |
Subject: |
bug#24766: 26.0.50: [PATCH] Confusing behaviour for indent-relative-maybe |
Date: |
Mon, 07 Nov 2016 19:53:22 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Alex <agrambot@gmail.com>
>> Cc: 24766@debbugs.gnu.org
>> Date: Mon, 24 Oct 2016 13:27:43 -0600
>>
>> > I'd prefer a backward-compatible change, i.e. make the new argument be
>> > the 2nd one, and keep the current behavior when the 1st arg is non-nil
>> > and the 2nd is nil or omitted.
>>
>> That's what I did, but I used a new name for the old argument and the
>> old name for the new argument. I did so as the old name fits the new
>> behaviour more.
>>
>> This is a backward-compatible change for indent-relative, but it does
>> use the new behaviour for indent-relative-maybe. Is that alright with
>> you?
>
> Yes, thanks.
Sorry for the delay.
After thinking about it some more, and after properly searching on
Github for `indent-relative-maybe', I'm not sure if my previous solution
is the best one now. I found that due to some blog posts and starter kit
configurations, a surprising amount of people use indent-relative-maybe
despite docstring claiming different functionality.
I now think the following should happen:
1) indent-relative-maybe's should be obsoleted in
favour of a name suiting the purpose (e.g. indent-relative-whitespace)
with a better docstring.
2) The docstring and second optional argument should be added as
discussed before.
3) Perhaps in the future a new function can be introduced that
automatically calls (indent-relative nil t), but I'm not sure if that
should be done now. To be honest, I lost my original reason that made me
interested in this function.
Anyway, I've attached a diff that addresses this new proposal.
indent3-2.diff
Description: 3rd time
- bug#24766: 26.0.50: [PATCH] Confusing behaviour for indent-relative-maybe,
Alex <=