bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list

bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list

[Teemu Likonen]

I think it would be better if "C-x TAB" (bound to indent-rigidly)
advanced the indentation to the next tab stop (as in tab-stop-list) by
default, instead of by 1. Similarly, if negative prefix argument were
given (with "C-u -") it would change the indentation to the previous tab
stop. Only when the prefix argument is actual number, positive or
negative integer, it would move the indentation to the left or right by
the given count.

To demonstrate this I have written the following functions. Function
tl-indent-region is a kind of replacement for indent-rigidly, so it can
be bound to "C-x TAB".


--8<---------------cut here---------------start------------->8---
(global-set-key (kbd "C-x TAB") #'tl-indent-region)


(defun tl-region-indentation (beg end)
  "Return the smallest indentation in range from BEG to END.
Blank lines are ignored."
  (save-excursion
    (let ((beg (progn (goto-char beg) (line-beginning-position)))
          indent)
      (goto-char beg)
      (while (re-search-forward "^\\s-*[[:print:]]" end t)
        (setq indent (min (or indent (current-indentation))
                          (current-indentation))))
      indent)))


(defun tl-indent-region-engine (beg end arg)
  "Back-end function for `tl-indent-region'."
  (interactive "r\nP")
  (let* ((beg (save-excursion (goto-char beg) (line-beginning-position)))
         (current (tl-region-indentation beg end))
         (indent (cond ((not arg)
                        (- (catch 'answer
                             (dolist (col tab-stop-list (1+ current))
                               (when (> col current)
                                 (throw 'answer col))))
                           current))
                       ((eq arg '-)
                        (- (catch 'answer
                             (dolist (col (reverse tab-stop-list) 0)
                               (when (< col current)
                                 (throw 'answer col))))
                           current))
                       (t (prefix-numeric-value arg)))))
    (indent-rigidly beg end indent)))


(defun tl-indent-region (beg end arg)
  "Indent region to a tab stop column or to a specified column.

Indent the region from BEG to END according to the command's
prefix argument ARG. If ARG is nil (i.e., there is no prefix
argument) indent the region to the next tab stop column in
`tab-stop-list'. With negative prefix ARG (C-u -) indent the
region to the previous tab stop column. If ARG is an integer
indent the region by ARG columns (just like `indent-rigidly'
command).

If this command is invoked by a multi-character key sequence, it
can be repeated by repeating the final character of the
sequence."

  (interactive "r\nP")
  (require 'repeat)
  (let ((repeat-message-function #'ignore))
    (setq last-repeatable-command #'tl-indent-region-engine)
    (repeat nil)))
--8<---------------cut here---------------end--------------->8---

bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list

[Teemu Likonen]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

Teemu Likonen [2011-03-07 20:19:13 +02:00] wrote:

> I think it would be better if "C-x TAB" (bound to indent-rigidly)
> advanced the indentation to the next tab stop (as in tab-stop-list) by
> default, instead of by 1. Similarly, if negative prefix argument were
> given (with "C-u -") it would change the indentation to the previous
> tab stop. Only when the prefix argument is actual number, positive or
> negative integer, it would move the indentation to the left or right
> by the given count.

Any opinions on this? If you want to use the code in my first message
just go on. The copyright assignment paperwork is done.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list

[Drew Adams]

> > I think it would be better if "C-x TAB" (bound to indent-rigidly)
> > advanced the indentation to the next tab stop (as in tab-stop-list) by
> > default, instead of by 1. Similarly, if negative prefix argument were
> > given (with "C-u -") it would change the indentation to the previous
> > tab stop.

Sorry, that does not make sense to me.

What is the "next" or "previous" tab stop?  Relative to what/where?

`indent-rigidly' is for indenting the lines in the region, all of which
might all be currently indented to different columns.  Do you pick the
indentation of one of those lines to measure the "next" or "previous" tab
stop from?  If so, which one?  Or do you measure from point (in which case
it matters which end of the region point is.

Even if you abandon the notion of a next/previous tab stop, because there
is no good answer to "Next/previous to what?", you still have a problem
if you intend to indent to ANY particular tab stop.  You cannot indent lines
RIGIDLY to any particular tab stop, unless they all happen to be indented to
the same column to begin with.  Otherwise, "to" any column has no sense.

Indenting rigidly is about indenting a particular amount, not indenting to
some column.

What you can do is indent the region rigidly a certain number of tab stops
(either direction).  For that, see below.

> > Only when the prefix argument is actual number, positive or
> > negative integer, it would move the indentation to the left or right
> > by the given count.
> 
> Any opinions on this? If you want to use the code in my first message
> just go on. The copyright assignment paperwork is done.

I am definitely against such a change, regardless of what you might actually
mean by the next/previous tab stop.

Such a change would not be great for interactive use, and it would certainly
be bad for Lisp use.  Existing code depends on the current behavior.

If you want a command that indents rigidly a certain number of tab stops (and
not TO a particular tab stop), that is easy enough to define.  Here is one
such definition.  The prefix arg specifies the number of tab stops to indent,
and a negative number means count backwards from the end of `tab-stop-list':

(defun indent-rigidly-to-tab-stop (start end nth)
  "Indent the region rigidly according to the NTH tab stop.
`tab-stop-list' defines the available tab stops.  NTH is the numeric
prefix arg.  One means indent rigidly the amount given by the first
tab stop.  If NTH is negative then indent negatively (outdent)."
  (interactive "r\np")
  (unless (zerop nth)
    (let ((tabstop  (nth (mod (1- (abs nth)) (length tab-stop-list))
                         tab-stop-list)))
      (indent-rigidly start end (if (natnump nth) tabstop (- tabstop))))))

bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list

[Drew Adams]

> If you want a command that indents rigidly a certain number of tab stops...
> 
> (defun indent-rigidly-to-tab-stop (start end nth)

Clearly I used a bad name.  Should have used something like
`indent-rigidly-tab-stops'.  It specifically does NOT try to indent TO any
tab stop.  Sorry about that.

bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list

[Teemu Likonen]

Drew Adams [2013-07-12 12:11:31 -07:00] wrote:

>>> I think it would be better if "C-x TAB" (bound to indent-rigidly)
>>> advanced the indentation to the next tab stop (as in tab-stop-list)
>>> by default, instead of by 1. Similarly, if negative prefix argument
>>> were given (with "C-u -") it would change the indentation to the
>>> previous tab stop.
>
> Sorry, that does not make sense to me.

First, here's some reference where this came from:
http://lists.gnu.org/archive/html/help-gnu-emacs/2011-03/msg00243.html
The feature supersedes indent-rigidly. If filed this wishlist bug report
because Stefan Monnier suggested so:

    Indeed, it sounds like a good improvement to the behavior of C-x
    TAB. Maybe you could propose it for inclusion via M-x
    report-emacs-bug.

Here's a concrete use-case. Let's say my tab-stop-list variable is like
(4 8 12 16 20 etc.). I'm in a message-mode buffer writing some email or
news message which is about Lisp programming. I copy a piece of code
from some other buffer, like this:

(defun foo (bar)
  (setq some-variable some-value)
  (some-function-call bar)
  ...)

I want to indent it so that it stands out from my normal text. I mark
the code piece with M-h and press C-x TAB (which runs my improved
indent-rigidly). It results in this:

    (defun foo (bar)
      (setq some-variable some-value)
      (some-function-call bar)
      ...)

The lowest indentation of that paragraph is now column 4. If I had kept
repeating TAB key the code would have been indented to columns 8, 12, 16
etc. as the tab-stop-list variable defines.

The doc string of that command could be like this:


    Indent region to a tab stop column or to the specified column.

    Indent the region from BEG to END according to the command's prefix
    argument ARG. If ARG is nil (i.e., there is no prefix argument)
    indent the region to the next tab stop column in `tab-stop-list'.
    With negative prefix ARG (C-u -) indent the region to the previous
    tab stop column. If ARG is an integer indent the region by ARG
    columns (just like `indent-rigidly' command).

    If this command is invoked by a multi-character key sequence, it can
    be repeated by repeating the final character of the sequence.

bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list

[Drew Adams]

> http://lists.gnu.org/archive/html/help-gnu-emacs/2011-03/msg00243.html

OK, so you take as the reference column the indentation of the leftmost
line.  Without some such specification what you described earlier was
incomplete.

> Here's a concrete use-case....

My point is that this does not belong in `indent-rigidly'.  Create a new
command for it.  That's all.  `indent-rigidly' is a very old function
that is used not only interactively but in Lisp code.  There's no telling
how much existing code out there might use the fact that ARG = nil
indents one column.

> The feature supersedes indent-rigidly.

I don't think so.  And I hope not.  It is a different function.
Superseding means nothing useful is lost.  In this case what is lost
is the default behavior (ARG = nil) that you are replacing.  Depending
on the context and the user, that lost behavior is at least as useful
as its replacement.

What you can propose instead is that your new command get the
traditional binding for `indent-rigidly', `C-x TAB'.  What we should not
do is replace the current `indent-rigidly' behavior by the proposed
behavior in the same command.  Steal the key, perhaps, but not the command.

A mix would also be possible, but less desirable IMO: modify
`indent-rigidly' to provide the new behavior only interactively, never
when used in code.  That has the disadvantage of not letting code take
advantage of the indentation-to-tab-stop behavior.  I think it best to
provide a separate command.

A separate command also lets any user who prefers the current default
behavior interactively to bind `indent-rigidly', instead of your command,
to `C-x TAB'.  You find it handy to indent to a tab stop by default
(ARG = nil), and then repeat (e.g., C-x z z z z).  Someone else might
find it handier to indent one column instead of one tab stop by default,
and then repeat to indent the region incrementally.

FWIW, I would no doubt do that (but that has nothing to do with why I
replied to this thread), since I never use tab stops and I do indent
regions rigidly and incrementally.

Just one opinion.  Two separate commands provide more options for users,
including Lisp coders.  I do not object to your appropriating `C-x TAB'
for the new command.  But please do not touch the existing command.

I would also suggest polling the users wrt the key binding.  It's not
obvious a priori that more people will want to indent via tab stops.

bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list

[Jambunathan K]

Drew Adams <drew.adams@oracle.com> writes:

> FWIW, I would no doubt do that (but that has nothing to do with why I
> replied to this thread), since I never use tab stops and I do indent
> regions rigidly and incrementally.

(I have no opinion on the proposed feature though.)

My usual invocation is 

    C-4 C-x TAB

Sometimes, I just open a rectangle of required width.

    C-x r o

I prefer *not* to rely on tab stops.  So I am with Drew on this.

bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list

[Teemu Likonen]

Jambunathan K. [2013-07-13 04:23:00 +05:30] wrote:

> My usual invocation is 
>
>     C-4 C-x TAB

My command does the same when called with a numeric prefix argument.

The difference is when you don't call it with a numeric prefix.
indent-rigidly uses the default value of 1. My command uses the next or
previous tab stop as the default (as defined in the tab-stop-list
variable). My command has all the functionality of indent-rigidly but
also added intelligence to understand tab-stop-list. My command relies
on indent-rigidly to do the actual job.

That's why I'm saying that my command supersedes indent-rigidly.

bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list

[Teemu Likonen]

Drew Adams [2013-07-12 14:18:27 -07:00] wrote:

> What you can propose instead is that your new command get the
> traditional binding for `indent-rigidly', `C-x TAB'. What we should
> not do is replace the current `indent-rigidly' behavior by the
> proposed behavior in the same command. Steal the key, perhaps, but not
> the command.

That's exactly what I'm doing. My command is called "tl-indent-region"
(ok, we can drop the tl- prefix) and it relies on indent-rigidly to do
the job. My command behaves the same as indent-rigidly when called with
a numeric prefix argument.

bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list

[Drew Adams]

> > What you can propose instead is that your new command get the
> > traditional binding for `indent-rigidly', `C-x TAB'. What we should
> > not do is replace the current `indent-rigidly' behavior by the
> > proposed behavior in the same command. Steal the key, perhaps, but not
> > the command.
> 
> That's exactly what I'm doing. My command is called "tl-indent-region"
> (ok, we can drop the tl- prefix) and it relies on indent-rigidly to do
> the job.

Great.  Sounds good.  I misunderstood that you wanted to change
`indent-rigidly'; sorry.

> My command behaves the same as indent-rigidly when called with
> a numeric prefix argument.

Yes, that I understood from the code.

bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list

[Stefan Monnier]

> I think it would be better if "C-x TAB" (bound to indent-rigidly)
> advanced the indentation to the next tab stop (as in tab-stop-list) by
> default, instead of by 1.

That sounds reasonable.  It can be changed by modifying simply the
interactive spec of indent-rigidly.

> Similarly, if negative prefix argument were given (with "C-u -") it
> would change the indentation to the previous tab stop.

Same here.

For both changes, there's a risk some users will be annoyed, but they
can still get the old behavior with a C-u 1 or C-u - 1 prefix.

This said, there's another good default behavior for non-prefixed C-x
TAB which is to enter an interactive loop that lets the user move the
block left/right with the cursor keys.  I think this would be a more
useful change.


        Stefan

bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list

[Teemu Likonen]

Stefan Monnier [2013-07-13 16:02:35 -04:00] wrote:

> This said, there's another good default behavior for non-prefixed C-x
> TAB which is to enter an interactive loop that lets the user move the
> block left/right with the cursor keys. I think this would be a more
> useful change.

Sounds good. I wrote a quick example command "tl-edit-indentation". It
works like "indent-rigidly" expect that when there is no prefix argument
it sets a temporary repeatable overlay keyboard with the cursor keys for
editing indentation. Plain <left> and <right> would move by 1 column and
<S-left> and <S-right> move by tab stops. I like this feature.


(defun tl-region-indentation (beg end)
  "Return the smallest indentation in range from BEG to END.
Blank lines are ignored."
  (save-excursion
    (save-match-data
      (let ((beg (progn (goto-char beg) (line-beginning-position)))
            indent)
        (goto-char beg)
        (while (re-search-forward "^\\s-*[[:print:]]" end t)
          (setq indent (min (or indent (current-indentation))
                            (current-indentation))))
        indent))))


(defun tl-edit-indentation (start end arg)
  (interactive "r\nP")
  (if arg
      (indent-rigidly start end (prefix-numeric-value arg))
    (message "Edit region indentation with <left>, <right>, <S-left> \
and <S-right>.")
    (set-temporary-overlay-map

     (let ((map (make-sparse-keymap)))
       (define-key map (kbd "<left>")
         (lambda () (interactive)
           (indent-rigidly (region-beginning) (region-end) -1)))

       (define-key map (kbd "<right>")
         (lambda () (interactive)
           (indent-rigidly (region-beginning) (region-end) 1)))

       (define-key map (kbd "<S-right>")
         (lambda () (interactive)
           (let* ((beg (region-beginning))
                  (end (region-end))
                  (current (tl-region-indentation beg end))
                  (next (catch 'answer
                          (dolist (col tab-stop-list (1+ current))
                            (when (> col current)
                              (throw 'answer col))))))
             (indent-rigidly beg end (- next current)))))

       (define-key map (kbd "<S-left>")
         (lambda () (interactive)
           (let* ((beg (region-beginning))
                  (end (region-end))
                  (current (tl-region-indentation beg end))
                  (next (catch 'answer
                          (dolist (col (reverse tab-stop-list) 0)
                            (when (< col current)
                              (throw 'answer col))))))
             (indent-rigidly beg end (- next current)))))
       map)
     t)))

bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list

[Stefan Monnier]

> Sounds good. I wrote a quick example command "tl-edit-indentation". It
> works like "indent-rigidly" expect that when there is no prefix argument
> it sets a temporary repeatable overlay keyboard with the cursor keys for
> editing indentation. Plain <left> and <right> would move by 1 column and
> <S-left> and <S-right> move by tab stops. I like this feature.

I like it too.  Thank you.
I just folded it into indent-rigidly.


        Stefan

bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list

[Drew Adams]

> I just folded it into indent-rigidly.

Dunno what that means exactly, but a priori: too bad.
Should be a separate command, as previously discussed and agreed.

It would be OK to bind `C-x TAB' to a new command by default,
but it is not so wise to change the behavior of `indent-rigidly'.

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8196#23

bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list

[Teemu Likonen]

Drew Adams [2013-10-08 08:12:16 -07:00] wrote:

>> I just folded it into indent-rigidly.
>
> Dunno what that means exactly, but a priori: too bad. Should be a
> separate command, as previously discussed and agreed.

The change has effect only when called interactively and when there is
no prefix argument. The new feature is more useful.

bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list

[Drew Adams]

> >> I just folded it into indent-rigidly.
> >
> > Dunno what that means exactly, but a priori: too bad. Should be a
> > separate command, as previously discussed and agreed.
> 
> The change has effect only when called interactively and when there is
> no prefix argument. The new feature is more useful.

Yes, we know that.  Please read the thread.  Remember this part, for
instance?

 > > > What you can propose instead is that your new command get the
 > > > traditional binding for `indent-rigidly', `C-x TAB'. What we
 > > > should not do is replace the current `indent-rigidly' behavior
 > > > by the proposed behavior in the same command. Steal the key,
 > > > perhaps, but not the command.
 > >
 > > That's exactly what I'm doing.  My command is called 
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 > > "tl-indent-region" (ok, we can drop the tl- prefix) and it relies
 > > on indent-rigidly to do the job.
 > 
 > Great.  Sounds good.  I misunderstood that you wanted to change
 > `indent-rigidly'; sorry.
 > 
 > > My command behaves the same as indent-rigidly when called with
 > > a numeric prefix argument.
 > 
 > Yes, that I understood from the code.

Changing the key binding but not the command itself, as you said you
were doing, would be fine.  There is no reason to change
`indent-rigidly' itself.

"My command" should have remained just that: a separate command.
The fact that without a prefix arg it behaves the same as
`indent-rigidly' is irrelevant, except as a (weak) argument for
someone wanting to replace `indent-rigidly'.  It means nothing for
someone truly intending to add a new command and bind it by default
to `C-x TAB'.

What is important is to keep two separate functions, and not screw
`indent-rigidly'.

This portion of the thread is also relevant, as it seems to be what has
now been implemented, in spite of the discussion:

d> A mix would also be possible, but less desirable IMO: modify
d> `indent-rigidly' to provide the new behavior only interactively,
d> never when used in code.  That has the disadvantage of not letting
                                                          ^^^^^^^^^^^
d> code take advantage of the indentation-to-tab-stop behavior.
d> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
d> I think it best to provide a separate command.
d> 
d> A separate command also lets any user who prefers the current default
d> behavior interactively to bind `indent-rigidly', instead of your
d> command, to `C-x TAB'.  You find it handy to indent to a tab stop by
d> default (ARG = nil), and then repeat (e.g., C-x z z z z).  Someone
d> else might find it handier to indent one column instead of one tab
d>                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
d> stop by default, and then repeat to indent the region incrementally.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The simplest approach is the best one, for these and other reasons
discussed: Provide the new command.  Even make it the new default
binding for `C-x TAB'.  But keep `indent-rigidly' as it has been.
Simple, sane, no downside, wise.