On 2005-01-20, at 05.25, Eric Ocean wrote:
Cocoa apps don't, unless the author specifically does something. When they do, it can be a PITA, as when MacJournal disabled the save item and thus every unnecessary save attempt resulted in the Cocoa "beep". I'm a compulsive saver and it got so bad that I had to turn on visual alert sounds just to work around that one app.
I would use that beep as feedback. "Ah, it's now successfully saved"
On 2005-01-20, at 06.03, Lang Riley wrote:
For what its worth, I really like how TM does save now. When I tell it to save, it had better save ; )
On 2005-01-20, at 04.40, Allan Odgaard wrote:
Having a program refuse to do X because it _thinks_ X is redundant is normally a bad idea IMHO. And since I personally _do_ need X when X = Save, then you're unlikely to convince me of the usefulness of blocking it, sorry.
I'm starting to like this feature too now that I know more specifically what it does. I honestly thought this was just a minor bug at first but now I see how it can be useful even for me :)
On 2005-01-20, at 04.40, Allan Odgaard wrote:
I have considered to use a piece table internally for TextMate, which would store the raw file in memory w/o converting it first (so it would save time & memory, since most files are larger after conversion, and allow for i/o mapped files), and then edits are basically stored as differences. But it has worse access time than the current scheme, though it's something I'd like to experiment with -- however, at present I don't think I should spend my time on such things, as the user benefits are unnoticeable for most.
I don't know how SEE does it, but I know that one user asked for the ability to change line endings on-the-fly, but not as in SEE, where changing it after having loaded the file would result in only new lines being with the changed-to line ending -- so while I do not know if the user was correct, it doesn't sound like it follows the same scheme as TM with the internal representation in unicode/LF. I would imagine that with the requirement to keep 'document owner' for arbitrary segments with a “local” undo stack, it is not entirely unlikely that their internal structure does allow each segment to have its own encoding, and the original document to be interpreted on-the-fly only, instead of converted at load time.
Lost me :) I'm no professional programmer yet, maybe that's why The way I interpreted it is that converting the current buffer into another encoding (without saving it at the same time) is something one should not want to do. Excuse my bad english and my sometimes lousy understanding of it.
Kind Regards Ivar