[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Drew Adams
Subject: bug#8196: 23.1; Feature request with code: "C-x TAB" to understand tab-stop-list
Date: Tue, 8 Oct 2013 09:21:26 -0700 (PDT)

> >> 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

 > > > 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

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> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]