GNU bug report logs - #24766
26.0.50: [PATCH] Confusing behaviour for indent-relative-maybe

Previous Next

Package: emacs;

Reported by: Alex <agrambot <at> gmail.com>

Date: Sat, 22 Oct 2016 19:02:01 UTC

Severity: minor

Tags: fixed, patch

Found in version 26.0.50

Fixed in version 26.1

Done: npostavs <at> users.sourceforge.net

Bug is archived. No further changes may be made.

Full log


Message #8 received at 24766 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 24766 <at> debbugs.gnu.org
Subject: Re: bug#24766: 26.0.50: [PATCH] Confusing behaviour for
 indent-relative-maybe
Date: Sat, 22 Oct 2016 22:21:51 +0300
> From: Alex <agrambot <at> gmail.com>
> Date: Sat, 22 Oct 2016 13:01:15 -0600
> 
> In emacs -Q's scratch buffer, try the following:
> 
> M-: (indent-relative) RET
> 
> Repeating this will move to the next appropriate indentation point as
> indicated in indent-relative's docstring.
> 
> Now try:
> 
> M-: (indent-relative-maybe) RET
> 
> The point does not move even when there are appropriate indentation
> points to move to.

It doesn't move because that's what UNINDENTED-OK means.

> This contradicts the intention of the docstring for
> indent-relative-maybe:
> 
>        If the previous nonblank line has no indent points beyond the
>        column point starts at, this command does nothing.
> 
> 
> I would have expected, in indent-relative, that the calculation of a
> suitable indentation position is done independent of the argument
> UNINDENTED-OK. The following diff fixes this:

These functions exist for ages in this form.  I agree that the doc
string is misleading (and the optional argument of indent-relative is
not even documented), but other than fixing the documentation, I see
no reason to change the behavior.  Am I missing something?




This bug report was last modified 7 years and 355 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.