Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.editors > #106908 > unrolled thread

Are TABs a topic? ( was Re: “A dispute over the TAB key highlights a mismatch [...])

Back to article view | Back to comp.editors

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Are TABs a topic? ( was Re: “A dispute over the TAB key highlights a mismatch [...]) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-03 10:28 +0200
    Re: Are TABs a topic? ( was Re: “A dispute over the TAB key highlights a mismatch [...]) Paul <nospam@needed.invalid> - 2026-06-03 05:20 -0400
      Re: Are TABs a topic? ( was Re: “A dispute over the TAB key highlights a mismatch [...]) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-03 14:50 +0200
      Re: Are TABs a topic? ( was Re: “A dispute over the TAB key highlights a mismatch [...]) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-04 00:07 +0000
    Re: Are TABs a topic? ( was Re: “A dispute over the TAB key highlights a mismatch [...]) steve g <Sgonedes1977@gmail.com> - 2026-10-12 18:09 -0400
      Re: Are TABs a topic? ( was Re: “A dispute over the TAB key highlights a mismatch [...]) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-13 04:29 +0200

#106908 — Are TABs a topic? ( was Re: “A dispute over the TAB key highlights a mismatch [...])

On 2026-06-02 21:20, Mario Rosell wrote:
>> [...]
> 
> I think TABs are cool because of this: you can set the indentation level
> to what you are used to.

Sure.

> also saves space if you really need to squash four bytes.

I think this is the weakest argument for TABs; it had been weak
in former days already, and it's IMO quite ridiculous nowadays.


Given the now existing powerful and flexible editors as options
to address own preferences (or project demands) you have anyway
all the freedom you like.

In Vim you have 'tabstop' and 'shiftwidth' to distinguish unequal
levels of spaces-indenting and TAB-definition, there's 'softtabstop'
to use spaces but let TAB and Backspace handle the various amounts
of blanks as a single entity, there's 'expandtab' to expand TABs
to blanks, or 'smarttab' to distinguish indentation TABs at the
front of a line from alignment-blanks in the mid of the code, all
conveniently handled with the Tab-key of course. (And I wouldn't
be astonished if there's more flexibility that I don't know of.)
I've also heard of (but never used) a setting to handle makefiles'
TABs. (Personally I'm defining just 'ts' and 'sw' and occasionally
define 'et'; the shortcuts for the above editor options.)

So that "Tabs vs. Spaces War" shouldn't be a topic nowadays since
we have all options in principle (but maybe not in all editors).

Janis

PS: And since I don't see the topical relevance for "C" (or C++)
I set Followup-to: comp.editors

[toc] | [next] | [standalone]

#106909

On Wed, 6/3/2026 4:28 AM, Janis Papanagnou wrote:
> On 2026-06-02 21:20, Mario Rosell wrote:
>>> [...]
>>
>> I think TABs are cool because of this: you can set the indentation level
>> to what you are used to.
> 
> Sure.
> 
>> also saves space if you really need to squash four bytes.
> 
> I think this is the weakest argument for TABs; it had been weak
> in former days already, and it's IMO quite ridiculous nowadays.

Tabs or tabulation control, was from the typewriter era. Setting
the stop, allowed *variable* field widths set up on your typewriter.
If you hit the tab, the carriage would move until it hit the
tab-stop you set. There was a bar along the top of the typewriter,
and the metal tab could be moved to the distance you wanted.
We used to play with this, as kids.

The Model 29 punched card terminal, had a programmable card that
wrapped around a cylinder in the middle of the machine. Power users
would load their card (designed for a particular data entry job)
and this worked in a similar way. Variable field widths, machine
moves to the stop you programmed. This is the start of when
tabulation control, moved into the computer field. Because of the
interest in fixed width fields to make the data cards pretty.
The card number would go way over on the right, so if you dropped
the deck on the floor, you could manually sort it back into order.
And you could set a stop with that card you loaded on the cylinder,
to have it stop so you could type the card number 10,20,30...20000
over on the right. A box would hold 2000 cards. By using multiples
of ten, you could "edit" a deck and insert a few cards and still
have some semblance of numbering.

Where does that leave us in a modern era ? Concept is
perverted, by emitting some fixed number of spaces per tab,
which is not how the original concept worked. Is indenting
the same amount each time, awe inspiring ? Of course. But then it
isn't really a tab any more, because it isn't banging against
a tab stop any more. It's a "schwing over N characters" button.
And it goes downhill from there (lots of environments do not
have a visible representation that tells you a tab character
is present).

   Paul

[toc] | [prev] | [next] | [standalone]

#106910

On 2026-06-03 11:20, Paul wrote:
> 
> Tabs or tabulation control, was from the typewriter era. Setting
> the stop, allowed *variable* field widths set up on your typewriter.
> If you hit the tab, the carriage would move until it hit the
> tab-stop you set. There was a bar along the top of the typewriter,
> and the metal tab could be moved to the distance you wanted.
> We used to play with this, as kids.

Yes, I once was at such a typewriter. The tabs were used to position
to text-fields of forms, "similar" to switching fields in GUI forms
on computers. The Tabs were thus not fixed at one width but more a
sequence of independent positioning marks.

> [...]
> 
> Where does that leave us in a modern era ? Concept is
> perverted, by emitting some fixed number of spaces per tab,
> which is not how the original concept worked.

The "original concept" makes just little sense in "modern [computer]
era". (For programming you want fixed intent positions and for GUIs
there's anyway a field-oriented organization.)

> Is indenting
> the same amount each time, awe inspiring ? Of course. But then it
> isn't really a tab any more, because it isn't banging against
> a tab stop any more.

It's a useful and simple method to indent code and align text.

> It's a "schwing over N characters" button.

I don't think so. - It positions to specific fixed columns positions,
for example (9, 17, 25, 33, etc.) with a tab-setting of 8. If you're
at, say, character position 6 it only only "swings over" 3 characters.

(There may be Tab behaviors like the ones you describe but not on the
systems I'm working on. - In editors you could certainly configure its
behavior to achieve such a "replace Tab by N characters or forwards"
independent of the actual position.)

> And it goes downhill from there (lots of environments do not
> have a visible representation that tells you a tab character
> is present).

Some may like to see it, maybe even depending on the application text,
others may not. That's why some text editors support controlling that.

Janis

[toc] | [prev] | [next] | [standalone]

#106911

On Wed, 3 Jun 2026 05:20:31 -0400, Paul wrote:

> Tabs or tabulation control, was from the typewriter era.

That concept did also carry over to the computer terminal era.

Press that big fat “SET-UP” button on a VT100 terminal, for example,
and the most prominent feature you see is the tab ruler along the
bottom, with a “T” marking each tab stop.

> Where does that leave us in a modern era ? Concept is perverted, by
> emitting some fixed number of spaces per tab, which is not how the
> original concept worked.

Not quite. It is usual for software to emulate tabs the way they were
supposed to work, by skipping to the next tab stop position, not by
emitting some fixed number of spaces.

[toc] | [prev] | [next] | [standalone]

#106991

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

> On 2026-06-02 21:20, Mario Rosell wrote:
>>> [...]
>> I think TABs are cool because of this: you can set the indentation level
>> to what you are used to.
>
> Sure.
>
>> also saves space if you really need to squash four bytes.
>
> I think this is the weakest argument for TABs; it had been weak
> in former days already, and it's IMO quite ridiculous nowadays.


No it is not over! I want my backtab to work like the drawing on the key

Tab
<-----
----->

Why doesn't anyone use the backtab? never mind emacs has support for the
backtab; it runs si:backtab :)

> So that "Tabs vs. Spaces War" shouldn't be a topic nowadays since
> we have all options in principle (but maybe not in all editors).

That fight will never end; sendmail.cf has created a new generation of
people that want spaces and not tab; tab should not be inserted into the
user buffer because it is a gray key ?


> Janis
>
> PS: And since I don't see the topical relevance for "C" (or C++)
> I set Followup-to: comp.editors

[toc] | [prev] | [next] | [standalone]

#106993

On 2026-10-13 00:09, steve g wrote:
> [...]  I want my backtab to work like the drawing on the key
> 
> Tab
> <-----
> ----->
> 
> Why doesn't anyone use the backtab?  [...]

Hmm.. - I'm sure I'm using it, but (AFAIR) only in GUI forms where I
jump forward from field to field with TAB and backwards with Shift
TAB.

The point with the editor I use is, frankly, that I don't know what
a back-tab would be supposed to do; I indent with Tab and clear TABs
backwards with Backspace. For all navigation I use in Vi and Vim the
"semantic positioning" on the various entities and units in a text.
(So I don't see how the back-tab would help here.)

It might make more sense with GUI oriented editors? - But also in the
more primitive GUI-editors and word-processors I typically move by at
least the few semantic entities supported; e.g. Ctrl-RightArrow (to
move by words).

> [...]
> 
> That fight will never end; sendmail.cf has created a new generation of
> people that want spaces and not tab; tab should not be inserted into the
> user buffer because it is a gray key ?

Oh, if that is the criterion then I can enter F1..F4 and F9..F12, but
won't enter F5..F8 (which are gray). ;-)

That might also explain why some text sources, e.g. some HTML pages,
contain of just a single long line; the Enter key is also gray. :-)

Janis

[toc] | [prev] | [standalone]

Back to top | Article view | comp.editors

csiph-web