Unix to Windows space formatting

[vb.net]

I currently develop on Win32 using Textpad, but my teammates develop on Linux. I like using Textpad; however when I bring up Emacs-formatted code into Textpad, the letter spacing isn't displayed as it was formatted in Linux. For example, consider this Linux code:

Code: Select all

sub toString {
    my $self = shift;
    my @miniStrings;
    if (defined($self->name())) {
        push(@miniStrings, "name=" . $self->name());
    }
}

On Win32, it displays as:

Code: Select all

sub toString {
        my $self = shift;
        my @miniStrings;
        if (defined($self->name())) {
        push(@miniStrings, "name=" . $self->name());
        }
}

Is there any solution to "fix" this?

[ben_josephs]

Presumably the file contains tabs, and emacs has been configured to display them as 4 spaces, while TextPad is using its default of 8 spaces. Note that the spacing when the file is displayed with 8 spaces per tab is wrong; the line beginning with push isn't indented enough. The file appears to contain an unhelpful mixture of spaces and tabs.

You can make the spaces and tabs visible with View | Visible Spaces.

Set the tab spacing in TextPad to 4, either for the current document, in
Configure | Preferences | Document Classes | <Class> | Tabulation
or for all documents in a class, in
View | Document Properties | Tabulation

You can tell TextPad to convert new and existing tabs to spaces. This will solve your problem... until somebody puts the tabs back again.

[vb.net]

Hi,

Actually, I have my Textpad tabs set to 2 spaces.

I believe you're right about Emacs setting tabs to 4 spaces. Unfortunately the files edited with Emacs, when opened with Textpad on Win32, lose their tabular characteristic, and are processed as white spaces only. This causes all sorts of weirdness in the spacing display. If I could get Textpad to treat Emacs tabs as a Windows/Textpad tab, this could solve my problem.

[ben_josephs]

A tab is a tab - the ASCII character whose value is 9. There are no emacs tabs or TextPad tabs.

If emacs is using a tab spacing of 4 and TextPad is using a tab spacing of 2, then the two files represented above are not the same file. Perhaps something has expanded all the tabs in the originals to 8 spaces.

[Drxenos]

This is why programming teams usually have a convention that disallowed the use of the tab character. Use spaces; they display consistently in all editors. I have TextPad set up to automatically convert tabs to spaces upon saving. That way, I don't have to even worry about it.

DrX

[ben_josephs]

It doesn't matter what conventions, rules or threats you make, someone will put tabs in, and someone else will put more in assuming a different spacing.

[vb.net]

A tab is a tab - the ASCII character whose value is 9. There are no emacs tabs or TextPad tabs.

If emacs is using a tab spacing of 4 and TextPad is using a tab spacing of 2, then the two files represented above are not the same file. Perhaps something has expanded all the tabs in the originals to 8 spaces.

Not exactly.

In Emacs, when you create a tab, it's treated as one character (\t).

When opened in Textpad, that tab created in Emacs is not treated as a one-character tab (\t) in Textpad, but multiple characters consisting of a series of spaces (\s\s\s\s).

[ben_josephs]

No. A tab is a tab, and TextPad treats it as such. But you can ask TextPad to convert tabs to spaces for you, either for the current document, in
Configure | Preferences | Document Classes | <Class> | Tabulation
or for all documents in a class, in
View | Document Properties | Tabulation

BTW, the notation \s represents any white space character (including a tab, carriage return or line feed), not just a space. (TextPad doesn't understand it, anyway.)

[Drxenos]

It doesn't matter what conventions, rules or threats you make, someone will put tabs in, and someone else will put more in assuming a different spacing.

Part of a code review is to ensure the conventions are meet. We have been doing this for years (as does every group I've ever worked with), and it works. It has nothing to do with "rules" or "threats." It's a group of serious professionals creating a consistent product.

[vb.net]

No. A tab is a tab, and TextPad treats it as such.

Not if the tab was created using a different operating system and/or encoding scheme. I have the file opened right here. Let me try to illustrate to you in Textpad the difference between a recognized tab and an unrecognized tab consisting of a series of white spaces, by using an actual piece of code that I'm working on:

Code: Select all

foreach my $group (@groups)
{
	my $name = $group->name();
	my @siblings = $group->_siblings(class => "JDT::Sibling");
	foreach my $sibling (@siblings)
	{
	        my $error = $sibling->error();
		my @datasets = $sibling->_datasets("JDT::Dataset::ColouredDatasets::OYE");

The line, my $error = $sibling->error();, was added in Linux. It is out of place with the rest of the code, which was added in Windows. The rest of the code uses pure tab indention, whereas this line consists of a tab + a series of 8 spaces, when it really should be 2 tabs like the line below it. When this line was created in Linux, the indentation was indeed 2 tabs. However, when I opened this code in Windows, the original tab indention added in Linux was lost, and thus the lines added in Linux do not appear as consistently formatted with the rest of the code.

[ben_josephs]

No. A tab is a tab. An unrecognized tab consisting of a series of white spaces is not a tab; it is a series of white spaces.

If the contents of the files being displayed on the Linux and Windows systems are identical (except possibly for the line endings--but that's irrelevant), and if the file is as you say (that is, all leading space consists of tabs except for the my $error = $sibling->error(); line) then your code example is being displayed with 3 spaces per tab. Presumably, at some point, the file was displayed elsewhere (the operating system has nothing to do with it) with 8 spaces per tab, and, for some reason, the 16-space indentation of the new line was entered as one tab (perhaps created automatically by the editor when <enter> was typed) and 8 individual spaces (perhaps typed explicitly). The text would then have appeared correctly lined up. Of course, when the file is displayed with 3 spaces per tab (the operating system has nothing to do with it) the tab and 8 spaces don't have the same width as two tabs.

The solution, as Drxenos has indicated, is not to use tabs.

[smolkowski]

vb.net,

Just thought I'd toss in my $.02, since I use Emacs in a Unix environment and TextPad in windows and have used the both daily for, well, about a decade.

First, tabs are tabs. It doesn't matter if they come from Unix or Windows or what encoding is used. At least I've never seen a tab act differently in different operating systems.

Second, both TextPad and Emacs can do quite a number of things with Tabs. In both, you can set the column width for the display of tabs. You can also have both TextPad and Emacs convert tabs to spaces. In fact, you can add a hook into Emacs that will convert tabs to spaces when open a file. Finally, in both you can tell both applications to insert either spaces or tab characters when you hit the tab key.

My point is that both TextPad and Emacs need to use compatible settings if want them to display similarly. I always set both applications to insert spaces when I hit tab and to replace tabs with spaces when I save, which generally solves all my problems.

I recommend you talk with your Linux-using buddies. In Emacs, just about anything is possible. For example, you could have Emacs show tabs at, say, 2 spaces per tab but convert tabs during a save to, say, 8 spaces for a tab. Granted, that would be unusual. Emacs can also tabify a file upon saving, so that it convert spaces to tabs it saves a file. And just to make matters more complicated, in Emacs can set a different tab column for each individual tab. That is, the first one might move the cursor to column 8, the second to column 12, the third to column 25.

Without knowing exactly how Emacs handles tabs for display, when reading a file, and when saving a file, it won't be possible to figure this out. As I mentioned, though, I've been working with both of these applications since at least '97 and have never had the problem described here.