[TxMt] A few things that annoy me

[Allan Odgaard]

On Jan 19, 2005, at 23:30, Ivar Åsell wrote:

>>> 1.
>>> I want "File-->Save" to be disabled when a file just has been opened 
>>> or saved. [...]
>> There are situations where at least I want to save a non-modified 
>> file [...]
> Isn't it against apple's HIG or something? It feels so incredibly 
> wrong to me :P

Interestingly how I have to hear AHIG when TM does something undesired 
;) anyway, AHIG is public and here's all I can find on the Save menu 
item:

    Save (Command-S). Saves the active document, leaves the
    document open, and provides feedback indicating that the
    document is being (or has been) saved. If the document has
    not previously been saved, display a Save dialog (see “Save
    Dialogs”).

> Isn't it easier to just make a command for those who want to recompile 
> a file by modifying access date?

You have a funny definition of 'easier'. :)

> In all programs I've ever used the save field is grayed out after you 
> have saved, indicating that the save was successful and you can't save 
> again until you have modified the file.

I actually couldn't find a single program which behaves like that. I do 
however remember having been bitten by such in the past.

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 don't want to save a file just to try out a different encoding.
> Re-Open doesn't let me play around with a file without saving it 
> between different test of encodings
> There are two ways to change the encoding of a file...
> 1. Convert the current encoding into another
> 2. Reinterpret current encoding into another
> Currently TM supports the latter, but by saving the file and 
> re-opening it.

What is your working pattern? Is it that you load a file which is 
estimated to have an incorrect encoding, you type into this file before 
you realize that it was loaded with the wrong encoding, and it is then 
that you save and re-open the file, and would have preferred not to 
need to save it first?

This is the only situation that I can think of where you'd want to 
change the buffer's encoding. But it's certainly not something I 
recommend, as it may actually end up destroying your special 
(non-ASCII) characters.

If you have problems that TM doesn't estimate the proper encoding, I'd 
strongly recommend you switch to UTF-8, which is highly unlikely to not 
be recognized. And if you can't for some reason use UTF-8, you should 
check that TM estimated the correct encoding before you start to modify 
the file.

> Have you tried out SSE encoding menus? They are really as simple as it 
> comes and with all features associated with encodings that I can think 
> of.

No sorry, haven't tried that. Though the way TextMate works is that it 
converts whatever file you load into unicode and LF line endings, and 
keeps it like that internally. Then when you save, it converts the 
internal unicode/LF buffer into what is requested by the user.

So to load a file, modify it, and then change encoding, is analogous to 
decoding a JPEG image as PNG, modify the white noise, and asking the 
application to change the compression/file format to JPEG ;)

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.