bug#34858: indent-relative called with prefix calls tab-to-tab-stop

[Basil L. Contovounesios]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "Basil L. Contovounesios" <contovob@tcd.ie>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  34858@debbugs.gnu.org
>> Date: Tue, 02 Apr 2019 01:11:57 +0100
>> 
>> > OK, patch attached. While looking over this I noticed the lisp reference
>> > manual also needed to be updated a bit so I did that as well.
>> 
>> I think some code needs updating in addition to the Elisp manual:
>
> Fine with me, thanks.
>
>> I think the changes pertaining to the move from indent-relative-maybe to
>> indent-relative-first-indent-point should be pushed independently of any
>> changes to the behaviour of indent-relative at BOB or its documentation.
>> 
>> Can they be pushed to master, and only backported to emacs-26 as
>> needed/applicable?
>
> Yes.

Thanks, pushed to master.  Alex, can you also please push your docfixes
for the Elisp manual?

> Please note that the emacs-26 branch is currently frozen, as we will
> probably release Emacs 26.2 soon.

Right, that's what I was alluding to when I said "as needed/applicable".

>> > -@var{unindented-ok} argument.  The return value is unpredictable.
>> > +@var{first-only} argument.  The return value is unpredictable.
>> 
>> Just curious: is there any preference between "unpredictable" and
>> "undefined" for documenting return values?  If so, why?
>
> I actually don't understand why this sentence should be there at all.
> IMO, it isn't useful to say that the return value is undefined, better
> not to say anything (which has the same meaning, but avoids the
> possible interpretation that other doc strings, which don't say that,
> imply otherwise).

Seconded.

>> > --- a/lisp/indent.el
>> > +++ b/lisp/indent.el
>> > @@ -598,8 +598,8 @@ considered.
>> >  
>> >  If the previous nonblank line has no indent points beyond the
>> >  column point starts at, then `tab-to-tab-stop' is done, if both
>> > -FIRST-ONLY and UNINDENTED-OK are nil, otherwise nothing is done
>> > -in this case.
>> > +FIRST-ONLY and UNINDENTED-OK are nil, otherwise nothing is done.
>> > +If there isn't a previous nonblank line, call `tab-to-tab-stop'.
>> 
>> I'm not against spelling this final sentence out, but in my reading it's
>> already covered by the first sentence, as a non-existent line vacuously
>> "has no indent points beyond the column point starts at". ;)
>
> Adding that was the main purpose of the changeset, as at least one
> person wasn't sure your interpretation is so clearly implied.

Right.

Thanks,

-- 
Basil