On Jan 19, 2005, at 23:30, Ivar Åsell wrote:
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...
- Convert the current encoding into another
- 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.