My thoughts on this are pretty straight-forward, and it looks like you've got some of the same ideas in the ticket.
My suggestion would be to look for the use of several different line-endings in the same file and if found, display a dialog informing the user of the counts of each type of line ending with a radio-button next to each type. The default selection for this dialog could be several different things, depending on how you look at it. Anyhow... offer to change all endings to the selected ending, or ignore the discrepancy.
Of course, this feature should be able to be switched off in Padre's preferences.
Regarding the default selection in the dialog, I personally would have a "default line-ending for new files" setting in Padre's preferences with the usual options, and the default of the dialog would be whatever this was set to.
Something that could be nice for newbies could be to somehow annotate, both in Padre's prefs and in the "mixed line-endings" dialog, what the "native" line-ending is for their platform.
Something else I'd probably add is perhaps a little help-button to explain to the novice *why* having mixed line-endings is a bad idea and why it should be fixed, along with what could go wrong (yep, I've seen programmers mix them *on purpose*, with the code depending on it, the bastards ...)
So, that's my $.02... I'm no design guru but I play one on TV. | [reply] |
What does the proton-ce guy do?
The way Scite (Sc1)
handles this is by letting the user chose line end characters
and/or converting the file (search/replace). | [reply] |
I did not ask what to do but how to do it.
| [reply] |
Ouch. That was uncalled for.
[]s, HTH, Massa (κς,πμ,πλ)
| [reply] |
I'll tell you, as a user of editors, I don't want my newlines changed. I run Linux and when I edit a windows file, I'm doing it for a good reason and I want the new newlines to be the same as the newlines that were there when I opened the file. Which is what happens with both emacs and gedit. If that's not what happens, I look for a new editor.
As far as detecting the value of \n, I think you're trying too hard not to reinvent the wheel. Deciding which of the 3 endings a file uses is, imho, a job for a regex, not a module.
Personally, I've never encountered a file where mixed newline types would be anything be a corrupt file. For fun, I'll imagine printing a file for a win client out of a mod_perl module that runs on linux. Well, the windows EOL would be contained in quotes and/or escaped so the obvious *NIX dominance should prevail. Of course, I could be missing an important use case here.
That said, an option to convert EOL to various formats would be a nice option to offer.
| [reply] |
Hi rowdog,
Indeed any application called "editor" ought to convert eol's only on demand.
FYI I did once encounter a CA Unicenter Software Delivery command line output on win32 where a sole \r was used and required in the middle of a specific line. Win32 interpreted it as a "space" and the application really needed it as such for I/O. :-( Officially it worked as designed due to its crossplatformness :p
.
Greetings
ddn123456
| [reply] |
