How to change the length of "\t"?

[Peng Yu]

Hi,

It is possible to change the length of "\t" to a number other than 8.

std::cout << "\t";

Thanks,
Peng

[Gernot Frisch]

It is possible to change the length of "\t" to a number other than 8.

std::cout << "\t";

I think what you want to do is to make a tab() function, that returns up to
8 space characters, depending on the current line length.

I don't know of a way to get the number of characters you have put to the
last line, which you need because:

a\tb should become "a b"
abc\td should become "abc d"
in your case.

[Matthias Buelow]

Lionel B wrote:

Certainly not by me! The first thing I do when configuring an editor for
programming (anything) is to change the displayed TAB width to 4 (I might

Then everyone who has his editor or viewer at the conventional eight
spaces width will see your text garbled.

also convert TABs to spaces, but that's not always an option). I've
always found 8 spaces makes code less readable and takes up an
inconvenient amount of horizontal space.

Hint: use soft tabs, or some other indenting mechanism which doesn't
rely on changing the hardtab setting. Most editors (outside of the
Windoze world, at least) provide such a feature. For example, in vi, it
can be done by setting sw (shiftwidth), in emacs, you use indentation
styles which can define various indentation widths. If an editor can't
do such a simple thing, it isn't suitable for programming and you should
look for a different one.

[Lionel B]

On Tue, 15 Jul 2008 16:16:28 +0200, Matthias Buelow wrote:

Lionel B wrote:

>Certainly not by me! The first thing I do when configuring an editor
for programming (anything) is to change the displayed TAB width to 4 (I
might

Then everyone who has his editor or viewer at the conventional eight
spaces width will see your text garbled.

Errm... I'm not with you here. I don't see other peoples' text garbled if
I change the displayed tabwidth in my editor - I just see the same text
but with tabs taking up more or less width - so why should they see *my*
text garbled? I'm not actually changing the text at all...

The only case I can think of where garbling might be said to occur might
be where someone has formatted text - say mixing tabs and spaces - *under
the assumption* that a tab occupies 8 spaces. And that's a dumb thing to
do anyway.

--
Lionel B

[Matthias Buelow]

Lionel B wrote:

I'm not actually changing the text at all...

Yes.. I meant the whitespace, obviously.

The only case I can think of where garbling might be said to occur might
be where someone has formatted text - say mixing tabs and spaces - *under
the assumption* that a tab occupies 8 spaces. And that's a dumb thing to
do anyway.

Vi does it that way per default, Emacs does it that way per default, and
most other editors I know, too, I certainly don't consider it "dumb".
It's debatable whether using only spaces might be a better idea;
however, the fact is that most source files (on Unix, at least) use
mixes of spaces and tabs, and assume a hard tab setting of 8 columns.
This isn't usually a problem, until someone comes around and changes the
tab width.
Anyways, this discussion is way OT here, sorry.

[James Kanze]

On Jul 15, 10:55 am, Lionel B <m...@privacy.n etwrote:

On Tue, 15 Jul 2008 01:42:37 -0700, James Kanze wrote:

On Jul 14, 10:22 pm, Victor Bazarov <v.Abaza...@com Acast.netwrote:

James Kanze wrote:
On Jul 14, 7:24 am, Peng Yu <PengYu...@gmai l.comwrote:

It is possible to change the length of "\t" to a number other than
8.

[...]

Today, as I said, the de facto standard is 8, and IMHO,
setting it to anything else is more or less the equivalent
of defining operator+ to do subtraction. I rather fear that
I'm not widely followed in this opinion,

Certainly not by me! The first thing I do when configuring an
editor for programming (anything) is to change the displayed
TAB width to 4 (I might also convert TABs to spaces, but
that's not always an option). I've always found 8 spaces makes
code less readable and takes up an inconvenient amount of
horizontal space.

The problem is that you don't look at text only in the editor.
If you grep for something in it, or do a diff between two
versions, then it will look funny as well.

And the position of the tab stop has nothing to do with how you
indent your code. I indent four as well. But my editor will
never output a tab character in a file I'm editing. (It also
does most of the indentation automatically.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 15, 4:16 pm, Matthias Buelow <m...@incubus.d ewrote:

Lionel B wrote:

Certainly not by me! The first thing I do when configuring
an editor for programming (anything) is to change the
displayed TAB width to 4 (I might

Then everyone who has his editor or viewer at the conventional
eight spaces width will see your text garbled.

also convert TABs to spaces, but that's not always an
option). I've always found 8 spaces makes code less readable
and takes up an inconvenient amount of horizontal space.

Hint: use soft tabs, or some other indenting mechanism which
doesn't rely on changing the hardtab setting. Most editors
(outside of the Windoze world, at least) provide such a
feature. For example, in vi, it can be done by setting sw
(shiftwidth),

shiftwidth doesn't affect whether tabs are present or not
(although it is independent of the tab position); the option
you're thinking of is expandtab (et), which tells vim (but not
vi) to output only spaces for indentation.

in emacs, you use indentation
styles which can define various indentation widths.

And there is a configuration variable indent-tabs-mode, which if
set to nil, prevents emacs from introducing a tab character as
well.

If an editor can't do such a simple thing, it isn't suitable
for programming and you should look for a different one.

Agreed.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 15, 4:54 pm, Lionel B <m...@privacy.n etwrote:

On Tue, 15 Jul 2008 16:16:28 +0200, Matthias Buelow wrote:

Lionel B wrote:

Certainly not by me! The first thing I do when configuring
an editor for programming (anything) is to change the
displayed TAB width to 4 (I might

Then everyone who has his editor or viewer at the
conventional eight spaces width will see your text garbled.

Errm... I'm not with you here. I don't see other peoples' text
garbled if I change the displayed tabwidth in my editor - I
just see the same text but with tabs taking up more or less
width - so why should they see *my* text garbled? I'm not
actually changing the text at all...

The only case I can think of where garbling might be said to
occur might be where someone has formatted text - say mixing
tabs and spaces - *under the assumption* that a tab occupies 8
spaces. And that's a dumb thing to do anyway.

Using anything other than 8 for tabstops is a dumb thing, since
that's the universal defacto standard today (and you certainly
don't look at text only in an editor). If you're using an
indentation other than 8 (and 8 is too big), then you have to
use some spaces for the indentation. (Because people are stupid
enough to set tabstops in their editor at something different
than 8, I've given up using tabs at all in text files. Just
spaces, so everyone will see the code as it was meant to be
formatted.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Matthias Buelow]

Alf P. Steinbach wrote:

I'm sorry, but that's not correct. The de facto Windows standard is 4
character positions per tab stop. Tools from early eighties (e.g.
Notepad) excepted.

And once again, the Microsoft world attempts to foist a broken
quasi-standard on us... will it ever end?

[Jerry Coffin]

In article <6e************ @mid.dfncis.de> , mk*@incubus.de says...

Alf P. Steinbach wrote:

I'm sorry, but that's not correct. The de facto Windows standard is 4
character positions per tab stop. Tools from early eighties (e.g.
Notepad) excepted.

And once again, the Microsoft world attempts to foist a broken
quasi-standard on us... will it ever end?

Pardon my being blunt, but what a bunch of crap. First of all, tabs and
expansion thereof have been a broken quasi-standard since LONG before
Windows was invented. I can remember well dealing with exactly this sort
of problem when moving data on 7- and 9-track tapes from IBM to Control
Data mainframes.

Second, MS-DOS and Windows command prompts have always done pretty much
the same as UNIX and similar systems, with tabs every 8 characters and a
tab moving to the next tab stop, NOT expanding to a fixed number of
spaces.

Finally, having tab stops every 4 character cells is a least a lot less
broken than having them every 8. It's not perfect, but 8 is completely
unusable.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[James Kanze]

On Jul 15, 8:12 pm, Jerry Coffin <jcof...@taeus. comwrote:

In article <6e4645F58v5... @mid.dfncis.de> , [e-mail] says...

[...]
I agree with the rest of what you said, but...

Finally, having tab stops every 4 character cells is a least a
lot less broken than having them every 8. It's not perfect,
but 8 is completely unusable.

Could you explain please. Starting with what use you see for
tabs.

They don't occur in written text, or at least, you can't
distinguish between a tab character and so many spaces.
Historically, they ended up in files as a very primitive means
of reducing file size---and 8 apparently worked well there.
(Note that the critical position in Fortran is 72. A multiple
of 8.) Today, frankly, I don't see much use of them in files at
all, and find the best solution is to ban them. Except that
some old programs (like make) still require them. (And I agree
that for make, 4 would be better. But 8 is still quite usable.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]