Please improve the handling of TAB characters in the DWC editor

zapta

DWC inserts tabs characters in the file and interprets them as four spaces which result in a different layout of the text compare to standard editors. See for example the difference in the screenshot below between VI and the DWC editor.

I think that the safest and cleanest would to to replace tabs automatically with spaces, during editing or when saving. This will avoid the ambiguity.

This is how the file looks in VI editor:

And this is how it looks in DWC editor

Stephen6309

@zapta Set the tab in VI to four spaces would also work.

zapta

Thanks @stephen6309. VI was just one example and I use VI for other text files as well.

Tab characters are problematic in general.

dc42

@zapta IMO it makes no sense to have tabs positions set to every 8 columns in an editor. 8 spaces is far too much block indent to use when writing programs (including GCode meta commands) because the blocks run off to the right hand edge of the page too quickly. 4 columns is much more reasonable.

If you're not willing to set vi to 4 column tab positions, why don't you configure vi to change tabs to spaces when saving the file?

zapta

@dc42, I gave Vi as a example. I use it to view files I sync to my computer but do all the editing using DWC.

It's common these days not to rely on the Tab character for indentation (not to be confused with the Tab key which is often a shortcut for indentation). E.g.

https://insanelab.com/blog/notes/spaces-vs-tabs/

https://google.github.io/styleguide/cppguide.html#Spaces_vs._Tabs

Anyway, this is not a show stopper, just a lingering nuisance.

resam

I think we are all aware of the long history and arguments of tab vs. spaces - so let's not rekindle that old war.

@zapta said in Please improve the handling of TAB characters in the DWC editor:

DWC inserts tabs characters in the file

@zapta what do you mean with this statement? Is DWC inserting tabs all by itself, or because you (the user) has pressed the Tab key to indent some code? At the moment this feels like a "you are holding it wrong" kinda argument.

If you don't want tabs, well, then don't insert any... or what aspect of your UX flow am I missing? Are you asking for DWC to explicitly rewrite gcode files because you "were careless" when editing them with other tools?

Or are you proposing to make the DWC "editing window" more like a proper IDE / smart editor where you can choose/configure how many spaces should be inserted when pressing the Tab key (instead of inserting an actual tab character)?

zapta

@resam said in Please improve the handling of TAB characters in the DWC editor:

Are you asking for DWC to explicitly rewrite gcode files because you "were careless" when editing them with other tools?

I am proposing that DWC will have the common behavior of code editors these days. TAB key as a shortcut for 'indent' and writing spaces only in the files it generates.

DWC developers can choose the indent size they like to support (I think it's currently 4 but am not sure).

Baenwort

Can those of us who feel that a tab is a tab and a space is a space and I'll well and good press the one I intend get a request also?

zapta

@baenwort, of course, you can.

And if you also want that pressing the delete key will insert a delete character and pressing the backspace key will insert a backspace character you can ask for it as well.

zapta

@dc42 said in Please improve the handling of TAB characters in the DWC editor:

@zapta IMO it makes no sense to have tabs positions set to every 8 columns in an editor.

It seems that this is this forum system also assumes 8 chars per tab

Non indented
	Indented by a single tab

And the preview is rendered like this

The ambiguity of the tab character is especially problematic with languages such as RRF gcode whose semantic depends on indentation. That is for example why RRF complains about the code below because it mixes spaces and tabs in the same nested block

if 1 < 2
  if 1 < 2   ; indented by two spaces
	echo "aaa"  ; indented by a single tab

Sticking to spaces eliminate this ambiguity.

dc42

@zapta said in Please improve the handling of TAB characters in the DWC editor:

Sticking to spaces eliminate this ambiguity.

Sticking to tabs also eliminates it; but many people using programming languages that use indentation to indicate block scope prefer to use only spaces.

zapta

@dc42 said in Please improve the handling of TAB characters in the DWC editor:

Sticking to tabs also eliminates it;

I don't see how it will eliminate the ambiguity, since the tab character doesn't have a standard interpretation and editors use 2, 4 or 8 positions.

@dc42 said in Please improve the handling of TAB characters in the DWC editor:

many people using programming languages that use indentation to indicate block scope prefer to use only spaces.

I wonder if this is the case. For example, python is a popular indentation sensitive language and its official style guide says "Spaces are the preferred indentation method".

https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces,

The Tab character used to have a single agreed upon interpretation (moving to next 8 positions column) but over the years people came with their own interpretations to the point that it's common these days to avoid it all together.

BTW, this became an issue with DWC when conditional gcode was introduced. Before that we didn't use to indent.

dc42

@zapta said in Please improve the handling of TAB characters in the DWC editor:

I don't see how it will eliminate the ambiguity, since the tab character doesn't have a standard interpretation and editors use 2, 4 or 8 positions.

Because for the purposes of indenting command blocks, all that matters is how many tabs you have at the start of the line; and it doesn't matter whether those tabs are displayed as 4, 8 or some other nonzero number of characters.

zapta

@dc42 said in Please improve the handling of TAB characters in the DWC editor:

it doesn't matter whether those tabs are displayed as 4, 8 or some other nonzero number of characters.

4 vs 8 will render the indentation differently to the user, right? Is this is why you warn if the same IF block contains both tabs and spaces? Because of the potential ambiguity?

dc42

@zapta said in Please improve the handling of TAB characters in the DWC editor:

4 vs 8 will render the indentation differently to the user, right? Is this is why you warn if the same IF block contains both tabs and spaces? Because of the potential ambiguity?

Yes and yes. It's only the indentation characters that need to be all spaces or all tabs so as to show the correct block scope in any editor. It doesn't matter whether the end-of-line comment is preceded by tabs, space, or a mixture - but of course if tabs are used, the editor tab setting will affect where the comment is displayed.

I usually use 2 spaces to indent a conditional GCode block, and tabs to place the end-of-line comments.

zapta

Today I learned that DWC inserts tabs even if I don't use the tab key.

To reproduce:

Start with a command indented by four spaces.

<four spaces>G1

Position the cursor at the end of the line, press Enter, and type the second command, e.g. G2. Notice how the second line is indented with a single tab rather than four spaces.

<four spaces>G1
<tab>G2

It seems that DWC not only supports tabs but actually prefers them over spaces.

gloomyandy

@zapta Yep I've also noticed it does this (and it is very irritating!).

Having to deal with files that contain mixed tabs/spaces for indentation is a personal bugbear of mine and creating them is in my view a terrible crime (though not as bad as the folks that reformat entire files to fit in with "the one true way" that they think the layout should look!). For many years now I've tried to practise (not always successfully!) an approach of using whatever style the original author has been using when making changes to existing source code. Personally I'd prefer to have some sort of option to use spaces for indentation (and to use the tab key to generate that indentation rather then insert a tab character), which is common in many other editors. Even better (IMHO) would be to have it auto adjust based on the exiting style(like some more advanced editors try to do, sometimes it works!).

dc42

@zapta I've asked @chrishamm to look into this.

zapta

@dc42 said in Please improve the handling of TAB characters in the DWC editor:

@zapta I've asked @chrishamm to look into this.

Thanks.