GNU bug report logs - #24766
26.0.50: [PATCH] Confusing behaviour for indent-relative-maybe

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 24766 in the body.
You can then email your comments to 24766 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.0.50: [PATCH] Confusing behaviour for indent-relative-maybe
Date: Sat, 22 Oct 2016 13:01:15 -0600

[Message part 1 (text/plain, inline)]

In emacs -Q's scratch buffer, try the following:

M-: (indent-relative) RET

Repeating this will move to the next appropriate indentation point as
indicated in indent-relative's docstring.

Now try:

M-: (indent-relative-maybe) RET

The point does not move even when there are appropriate indentation
points to move to. This contradicts the intention of the docstring for
indent-relative-maybe:

       If the previous nonblank line has no indent points beyond the
       column point starts at, this command does nothing.


I would have expected, in indent-relative, that the calculation of a
suitable indentation position is done independent of the argument
UNINDENTED-OK. The following diff fixes this:

[indent.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

Apparently this stems from the initial revision of indent.el. Am I just
misinterpreting this function's purpose, or has it been wrong this whole
time?

Message #8 received at 24766 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 24766 <at> debbugs.gnu.org
Subject: Re: bug#24766: 26.0.50: [PATCH] Confusing behaviour for
 indent-relative-maybe
Date: Sat, 22 Oct 2016 22:21:51 +0300

> From: Alex <agrambot <at> gmail.com>
> Date: Sat, 22 Oct 2016 13:01:15 -0600
> 
> In emacs -Q's scratch buffer, try the following:
> 
> M-: (indent-relative) RET
> 
> Repeating this will move to the next appropriate indentation point as
> indicated in indent-relative's docstring.
> 
> Now try:
> 
> M-: (indent-relative-maybe) RET
> 
> The point does not move even when there are appropriate indentation
> points to move to.

It doesn't move because that's what UNINDENTED-OK means.

> This contradicts the intention of the docstring for
> indent-relative-maybe:
> 
>        If the previous nonblank line has no indent points beyond the
>        column point starts at, this command does nothing.
> 
> 
> I would have expected, in indent-relative, that the calculation of a
> suitable indentation position is done independent of the argument
> UNINDENTED-OK. The following diff fixes this:

These functions exist for ages in this form.  I agree that the doc
string is misleading (and the optional argument of indent-relative is
not even documented), but other than fixing the documentation, I see
no reason to change the behavior.  Am I missing something?

Message #11 received at 24766 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24766 <at> debbugs.gnu.org
Subject: Re: bug#24766: 26.0.50: [PATCH] Confusing behaviour for
 indent-relative-maybe
Date: Sat, 22 Oct 2016 13:40:57 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Alex <agrambot <at> gmail.com>
>> Date: Sat, 22 Oct 2016 13:01:15 -0600
>> 
>> In emacs -Q's scratch buffer, try the following:
>> 
>> M-: (indent-relative) RET
>> 
>> Repeating this will move to the next appropriate indentation point as
>> indicated in indent-relative's docstring.
>> 
>> Now try:
>> 
>> M-: (indent-relative-maybe) RET
>> 
>> The point does not move even when there are appropriate indentation
>> points to move to.
>
> It doesn't move because that's what UNINDENTED-OK means.

I took UNINTENDED-OK to mean that "if non-nil, nothing is done in the
case that there are no appropriate indentation positions. If there are
appropriate indentation positions, then it should indent as usual."

The docstring could be improved to state that.

>> This contradicts the intention of the docstring for
>> indent-relative-maybe:
>> 
>>        If the previous nonblank line has no indent points beyond the
>>        column point starts at, this command does nothing.
>> 
>> 
>> I would have expected, in indent-relative, that the calculation of a
>> suitable indentation position is done independent of the argument
>> UNINDENTED-OK. The following diff fixes this:
>
> These functions exist for ages in this form.  I agree that the doc
> string is misleading (and the optional argument of indent-relative is
> not even documented),

The optional argument is implicitly mentioned as "unless
this command is invoked with a numeric argument, in which case it
does nothing."

> but other than fixing the documentation, I see
> no reason to change the behavior.  Am I missing something?

IIUC the current behaviour essentially makes indent-relative-maybe a
no-op. But again, perhaps there's something I'm missing?

Message #14 received at 24766 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 24766 <at> debbugs.gnu.org
Subject: Re: bug#24766: 26.0.50: [PATCH] Confusing behaviour for
 indent-relative-maybe
Date: Sat, 22 Oct 2016 22:48:32 +0300

> From: Alex <agrambot <at> gmail.com>
> Cc: 24766 <at> debbugs.gnu.org
> Date: Sat, 22 Oct 2016 13:40:57 -0600
> 
> >> The point does not move even when there are appropriate indentation
> >> points to move to.
> >
> > It doesn't move because that's what UNINDENTED-OK means.
> 
> I took UNINTENDED-OK to mean that "if non-nil, nothing is done in the
> case that there are no appropriate indentation positions. If there are
> appropriate indentation positions, then it should indent as usual."
> 
> The docstring could be improved to state that.

Definitely.  Would you like to give it a try?

> The optional argument is implicitly mentioned as "unless
> this command is invoked with a numeric argument, in which case it
> does nothing."

Well, that's not how we document such functions, right?  Both the
effect of the argument, when used from Lisp, and the fact that it's
the prefix argument in interactive invocation, should be stated.

> > but other than fixing the documentation, I see
> > no reason to change the behavior.  Am I missing something?
> 
> IIUC the current behaviour essentially makes indent-relative-maybe a
> no-op.

No, it's definitely not a no-op.  It is only a no-op if the previous
non-blank line has no white space at its beginning, or the current
column is already past that first indentation point.  IOW,
indent-relative-maybe only ever indents to the first indentation
point, and only when that indentation point is preceded by whitespace.

Message #17 received at 24766 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24766 <at> debbugs.gnu.org
Subject: Re: bug#24766: 26.0.50: [PATCH] Confusing behaviour for
 indent-relative-maybe
Date: Sat, 22 Oct 2016 15:49:57 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Alex <agrambot <at> gmail.com>
>> Cc: 24766 <at> debbugs.gnu.org
>> Date: Sat, 22 Oct 2016 13:40:57 -0600
>> 
>> >> The point does not move even when there are appropriate indentation
>> >> points to move to.
>> >
>> > It doesn't move because that's what UNINDENTED-OK means.
>> 
>> I took UNINTENDED-OK to mean that "if non-nil, nothing is done in the
>> case that there are no appropriate indentation positions. If there are
>> appropriate indentation positions, then it should indent as usual."
>> 
>> The docstring could be improved to state that.
>
> Definitely.  Would you like to give it a try?

Sure. That would describe the behaviour that my diff brings -- does that
mean that you're okay with the proposed change?

>> The optional argument is implicitly mentioned as "unless
>> this command is invoked with a numeric argument, in which case it
>> does nothing."
>
> Well, that's not how we document such functions, right?  Both the
> effect of the argument, when used from Lisp, and the fact that it's
> the prefix argument in interactive invocation, should be stated.

Indeed. Though it seems, according to commit
1fd63d9b9bc249488ec12a49cc3a576baf8c788a, that you were the one to
document it. ;-)

>> > but other than fixing the documentation, I see
>> > no reason to change the behavior.  Am I missing something?
>> 
>> IIUC the current behaviour essentially makes indent-relative-maybe a
>> no-op.
>
> No, it's definitely not a no-op.  It is only a no-op if the previous
> non-blank line has no white space at its beginning, or the current
> column is already past that first indentation point.  IOW,
> indent-relative-maybe only ever indents to the first indentation
> point, and only when that indentation point is preceded by whitespace.

Oh, I see. Sorry about missing that. For some reason I was only testing
lines that started with non-whitespace.

I feel more hesitant to change such old behaviour now, but I still think
that it should be done. Here are the functions that call
indent-relative-maybe or call indent-relative with an argument:

* add-change-log-entry
* mh-letter-next-header-field-or-indent
* A few functions in AUCTeX (ELPA)

I'm not sure if they should be changed, but if they should, a new
function could be made to match the previous indent-relative-maybe
behaviour:

(let ((first-indent (save-excursion
                      (re-search-backward "^[^\n]")
                      (backward-to-indentation 0))))
  (when (< (current-column)
           first-indent)
    (indent-to first-indent)))

Message #20 received at 24766 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 24766 <at> debbugs.gnu.org
Subject: Re: bug#24766: 26.0.50: [PATCH] Confusing behaviour for
 indent-relative-maybe
Date: Sun, 23 Oct 2016 09:23:45 +0300

> From: Alex <agrambot <at> gmail.com>
> Cc: 24766 <at> debbugs.gnu.org
> Date: Sat, 22 Oct 2016 15:49:57 -0600
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> I took UNINTENDED-OK to mean that "if non-nil, nothing is done in the
> >> case that there are no appropriate indentation positions. If there are
> >> appropriate indentation positions, then it should indent as usual."
> >> 
> >> The docstring could be improved to state that.
> >
> > Definitely.  Would you like to give it a try?
> 
> Sure. That would describe the behaviour that my diff brings -- does that
> mean that you're okay with the proposed change?

No, I meant to improve the doc string to describe the current
behavior.

> >> The optional argument is implicitly mentioned as "unless
> >> this command is invoked with a numeric argument, in which case it
> >> does nothing."
> >
> > Well, that's not how we document such functions, right?  Both the
> > effect of the argument, when used from Lisp, and the fact that it's
> > the prefix argument in interactive invocation, should be stated.
> 
> Indeed. Though it seems, according to commit
> 1fd63d9b9bc249488ec12a49cc3a576baf8c788a, that you were the one to
> document it. ;-)

Yes, but my change just described one subtlety of that function, it
didn't change anything about the rest.  Most probably I bumped into
the aspect of the behavior I described, and found it not documented at
all.

> > No, it's definitely not a no-op.  It is only a no-op if the previous
> > non-blank line has no white space at its beginning, or the current
> > column is already past that first indentation point.  IOW,
> > indent-relative-maybe only ever indents to the first indentation
> > point, and only when that indentation point is preceded by whitespace.
> 
> Oh, I see. Sorry about missing that. For some reason I was only testing
> lines that started with non-whitespace.
> 
> I feel more hesitant to change such old behaviour now, but I still think
> that it should be done. Here are the functions that call
> indent-relative-maybe or call indent-relative with an argument:
> 
> * add-change-log-entry
> * mh-letter-next-header-field-or-indent
> * A few functions in AUCTeX (ELPA)
> 
> I'm not sure if they should be changed, but if they should, a new
> function could be made to match the previous indent-relative-maybe
> behaviour:
> 
> (let ((first-indent (save-excursion
>                       (re-search-backward "^[^\n]")
>                       (backward-to-indentation 0))))
>   (when (< (current-column)
>            first-indent)
>     (indent-to first-indent)))

Like I said, I don't think the behavior should be changed, only the
documentation, which is somewhat misleading.  If we want some
different behavior, we could have a new function, or a new value of
the argument to indent-relative.

Thanks.

Message #23 received at 24766 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24766 <at> debbugs.gnu.org
Subject: Re: bug#24766: 26.0.50: [PATCH] Confusing behaviour for
 indent-relative-maybe
Date: Sun, 23 Oct 2016 14:43:57 -0600

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> Like I said, I don't think the behavior should be changed, only the
> documentation, which is somewhat misleading.  If we want some
> different behavior, we could have a new function, or a new value of
> the argument to indent-relative.
>
> Thanks.

What about changing `indent-relative-maybe' and adding an extra argument
to `indent-relative'? Since `indent-relative-maybe' has had that
docstring for a good 15 years, and the name fits the new behaviour more.

Then in Emacs core we can replace the single instance of it with
(indent-relative t). The corresponding diff:

[indent2.patch (text/x-diff, inline)]

diff --git a/lisp/indent.el b/lisp/indent.el
index 0f6c68d..675b6b8 100644
--- a/lisp/indent.el
+++ b/lisp/indent.el
@@ -566,9 +566,9 @@ indent-relative-maybe
 
 See also `indent-relative'."
   (interactive)
-  (indent-relative t))
+  (indent-relative nil t))
 
-(defun indent-relative (&optional unindented-ok)
+(defun indent-relative (&optional first-only unindented-ok)
   "Space out to under next indent point in previous nonblank line.
 An indent point is a non-whitespace character following whitespace.
 The following line shows the indentation points in this line.
@@ -594,17 +594,18 @@ indent-relative
 	    (if (> (current-column) start-column)
 		(backward-char 1))
 	    (or (looking-at "[ \t]")
-		unindented-ok
+		first-only
 		(skip-chars-forward "^ \t" end))
 	    (skip-chars-forward " \t" end)
 	    (or (= (point) end) (setq indent (current-column))))))
-    (if indent
-	(let ((opoint (point-marker)))
-	  (indent-to indent 0)
-	  (if (> opoint (point))
-	      (goto-char opoint))
-	  (move-marker opoint nil))
-      (tab-to-tab-stop))))
+    (cond (indent
+           (let ((opoint (point-marker)))
+             (indent-to indent 0)
+             (if (> opoint (point))
+                 (goto-char opoint))
+             (move-marker opoint nil)))
+          (unindented-ok nil)
+          (t (tab-to-tab-stop)))))
 
 (defcustom tab-stop-list nil
   "List of tab stop positions used by `tab-to-tab-stop'.

Message #26 received at 24766 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 24766 <at> debbugs.gnu.org
Subject: Re: bug#24766: 26.0.50: [PATCH] Confusing behaviour for
 indent-relative-maybe
Date: Mon, 24 Oct 2016 11:23:22 +0300

> From: Alex <agrambot <at> gmail.com>
> Cc: 24766 <at> debbugs.gnu.org
> Date: Sun, 23 Oct 2016 14:43:57 -0600
> 
> What about changing `indent-relative-maybe' and adding an extra argument
> to `indent-relative'? Since `indent-relative-maybe' has had that
> docstring for a good 15 years, and the name fits the new behaviour more.
> 
> Then in Emacs core we can replace the single instance of it with
> (indent-relative t). The corresponding diff:

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.

Also, please add the necessary text to the doc string to document the
new argument.

Thanks.

Message #29 received at 24766 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24766 <at> debbugs.gnu.org
Subject: Re: bug#24766: 26.0.50: [PATCH] Confusing behaviour for
 indent-relative-maybe
Date: Mon, 24 Oct 2016 13:27:43 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Alex <agrambot <at> gmail.com>
>> Cc: 24766 <at> debbugs.gnu.org
>> Date: Sun, 23 Oct 2016 14:43:57 -0600
>> 
>> What about changing `indent-relative-maybe' and adding an extra argument
>> to `indent-relative'? Since `indent-relative-maybe' has had that
>> docstring for a good 15 years, and the name fits the new behaviour more.
>> 
>> Then in Emacs core we can replace the single instance of it with
>> (indent-relative t). The corresponding diff:
>
> 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?

> Also, please add the necessary text to the doc string to document the
> new argument.

Sure, I'll do that once the code changes are agreed upon.

> Thanks.

Message #32 received at 24766 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 24766 <at> debbugs.gnu.org
Subject: Re: bug#24766: 26.0.50: [PATCH] Confusing behaviour for
 indent-relative-maybe
Date: Mon, 24 Oct 2016 22:57:43 +0300

> From: Alex <agrambot <at> gmail.com>
> Cc: 24766 <at> 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.

Message #35 received at 24766 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24766 <at> debbugs.gnu.org
Subject: Re: bug#24766: 26.0.50: [PATCH] Confusing behaviour for
 indent-relative-maybe
Date: Mon, 07 Nov 2016 19:53:22 -0600

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Alex <agrambot <at> gmail.com>
>> Cc: 24766 <at> 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 (text/x-diff, attachment)]

Message #38 received at 24766 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 24766 <at> debbugs.gnu.org
Subject: Re: bug#24766: 26.0.50: [PATCH] Confusing behaviour for
 indent-relative-maybe
Date: Tue, 08 Nov 2016 17:07:25 +0200

> From: Alex <agrambot <at> gmail.com>
> Cc: 24766 <at> debbugs.gnu.org
> Date: Mon, 07 Nov 2016 19:53:22 -0600
> 
> 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.

Thanks, this is fine, except that the new function's name should be
better as indent-relative-first-indent-point or somesuch.

Message #41 received at 24766 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24766 <at> debbugs.gnu.org
Subject: Re: bug#24766: 26.0.50: [PATCH] Confusing behaviour for
 indent-relative-maybe
Date: Tue, 08 Nov 2016 13:09:42 -0600

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> Thanks, this is fine, except that the new function's name should be
> better as indent-relative-first-indent-point or somesuch.

That name does better describe how (indent-relative t) works, but I
figured that indent-relative-whitespace is a better name for what people
seem to use it for (indent according to the whitespace on the previous
nonblank line).

Though if you still disagree then `indent-relative-first-indent-point'
seems fine (if not a bit long).

I suppose this diff goes over the accepted limit for non-assigned
submissions? I mailed my copyright forms about a month ago but
unfortunately the FSF hasn't informed me that the process is complete
yet.

[indent4.diff (text/x-diff, attachment)]

Message #44 received at 24766 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 24766 <at> debbugs.gnu.org
Subject: Re: bug#24766: 26.0.50: [PATCH] Confusing behaviour for
 indent-relative-maybe
Date: Tue, 08 Nov 2016 22:26:22 +0200

> From: Alex <agrambot <at> gmail.com>
> Cc: 24766 <at> debbugs.gnu.org
> Date: Tue, 08 Nov 2016 13:09:42 -0600
> 
> I suppose this diff goes over the accepted limit for non-assigned
> submissions? I mailed my copyright forms about a month ago but
> unfortunately the FSF hasn't informed me that the process is complete
> yet.

Please ping them.

Message #47 received at 24766 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 24766 <at> debbugs.gnu.org
Subject: Re: bug#24766: 26.0.50: [PATCH] Confusing behaviour for
 indent-relative-maybe
Date: Fri, 18 Nov 2016 11:04:49 +0200

> From: Alex <agrambot <at> gmail.com>
> Cc: 24766 <at> debbugs.gnu.org
> Date: Tue, 08 Nov 2016 13:09:42 -0600
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Thanks, this is fine, except that the new function's name should be
> > better as indent-relative-first-indent-point or somesuch.
> 
> That name does better describe how (indent-relative t) works, but I
> figured that indent-relative-whitespace is a better name for what people
> seem to use it for (indent according to the whitespace on the previous
> nonblank line).

Thanks, pushed to the master branch.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.