GNU bug report logs -
#34858
indent-relative called with prefix calls tab-to-tab-stop
Previous Next
Full log
View this message in rfc822 format
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Alex <agrambot <at> gmail.com>
>> Cc: Alex Branham <alex.branham <at> gmail.com>, 34858 <at> debbugs.gnu.org
>> Date: Thu, 14 Mar 2019 10:45:32 -0600
>> >
>> > I think this is a documentation bug, as it doesn't describe the
>> > special case of "no previous nonblank line".
>>
>> I believe that the case of "no previous nonblank line" could be
>> considered as there being a single indent point at column 0, so if
>> FIRST-ONLY is non-nil, then `tab-to-tab-stop' shouldn't be called. How
>> about the following patch instead?
>
> I don't understand what you are saying here. The doc string says "no
> indent point _beyond_" the column where point starts, so assuming a
> single indent point at column zero doesn't change anything.
Sorry, I wasn't clear. I meant that the special case here could be
considered (trivially) equivalent to the case where the previous
non-blank line has a single indent point at column zero, and therefore
should be treated equivalently when FIRST-ONLY is non-nil
(`tab-to-tab-stop` should not be called if on or past the first indent
point, i.e., column 0).
The usage of `beyond' does not change the behaviour when the starting
column is on the first indent point, which outside of this special case
is doing nothing. Specifically, the `indent' branch of the cond is
normally executed when FIRST-ONLY is non-nil because `indent' is set
within the `re-search-backward' conditional to be equal to the starting
column; however, in this special case, `re-search-backward' returns nil
and so `indent' remains nil. My patch covers this case by also checking
for FIRST-ONLY in the cond.
This bug report was last modified 6 years and 50 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.