[TxMt] A few things that annoy me

[Ivar Åsell]

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