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

[Eli Zaretskii]

> 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.  Please note that the emacs-26 branch is currently frozen, as we
will probably release Emacs 26.2 soon.

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

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