I'm interested how it would be possible to create an autocompletion plugin/bundle for Textmate and ruby. I realize there is ESC, but I would like to open a menu with say CTRL-SPACE and then see all the possible completions based on the entered characters. Then when I continue typing in the editor, the menu adjusts it's contents to show only the matching entries. The user can navigate the menu and choose an entry to be inserted in the editor. Like auto completion in eclipse, Visual Studio or XCode.
I found this article: http://macromates.com/blog/archives/2005/06/09/code-sense/ and wonder what the actual state of code sense is in Textmate. Is it possible to create a Plugin/Bundle that controls an auto completion menu?
Ruben
The file tabs are annotated with a dot or cross to show if the file has been edited. I find I have to read the tabs to find dirty files rather than just seeing then automatically.
I don't think the correspondence of dot and cross to edited and un- edited is obvious or natural and it would be better to no show any annotation for un-edited files. Colouring the name of edited files would also make it much easier to see at-a-glance if something was dirty.
Dave.
Dave Baldwin wrote:
I don't think the correspondence of dot and cross to edited and un- edited is obvious or natural and it would be better to no show any
Actually, I think it's obvious, given that the red close button in all OS X apps behaves the same way. (Except you only get the cross when moving the mouse pointer near it.)
Regards, Christopher
On 22 Feb 2006, at 13:32, Christopher Creutzig wrote:
Dave Baldwin wrote:
I don't think the correspondence of dot and cross to edited and un- edited is obvious or natural and it would be better to no show any
Actually, I think it's obvious, given that the red close button in all OS X apps behaves the same way. (Except you only get the cross when moving the mouse pointer near it.)
i.e. the button is empty when there is nothing to do (to save your work), but is marked always when you need to do something. It gains a close symbol (cross) when you mouse near it (and you have noting to do) to give some weak idea of what an arbitrary coloured button does. Plenty was written why this is poor UI design when OS X was first released - beauty over function.
With TM the invisible button (holding the dot or cross) is marked when you have nothing to do and when you have something to do. When you mouse close to the button it appears.
Anyhow my real point was you couldn't instantly see which files needed saving without having to read along the tabs. Try having a dozen or so files open and the odd one or two dirty. Using colour and/or a symbol / no symbol to show this works much better than using two symbols, one of which is always showing.
Dave.
Regards, Christopher
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
I think this observation is key:
On Feb 22, 2006, at 6:01 AM, Dave Baldwin wrote:
On 22 Feb 2006, at 13:32, Christopher Creutzig wrote:
Anyhow my real point was you couldn't instantly see which files needed saving without having to read along the tabs. Try having a dozen or so files open and the odd one or two dirty. Using colour and/or a symbol / no symbol to show this works much better than using two symbols, one of which is always showing.
Dave.
I'm sure there must be some sort of Interface Design Rule about this. You don't need a mark/alarm/indicator to show when an item is in a "safe" state... you only need to change the presentation from a normal one when you need to indicate an UNSAFE (warning) state. I recall a discussion of the design of instrumentation for needle read- outs in an airplane cockpit. In this case, all the instruments were designed so that if the needle pointed to "3 o'clock" that indicated a "normal" condition, regardless of what was being measured. The benefit was that the pilot did not need to "read" each individual gauge. Instead, with a glance, they could instantly detect a problem and home in on it.
One problem is that the "close" widget on the tabs is doing double duty by also indicating whether the file has been saved or not. That's "overloading an affordance" ... or something. I think it's illegal! ;)
It would probably be MUCH easier to quickly scan a number of tabs and understand which files were dirty if the "dirty" indicator were separated from the "click here to close this tab" indicator. For example, if "click here to close" ALWAYS showed as an "x" and "dirty" was indicated by underlined or bolded text in the tab.
eo
On Feb 23, 2006, at 12:16 AM, Eric O'Brien wrote:
I think this observation is key:
On Feb 22, 2006, at 6:01 AM, Dave Baldwin wrote:
On 22 Feb 2006, at 13:32, Christopher Creutzig wrote:
Anyhow my real point was you couldn't instantly see which files needed saving without having to read along the tabs. Try having a dozen or so files open and the odd one or two dirty. Using colour and/or a symbol / no symbol to show this works much better than using two symbols, one of which is always showing.
Dave.
I'm sure there must be some sort of Interface Design Rule about this. You don't need a mark/alarm/indicator to show when an item is in a "safe" state... you only need to change the presentation from a normal one when you need to indicate an UNSAFE (warning) state. I recall a discussion of the design of instrumentation for needle read-outs in an airplane cockpit. In this case, all the instruments were designed so that if the needle pointed to "3 o'clock" that indicated a "normal" condition, regardless of what was being measured. The benefit was that the pilot did not need to "read" each individual gauge. Instead, with a glance, they could instantly detect a problem and home in on it.
One problem is that the "close" widget on the tabs is doing double duty by also indicating whether the file has been saved or not. That's "overloading an affordance" ... or something. I think it's illegal! ;)
It would probably be MUCH easier to quickly scan a number of tabs and understand which files were dirty if the "dirty" indicator were separated from the "click here to close this tab" indicator. For example, if "click here to close" ALWAYS showed as an "x" and "dirty" was indicated by underlined or bolded text in the tab.
I'd like to add a mild complaint about the way unsaved files are denoted in a window without tabs. The slight dimming of the icon next to the filename in the titlebar is not a distinct enough indicator. It's OK when you have several windows up on the screen and can compare dimmed to undimmed icons, but when you have nothing to compare to, the state of the file is not obvious (not to my middle- aged eyes, anyway).
I'm assuming that, like me, Allan doesn't consider the dot in the middle of the red close button to be a sufficiently "loud" indicator, otherwise he wouldn't have added his own.
-- Dr. Drang
On 23/2/2006, at 15:33, Dr. Drang wrote:
I'd like to add a mild complaint about the way unsaved files are denoted in a window without tabs [...]
This should go to https://bugreport.apple.com/ (yes, they accept constructive criticism there as well).
For the records, I dislike the faint dimming as well.
On Feb 24, 2006, at 5:21 AM, Allan Odgaard wrote:
On 23/2/2006, at 15:33, Dr. Drang wrote:
I'd like to add a mild complaint about the way unsaved files are denoted in a window without tabs [...]
This should go to https://bugreport.apple.com/ (yes, they accept constructive criticism there as well).
For the records, I dislike the faint dimming as well.
Ahh, I thought the dimming of the icon in the titlebar was yours. I don't recall seeing it in any other program. My apologies for attributing it to you.
-- Dr. Drang
Btw, the dimming of the file icon is primarily to indicate that it is not draggable, not to communicate the saved/unsaved state of the file. File-based document windows that show an icon allow you to command+click on the file to see the path to it and allow you to drag the icon off to move / alias / copy it.
For new, unsaved documents, the icon is dimmed to indicate that this feature is disabled because no physical file exists.
For changed, unsaved documents, it is disabled to prevent you from operating on the file. Because you might assume the file would have the changes currently represented in the open document, but they wouldn't, since you haven't saved them.
I've wondered if they might someday offer the ability to drag an unsaved file regardless, invoking a "save a copy" behavior upon dropping it someplace... but I'm not familiar enough with the interfaces at work here to know if that's even feasible or not.
On Feb 24, 2006, at 3:21 AM, Allan Odgaard wrote:
On 23/2/2006, at 15:33, Dr. Drang wrote:
I'd like to add a mild complaint about the way unsaved files are denoted in a window without tabs [...]
This should go to https://bugreport.apple.com/ (yes, they accept constructive criticism there as well).
For the records, I dislike the faint dimming as well.
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 Feb 24, 2006, at 11:43 AM, Brad Choate wrote:
I've wondered if they might someday offer the ability to drag an unsaved file regardless, invoking a "save a copy" behavior upon dropping it someplace... but I'm not familiar enough with the interfaces at work here to know if that's even feasible or not.
Technically, it's feasible, but it becomes complicated to communicate to the user exactly what the state of the data on disk would be, and in which copy. You really don't want to be confused about where your data is.
Chris
On Feb 22, 2006, at 22:16, Eric O'Brien wrote:
One problem is that the "close" widget on the tabs is doing double duty by also indicating whether the file has been saved or not. That's "overloading an affordance" ... or something. I think it's illegal! ;)
Somehow this interface isn't a major concern for me since I know I can always do Cmd-Opt-S to save all, so I don't consider it a "critical" status indicator in the same sense as an airplane gauge.
I like your dashboard analogy, but a counter-argument would be that stuffing too much status information into the tabs would also make them look too cluttered and confusing, thus more likely to be overlooked.
But since we're talking tabs, I'd like to see numbers on them when I hold Cmd, to indicate the keyboard shortcut for jumping to them. Beyond 5-6 it's hard to spot them at a glance and forces me to count on my fingers. ;^)
-- Andrew Vit
On 23/2/2006, at 21:40, Andrew Vit wrote:
[...] I'd like to see numbers on them when I hold Cmd, to indicate the keyboard shortcut for jumping to them. Beyond 5-6 it's hard to spot them at a glance and forces me to count on my fingers. ;^)
Conditional disclosure of the numbers sounds like a good idea (better than having them permanently there) -- one problem is that you use command for a lot more than switching tabs (through numbers), so these numbers would show on a lot of keyboard actions, and are likely to be a bother for most users (because part of the interface blink/ flashes when using the command modifier key).
Allan Odgaard wrote on 2/24/06 6:25 AM:
On 23/2/2006, at 21:40, Andrew Vit wrote:
[...] I'd like to see numbers on them when I hold Cmd, to indicate the keyboard shortcut for jumping to them. Beyond 5-6 it's hard to spot them at a glance and forces me to count on my fingers. ;^)
Conditional disclosure of the numbers sounds like a good idea (better than having them permanently there) -- one problem is that you use command for a lot more than switching tabs (through numbers), so these numbers would show on a lot of keyboard actions, and are likely to be a bother for most users (because part of the interface blink/ flashes when using the command modifier key).
Maybe the numbers could show up whenever someone switches tabs via the keyboard, e.g. via Cmd-opt-right, or Cmd-4.
On Feb 24, 2006, at 3:25, Allan Odgaard wrote:
Conditional disclosure of the numbers sounds like a good idea (better than having them permanently there) -- one problem is that you use command for a lot more than switching tabs (through numbers), so these numbers would show on a lot of keyboard actions, and are likely to be a bother for most users (because part of the interface blink/flashes when using the command modifier key).
A slight (half-second?) delay before showing the numbers might work nicely. This way, quick key commands wouldn't cause a flash, and slower multi-modifier (Cmd-Opt-Ctrl-Shift) "chords" shouldn't make it a distraction either since we're probably just looking at our hands by that point anyway...
For those who don't like this behaviour, the preferences window still has room for one more toggle!
--Andrew
On 23/2/2006, at 7:16, Eric O'Brien wrote:
One problem is that the "close" widget on the tabs is doing double duty by also indicating whether the file has been saved or not. That's "overloading an affordance" ... or something. I think it's illegal! ;)
It would probably be MUCH easier to quickly scan a number of tabs and understand which files were dirty if the "dirty" indicator were separated from the "click here to close this tab" indicator. For example, if "click here to close" ALWAYS showed as an "x" and "dirty" was indicated by underlined or bolded text in the tab.
The close button on the tabs mimic the window close button with one exception: the tabs always show the x, where the window only show it when you hover the mouse near it.
This is done because there is no outline/button in the tabs which indicate “you can click here” as with the window’s close button.
I don’t follow your accusations of overloading the button with status indicators, or how it differs from the flight control panel. The button has exactly two states: safe (cross) or unsafe (circle).
You neglect the principle of consistency with the rest of the UI. Making text bold or underlined to indicate that something is unsaved or unsafe, is not drawing on the users experience with the rest of OS X.
If anything should be changed, I would say the cross should be replaced with an open circle, to make the two symbols more distinct (and then show the cross inside the circle, when the mouse hovers over the button) -- but I think the loss in aesthetics from this does not make up for what is gained in usability.
You might btw be interested to know that the file manager image shown at my blog [1] has the list header pop-up contain an “open files” option, which show only open files in the list, where modified status is generally easier to pick up from skimming it.
[1] http://macromates.com/blog/archives/2006/02/15/future-directions/
Hi Allan,
Any plans for such an API? From the "code sense" article mentioned above, I understood such an API is in the works.
Ruben
On 2/22/06, Allan Odgaard throw-away-1@macromates.com wrote:
On 22/2/2006, at 10:14, Ruben Bakker wrote:
[...] Like auto completion in eclipse, Visual Studio or XCode.
There's no API for that.
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
Hi Allan,
I think that the possiblity to offer full auto completion would add a very important feature to TextMate. It would certainltly drive people from XCode and other Editors to TextMate. And it would open the possiblity to add even better language support (ruby, python etc.).
In short: it would be nice, if auto completion support would get high priority... Ruben
On 2/23/06, Allan Odgaard throw-away-1@macromates.com wrote:
On 23/2/2006, at 6:45, Ruben Bakker wrote:
Any plans for such an API? From the "code sense" article mentioned above, I understood such an API is in the works.
It was something I did work on, but it is currently on hold.
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
-
Allan Odgaard -
Andrew Vit -
Brad Choate -
Chris Thomas -
Christopher Creutzig -
Dave Baldwin -
Dr. Drang -
Eric O'Brien -
Jacob Rus -
Ruben Bakker