Ack.. Too many things to reply to. Here we go... lol
Quote:
"... and the normal ANSI part at defaults (something Mushclient already violates. lol)"
In what way?
Mushclient violates the rule of not changing the base 16 ANSI colors because we "can" already edit them. ".pal" files generally have the first 16 and the last 8? as default settings, this was a convention from the old days where the applications had to use the same color palette as the OS, so if you changed the first 16 or the grey scale either a) Your the OS would replace the images first 16 and last 8 with its standards, messing up the picture, or in more unusual cases, the applications colors would get changed to match the image (which in some cases could be very bad). So, Mushclient is violating the rules by allowing you to change those colors.
This is however irrelevant, unless someone expects those colors to be defaults and your text gets messed up somehow because of it. But if that is the case, there is nothing to prevent you from changing back to the normal set.
Quote:
I am inclined to agree with Shaun here. It is all very well wanting 500 colours in the picker, but it then gets unwieldy.
It is very easy to choose a colour like "powderblue" and then adjust the RGB sliders to modify the colour slightly, or click "other colour" to open the standard Windows colour picker, and then move the luminance slider, if you want to change the brightness of it.
Umm. Thinking more in terms of the script. If you want "powderblue4", you can't tell it, "Use powderblue, but make it X% darker." You would have to return the actual RGB color for it, break that into its components, calculate the darker/lighter color, glue the conponents back together, then send that result to through the colornote command. One way to make it less unwieldy in the picker would be to just add a check box that would sort through the colors and only show the "main" set. I.e., anything that showed up as "powderblue(n)" would be tossed, giving the original list. And one of the most frustrating problems I had when looking for a color value was trying to remember what I used some place else. Sure, you can look through your code. Sure, you can look through the main world to see what you set an alternate color to, sure, you can "find" it, but it would be a lot easier to find if it either already had, or you could give it a name.
I remember, for example, that the "Brown" definition in POVRay never looked right, it was more red than it should have been. Maybe someone *wants* to use that color so would call it "MyBrown", just as about 90% of us added a "MyBrown" or "TrueBrown" definition to the file to fix it. (The original ran on the Commodore Amiga, and apparently something odd about the hardware meant that what we see as a correct brown color looked too green, so they had to originally make it more red to compensate.)
Quote:
Vim is a text editor which is Vi IMproved. The .vim files are colour schemes for the editor. The screenshot just above all the .vim files is a screenshot of someone using vim to edit some code.
Thanks. I did look at the files and did mention that I suspected this was the case. The page it was on wasn't, like most that assume you know what the files do already, too specific about that.
Quote:
* Show the entire (bad) sequence as regular text, making the assumption that it is really intended to be seen.
* Note the sequence is bad, but still hide it (ie. everything from ESC ... m), as it is clearly a control sequence, and not intended to be seen.
* Display as much as you can (eg. my earlier example of multiple codes, some of which are good and some are bad) - in other words, skipping (and not displaying) any bad codes in the middle.
* Process as much as you can, up to the bad code, and then ignore the rest.
* Process as much as you can, up to the bad code, and then display the rest.
In my experience, going clear back to BBSes, its more or less something between all 4. If something went screwy with a sequence like "esc[32;1;194mesc[45;0m" and you ended up with "[32;1mesc[45;qm" The result would be: "[32;1mm", since the second set would be seen, but do to the incorrect termination, processing ends the moment it hits the bad data, taking the offending invalid character with it. I think it ignores numbers though, so you could do something like esc[32;5;4;99;5;6m and it would just throw out the invalid values, but if a character landed in there some place, instead of a number, it would immediately terminate, usually only doing what that final character specified, so "m" sets a color, while "s" would "only" do what that character designates. The only source I have is, I think, is in ML for DOS3.3 or something and there is no telling if MS followed spec either. lol |
![[Previous page]](/images/thin_prev.gif){kind=small}
1
2
3 4
![[Next page]](/images/thin_next.gif){kind=small}
![[Go to top]](/images/gototop.gif){kind=small}
top