bug#35647: Documentation and implementation of (move-to-column <n> t) differ.

bug#35647: Documentation and implementation of (move-to-column <n> t) differ.

[Alan Mackenzie]

Hello, Emacs.

In (move-to-column <n> t), the t argument, FORCE, "replaces the tab with
spaces" if it needs to do so to get exactly to column <n> which is in
the middle of a tab.

At least, that's what the documentation says.

In the implementation, when indent-tabs-mode is non-nil, Emacs _inserts_
spaces before the tab to get to column <n>, rather than replacing the
tab with spaces.

This discrepancy is a bug.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

What the code in Fmove_to_column actually does is to delete the tab,
insert enough spaces to get to column <n>, then calls Findent_to to
finish the indentation to <n>.  Findent_to uses a tab when
indent-tabs-mode is non-nil.

My feeling here is that the documentation rather than the code should be
amended.  To amend the code would make it more difficult for
uncomment-region to restore a tab character which has been earlier
manipulated by comment-region.  (See also bug #35600.)

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#35647: Documentation and implementation of (move-to-column <n> t) differ.

[Eli Zaretskii]

> Date: Thu, 9 May 2019 10:48:50 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> What the code in Fmove_to_column actually does is to delete the tab,
> insert enough spaces to get to column <n>, then calls Findent_to to
> finish the indentation to <n>.  Findent_to uses a tab when
> indent-tabs-mode is non-nil.
> 
> My feeling here is that the documentation rather than the code should be
> amended.  To amend the code would make it more difficult for
> uncomment-region to restore a tab character which has been earlier
> manipulated by comment-region.  (See also bug #35600.)

Would you mind preparing a documentation patch for this issue?

Thanks.

bug#35647: Documentation and implementation of (move-to-column <n> t) differ.

[Alan Mackenzie]

Hello, Eli.

On Thu, May 09, 2019 at 17:04:19 +0300, Eli Zaretskii wrote:
> > Date: Thu, 9 May 2019 10:48:50 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > What the code in Fmove_to_column actually does is to delete the tab,
> > insert enough spaces to get to column <n>, then calls Findent_to to
> > finish the indentation to <n>.  Findent_to uses a tab when
> > indent-tabs-mode is non-nil.

> > My feeling here is that the documentation rather than the code should be
> > amended.  To amend the code would make it more difficult for
> > uncomment-region to restore a tab character which has been earlier
> > manipulated by comment-region.  (See also bug #35600.)

> Would you mind preparing a documentation patch for this issue?

How about:


diff --git a/doc/lispref/text.texi b/doc/lispref/text.texi
index 500df1f8f0..278bc3c268 100644
--- a/doc/lispref/text.texi
+++ b/doc/lispref/text.texi
@@ -2252,9 +2252,11 @@ Columns
 the middle of a multicolumn character such as a tab, point moves to the
 end of that character.  However, if @var{force} is non-@code{nil}, and
 @var{column} is in the middle of a tab, then @code{move-to-column}
-converts the tab into spaces so that it can move precisely to column
-@var{column}.  Other multicolumn characters can cause anomalies despite
-@var{force}, since there is no way to split them.
+either converts the tab into spaces (when @code{indent-tabs-mode} is
+@code{nil}), or inserts enough spaces before it (otherwise), so that
+point can move precisely to column @var{column}.  Other multicolumn
+characters can cause anomalies despite @var{force}, since there is no
+way to split them.
 
 The argument @var{force} also has an effect if the line isn't long
 enough to reach column @var{column}; if it is @code{t}, that means to
diff --git a/src/indent.c b/src/indent.c
index c76e6b7b4b..90d8b1ce8e 100644
--- a/src/indent.c
+++ b/src/indent.c
@@ -983,9 +983,10 @@ If specified column is within a character, point goes after that character.
 If it's past end of line, point goes to end of line.
 
 Optional second argument FORCE non-nil means if COLUMN is in the
-middle of a tab character, change it to spaces.
-In addition, if FORCE is t, and the line is too short to reach
-COLUMN, add spaces/tabs to get there.
+middle of a tab character, either change it to spaces (when
+`indent-tabs-mode' is nil), or insert enough spaces before it to reach
+COLUMN (otherwise).  In addition, if FORCE is t, and the line is too short
+to reach COLUMN, add spaces/tabs to get there.
 
 The return value is the current column.  */)
   (Lisp_Object column, Lisp_Object force)


?

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#35647: Documentation and implementation of (move-to-column <n> t) differ.

[Eli Zaretskii]

> Date: Thu, 9 May 2019 15:05:37 +0000
> Cc: 35647@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Would you mind preparing a documentation patch for this issue?
> 
> How about:

Fine with me, thanks.

Please push to the emacs-26 branch.

bug#35647: Documentation and implementation of (move-to-column <n> t) differ.

[Alan Mackenzie]

Hello, Eli.

On Thu, May 09, 2019 at 18:43:06 +0300, Eli Zaretskii wrote:
> > Date: Thu, 9 May 2019 15:05:37 +0000
> > Cc: 35647@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > Would you mind preparing a documentation patch for this issue?

> > How about:

> Fine with me, thanks.

:-)

> Please push to the emacs-26 branch.

DONE.

I'm closing the bug.

-- 
Alan Mackenzie (Nuremberg, Germany).