Version: 2.2 (using KDE 3.1.93 (3.2 beta 1), Gentoo) Compiler: gcc version 3.3.2 20031022 (Gentoo Linux 3.3.2-r2, propolice) OS: Linux (i686) release 2.4.20-gentoo-r8 it used to work in kde-3.1.4 but since i upgraded to 3.2beta, this functionality has disappeard. the description in Bug #48315 is right on, but that one's been closed, so i'm posting this one. note that saving the file does in fact nuke all the excess space, it's just that the spaces aren't removed "on the fly".
This was changed intentionally. I'm not sure of the reasoning as to why, as it wasn't me that changed it. I have however grown accustomed to it. Not sure if this is a WONTFIX or whether we should add the old behaviour as an option?
o please put it back! at least as an option... it was practically my favourite feature in kate.
we could reintroduce it for some later kde version as config option, but could you explain why it is important that the spaces are removed while editing/viewing ?
I like no trailing spaces ... _ever_ :) They must die. There's two scenario's that can be distinguished 1) Lines that are just whitespace -- the most evil of all sins These lines should never exist. It seems that to not interfer with the undo system here (I think that's the problem wasn't it?) that the cursor should be 'virtually' placed at the indention level and only when you hit a printable character should the indention be commited to the buffer. This way there is really nothing to 'undo' and dead lines never exist in the first place. 2) Trailing whitespace at the end of a line Remove it unconditionally without regard to 'undo' But I also agree that, if the above is not an option, the document you currently see on-screen matches what's on disk. This means that if I save some random file and I have "Strip trailing whitespace" on, that there should be _no_ trailing whitespace in my view. I would consider it almost a filter that is actively applied to my file -- and I expect modification to occur. Ideally, it's best have kate guard against trailing whitespace during the editing so not to leave it until the end. *shrug*
Subject: Re: deselcting "keep extra spaces" in kate no longer deletes extra spaces when the cursor leaves that line hmm, me used the "keep extra spaces" in other intention ever: I wanted to have some clean file on disc, after save, I never liked the desribed "cleaning up while editing", the extraspaces at the end of lines really doesn't hurt while editing the text, for me, they are often even wanted to stay where they are :P As the current "keep extra spaces" option is under open/save, automatic cleanups, should be clear to the user that the behaviour is intended. If you really need/like/love the old behaviour, would have no probs to add such an option to the editing "remove trailing spaces on the fly" or whatever, as long, as each removal of some space goes into the undo buffer, as IT is ;) important to have them, if you undo all changes, I expect to get the 1:1 of my original cu Christoph
for me it's a matter of ease of use and cleanliness. i like my code clean -- even the spaces. lines full of spaces drive me mad while i'm coding, so much that when i upgraded to 3.2beta i went around manually deleting all the extra white space while i typed. sure, i know it'll all get nuked when i save and close, but with the auto-indent feature enabled, the doc can get too "messy" real fast.
btw., lets move over this "bug" into wishlist area
I like it very much. I think it will be very bad (for me) if it is missing. So here is the reason why this feature is usefull. Sorry for my bad English i will give my best to understand reasons why I use it ... 1. When you have trailing spaces and hit End key you DO NOT go to last typed char but to the end of line (where we have 100 spaces after the last char) and you have to go to the end of the line by hand. 2. When you have 2 lines one by another and you want to move second line at the end of the first line if you do not have trailing spaces it is a matter of hitting Del key at the end of the line but now you also have to clear spaces betwean them
This is certainly a big bug and not a "wishlist". I would call it a regression. For me, on 3.2rc1 trailing whitespace is removed neither "on the fly" (the way I prefer it) nor on saving (as the Setting suggests it will be.) I could live with it removing the extra spaces on save only (although it would be non-optimal) but now it does not even remove the spaces on save, and the editor becomes much less useful to me.
Well, it is removed on saving, but that is only on-disk - you have to press F5 to reload the buffer for it to take effect. I guess there's a possibility that we could put this back in branch, but there will have to be a pretty good argument (ie. lots of people considering this a regression) for it to go back in. For 3.3 / 4.0 we will have this back, and better (no more undo bugs etc).
Having to reload to see the effect of the space removal is no good because you lose your undo/redo history.
Now, in 3.2.0 final, the trailing whitespace _is_ removed when the file is saved. However, when the whitespace is removed, the file is marked as "changed on disk by another program" which is not really quite right, since it was kate that made the change. (Although it is true and important that the file on disk and the file in the buffer are now no longer the same)
Actually (sorry) the removal of trailing spaces still does not always happen, but when it does I get the "modified on disk" behaviour.
I prefer the 'remove spaces on the fly' option to the 'remove spaces on save' option. If I've pressed Enter with auto-indent enabled, I've moved the cursor away and back, and I want my tabs back, I just press Backspace and Enter again; losing tabs like that is no inconvenience to me at all. The latter option does introduce another* rift between saved and loaded views, which I don't like. Therefore I think the former option should be available. (*There is an existing rift when not all characters are supported in the encoding used to save the file ...) I think it goes without saying that when a 'remove white space on the fly' option is selected, the current line should also be cleaned before any save occurs (I don't know if the old code did this). I am happy for the removal of spaces from a line to need undoing explicitly. In fact, at the risk of veering off topic, I think it could go further than that. After moving the cursor away from the point of last edit, and perhaps scrolling halfway through the document, I'd like to be able to press Ctrl+Z just to get back where I was without changing anything. RHIDE (an IDE for DJGPP) did this, and it was very nice indeed. (But don't store a 'move cursor' event after an undo, because that would clobber the redo buffer.)
*** Bug 77500 has been marked as a duplicate of this bug. ***
Please put back the "remove trailing spaces on the fly" option. I'm going mad because my code is full with those spaces, and that the file in the editor and on the disk differs. Even if I know that it's harmless. I have all those problems that was described above, the End doesn't go where it should, etc. I think you should not remove such features, as I see kate tries to be programmer's editor, and as such it must be well customizable. Thanks.
"Keep extra spaces" is in the indent config page, and has nothing to do with trailing spaces. I have changed the saving code, so that the tab replacing and trailing space removing becomes instantly visible in the document (and also added to the undo stack). I can't add new features for KDE 3.2.x, but I have working implementations of "insert spaces instead of tabs" and "remove trailing space" that will be available for KDE 3.3.
It would be very nice if we didn't have to wait until KDE v3.3 to have a Kate that displays, within the editor, the same file that it stores on disk when you issue a save directive. This shouldn't be an option! There is no need to create an extra [ ] Get Rid of Extra Spaces on the Fly option. KDE 3.3 looks a long way off. Is a KDE 3.2.2 planned? If not, I guess we'll have to wait. If so, I'd be really bummed if this bug wasn't fixed. Kate is one of my favorite tools. Keep up the awesome work! Sean.
As I said above, I have fixed the saving. From KDE 3.2.2, which will get tagged this week, removing sapces and replacing tabs will work, and be immediately visible when yous ave your document.
I shouldn't be only when the document is saved, because, for example, when we want to use the End key to get to the end of one line, we go to the end of the spaces... and we have to alternatives: either we save each time we want to move the cursor, or we delete the spaces manually. Not removing spaces on-the-fly is a regression. It can decrease productivity.
My previous comment should be read: "It shouldn't be only when the document is saved, because, for example, when we want to use the End key to get to the end of one line, we go to the end of the spaces... and we have two alternatives: either we save each time we want to move the cursor, or we delete the spaces manually. Not removing spaces on-the-fly is a regression. It can decrease productivity."
no comments have been made to this bug in a long time and since i'm the guy who reported it and i have no issues with how it's been handled (extra spaces go away when you save in kde3.3) i'm resolving it. if someone is really desperate for the former functionality, i leave it to them to re-open it.