I just voted for wish list item "Option to convert new tabs to spaces" and shouldn't have. The same problem exists as for the Expand tabs option. You won't remember to switch it off when editing a file where you do want to preserve or insert tabs.
I only care about indenting blocks, and about these types of files:
files indented with tab only
files indented with space only
So instead of a new option, couldn't EDP follow the same strategy as for newlines? If it detects that the leading white space character is space, then the tab key indents with spaces. If it's a tab, it indents using tabs.
Sure there may be files with a mix of whitespace characters at the start of lines, just as there may be different line endings throughout a file. These files will look bad given the varying opinions on tab size that different programs and people have. There may be tabs not at the start of lines. EDP should just leave those as is IMO.
And there may be files without any indentation yet, but then why would you start indenting with EDP?
So instead of a new option, couldn't EDP follow the same strategy as for newlines? If it detects that the leading white space character is space, then the tab key indents with spaces. If it's a tab, it indents using tabs.
I think it's too harsh. EDP's default behavior (i.e. without 'Convert tabs to spaces' option) is to preserve the file. I believe if EDP starts changing white space the way you described, many users will be upset about files suddenly being changed as a result of saving them in EDP.
I definitely don't want EDP to change anything. You describe exactly why I think the 'Convert tabs to spaces' option (not 'Expand tabs' as I incorrectly wrote earlier) was a bad idea. I was upset when EDP converted tabs in Visual Studio .dsp files and in makefiles. I expect 'Convert tabs to spaces' to apply to the tab key (and its nice block indentation), not to convert existing tabs in files far away from any line you edit or merge. Maybe that's what the author of wish list item "Option to convert new tabs to spaces" aimed at too.
The way the EDP editor and merger handle new end-of-lines is perfect to me and if they would operate likewise on the start of lines, both 'Convert tabs to spaces' and 'convert new tabs to spaces' should be banned forever.
Maybe that's what the author of wish list item "Option to convert new tabs to spaces" aimed at too.
This is correct.
The way the EDP editor and merger handle new end-of-lines is perfect to me and if they would operate likewise on the start of lines, both 'Convert tabs to spaces' and 'convert new tabs to spaces' should be banned forever.
I have to disagree with you here. Take a look at Textpad (if it proves anything -- but I hope you'd agree that it's a very popular text editor): it has both options, although they are more explicitly named "Convert new tabs to spaces" and "Convert existing tabs to spaces when saving files".
My apologies for apparently having posted this under announcements.
I haven't used Textpad. If it's as good as it claims, it allows different values for those options for different file types. Even then I think EDP's paradigm of per file automatic end-of-line character detection is on a higher level of intelligence. Actually, vim does something similar and I bet Textpad does too. But I know of no editor that applies the same intelligence to start-of-line indentation characters.
I can't expect EDP to outclass all editors in addition to all comparison program. Splitting up the existing 'Convert tabs to spaces' into one for existing and one for new tabs is definitely welcome (I'll only care about the latter)
My apologies for apparently having posted this under announcements.
I'll try and move it to ExamDiff Pro Enhancement Suggestions and Bug Reports.
I can't expect EDP to outclass all editors in addition to all comparison program. Splitting up the existing 'Convert tabs to spaces' into one for existing and one for new tabs is definitely welcome.
