custom keyword coloring

custom keyword coloring

Post by Kurt Bigle » Mon, 21 Jul 2003 09:42:29



There are things about custom keyword coloring that have never worked,
particularly regarding the target-specific custom keywords.

I depend on this custom coloring being used globally, not just in project
files (or files in a given target), so I have actually hesitated to
complain, thinking the result might be that it gets fixed in a way that
makes the feature useless to me, whereas not it is simply awkward to use.

The problem is that the current global coloring is set (if I have this
right) by the last target for which any preferences panel is saved.  This
requires either maintaining the same set of 4 colors in dozens of targets
(prohibitive, if you ask me) or else picking a "special" target in which the
desired colors are saved and forcing them to take effect again whenever they
are lost (by another target's colors taking effect).  I usually restore the
colors by going into the "special" target's settings, chosing custom
keywords, changing a color, clicking save, changing it back, and clicking
save again.  Having written this I realize I could possibly change any
setting on any panel and save, since this is what apparently causes the
colors to be lost in the first place.

I am only using the target-specific settings because there are not enough
keyword categories (i.e. only 4) in the global custom keywords.  The
project-specific custom keywords are not really target-specific except for
the colors, i.e. the 4 keyword lists are global across all targets.  Target
specific colors alone strikes me as not very useful, and it would appear in
general that this feature was left half-implemented, perhaps for lack of
use.

As I recall there are other problems with the feature.  Changes to the
keyword list in a target can not be made to take effect until you also
change one of the colors, because the panel is not considered "dirty" and
the Save button is not enabled unless there is a change to one of the
colors.

Personally I would like to see more than 4 keyword lists in the global
place.  12 would be good for me.  I realize such usage may be rare, but
except for screen real estate I see no reason to keep the number down to 4.
The screen real-estate issue did not even exist until the custom keywords
were combined into the single syntax coloring panel.

I have special uses for these in an add-on language setting, and wish the
keywords lists could be set via apple events or even by saving to a file
somewhere rather than going into the panels and importing.

-Kurt Bigler

 
 
 

custom keyword coloring

Post by MW Ro » Wed, 23 Jul 2003 01:39:39




Quote:>There are things about custom keyword coloring that have never worked,
>particularly regarding the target-specific custom keywords.

>I depend on this custom coloring being used globally, not just in project
>files (or files in a given target), so I have actually hesitated to
>complain, thinking the result might be that it gets fixed in a way that
>makes the feature useless to me, whereas not it is simply awkward to use.

Been there done that :)

I understand that you want to have more color coding for custom
keywords,  but I think I got lost in the other stuff and I'm missing
something,  Can you let me know what you would like besides more keyword
colors?

Ron

Quote:>The problem is that the current global coloring is set (if I have this
>right) by the last target for which any preferences panel is saved.  This
>requires either maintaining the same set of 4 colors in dozens of targets
>(prohibitive, if you ask me) or else picking a "special" target in which the
>desired colors are saved and forcing them to take effect again whenever they
>are lost (by another target's colors taking effect).  I usually restore the
>colors by going into the "special" target's settings, chosing custom
>keywords, changing a color, clicking save, changing it back, and clicking
>save again.  Having written this I realize I could possibly change any
>setting on any panel and save, since this is what apparently causes the
>colors to be lost in the first place.

>I am only using the target-specific settings because there are not enough
>keyword categories (i.e. only 4) in the global custom keywords.  The
>project-specific custom keywords are not really target-specific except for
>the colors, i.e. the 4 keyword lists are global across all targets.  Target
>specific colors alone strikes me as not very useful, and it would appear in
>general that this feature was left half-implemented, perhaps for lack of
>use.

>As I recall there are other problems with the feature.  Changes to the
>keyword list in a target can not be made to take effect until you also
>change one of the colors, because the panel is not considered "dirty" and
>the Save button is not enabled unless there is a change to one of the
>colors.

>Personally I would like to see more than 4 keyword lists in the global
>place.  12 would be good for me.  I realize such usage may be rare, but
>except for screen real estate I see no reason to keep the number down to 4.
>The screen real-estate issue did not even exist until the custom keywords
>were combined into the single syntax coloring panel.

>I have special uses for these in an add-on language setting, and wish the
>keywords lists could be set via apple events or even by saving to a file
>somewhere rather than going into the panels and importing.

>-Kurt Bigler

--
           Metrowerks has moved, our new address is now
                     7700 West Parmer Lane
                       Austin, TX 78729
        Sales and Support 512-996-5300   800-377-5416    


 
 
 

custom keyword coloring

Post by Kurt Bigle » Wed, 23 Jul 2003 17:22:55






>> There are things about custom keyword coloring that have never worked,
>> particularly regarding the target-specific custom keywords.

> I understand that you want to have more color coding for custom
> keywords,  but I think I got lost in the other stuff and I'm missing
> something,  Can you let me know what you would like besides more keyword
> colors?

> Ron

Ok, I'l translate what I already wrote...

Quote:>> The problem is that the current global coloring is set (if I have this
>> right) by the last target for which any preferences panel is saved.

Every target has its own custom keywords panel.  But in reality all targets
share the same 4 sets of custom keywords.  However each target allows a
different set of 4 colors to be specified for these keywords.

So far that all sounds reasonable.  However, the target whose colors are
used at any given moment have nothing to do with what the current target is.
I eventually realized that whenever I changed any target settings, that the
colors for that most recently "touched" target began to take effect.

Now you're going to have to follow me here, I can't make it much simpler.
Go into any target select any pref panel, and make a change, and voila, the
custom keyword colors for that target are now in effect.  Even though that
target is not the current target, and even though I did not touch the custom
keywords panel.

So the question then becomes, what do I do to live with this behavior?  Well
I have 2 alternatives.  Think through this with me.  If I modify a target's
preferences, its colors take effect.  I didn't want that.  But one way
around it is that I go into every single target in my project and change
everyone of them to use an identical set of colors, by going into the color
picker 4 times the number of targets times, and specifying the same set of 4
colors for every target.  Then if I want to change on of the colors, I have
to change it individually in every target.  Obviously this is a little bit
of trouble.  So instead I have adopted another approach:  to set my colors
in ONE target (chosen arbitrarily) and keep forcing CodeWarrior to go back
to a specific target's colors every time they change.  I can force it back
by modifying my arbitrarily-chosen color-controlling target in some way.

Obviously even this 2nd workaround is a bit of a problem.

But all these problems are symptomatic of what is to me a fundamental
underlying problem:  that different targets are allowed to have different
sets of colors for the same set of keywords in the first place.  Maybe
someone had a feature idea, and started to work on it and forgot to finish.
Maybe the original intention was to have also a different set of custom
keywords for each target.  Maybe the original intention was to have the
CURRENT target determine the colors.  Maybe the second idea was implemented
and people didn't like it and wanted a way to have the colors for a given
target stick even when the current target changed.  I can't guess what the
intention was, but my suspicion is that if the original intention is
implemented I will lose my ability to have 8 custom colors, unless perhaps I
program in at least the same set of 4 colors into every target, and possibly
(if things change from how they are now) the same 4 lists of keywords.

In short the current implementation makes no sense at all as far as I can
tell, and it only serves as an indirect way of allowing 8 sets of custom
keywords with their respective colors, and requires very awkward methods in
order to be used.

So in a sense you have now for several years supported this level of
functionality, you have provided an awkward way for people to have 8 sets of
custom keywords with colors.  I vote that you bite the bullet and actually
support the current defacto functionality so that is works without hassle.
Just increase the number of custom colors in the global settings from 4 to
8.  Better yet while you're at it increase it to twelve.  But even 8 would
be great.  8 sets with no hassles.

And then if you still care about the per-project custom keywords, whatever
it was you thought you might do someday, then do that also.  But don't break
the currently crippled functionality which permits awkward availability to 8
sets of keywords/colors.

Three other paragraphs that I wrote last time stands on their own, I think,
and if you re-read hopefully you can understand these now:

Quote:>> As I recall there are other problems with the feature.  Changes to the
>> keyword list in a target can not be made to take effect until you also
>> change one of the colors, because the panel is not considered "dirty" and
>> the Save button is not enabled unless there is a change to one of the
>> colors.

>> Personally I would like to see more than 4 keyword lists in the global
>> place.  12 would be good for me.  I realize such usage may be rare, but
>> except for screen real estate I see no reason to keep the number down to 4.
>> The screen real-estate issue did not even exist until the custom keywords
>> were combined into the single syntax coloring panel.

>> I have special uses for these in an add-on language setting, and wish the
>> keywords lists could be set via apple events or even by saving to a file
>> somewhere rather than going into the panels and importing.

>> -Kurt Bigler

 
 
 

custom keyword coloring

Post by MW Ro » Thu, 24 Jul 2003 06:20:30








>>> There are things about custom keyword coloring that have never worked,
>>> particularly regarding the target-specific custom keywords.

>> I understand that you want to have more color coding for custom
>> keywords,  but I think I got lost in the other stuff and I'm missing
>> something,  Can you let me know what you would like besides more keyword
>> colors?

>> Ron

>Ok, I'l translate what I already wrote...

>>> The problem is that the current global coloring is set (if I have this
>>> right) by the last target for which any preferences panel is saved.

>Every target has its own custom keywords panel.  But in reality all targets
>share the same 4 sets of custom keywords.  However each target allows a
>different set of 4 colors to be specified for these keywords.

>So far that all sounds reasonable.  However, the target whose colors are
>used at any given moment have nothing to do with what the current target is.
>I eventually realized that whenever I changed any target settings, that the
>colors for that most recently "touched" target began to take effect.

>Now you're going to have to follow me here, I can't make it much simpler.
>Go into any target select any pref panel, and make a change, and voila, the
>custom keyword colors for that target are now in effect.  Even though that
>target is not the current target, and even though I did not touch the custom
>keywords panel.

>So the question then becomes, what do I do to live with this behavior?  Well
>I have 2 alternatives.  Think through this with me.  If I modify a target's
>preferences, its colors take effect.  I didn't want that.  But one way
>around it is that I go into every single target in my project and change
>everyone of them to use an identical set of colors, by going into the color
>picker 4 times the number of targets times, and specifying the same set of 4
>colors for every target.  Then if I want to change on of the colors, I have
>to change it individually in every target.  Obviously this is a little bit
>of trouble.  So instead I have adopted another approach:  to set my colors
>in ONE target (chosen arbitrarily) and keep forcing CodeWarrior to go back
>to a specific target's colors every time they change.  I can force it back
>by modifying my arbitrarily-chosen color-controlling target in some way.

>Obviously even this 2nd workaround is a bit of a problem.

>But all these problems are symptomatic of what is to me a fundamental
>underlying problem:  that different targets are allowed to have different
>sets of colors for the same set of keywords in the first place.  Maybe
>someone had a feature idea, and started to work on it and forgot to finish.
>Maybe the original intention was to have also a different set of custom
>keywords for each target.  Maybe the original intention was to have the
>CURRENT target determine the colors.  Maybe the second idea was implemented
>and people didn't like it and wanted a way to have the colors for a given
>target stick even when the current target changed.  I can't guess what the
>intention was, but my suspicion is that if the original intention is
>implemented I will lose my ability to have 8 custom colors, unless perhaps I
>program in at least the same set of 4 colors into every target, and possibly
>(if things change from how they are now) the same 4 lists of keywords.

>In short the current implementation makes no sense at all as far as I can
>tell, and it only serves as an indirect way of allowing 8 sets of custom
>keywords with their respective colors, and requires very awkward methods in
>order to be used.

>So in a sense you have now for several years supported this level of
>functionality, you have provided an awkward way for people to have 8 sets of
>custom keywords with colors.  I vote that you bite the bullet and actually
>support the current defacto functionality so that is works without hassle.
>Just increase the number of custom colors in the global settings from 4 to
>8.  Better yet while you're at it increase it to twelve.  But even 8 would
>be great.  8 sets with no hassles.

>And then if you still care about the per-project custom keywords, whatever
>it was you thought you might do someday, then do that also.  But don't break
>the currently crippled functionality which permits awkward availability to 8
>sets of keywords/colors.

>Three other paragraphs that I wrote last time stands on their own, I think,
>and if you re-read hopefully you can understand these now:

>>> As I recall there are other problems with the feature.  Changes to the
>>> keyword list in a target can not be made to take effect until you also
>>> change one of the colors, because the panel is not considered "dirty" and
>>> the Save button is not enabled unless there is a change to one of the
>>> colors.

>>> Personally I would like to see more than 4 keyword lists in the global
>>> place.  12 would be good for me.  I realize such usage may be rare, but
>>> except for screen real estate I see no reason to keep the number down to 4.
>>> The screen real-estate issue did not even exist until the custom keywords
>>> were combined into the single syntax coloring panel.

>>> I have special uses for these in an add-on language setting, and wish the
>>> keywords lists could be set via apple events or even by saving to a file
>>> somewhere rather than going into the panels and importing.

OK

Thanks

Ron

--
           Metrowerks has moved, our new address is now
                     7700 West Parmer Lane
                       Austin, TX 78729
        Sales and Support 512-996-5300   800-377-5416    

 
 
 

1. colors while editing/ highlighting keywords

I found that vim can be used to get different colours while editing.
I tried with the options given in the 7.4 FAQ. But, it doesn't work
for me. For eg. I tried
:set t_ue=<Esc>[0;1;36m

But immediately after pressing <ESC> the cursor goes back to the text
portion.
Why?  What mistake am i doing? Should I install something?

Also, I want the keywords to be highlighted with the color I want whil
editing my C++ code. I think this is very very useful. I'm working in
Solaris for your information.

2. Ami Pro problem and other question.

3. c keyword color printing tool

4. Does Context support type ANY?

5. vi-like keyword coloring editor WANTED

6. I want an upgrade to Appleworks GS!!

7. Custom Colours in Quark...

8. Aldus Trapwise and AI5.0 Custom Colors

9. Custom color problem in Emacs

10. Wanted: text editor /w custom color coding schemes

11. custom color table

12. (howto) Set up a custom (colour) vt term