Continuing the discussion from Multiple spaces are replaced by tabs:
Right now I have some buggy code that tries to automatically convert from leading space indentation to tab indentation when reading a file into TaskPaper. The reasoning behind this is:
-
Lots of text editor default to using leading spaces for indentation.
-
If such a file is opened in TaskPaper without conversion then it will visually look like there’s a hierarchy because of the leading spaces, but none of the hierarchy commands will work (such as expand collapse), because there will be no hierarchy in TaskPaper’s model. Visually you would have some indication that there isn’t a hierarchy, since the guide lines and leading bullets would all be left aligned, but still I’m sure it would be confusing.
The problem with this behavior (besides the fact that’s it’s buggy) is that it means if you open a file in TaskPaper, and then save it, spaces get converted into tabs even if you make no edits. So that behavior is a bit weird too.
I guess the “ideal” behavior would be to detect and remember the indentation method. Tabs, two spaces, four spaces, etc… and then when saving encode the indentation using the same method. That would be idea from the individual users perspective, but it would make parsing TaskPaper files more complex, since parsers would have to take into consideration multiple indentation methods.
Programmers and scripters (@complexpoint, @macdrifter, @mattgemmell) what do you think:
-
Only consider leading tabs when parsing for indentation… just read file in and be done with it?
-
Consider both leading tabs and spaces when parsing for indentation… but always save using tabs?
-
Consider both leading tabs and spaces when parsing for indentation… and save out using detected method?
Note These a similar question relating to line endings. Right now TaskPaper recognizes multiple types of line endings, but always saves using \n
.