* bug#35647: Documentation and implementation of (move-to-column <n> t) differ. @ 2019-05-09 10:48 Alan Mackenzie 2019-05-09 14:04 ` Eli Zaretskii 0 siblings, 1 reply; 5+ messages in thread From: Alan Mackenzie @ 2019-05-09 10:48 UTC (permalink / raw) To: 35647 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). ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#35647: Documentation and implementation of (move-to-column <n> t) differ. 2019-05-09 10:48 bug#35647: Documentation and implementation of (move-to-column <n> t) differ Alan Mackenzie @ 2019-05-09 14:04 ` Eli Zaretskii 2019-05-09 15:05 ` Alan Mackenzie 0 siblings, 1 reply; 5+ messages in thread From: Eli Zaretskii @ 2019-05-09 14:04 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 35647 > 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#35647: Documentation and implementation of (move-to-column <n> t) differ. 2019-05-09 14:04 ` Eli Zaretskii @ 2019-05-09 15:05 ` Alan Mackenzie 2019-05-09 15:43 ` Eli Zaretskii 0 siblings, 1 reply; 5+ messages in thread From: Alan Mackenzie @ 2019-05-09 15:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 35647 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). ^ permalink raw reply related [flat|nested] 5+ messages in thread
* bug#35647: Documentation and implementation of (move-to-column <n> t) differ. 2019-05-09 15:05 ` Alan Mackenzie @ 2019-05-09 15:43 ` Eli Zaretskii 2019-05-09 16:32 ` Alan Mackenzie 0 siblings, 1 reply; 5+ messages in thread From: Eli Zaretskii @ 2019-05-09 15:43 UTC (permalink / raw) To: Alan Mackenzie; +Cc: 35647 > 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#35647: Documentation and implementation of (move-to-column <n> t) differ. 2019-05-09 15:43 ` Eli Zaretskii @ 2019-05-09 16:32 ` Alan Mackenzie 0 siblings, 0 replies; 5+ messages in thread From: Alan Mackenzie @ 2019-05-09 16:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 35647-done 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). ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-05-09 16:32 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-05-09 10:48 bug#35647: Documentation and implementation of (move-to-column <n> t) differ Alan Mackenzie 2019-05-09 14:04 ` Eli Zaretskii 2019-05-09 15:05 ` Alan Mackenzie 2019-05-09 15:43 ` Eli Zaretskii 2019-05-09 16:32 ` Alan Mackenzie
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).