-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for OSC 4 ; color ; color spec #3163
Changes from 15 commits
5c7644a
1c3da7e
b22d7f1
b127436
712f0ae
b898e01
d5f4ae5
bc86b78
77ed5ba
6535995
e6917d1
4c6dc45
52b64be
f4a5638
5a74ce2
2804bfa
7d3f537
5c33e40
676aabc
19c14b0
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -18,7 +18,9 @@ export function generateConfig(scaledCharWidth: number, scaledCharHeight: number | |
selection: undefined, | ||
// For the static char atlas, we only use the first 16 colors, but we need all 256 for the | ||
// dynamic character atlas. | ||
ansi: colors.ansi.slice(0, 16) | ||
// ansi: colors.ansi.slice(0, 16) | ||
// TODO: Using entire array to support OSC 4; can this break anything? | ||
ansi: colors.ansi | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm yes, it basically increases the atlas size from 16 * 256 pixmaps to 256 * 256. Not sure thought if it will cause problems in terms of browser limits. This needs some serious testing by someone with more atlas insights than me. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @Tyriar Is it safe to expand the atlas here that way? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Looking at the code it seems like this should be fine, I think the slice is there as previously it was static but it ends up falling back to |
||
}; | ||
return { | ||
devicePixelRatio: window.devicePixelRatio, | ||
|
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -5,7 +5,7 @@ | |||
|
||||
import { assert, expect } from 'chai'; | ||||
import { InputHandler } from 'common/InputHandler'; | ||||
import { IBufferLine, IAttributeData } from 'common/Types'; | ||||
import { IBufferLine, IAttributeData, IAnsiColorChangeEvent } from 'common/Types'; | ||||
import { DEFAULT_ATTR_DATA } from 'common/buffer/BufferLine'; | ||||
import { CellData } from 'common/buffer/CellData'; | ||||
import { Attributes, UnderlineStyle } from 'common/buffer/Constants'; | ||||
|
@@ -1692,4 +1692,31 @@ describe('InputHandler', () => { | |||
assert.equal(coreService.decPrivateModes.origin, false); | ||||
}); | ||||
}); | ||||
describe('OSC', () => { | ||||
it('should parse correct Ansi color change data', () => { | ||||
// this is testing a private method | ||||
const parseAnsiColorChange = inputHandler['_parseAnsiColorChange']; | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Haha - thats a quite hacky access, but okish for tests. I normally subclass things to be tested with privates exposed in test files to still get the type checking done (which will be completely skipped with your way). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, that's for tests only. Was suggested by @kena0ki as I was using There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yes thats true. Either you can go with
I did something similar with protected and subclassing in the parser tests here:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👍 this is the recommended way as then TS refactors will just work automatically instead of causing a test runtime error. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks. Done. I did not realize there was already |
||||
|
||||
assert.deepEqual( | ||||
parseAnsiColorChange('19;rgb:a1/b2/c3'), | ||||
{ colorIndex: 19, red: 0xa1, green: 0xb2, blue: 0xc3 } | ||||
); | ||||
}), | ||||
it('should ignore incorrect Ansi color change data', () => { | ||||
// this is testing a private method | ||||
const parseAnsiColorChange = inputHandler['_parseAnsiColorChange']; | ||||
|
||||
assert.isNull(parseAnsiColorChange('17;rgb:a/b/c')); | ||||
assert.isNull(parseAnsiColorChange('17;rgb:#aabbcc')); | ||||
assert.isNull(parseAnsiColorChange('17;rgba:aa/bb/cc')); | ||||
assert.isNull(parseAnsiColorChange('rgb:aa/bb/cc')); | ||||
}); | ||||
it('should fire event on Ansi color change', (done) => { | ||||
inputHandler.onAnsiColorChange(e => { | ||||
assert.deepEqual(e, { colorIndex: 17, red: 0x1a, green: 0x2b, blue: 0x3c }); | ||||
done(); | ||||
}); | ||||
inputHandler.parse('\x1b]4;17;rgb:1a/2b/3c\x1b\\'); | ||||
}); | ||||
}); | ||||
}); |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,7 +4,7 @@ | |
* @license MIT | ||
*/ | ||
|
||
import { IInputHandler, IAttributeData, IDisposable, IWindowOptions } from 'common/Types'; | ||
import { IInputHandler, IAttributeData, IDisposable, IWindowOptions, IAnsiColorChangeEvent } from 'common/Types'; | ||
import { C0, C1 } from 'common/data/EscapeSequences'; | ||
import { CHARSETS, DEFAULT_CHARSET } from 'common/data/Charsets'; | ||
import { EscapeSequenceParser } from 'common/parser/EscapeSequenceParser'; | ||
|
@@ -250,6 +250,8 @@ export class InputHandler extends Disposable implements IInputHandler { | |
public get onScroll(): IEvent<number> { return this._onScroll.event; } | ||
private _onTitleChange = new EventEmitter<string>(); | ||
public get onTitleChange(): IEvent<string> { return this._onTitleChange.event; } | ||
private _onAnsiColorChange = new EventEmitter<IAnsiColorChangeEvent>(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Whats the idea for a custom event here? Shall this be interceptable later on from outside? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure 😊 I modeled it after "title change". There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thinking about it some more, using the event is the way that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes sounds good that way. I still wonder, if we would need a stricter coupling of the color manager to the input handler, esp. for those There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hi, @slawekzachcial! Thanks for the great PR! Would it be possible to also make |
||
public get onAnsiColorChange(): IEvent<IAnsiColorChangeEvent> { return this._onAnsiColorChange.event; } | ||
|
||
constructor( | ||
private readonly _bufferService: IBufferService, | ||
|
@@ -372,6 +374,7 @@ export class InputHandler extends Disposable implements IInputHandler { | |
this._parser.setOscHandler(2, new OscHandler((data: string) => this.setTitle(data))); | ||
// 3 - set property X in the form "prop=value" | ||
// 4 - Change Color Number | ||
this._parser.setOscHandler(4, new OscHandler((data: string) => this.setAnsiColor(data))); | ||
// 5 - Change Special Color Number | ||
// 6 - Enable/disable Special Color Number c | ||
// 7 - current directory? (not in xterm spec, see https://gitlab.com/gnachman/iterm2/issues/3939) | ||
|
@@ -2711,6 +2714,38 @@ export class InputHandler extends Disposable implements IInputHandler { | |
this._iconName = data; | ||
} | ||
|
||
private _parseAnsiColorChange(data: string): IAnsiColorChangeEvent | null { | ||
// example data: 5;rgb:aa/bb/cc | ||
const regex = /(\d+);rgb:([0-9a-fA-F]{2})\/([0-9a-fA-F]{2})\/([0-9a-fA-F]{2})/; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think this does not enough for OSC 4. As far as I get it from the xterm spec it should be capable to handle arbitrary long
Furthermore xterm supports a
(also note the double width of the response for the color spec, not sure if we have to support that as well for input) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes indeed OSC 4 allows to set multiple colors in the same command. This can be easily fixed I think I'll admit I did not understand the Interestingly enough, in your There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @jerch The latest commits allow to pass multiple color values in the same OSC 4 call. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The Idc much if we dont support that yet, we can add it by a later PR. In the end we should be capable to handle OSC 4 as xterm would, otherwise we have a partly broken implementation. |
||
const match = data.match(regex); | ||
|
||
if (match) { | ||
return { | ||
colorIndex: parseInt(match[1]), | ||
red: parseInt(match[2], 16), | ||
green: parseInt(match[3], 16), | ||
blue: parseInt(match[4], 16) | ||
}; | ||
} | ||
return null; | ||
} | ||
|
||
/** | ||
* OSC 4; <num> ; <text> ST (set ANSI color <num> to <text>) | ||
* | ||
* @vt: #Y OSC 4 "Set ANSI color" "OSC 4 ; c ; spec BEL" "Change color number `c` to the color specified by `spec`." | ||
* `c` is the color index between 0 and 255. `spec` color format is 'rgb:hh/hh/hh' where `h` are hexadecimal digits. | ||
*/ | ||
public setAnsiColor(data: string): void { | ||
const event = this._parseAnsiColorChange(data); | ||
if (event) { | ||
this._onAnsiColorChange.fire(event); | ||
} | ||
else { | ||
this._logService.warn(`Expected format <num>;rgb:<rr>/<gg>/<bb> but got data: ${data}`); | ||
} | ||
} | ||
|
||
/** | ||
* ESC E | ||
* C1.NEL | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An additional method on
Terminal
is an unlucky choice, as we try to get rid of helpers on terminal in favor of more direct service usage. Can we get this moved to the color manager directly? Not sure if it is properly service'ified yet, if not we can keep it here and move it later on...I dont like the
!
much, as it might lead to runtime errors in case the manager is indeed not there for whatever reason. Lets better hide the access behind an initial condition test, something likeif (!this._colorManager) { return; }
...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes,
if (!this._colorManager) { return; }
is a good idea here.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jerch The function now exists early if
_colorManager
is undefined.