Hi,
Would it be possible to have included files in code-completion settings in the theme editor.
I'm thinking of making property-specific completions for the css syntax, and it would be helpful if frequently used sets of keywords could be included as often as necessary to avoid it being really massive. (things like colours, units, top left right etc.)
Also, on a similar note, would it be possible to block general completions for a specific scope, ie. have a property such as "use_general_comps" which could be set to 0. I find that pressing escape often brings up options that shouldn't be present in the particular scope, but are in other parts of the document. eg: .blah { font-color: black; } #foo { display: b<esc> }
Pressing escape after "display: b" would offer "block", as part of the 'display' property's completions, but would not suggest "blah" from the class of the other selector, or even "black" from the font- color's value. In a big file you can end up going through loads of unnecessary stuff when one press is all that's necessary. (I know i could type "blo" and then esc, but that's more typing).
In my opinion, for the way I work, this would be a very fast system of coding.
Thanks, Max
On May 22, 2005, at 18:34, Max Williams wrote:
Would it be possible to have included files in code-completion settings in the theme editor.
I'd rather make it so that you can specify a callback instead. Then to get the include functionality your callback could possibly be: “grep ^"$TM_CURRENT_WORD" my_list.txt”. Perhaps even using the $TM_SCOPE to figure out which list to use, or add parts of the scope to the grep.
In the future I'll open up for having scope specific settings in the bundles instead of only the theme editor, then lists of keywords can be kept in the proper bundle.
Also, on a similar note, would it be possible to block general completions for a specific scope [...]
Yes, I can add that (probably b10) -- I've been wanting something like this myself :)
Thanks, Allan, my first point was actually the one I wasn't too bothered about. blocking scopes was my main objective in that request. so I'm very happy that you agree :).
Yes, I can add that (probably b10) -- I've been wanting something like this myself :)
On a similar note, would it be possible to have a bunch of completions for a scope but not for its contained elements. eg: scope= foo, !foo bar
I think I remember someone talking about this but can't remember the result.
regards, Max
On May 23, 2005, at 19:56, Max Williams wrote:
On a similar note, would it be possible to have a bunch of completions for a scope but not for its contained elements. eg: scope= foo, !foo bar
What you can do is make a new setting with scope “foo bar” and just set the completions to an empty list.
On 23 May 2005, at 20:34, Allan Odgaard wrote:
What you can do is make a new setting with scope “foo bar” and just set the completions to an empty list.
thanks for the tip. I had actually noticed that scopes couldn't have more than one set of completions but thought it was a bug :). regards, max
On May 23, 2005, at 22:52, Max Williams wrote:
What you can do is make a new setting with scope “foo bar” and just set the completions to an empty list.
thanks for the tip. I had actually noticed that scopes couldn't have more than one set of completions but thought it was a bug :).
In the future I may add “_add” and “_sub” to the settings key to modify existing values, but currently it's always a full override of the setting.
was going to try to talk to you on irc, but my internet connection only seems to be staying active for about ten minutes at a time today :(.
would it be possible to have a variable that lists all the completions for a certain scope? I'm thinking along the lines of displaying a tooltip...
regards, max
On May 23, 2005, at 23:27, Max Williams wrote:
would it be possible to have a variable that lists all the completions for a certain scope? I'm thinking along the lines of displaying a tooltip...
Only the completions set as a scope setting, or also the completions gathered by TM?
The latter is not good, because then I'd have to gather completions for each shell run (doesn't scale). For the former, I was thinking along the lines of making available all settings for a given scope, since it might be useful for debug purposes and it opens up for possibilities similar to what I did with the toggle comment for b10 which required I added shell variables as a scope setting, but if the command could access all the settings for the current scope, that wouldn't have been necessary.
-
Allan Odgaard -
Max Williams