Version: (using KDE KDE 3.5.6) OS: Linux Steps: 1. Open a text file in Kate or KWrite. 2. Change its line-ending convention from the Tools > End of Line menu item. Expected: The file should be marked as [modified]. Actual: It is not marked as [modified].
nothing changed in the buffer. it only has affect, if you save the file explicitly. right now we only have typing stuff in the undo history and no actions.
... but it should, as otherwise it is possible to close kate without a warning, and the change is lost.
I like it the way it is. The change does not alter the buffer, if we would mark as modified, we need to implement undo for that, too. Agree with dominik, won't change that behaviour.
Whether it alters the buffer or not is not the matter. Whether it alters the potential *contents* (i.e. bytes) contained in the file is the matter. An editors serves to help the user alter the contents of a file, and the buffer is merely a detail of implementation thereof. Keep in your mind the purpose of the editor. The point is that the user has made this selection (of changing the line ending) with a clear intent of changing the contents of the file. Some text utilities (on Windows) expect CRLF line endings, some expect LF, and it makes a real difference. If you do not warn the user that he has not saved the changes he/she made, you are not helping him/her, and your warning system is incomplete. Further, saying that the undo history only works for typing stuff and not for actions is not entirely accurate. Do a "Join lines" script, and that's not "typing", it's an "action", but it causes a new undoable change. You might argue that it changes the buffer, and so it is undoable. Again I say what changes the buffer is not the matter, what changes the contents of the file on disk is the matter. Therefore, WONTFIX is unjustified. Just because you would need to implement undo for that does not mean you can close this bug as WONTFIX. Reopening it. What's more, the same should be done for encoding too. If the user selects a different encoding, he wants the bytes to change. If you don't warn of not saving that change, again your warning system is incomplete. If you want, I can open a separate bug for that.
I agree that this bug needs to be fixed. I was going to report this bug myself, then I found its already reported here. I'm surprised that this bug has been reported but has not been fixed. I copied a dozen files over from Windows, and opened them in Kate. I spent some time going through them all, changing the line endings. I used Save All, and expected these files to be saved, with the changed line endings. Later I found the line endings had not been changed permanently, so I opened Kate and tried it again. I tried this a few times, spending a lot of time trying to get the changed files saved. Eventually I found that the only way to save the line endings is to modify each file, by typing in a space character into each file. Then when I do "Save All", the changed line endings are saved. For me it is very important that the changed line endings are saved. I need to use the correct line endings so that I can trace through script files with a debugger. Without the correct line endings, I cannot use the debugger, and I would be unable to continue work on my program. I cannot imagine that anyone would change the line endings in Kate, but not want these changes saved to file. To change these line endings, but have the changes discarded when Kate exits is clearly a waste of time.
It occurs to me, I can see where I would prefer that changes to the file encoding (by which I mean, how it is represented on disk, which includes character-set encoding and also line endings) not get undone with 'undo'... though of course I can see it the other way, also. At any rate, I strongly agree that such changes should be considered modifications. Would it be too unreasonable to have a second change mode, so we have "buffer changed" (undo-able) and "representation changed" (not undo-able)? We could maybe use "+" instead of "*" for the latter, and of course "buffer changed" would supercede "representation changed" (i.e. don't show both indicators).
I would stay with one modified indicator. And just keep the document in the modified stayed still reloaded or saved, independently of undo/redo steps
I also support one modified indicator. All the indicator shows to the user is "This file needs to be saved!" Whether the content or the (byte) representation is changed is not the matter. Further, these changes of encoding or line endings should not be undo/redoable as from the user's POV undo/redo is for content which they (or someone else) type, not for representation which one does not really "type".
fixed for kde 4.7.