Thanks for the article on writing micro-content subjects, hopefully I'll write better headlines in the future.

On 2005-01-19, at 22.29, Allan Odgaard wrote:

On Jan 19, 2005, at 18:35, 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, for example to give it a new date stamp to trigger recompile of that file.

Isn't it against apple's HIG or something? It feels so incredibly wrong to me :P Isn't it easier to just make a command for those who want to recompile a file by modifying access date? It would look something like this: touch $TM_FILENAME 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 don't want to save a file just to try out a different encoding. Many times per day I open files where my special swedish letters åäö is messed up because applications like SSE doesn't save the file properly for TM to understand which encoding it uses so it gets wrong all the time. I'd really really like to see "reinterpret this file with encoding: "

If I understand you correctly, that's what the “Re-open with Encoding” sub menu does.

No.

...

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. Excuse me if I sound irritated and such but I am kind of lousy at expressing myself and explaining things. Sorry :(

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.

...

A Document saved by SSE as ISO-Latin1 and open by TM is recognized as that encoding. But saving the file with TM now magically changes the file to UTF-8.

This appears to be a bug. If you go to Preferences / Advanced and set the encoding to ISO-8859-1 there (under Saving) it will use that instead when possible -- I'll look into it probably tomorrow.

Ok at least something productive from me then :)

Kindest Regards Ivar

And btw, please read http://www.useit.com/alertbox/980906.html about writing proper subjects!

---

For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate

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...

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.

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

Allan,

For what its worth, I really like how TM does save now. When I tell it to save, it had better save ; ) I always refer to the project drawer in my peripheral vision which indicates when a file has become 'dirty'. Besides I neurotically hit cmd-S after all my edits anyways. The direct nature of TM's behavior gives it a *nix flavor that I really love, unlike a lot of other tools, e.g., Adobe products (which I also use and enjoy). Hopefully TM will always stay lean, mean, and fast.

---

For new threads USE THIS: textmate@lists.macromates.com (threading gets destroyed and the universe will collapse if you don't) http://lists.macromates.com/mailman/listinfo/textmate