🚀 go-pugleaf

"Hauke Ingmar Schmidt" <usenet@haukeingmar.de> wrote in message
news:ahsdb4$viobd$1@ID-76405.news.dfncis.de...
> Moin!
>
> Dale King <KingD@TCE.com> schrieb:
>
> > "Hauke Ingmar Schmidt" <usenet@haukeingmar.de> wrote in message
> > news:ahneaj$ulpsj$1@ID-76405.news.dfncis.de...
> >> Dale King <KingD@TCE.com> schrieb:
> >> Tabs do. A tab sets the cursor to the next tab stop; it is not moving
> >> the cursor for a special number of spaces (only at very simple
> >> editors). So if the next tab stop is at e.g. column 16 (which
> >> normally is not "16 characters from the left margin" but units of
> >> your choice, centimeter, millimeter, miles...) and both of the types
> >> above end before column 16 it aligns perfectly. Only if one of the
> >> texts goes beyond the tab stop the alignment will be disturbed.
> >
> > And the meaning of next tab stop differs based on the width of the
> > text before it. You are the one suggesting different fonts and
> > proportional fonts. Depending on the size of your proportional font
> > next tab stop will differ.
>
> The meaning does not differ. Only in very simple editors which replace
> tabs by spaces. Otherwise a tab stop is a column. A tab jumps to this
> column.

And which column it jumps to is relative to the end of the text that
preceded it. If you change where the text preceding it ends either by
changing the text contents or for non-proportional fonts changing the font
type or size you will change what the next column is. You may change it on
some lines while on others it stays the same.

If you have access to Windows Notepad (which is not just inserting spaces)
try this text (where <tab> is the tab key):

aabcdef<tab><tab>123
aabcdefg<tab>123

You will see the 123 lined up. Now delete the first a from both lines, and
voila they won't line up.

> >>> Tabs will line it up for a particular font, but
> >>> is not portable to a different font.
> >>
> >> Tabs don't care for fonts.
> >
> > Well, you were the one bringing proportional fonts into this. If I
> > take code with tabs to line that up with one font at a particular
> > size it will become unaligned as I change fonts or font sizes. Once
> > again tabs are not portable.
>
> No, again it does not. It does, if you use simple software that replaces
> a tab by a specified number of spaces. But that is really old software
> which should fall out of work.


For proportional fonts, try WordPad (which once again is not just inserting
spaces). With Arial 10 as the font, enter this text (where <tab> is the tab
key):

abcdef<tab><tab>123
abcdefgh<tab>123

Then switch to 8 pt. or 12 pt. and you will see that they no longer line up.

> >>> For indentation tabs only or spaces only will both work if your tool
> >>> supports tabs (which once again not all tools do).
> >>
> >> For example?
> >
> > I've already said that I have seen compiler error outputs not work
> > well with tabs and difference tools. Do I have the names of specific
> > products? No. It has been a while since I looked at difference tools
> > and believe me I looked at a lot of them.
>
> I guess there is NONE that produces problems with tabs that was designed
> for Java.

And that would be a faulty conclusion. And what does designed for Java have
to do with it? I am talking about tools like difference tools that are just
normal file based tools. There are plenty of file based tools that you could
potentially use on a java file that are not necessarily designed for Java.
How about just a tool like less. While it will handle tabs are the tabs the
same as what you set for your editor? I know of few people that use 8
character tabs as that is too much indentation.

There is no tool that does not support a space. And for non-proportional
fonts (the most sensible choice for code) it will always represent the same
amount of space, the width of one character.

> > I ran into a tabs vs. spaces thing myself just this past week. I have
> > a Java program that reads a file with commands where each command is
> > a single line of text or a comment. This file is read and each line
> > becomes an item in a JList. The person that created the file in his
> > text editor had tabs in the comments. In the JList they showed up as
> > boxes. There was no way to handle this elegantly, so I just replaces
> > the tabs with a space. Now they don't line up.
>
> Write a better listrenderer that handles tabs. Yours obviously does not.

"Mine" is the default one provided by the JDK that uses a JLabel. By default
Java does not support tabs in a JList. Sure I can write one that does, but
the point is still valid that when you use tabs you will run into this kind
of situation all the time. Either you find something that does not support
tabs or it supports a different size tab.

So once again spaces are 100% portable, tabs are not.

--
  Dale King