Question:
Variable substitutions that are available for (see ) do not include currently selected text. I am looking for something similar to $(CurText) that is available in Visual Studio Arguments for External Tools (see ). Please add a variable ${curtext} which would be replaced with the currently selected text in the editor window. If no selection is available, it could use the current line at cursor position.
Nice idea, but I think it's too late for implement that in the current milestone...
Fixed by in
Verifiers: what happens if all text in a 300 MB file is selected...
good point. Maybe we should put a limit on this. Or only to copy the howl line at most (even though the line could also be 300mb I am fine with that) thoughts?
Selecting lots of text, at some point I get . If there's a predictable limit where this will fail, we should just cut the string off there. Unless only sending part of the text could be dangerous or unexpected for the user. In any case I think that sending multiple lines of text could be useful.
there is not a predictable limit since the variables are used in different scenarios. If somebody has an idea for a limit I am open to PRs

public activeEditorOptions: IEditorOptions; public activeEditorPosition: Position; public mockLineNumber: number; <ins> public mockSelectedText: string; </ins> private callback: (method: string) => void; constructor(callback?: (method: string) => void) { this.callback = callback || ((s: string) => { }); this.mockLineNumber = 15; <ins> this.mockSelectedText = 'selected text'; </ins> } public openEditors(inputs: any[]): Promise {


Question:
Variable substitutions that are available for (see ) do not include currently selected text. I am looking for something similar to $(CurText) that is available in Visual Studio Arguments for External Tools (see ). Please add a variable ${curtext} which would be replaced with the currently selected text in the editor window. If no selection is available, it could use the current line at cursor position.
Nice idea, but I think it's too late for implement that in the current milestone...
Fixed by in
Verifiers: what happens if all text in a 300 MB file is selected...
good point. Maybe we should put a limit on this. Or only to copy the howl line at most (even though the line could also be 300mb I am fine with that) thoughts?
Selecting lots of text, at some point I get . If there's a predictable limit where this will fail, we should just cut the string off there. Unless only sending part of the text could be dangerous or unexpected for the user. In any case I think that sending multiple lines of text could be useful.
there is not a predictable limit since the variables are used in different scenarios. If somebody has an idea for a limit I am open to PRs

getId: () => { return null; }, getControl: () => { return { <del> getSelection: () => { return { positionLineNumber: this.mockLineNumber }; } </del> <ins> getSelection: () => { return { positionLineNumber: this.mockLineNumber }; }, getModel: () => { return { getValueInRange: () => this.mockSelectedText }; } </ins> }; }, focus: () => { },


Question:
Platforms Tested: Insiders 5-30 Code 1.11.1 Stable Windows 7 OS X Sierra (should be all platforms) Problem: Output panel drop-down does not track current active output if output channel is activated later , typically when an extension output Channel is active (eg Git). Output select box will show the default 0 index output (Tasks) Steps to reproduce: Open code with git repository/workspace select Git output Channel close code reopen code Git output will be active but drop-down shows Tasks Fixed with PR always update active select box selection with setOptions call on any output channel update Tested on Windows 7, OS X
Fixed via

) { super(null, action, [], 0); <del> this.toDispose.push(this.outputService.onOutputChannel(() => this.setOptions(this.getOptions(), this.getSelected(undefined)))); </del> <ins> this.toDispose.push(this.outputService.onOutputChannel(() => { const activeChannelIndex = this.getSelected(this.outputService.getActiveChannel().id); this.setOptions(this.getOptions(), activeChannelIndex); })); </ins> this.toDispose.push(this.outputService.onActiveOutputChannel(activeChannelId => this.setOptions(this.getOptions(), this.getSelected(activeChannelId)))); this.toDispose.push(attachSelectBoxStyler(this.selectBox, themeService));


Question:
Testing Steps to Reproduce: integrated terminal and open the find widget the integrated terminal area very skinny bug The find widget starts overflowing into the explorer area: <img width="420" alt="screen shot 2017-06-28 at 1 25 51 pm" src="https://user-"
After , no more overflow but we now clip the find box: !
I guess we want it to be tiny like in the editor: <img width="221" alt="screen shot 2017-07-07 at 3 02 45 pm" src="https://user-"

display: flex; padding: 4px; align-items: center; <ins> width: 220px; max-width: calc(100% - 28px - 28px - 8px); </ins> -webkit-transition: top 200ms linear; -o-transition: top 200ms linear;


Question:
Testing Steps to Reproduce: integrated terminal and open the find widget the integrated terminal area very skinny bug The find widget starts overflowing into the explorer area: <img width="420" alt="screen shot 2017-06-28 at 1 25 51 pm" src="https://user-"
After , no more overflow but we now clip the find box: !
I guess we want it to be tiny like in the editor: <img width="221" alt="screen shot 2017-07-07 at 3 02 45 pm" src="https://user-"

top: 0; } <ins> .monaco-workbench .simple-find-part .monaco-findInput { flex: 1; } </ins> /* Temporarily we don't show match numbers */ .monaco-workbench .simple-find-part .monaco-findInput .controls { display: none;


Question:
Testing Steps to Reproduce: integrated terminal and open the find widget the integrated terminal area very skinny bug The find widget starts overflowing into the explorer area: <img width="420" alt="screen shot 2017-06-28 at 1 25 51 pm" src="https://user-"
After , no more overflow but we now clip the find box: !
I guess we want it to be tiny like in the editor: <img width="221" alt="screen shot 2017-07-07 at 3 02 45 pm" src="https://user-"

) { super(); this._findInput = this._register(new FindInput(null, this._contextViewService, { <del> width: 155, </del> label: NLS_FIND_INPUT_LABEL, placeholder: NLS_FIND_INPUT_", }));


Question:
I noticed that the terminal no sends Operating System Commands (OSC) like setting the window title. Right now the task runner filters them but this gets more and more complex and I am actually not an expert with this. So I would like to request that the terminal provides API to notify data without control sequences. Currently I used these two regular expressions to filter them:
There are two unknowns to me right now with this: Various control sequences can do , so where is the best place to gather this data? It might be worth seeing if adding listeners to will give what you need. How do this efficiently. Because a lot of data can stream through the terminal, we should probably only enable this when it's explicitly requested (ie. only fire the event if something is listening). It should probably also be batched. PR welcome upstream.
From a problem matcher point of view it would be enough sending the line. We could sent it when a linefeed is . Then there is still the problem of a line content changing. We once discussed the idea of a line identifier to signal that. I agree that sending single characters might not be a smart idea in terms of performance.
If it's just on line feed then many characters could go missing, eg. "abc" <move cursor up a row"def" <linefeedwould result in "def" only. Maybe this is not something we care about, but it could lead to some obscure bugs if people relied on this new API.
This is a good example why something like a line model would be helpful: After looking into the issue it looks like that pester constantly 'repaints' the whole screen hence the terminal sending the same line onData over and over again. For me it is very hard to tell whether I have seen that line and whether I have processed it already (the same content). What would be cool if the terminal could provide a line model where is line has an id (number) and changes are signaled on that model instead of sending raw data.
I actually an ID concept to the buffer when doing the selection stuff () but I ended up not needing it and pulling it out, instead the selection listens to when the buffer is trimmed and adjusts the indexes of its own model. It really didn't feel very good adding it as it introduced much more complexity to the already complex circular list and the overhead of an addition object for every entry - which is a lot when you need to create tens of thousands of these things in an instant. There were other issues that come up with this like IDs being interleaved due to programs having the ability to delete/insert lines so there's no way I could think of to optimize it nicely, leading to a slower, more memory hungry terminal. It would probably be easier and more performant to just deduplicate these errors on your end. For example you could record a hash for current problems and check it before adding new problems, or perhaps even better, record the raw terminal line of the error so you don't need to parse it again for duplicate problems.
I implemented the deduplicate yesterday but it feels like a hack on my side :-) I need to create a unique key for something that doesn't necessarily have one. I still think having a line bassed model comparable to what the editor exposes would be a nice thing. Me giving the raw data is comparable to the editor signaling raw cursor moves and text changes. Instead I get a nice model with text edit events. And I am not interested in color information like I am not interested in this on an editor buffer.
Just for the record. I can not filter on the line itself from the terminal without knowing if I have parsed that line already. Matchers are multiline aware and there could be two equal lines in one output on purpose since they difference is made by a line above. Me knowing this is implementing a line model on top of it :-)
isn't the point of programs rewriting lines that the lines do change and that they may need to be reparsed? Here's one idea that might work for both of us: exposing some data stream you can listen to as in the original comment, but only ever pushing data if it's on the last line in the terminal. Would this cover your use case? For the PS case you would get multiple lines for the last line but maybe this could be more clever somehow in recording when the cursor moves and only reporting the line a single time (not by using IDs but by only reporting once after a call inserts a new line.
yes, it would be cool to be able to reparse a line when it changes. As I tried to outline in this needs to have some sort of model to do it right. I can't simply decide things on the content of a line. So instead me implementing a line model on top of ANSI control sequence characters I was somehow hoping that the terminal could expose its. I my simple mind the terminal works like this: program -Output with control characters -line model -view model (does the wrapping, could do folding, ...) -DOM. I think the last line suggestion will work for parsing problems. However when exposing this as API in the extension host I think it might be a little to limited.
currently there is only the line model, no view model. I did a big write up on introducing one to properly support reflowing lines here This has been a pretty long discussion across a few issues but to clarify where we are now, here are my concerns: Extra memory overhead in the buffer: I'm currently in the process of trying to push down the terminal's memory usage as I need to store more data against each character and memory usage right now is approaching unacceptable limits imo Here is a snapshot of a 160x24 terminal with 5000 scrollback filled which is not out of the ordinary, I typically have two of these running just in the window with Microsoft/vscode opened: ! Extra processing when data/lines are to the buffer: back in December I made a big effort improving the terminal's performance by attacking it in a number of ways. The main take aways from this experience was that trying to write a high performance terminal in JavaScript/DOM is very hard because processing and displaying data is so expensive. I can now safely say that is the fastest JS terminal out there by a long shot and I want us to maintain this status. A proper view model that can track lines that changes would amount to a significant amount of processing in the worst case which would be generally unnecessary for other use cases. Some possible solutions: a new event that you can listen to that fires when a line feed is to the last line, ie. only fire an event once per line and ignore lines being updated or lines being inserted. Pros: It doesn't involve storing any more data or doing anymore processing, other that pulling the string from the buffer. Cons: it probably isn't sufficient to cover all use cases. an ID to each buffer line () and fire an event when there is a line feed against a line or the cursor moves away from it (specifics here would need to be figured out). Pros: It's a more complete solution and covers more use cases. We need an addition JS object and number associated with each line, this probably doesn't add up to that much data as it's on the line rather than the char. Cons: Additional complexity within the data structure. I'm not so sure just yet when exactly we should fire these events. The IDs will be out of order in some cases which may be confusing to consumers. These events may still fire when the line did not change (eg. if the program/script erased and rewrote the line). a proper view model that throws events only when a line changes. Pros: I think this is the ideal solution from your perspective. Cons: All the cons of number 2. The amount of string comparisons needed here is out of the question in the worst case with my current thinking, unless this was disabled by default and generally did not run on a lot of data. Commentary on the solutions: doesn't look like this is sufficient for problem matchers could work, but I'm not sure it helps much with the issue in behind an option on terminal initialization is probably the best way to go, but it's also the most difficult and time consuming to implement. Work on this is blocked on the following active PRs: & , and it should be done in a way that accommodates future line reflowing
thanks a lot for the detailed explanation. Having solution 2 will for sure make my life easier and will not make things worse on my end. Regarding option 3: I am not interested in the view model since I need lines unwrapped. The line model is what would work best for me assuming that the line model doesn't have any in there to make lines visually wrap .
option 3 including reflow is required in order to get unwrapped lines Not sure when I'll have time to work on this, pretty swamped atm. It might be a good opportunity to collaborate if this is high priority for you?
I will be out on vacation until 2. August. I think we need to address this sooner than later since we can't assume that problems always fit onto one line. An interims solution could be as follows: can we introduce a custom control sequence (e.g. a operating system control sequence) that describes the new lines inserted to wrap the text. I could then filter them on my end since I would be able to distinguish them from normal newline. Would this be something you can add in July then I would catchup with it for the July build ?
I actually expect you to get the unwrapped lines currently, just wraps the lines when they are going to overflow , that's the only wrapping it knows about. On Windows though I'm not sure rows are ever marked to be wrapped (not 100% sure), at least on PowerShell. This is just how winpty works.

* * @param listener The listener function which takes the processes' data stream (including * ANSI escape sequences). <ins> * * @deprecated onLineData will replace this. </ins> */ onData(listener: (data: string) => void): IDisposable; /** <ins> * Attach a listener to listen for new lines added to this terminal instance. * * @param listener The listener function which takes new line strings added to the terminal, * excluding ANSI escape sequences. The line event will fire when an LF character is added to * the terminal (ie. the line is not wrapped), note that this means taht the line data will * never fire for the last line, until the line is ended with a LF character. The lineData * string will contain the fully wrapped line, not containing any LF/CR characters. */ onLineData(listener: (lineData: string) => void): IDisposable; /** </ins> * Attach a listener that fires when the terminal's pty process exits. * * @param listener The listener function which takes the processes' exit code, an exit code of


Question:
I noticed that the terminal no sends Operating System Commands (OSC) like setting the window title. Right now the task runner filters them but this gets more and more complex and I am actually not an expert with this. So I would like to request that the terminal provides API to notify data without control sequences. Currently I used these two regular expressions to filter them:
There are two unknowns to me right now with this: Various control sequences can do , so where is the best place to gather this data? It might be worth seeing if adding listeners to will give what you need. How do this efficiently. Because a lot of data can stream through the terminal, we should probably only enable this when it's explicitly requested (ie. only fire the event if something is listening). It should probably also be batched. PR welcome upstream.
From a problem matcher point of view it would be enough sending the line. We could sent it when a linefeed is . Then there is still the problem of a line content changing. We once discussed the idea of a line identifier to signal that. I agree that sending single characters might not be a smart idea in terms of performance.
If it's just on line feed then many characters could go missing, eg. "abc" <move cursor up a row"def" <linefeedwould result in "def" only. Maybe this is not something we care about, but it could lead to some obscure bugs if people relied on this new API.
This is a good example why something like a line model would be helpful: After looking into the issue it looks like that pester constantly 'repaints' the whole screen hence the terminal sending the same line onData over and over again. For me it is very hard to tell whether I have seen that line and whether I have processed it already (the same content). What would be cool if the terminal could provide a line model where is line has an id (number) and changes are signaled on that model instead of sending raw data.
I actually an ID concept to the buffer when doing the selection stuff () but I ended up not needing it and pulling it out, instead the selection listens to when the buffer is trimmed and adjusts the indexes of its own model. It really didn't feel very good adding it as it introduced much more complexity to the already complex circular list and the overhead of an addition object for every entry - which is a lot when you need to create tens of thousands of these things in an instant. There were other issues that come up with this like IDs being interleaved due to programs having the ability to delete/insert lines so there's no way I could think of to optimize it nicely, leading to a slower, more memory hungry terminal. It would probably be easier and more performant to just deduplicate these errors on your end. For example you could record a hash for current problems and check it before adding new problems, or perhaps even better, record the raw terminal line of the error so you don't need to parse it again for duplicate problems.
I implemented the deduplicate yesterday but it feels like a hack on my side :-) I need to create a unique key for something that doesn't necessarily have one. I still think having a line bassed model comparable to what the editor exposes would be a nice thing. Me giving the raw data is comparable to the editor signaling raw cursor moves and text changes. Instead I get a nice model with text edit events. And I am not interested in color information like I am not interested in this on an editor buffer.
Just for the record. I can not filter on the line itself from the terminal without knowing if I have parsed that line already. Matchers are multiline aware and there could be two equal lines in one output on purpose since they difference is made by a line above. Me knowing this is implementing a line model on top of it :-)
isn't the point of programs rewriting lines that the lines do change and that they may need to be reparsed? Here's one idea that might work for both of us: exposing some data stream you can listen to as in the original comment, but only ever pushing data if it's on the last line in the terminal. Would this cover your use case? For the PS case you would get multiple lines for the last line but maybe this could be more clever somehow in recording when the cursor moves and only reporting the line a single time (not by using IDs but by only reporting once after a call inserts a new line.
yes, it would be cool to be able to reparse a line when it changes. As I tried to outline in this needs to have some sort of model to do it right. I can't simply decide things on the content of a line. So instead me implementing a line model on top of ANSI control sequence characters I was somehow hoping that the terminal could expose its. I my simple mind the terminal works like this: program -Output with control characters -line model -view model (does the wrapping, could do folding, ...) -DOM. I think the last line suggestion will work for parsing problems. However when exposing this as API in the extension host I think it might be a little to limited.
currently there is only the line model, no view model. I did a big write up on introducing one to properly support reflowing lines here This has been a pretty long discussion across a few issues but to clarify where we are now, here are my concerns: Extra memory overhead in the buffer: I'm currently in the process of trying to push down the terminal's memory usage as I need to store more data against each character and memory usage right now is approaching unacceptable limits imo Here is a snapshot of a 160x24 terminal with 5000 scrollback filled which is not out of the ordinary, I typically have two of these running just in the window with Microsoft/vscode opened: ! Extra processing when data/lines are to the buffer: back in December I made a big effort improving the terminal's performance by attacking it in a number of ways. The main take aways from this experience was that trying to write a high performance terminal in JavaScript/DOM is very hard because processing and displaying data is so expensive. I can now safely say that is the fastest JS terminal out there by a long shot and I want us to maintain this status. A proper view model that can track lines that changes would amount to a significant amount of processing in the worst case which would be generally unnecessary for other use cases. Some possible solutions: a new event that you can listen to that fires when a line feed is to the last line, ie. only fire an event once per line and ignore lines being updated or lines being inserted. Pros: It doesn't involve storing any more data or doing anymore processing, other that pulling the string from the buffer. Cons: it probably isn't sufficient to cover all use cases. an ID to each buffer line () and fire an event when there is a line feed against a line or the cursor moves away from it (specifics here would need to be figured out). Pros: It's a more complete solution and covers more use cases. We need an addition JS object and number associated with each line, this probably doesn't add up to that much data as it's on the line rather than the char. Cons: Additional complexity within the data structure. I'm not so sure just yet when exactly we should fire these events. The IDs will be out of order in some cases which may be confusing to consumers. These events may still fire when the line did not change (eg. if the program/script erased and rewrote the line). a proper view model that throws events only when a line changes. Pros: I think this is the ideal solution from your perspective. Cons: All the cons of number 2. The amount of string comparisons needed here is out of the question in the worst case with my current thinking, unless this was disabled by default and generally did not run on a lot of data. Commentary on the solutions: doesn't look like this is sufficient for problem matchers could work, but I'm not sure it helps much with the issue in behind an option on terminal initialization is probably the best way to go, but it's also the most difficult and time consuming to implement. Work on this is blocked on the following active PRs: & , and it should be done in a way that accommodates future line reflowing
thanks a lot for the detailed explanation. Having solution 2 will for sure make my life easier and will not make things worse on my end. Regarding option 3: I am not interested in the view model since I need lines unwrapped. The line model is what would work best for me assuming that the line model doesn't have any in there to make lines visually wrap .
option 3 including reflow is required in order to get unwrapped lines Not sure when I'll have time to work on this, pretty swamped atm. It might be a good opportunity to collaborate if this is high priority for you?
I will be out on vacation until 2. August. I think we need to address this sooner than later since we can't assume that problems always fit onto one line. An interims solution could be as follows: can we introduce a custom control sequence (e.g. a operating system control sequence) that describes the new lines inserted to wrap the text. I could then filter them on my end since I would be able to distinguish them from normal newline. Would this be something you can add in July then I would catchup with it for the July build ?
I actually expect you to get the unwrapped lines currently, just wraps the lines when they are going to overflow , that's the only wrapping it knows about. On Windows though I'm not sure rows are ever marked to be wrapped (not 100% sure), at least on PowerShell. This is just how winpty works.

}; } <ins> public onLineData(listener: (lineData: string) => void): lifecycle.IDisposable { if (!this._xterm) { throw new Error('xterm must be initialized'); } const lineFeedListener = () => { const buffer = (<any>this._xterm.buffer); const newLine = buffer.lines.get(buffer.ybase + buffer.y); if (!newLine.isWrapped) { let i = buffer.ybase + buffer.y - 1; let lineData = buffer.translateBufferLineToString(i, true); while (i >= 0 && buffer.lines.get(i--).isWrapped) { lineData = buffer.translateBufferLineToString(i, true) + lineData; } listener(lineData); } }; this._xterm.on('lineFeed', lineFeedListener); return { dispose: () => { if (this._xterm) { this._xterm.off('lineFeed', lineFeedListener); } } }; } </ins> public onExit(listener: (exitCode: number) => void): lifecycle.IDisposable { if (this._process) { this._process.on('exit', listener);


Question:
Would be great to see a tooltip on links, showing the target. Or popping it up in the status bar or elsewhere, like Chrome.
: Could you please explain the preview functionality bit more with screenshots of Chrome? I am new to open source community and this project. I use vscode often and would love to work on this if someone can guide me a little.
Lower left corner of the Chrome window when I hover the link to your name: ! But I think a normal tooltip would be easier.
Ah yes. I understand what you are talking about now. To verify, where the link is leading to. Seems like a beginner friendly feature. I can pick it up this weekend if anyone can nudge me towards the right direction. :)
Sorry for the delayed response. It seems that tooltips are only shown if the element has a attribute, but not for links that only have a . I wasn't able to find if there is an electron setting to enable tooltips for links without . I think we may have to implement this ourselves. To get started, take a look at this PR that a similar feature to another electron app: Here's where our webview code lives: I believe you should be able to attach a handler to the webview handler. Please let me know if you have any questions about the code or want to discuss potential designs
I m happy to receive help! :) I was facing issues while trying to build and fiddle around with the source code. Will definitely look into this PR and the code you pointed out this weekend. Thanks for taking your time to post this info. I ll post any questions or designs which I have.
Hi , I will create a PR to add attribute to every .
For verification: this was implemented as tooltip when you hover over links in a webview

const text = data.contents.join('n'); const newDocument = new DOMParser().parseFromString(text, 'text/html'); <ins> newDocument.querySelectorAll('a').forEach(a => { if (!a.title) { a.title = a.href; } }); </ins> // set base-url if applicable if (initData.baseUrl && newDocument.head.getElementsByTagName('base').length === 0) { const baseElement = newDocument.createElement('base');


Question:
<!-- Do you have a question? Please ask it on --<!-- Use Help Report Issues to prefill these. --- VSCode Version: latest OS Version: Win10 A little bit more space between last line from terminal and the blue line below would be nice !
I 1px border on the bottom would be fine, opening to PRs. Who ever wants to pick this up, you need to make sure the size of the terminal is calculated correctly given the new margin. Relevant files: , .
I'll pick this up. pretty much all of the other terminal issues are already taken, or out of my realm. just let me know somebody's not already working on this ;-)
sounds good
PR posted

position: absolute; bottom: 0; top: 0; <ins> padding-bottom: 2px; </ins> } .monaco-workbench .panel.integrated-terminal .xterm a:not(.xterm-invalid-link) {


Question:
<!-- Do you have a question? Please ask it on --<!-- Use Help Report Issues to prefill these. --- VSCode Version: latest OS Version: Win10 A little bit more space between last line from terminal and the blue line below would be nice !
I 1px border on the bottom would be fine, opening to PRs. Who ever wants to pick this up, you need to make sure the size of the terminal is calculated correctly given the new margin. Relevant files: , .
I'll pick this up. pretty much all of the other terminal issues are already taken, or out of my realm. just let me know somebody's not already working on this ;-)
sounds good
PR posted

} const padding = parseInt(getComputedStyle(document.querySelector('.terminal-outer-container')).paddingLeft.split('px')[0], 10); <ins> const paddingBottom = parseInt(getComputedStyle(document.querySelector('.terminal-wrapper.active')).paddingBottom.split('px')[0], 10); </ins> // Use left padding as right padding, right padding is not defined in CSS just in case // xterm.js causes an unexpected overflow. const innerWidth = width - padding * 2; <del> TerminalInstance._lastKnownDimensions = new Dimension(innerWidth, height); </del> <ins> const innerHeight = height - paddingBottom; TerminalInstance._lastKnownDimensions = new Dimension(innerWidth, innerHeight); </ins> return TerminalInstance._lastKnownDimensions; }


Question:
FYI I commented out the test. Please fix it and enable it.
The test is failing because the DOM is no longer filled with nodes so these tests can't work the way they did previously. Is it possible with Spectron to pull a DOM node object, including any custom properties it has? If so I could attach a reference to the object to the terminal element which would allow querying the terminal for this sort of information really easily.
Yes, you can access the DOM in Spectron and we do it in multiple places. For example refer to . This will allow you to execute java script code on the renderer process that has access to DOM and let you return the model you want. But please be aware that, Since it runs in a different process than the test process, console log does not work.
PR with fix is out , will merge in after release is branched off.

dom.addClass(this._wrapperElement, 'terminal-wrapper'); this._xtermElement = document.createElement('div'); <ins> // Attach the xterm object to the DOM, exposing it to the smoke tests (<any>this._wrapperElement).xterm = this._xterm; </ins> this._xterm.open(this._xtermElement); this._xterm.attachCustomKeyEventHandler((event: KeyboardEvent) => { // Disable all input if the terminal is exiting


Question:
FYI I commented out the test. Please fix it and enable it.
The test is failing because the DOM is no longer filled with nodes so these tests can't work the way they did previously. Is it possible with Spectron to pull a DOM node object, including any custom properties it has? If so I could attach a reference to the object to the terminal element which would allow querying the terminal for this sort of information really easily.
Yes, you can access the DOM in Spectron and we do it in multiple places. For example refer to . This will allow you to execute java script code on the renderer process that has access to DOM and let you return the model you want. But please be aware that, Since it runs in a different process than the test process, console log does not work.
PR with fix is out , will merge in after release is branched off.

import { SpectronApplication } from '../../spectron/application'; <del> export class Terminal { static TERMINAL_SELECTOR = '.panel.integrated-terminal'; static TERMINAL_ROWS_SELECTOR = `${Terminal.TERMINAL_SELECTOR} .xterm-rows > div`; static TERMINAL_CURSOR = `${Terminal.TERMINAL_SELECTOR} .terminal-cursor`; </del> <ins> const PANEL_SELECTOR = 'div[id="workbench.panel.terminal"]'; const XTERM_SELECTOR = `${PANEL_SELECTOR} .terminal-wrapper`; export class Terminal { </ins> constructor(private spectron: SpectronApplication) { } public async showTerminal(): Promise<void> { if (!await this.isVisible()) { await this.spectron.workbench.quickopen.runCommand('View: Toggle Integrated Terminal'); <del> await this.spectron.client.waitForElement(Terminal.TERMINAL_CURSOR); </del> <ins> await this.spectron.client.waitForElement(XTERM_SELECTOR); </ins> await this.waitForTerminalText(text => text.length > 0, 'Waiting for Terminal to be ready'); } } public async isVisible(): Promise<boolean> { <del> const element = await this.spectron.client.element(Terminal.TERMINAL_SELECTOR); </del> <ins> const element = await this.spectron.client.element(PANEL_SELECTOR); </ins> return !!element; }


Question:
FYI I commented out the test. Please fix it and enable it.
The test is failing because the DOM is no longer filled with nodes so these tests can't work the way they did previously. Is it possible with Spectron to pull a DOM node object, including any custom properties it has? If so I could attach a reference to the object to the terminal element which would allow querying the terminal for this sort of information really easily.
Yes, you can access the DOM in Spectron and we do it in multiple places. For example refer to . This will allow you to execute java script code on the renderer process that has access to DOM and let you return the model you want. But please be aware that, Since it runs in a different process than the test process, console log does not work.
PR with fix is out , will merge in after release is branched off.

} private async getTerminalText(): Promise<string[]> { <del> const linesText: string[] = await this.spectron.webclient.selectorExecute<string[]>(Terminal.TERMINAL_ROWS_SELECTOR, div => (Array.isArray(div) ? div : [div]) .map(element => { function getTextFromAll(spanElements: NodeList): string { let text = ''; for (let i = 0; i < spanElements.length; i++) { text += getText(spanElements.item(i) as HTMLElement); } return text; } function getText(spanElement: HTMLElement): string { if (spanElement.hasChildNodes()) { return getTextFromAll(spanElement.childNodes); } return spanElement.textContent || ''; } return getTextFromAll(element.querySelectorAll('span')); })); let lastLineIndex = 0; for (let index = 0; index < linesText.length; index++) { if (linesText[index].trim()) { lastLineIndex = index; </del> <ins> return await this.spectron.webclient.selectorExecute(XTERM_SELECTOR, div => { const xterm = (<any>(Array.isArray(div) ? div[0] : div)).xterm; const buffer = xterm.buffer; const lines: string[] = []; for (let i = 0; i < buffer.lines.length; i++) { lines.push(buffer.translateBufferLineToString(i, true)); } return lines; </ins> } <del> } return linesText.slice(0, lastLineIndex + 1); </del> <ins> ); </ins> } }  No newline at end of file


Question:
I admit that it's a niche scenario, but I think that what "Open Changes" shows for not-yet-staged changes to files that have been detected as renamed in the index is incorrect, at least inconsistent with how changes to files in the index are shown that have not been renamed. Steps to Reproduce: an empty directory and initialize a git repository in it. that directory create two files and with identical content: This exact content is somewhat important, as I've confirmed that it triggers git's "rename detection" (checked with git v2.14.1). and commit both files. the first line in both files. to . "": ! does the right thing for both files, that is, it shows the changes between HEAD and the staged version: : ! : ! the first line in both files once more, but don't stage these changes. still shows the right thing for (in this case the changes between the staged version and the file in the working tree): ! As the content of both files is identical both in the index and the working tree, I would have expected the exact same result for , but now the left side is just empty instead of showing the staged version: ! VSCode Version: Code 1.16.1 (, 2017-09-14T16:26:20.018Z) OS Version: Linux x64 4.12.13-1-ARCH
Hehe great catch! Would you like to to it?
So is this issue still open and up for grabs? If so I would like to try to help
Just look above your comment, there's a PR for it already:
Fixed by

if (ref === '~') { const fileUri = Uri.file(path); const uriString = fileUri.toString(); <del> const [indexStatus] = repository.indexGroup.resourceStates.filter(r => r.original.toString() === uriString); </del> <ins> const [indexStatus] = repository.indexGroup.resourceStates.filter(r => r.resourceUri.toString() === uriString); </ins> ref = indexStatus ? '' : 'HEAD'; }


Question:
a .ts file tab to activate the "import statement" snippet Expected and actual: completes to a .tsx file (TypeScript + JSX) tab to activate the "import statement" snippet Actual: completes to Expected: completes to Is there any reason why the snippet is inconsistent between .ts and .tsx files?
Yes this is unintentional. I've marked this as help wanted in case anyone want to take a look. Here are the relevant snippet files:
Thanks! See I was also thinking it would be useful to add this to .js and .jsx extensions. What do you think?
Thanks for the PR! The change should be in the next insiders build Yes I think adding the same for js/jsx also make sense. Did you want to submit another PR that copies these snippets over to js/jsx?

"Import external module.": { "prefix": "import statement", "body": [ <del> "import ${1:name} = require('$0');" </del> <ins> "import { $0 } from "${1:module}";" </ins> ], "description": "Import external module." },


Question: VSCode Version: Code 1.15.1 (, 2017-08-16T18:07:25.676Z) OS Version: WindowsNT x64 10.0. Extensions: ExtensionVersion ------ overtype0.2.0 python0.7.0 theme-dark-plus-contrast0.1.101 cpptools0.13.0 monitor-file1.0.1 (4 theme extensions excluded) Steps to Reproduce: there is such line in a *.bat file rem set SERVERVERSION=5.7 cursor on it, and uncomment with "Ctrl+/" expected: set SERVERVERSION=5.7 actual result: REM rem set SERVERVERSION=5.7 Looks like uncomment is unnecessarily case-sensitive. It should uncomment despite it is 'rem' or 'REM'. I don't care whether with next "Ctrl+/" it will add Upper-Case 'REM' instead of 'rem' - it is not problem. <!-- Launch with to check. --Reproduces without extensions: Yes/No

if (offset + needleLength > haystackLength) { return false; } <ins> const haystackUpper = haystack.toUpperCase(); const needleUpper = needle.toUpperCase(); </ins> for (let i = 0; i < needleLength; i++) { <del> if (haystack.charCodeAt(offset + i) !== needle.charCodeAt(i)) { </del> <ins> if (haystackUpper.charCodeAt(offset + i) !== needleUpper.charCodeAt(i)) { </ins> return false; } }


Question:
VSCode Version: Code 1.17.0 (, 2017-10-05T06:07:51.906Z) OS Version: Darwin x64 16.7.0 Extensions: ExtensionVersion ------ vscode-markdownlint0.10.1 xml1.9.2 code-settings-sync2.8.3 sonarlint-vscode1.1.0 html-snippets0.1.0 Bookmarks0.16.0 markdown-preview-github-styles0.0.4 path-intellisense1.4.2 gitignore0.5.0 vscode-eslint1.3.2 githistory0.2.3 jquerysnippets0.0.1 tslint1.0.9 auto-rename-tag0.0.14 Angular22.7.0 HTMLHint0.4.0 cpptools0.13.1 csharp1.12.1 indent-rainbow0.7.2 tsimporter1.2.14 java0.11.0 vscode-open0.1.0 stylelint0.29.1 code-spell-checker1.4.7 code-spell-checker-spanish1.0.1 bootstrap-3-snippets0.1.0 JavaScriptSnippets1.5.0 Steps to Reproduce: new CSS file to add -bdrd with vendor-prefixed as mention in emmet documentation adding a hyphen before. But not show any suggestion or auto-complation list. Expected result: Emmet Documentation: I'm not see in his documentation if there is a way or option to enable this behaviour: <!-- Launch with to check. --Reproduces without extensions: Yes
You are right, expanding the abbreviations so that all vendor prefixes are included is not supported in Emmet 2.0 Have you used the command? We could just overload that command to add missing vendor prefixes or have a new command to do the same.
I'm not using it, but I think is better add it to a new command.
Note to verifier: The vendor prefixes should be attached as documented in when using the command.

}, "css.webkitProperties": { "type": "string", <del> "default": "", </del> <ins> "default": "animation, animation-delay, animation-direction, animation-duration, animation-fill-mode, animation-iteration-count, animation-name, animation-play-state, animation-timing-function, appearance, backface-visibility, background-clip, background-composite, background-origin, background-size, border-fit, border-horizontal-spacing, border-image, border-vertical-spacing, box-align, box-direction, box-flex, box-flex-group, box-lines, box-ordinal-group, box-orient, box-pack, box-reflect, box-shadow, color-correction, column-break-after, column-break-before, column-break-inside, column-count, column-gap, column-rule-color, column-rule-style, column-rule-width, column-span, column-width, dashboard-region, font-smoothing, highlight, hyphenate-character, hyphenate-limit-after, hyphenate-limit-before, hyphens, line-box-contain, line-break, line-clamp, locale, margin-before-collapse, margin-after-collapse, marquee-direction, marquee-increment, marquee-repetition, marquee-style, mask-attachment, mask-box-image, mask-box-image-outset, mask-box-image-repeat, mask-box-image-slice, mask-box-image-source, mask-box-image-width, mask-clip, mask-composite, mask-image, mask-origin, mask-position, mask-repeat, mask-size, nbsp-mode, perspective, perspective-origin, rtl-ordering, text-combine, text-decorations-in-effect, text-emphasis-color, text-emphasis-position, text-emphasis-style, text-fill-color, text-orientation, text-security, text-stroke-color, text-stroke-width, transform, transition, transform-origin, transform-style, transition-delay, transition-duration, transition-property, transition-timing-function, user-drag, user-modify, user-select, writing-mode, svg-shadow, box-sizing, border-radius", </ins> "description": "%emmetPreferencesCssWebkitProperties%" }, "css.mozProperties": { "type": "string", <del> "default": "", </del> <ins> "default": "animation-delay, animation-direction, animation-duration, animation-fill-mode, animation-iteration-count, animation-name, animation-play-state, animation-timing-function, appearance, backface-visibility, background-inline-policy, binding, border-bottom-colors, border-image, border-left-colors, border-right-colors, border-top-colors, box-align, box-direction, box-flex, box-ordinal-group, box-orient, box-pack, box-shadow, box-sizing, column-count, column-gap, column-rule-color, column-rule-style, column-rule-width, column-width, float-edge, font-feature-settings, font-language-override, force-broken-image-icon, hyphens, image-region, orient, outline-radius-bottomleft, outline-radius-bottomright, outline-radius-topleft, outline-radius-topright, perspective, perspective-origin, stack-sizing, tab-size, text-blink, text-decoration-color, text-decoration-line, text-decoration-style, text-size-adjust, transform, transform-origin, transform-style, transition, transition-delay, transition-duration, transition-property, transition-timing-function, user-focus, user-input, user-modify, user-select, window-shadow, background-clip, border-radius", </ins> "description": "%emmetPreferencesCssMozProperties%" }, "css.oProperties": { "type": "string", <del> "default": "", </del> <ins> "default": "dashboard-region, animation, animation-delay, animation-direction, animation-duration, animation-fill-mode, animation-iteration-count, animation-name, animation-play-state, animation-timing-function, border-image, link, link-source, object-fit, object-position, tab-size, table-baseline, transform, transform-origin, transition, transition-delay, transition-duration, transition-property, transition-timing-function, accesskey, input-format, input-required, marquee-dir, marquee-loop, marquee-speed, marquee-style", </ins> "description": "%emmetPreferencesCssOProperties%" }, "css.msProperties": { "type": "string", <del> "default": "", </del> <ins> "default": "accelerator, backface-visibility, background-position-x, background-position-y, behavior, block-progression, box-align, box-direction, box-flex, box-line-progression, box-lines, box-ordinal-group, box-orient, box-pack, content-zoom-boundary, content-zoom-boundary-max, content-zoom-boundary-min, content-zoom-chaining, content-zoom-snap, content-zoom-snap-points, content-zoom-snap-type, content-zooming, filter, flow-from, flow-into, font-feature-settings, grid-column, grid-column-align, grid-column-span, grid-columns, grid-layer, grid-row, grid-row-align, grid-row-span, grid-rows, high-contrast-adjust, hyphenate-limit-chars, hyphenate-limit-lines, hyphenate-limit-zone, hyphens, ime-mode, interpolation-mode, layout-flow, layout-grid, layout-grid-char, layout-grid-line, layout-grid-mode, layout-grid-type, line-break, overflow-style, perspective, perspective-origin, perspective-origin-x, perspective-origin-y, scroll-boundary, scroll-boundary-bottom, scroll-boundary-left, scroll-boundary-right, scroll-boundary-top, scroll-chaining, scroll-rails, scroll-snap-points-x, scroll-snap-points-y, scroll-snap-type, scroll-snap-x, scroll-snap-y, scrollbar-arrow-color, scrollbar-base-color, scrollbar-darkshadow-color, scrollbar-face-color, scrollbar-highlight-color, scrollbar-shadow-color, scrollbar-track-color, text-align-last, text-autospace, text-justify, text-kashida-space, text-overflow, text-size-adjust, text-underline-position, touch-action, transform, transform-origin, transform-origin-x, transform-origin-y, transform-origin-z, transform-style, transition, transition-delay, transition-duration, transition-property, transition-timing-function, user-select, word-break, wrap-flow, wrap-margin, wrap-through, writing-mode", </ins> "description": "%emmetPreferencesCssMsProperties%" } }


Question: VSCode Version: Code - Insiders 1.19.0-insider (, 2017-12-01T06:07:42.474Z) OS Version: Darwin x64 16.5.0 Extensions: ExtensionVersion ------ beautify1.1.1 vscode-caniuse0.5.0 jshint0.10.15 tslint1.0.24 php-debug1.12.1 php-intellisense2.0.4 php-pack1.0.1 plantuml2.3.3 vscode-duplicate1.2.0 sublime-keybindings3.0.3 debugger-for-chrome3.5.0 laravel-blade1.10.0 Steps to Reproduce: a HTML file with references to javascript files over the path of the JS file in any <scripttag 'll get the tooltip "Alt + click to follow link" Well, there isn't an Alt key in my MacOS keyboard (stock Apple keyboard). So saying "Option + click to follow link" will make more sense for Mac users. Not a big deal though. Thought I'll just point out. :) <!-- Launch with to check. --Reproduces without extensions: Yes/No

: nls.localize('links.command', "Ctrl + click to execute command") ); <del> const HOVER_MESSAGE_GENERAL_ALT = new MarkdownString().appendText(nls.localize('links.navigate.al', "Alt + click to follow link")); const HOVER_MESSAGE_COMMAND_ALT = new MarkdownString().appendText(nls.localize('links.command.al', "Alt + click to execute command")); </del> <ins> const HOVER_MESSAGE_GENERAL_ALT = new MarkdownString().appendText( platform.isMacintosh ? nls.localize('links.navigate.al.mac', "Option + click to follow link") : nls.localize('links.navigate.al', "Alt + click to follow link") ); const HOVER_MESSAGE_COMMAND_ALT = new MarkdownString().appendText( platform.isMacintosh ? nls.localize('links.command.al.mac', "Option + click to execute command") : nls.localize('links.command.al', "Alt + click to execute command") ); </ins> const decoration = { meta: ModelDecorationOptions.register({


Question:
VSCode Version: Version 1.19.1 (1.19.1) 0759f77bb8d86658bc935a10a64f6182c5a1eebaOS Version: macOS, 10.12.6 Steps to Reproduce: TypeScript React, and Reproduces without extensions: Yes.
For the case: where the user has just typed , returns false since returns . This in turn is caused by having the following language ranges for the string : where = and = . These language ranges cause to take as the current word, which does not match against the known word patterns
Any update on this? The Ctrl-Space works and provides the correct autocomplete options for props with associated type. Would be nice if I didn't have to do that each time.
Have the same problem, but wonder about: "... autocomplete options for props ...". Is VS Code capable to autocomplete my custom from an imported component?

const position = this.validatePosition(_position); const lineContent = this.getLineContent(position.lineNumber); const lineTokens = this._getLineTokens(position.lineNumber); <del> const offset = position.column - 1; const tokenIndex = lineTokens.findTokenIndexAtOffset(offset); </del> <ins> const tokenIndex = lineTokens.findTokenIndexAtOffset(position.column - 1); // (1). First try checking right biased word const [rbStartOffset, rbEndOffset] = TextModel._findLanguageBoundaries(lineTokens, tokenIndex); const rightBiasedWord = getWordAtText( position.column, LanguageConfigurationRegistry.getWordDefinition(lineTokens.getLanguageId(tokenIndex)), lineContent.substring(rbStartOffset, rbEndOffset), rbStartOffset ); if (rightBiasedWord) { return rightBiasedWord; } // (2). Else, if we were at a language boundary, check the left biased word if (tokenIndex > 0 && rbStartOffset === position.column - 1) { // edge case, where `position` sits between two tokens belonging to two different languages const [lbStartOffset, lbEndOffset] = TextModel._findLanguageBoundaries(lineTokens, tokenIndex - 1); const leftBiasedWord = getWordAtText( position.column, LanguageConfigurationRegistry.getWordDefinition(lineTokens.getLanguageId(tokenIndex - 1)), lineContent.substring(lbStartOffset, lbEndOffset), lbStartOffset ); if (leftBiasedWord) { return leftBiasedWord; } } return null; } private static _findLanguageBoundaries(lineTokens: LineTokens, tokenIndex: number): [number, number] { </ins> const languageId = lineTokens.getLanguageId(tokenIndex); // go left until a different language is hit


Question:
VSCode Version: Version 1.19.1 (1.19.1) 0759f77bb8d86658bc935a10a64f6182c5a1eebaOS Version: macOS, 10.12.6 Steps to Reproduce: TypeScript React, and Reproduces without extensions: Yes.
For the case: where the user has just typed , returns false since returns . This in turn is caused by having the following language ranges for the string : where = and = . These language ranges cause to take as the current word, which does not match against the known word patterns
Any update on this? The Ctrl-Space works and provides the correct autocomplete options for props with associated type. Would be nice if I didn't have to do that each time.
Have the same problem, but wonder about: "... autocomplete options for props ...". Is VS Code capable to autocomplete my custom from an imported component?

endOffset = lineTokens.getEndOffset(i); } <del> return getWordAtText( position.column, LanguageConfigurationRegistry.getWordDefinition(languageId), lineContent.substring(startOffset, endOffset), startOffset ); </del> <ins> return [startOffset, endOffset]; </ins> } public getWordUntilPosition(position: IPosition): model.IWordAtPosition {


Question:
VSCode Version: Version 1.19.1 (1.19.1) 0759f77bb8d86658bc935a10a64f6182c5a1eebaOS Version: macOS, 10.12.6 Steps to Reproduce: TypeScript React, and Reproduces without extensions: Yes.
For the case: where the user has just typed , returns false since returns . This in turn is caused by having the following language ranges for the string : where = and = . These language ranges cause to take as the current word, which does not match against the known word patterns
Any update on this? The Ctrl-Space works and provides the correct autocomplete options for props with associated type. Would be nice if I didn't have to do that each time.
Have the same problem, but wonder about: "... autocomplete options for props ...". Is VS Code capable to autocomplete my custom from an imported component?

} const pos = editor.getPosition(); model.tokenizeIfCheap(pos.lineNumber); const word = model.getWordAtPosition(pos); if (!word) { return false;


Question:
VSCode Version: Version 1.19.1 (1.19.1) 0759f77bb8d86658bc935a10a64f6182c5a1eebaOS Version: macOS, 10.12.6 Steps to Reproduce: TypeScript React, and Reproduces without extensions: Yes.
For the case: where the user has just typed , returns false since returns . This in turn is caused by having the following language ranges for the string : where = and = . These language ranges cause to take as the current word, which does not match against the known word patterns
Any update on this? The Ctrl-Space works and provides the correct autocomplete options for props with associated type. Would be nice if I didn't have to do that each time.
Have the same problem, but wonder about: "... autocomplete options for props ...". Is VS Code capable to autocomplete my custom from an imported component?

import * as assert from 'assert'; import { Event } from 'vs/base/common/event'; import URI from 'vs/base/common/uri'; <del> import { IDisposable, dispose } from 'vs/base/common/lifecycle'; </del> <ins> import { IDisposable, dispose, Disposable } from 'vs/base/common/lifecycle'; </ins> import { TextModel } from 'vs/editor/common/model/textModel'; import { Handler } from 'vs/editor/common/editorCommon'; <del> import { ISuggestSupport, ISuggestResult, SuggestRegistry, SuggestTriggerKind } from 'vs/editor/common/modes'; </del> <ins> import { ISuggestSupport, ISuggestResult, SuggestRegistry, SuggestTriggerKind, LanguageIdentifier, TokenizationRegistry, IState, MetadataConsts } from 'vs/editor/common/modes'; </ins> import { SuggestModel, LineContext } from 'vs/editor/contrib/suggest/suggestModel'; import { TestCodeEditor, MockScopeLocation } from 'vs/editor/test/browser/testCodeEditor'; import { ServiceCollection } from 'vs/platform/instantiation/common/serviceCollection';


Question:
VSCode Version: Version 1.19.1 (1.19.1) 0759f77bb8d86658bc935a10a64f6182c5a1eebaOS Version: macOS, 10.12.6 Steps to Reproduce: TypeScript React, and Reproduces without extensions: Yes.
For the case: where the user has just typed , returns false since returns . This in turn is caused by having the following language ranges for the string : where = and = . These language ranges cause to take as the current word, which does not match against the known word patterns
Any update on this? The Ctrl-Space works and provides the correct autocomplete options for props with associated type. Would be nice if I didn't have to do that each time.
Have the same problem, but wonder about: "... autocomplete options for props ...". Is VS Code capable to autocomplete my custom from an imported component?

import { IStorageService, NullStorageService } from 'vs/platform/storage/common/storage'; import { SnippetController2 } from 'vs/editor/contrib/snippet/snippetController2'; import { ISelectedSuggestion } from 'vs/editor/contrib/suggest/suggestWidget'; <ins> import { MockMode } from 'vs/editor/test/common/mocks/mockMode'; import { LanguageConfigurationRegistry } from 'vs/editor/common/modes/languageConfigurationRegistry'; import { TokenizationResult2 } from 'vs/editor/common/core/token'; import { NULL_STATE } from 'vs/editor/common/modes/nullMode'; </ins> function createMockEditor(model: TextModel): TestCodeEditor { const contextKeyService = new MockContextKeyService();


Question:
VSCode Version: Version 1.19.1 (1.19.1) 0759f77bb8d86658bc935a10a64f6182c5a1eebaOS Version: macOS, 10.12.6 Steps to Reproduce: TypeScript React, and Reproduces without extensions: Yes.
For the case: where the user has just typed , returns false since returns . This in turn is caused by having the following language ranges for the string : where = and = . These language ranges cause to take as the current word, which does not match against the known word patterns
Any update on this? The Ctrl-Space works and provides the correct autocomplete options for props with associated type. Would be nice if I didn't have to do that each time.
Have the same problem, but wonder about: "... autocomplete options for props ...". Is VS Code capable to autocomplete my custom from an imported component?

} suite('SuggestModel - Context', function () { <ins> const OUTER_LANGUAGE_ID = new LanguageIdentifier('outerMode', 3); const INNER_LANGUAGE_ID = new LanguageIdentifier('innerMode', 4); class OuterMode extends MockMode { constructor() { super(OUTER_LANGUAGE_ID); this._register(LanguageConfigurationRegistry.register(this.getLanguageIdentifier(), {})); this._register(TokenizationRegistry.register(this.getLanguageIdentifier().language, { getInitialState: (): IState => NULL_STATE, tokenize: undefined, tokenize2: (line: string, state: IState): TokenizationResult2 => { const tokensArr: number[] = []; let prevLanguageId: LanguageIdentifier = undefined; for (let i = 0; i < line.length; i++) { const languageId = (line.charAt(i) === 'x' ? INNER_LANGUAGE_ID : OUTER_LANGUAGE_ID); if (prevLanguageId !== languageId) { tokensArr.push(i); tokensArr.push((languageId.id << MetadataConsts.LANGUAGEID_OFFSET)); } prevLanguageId = languageId; } const tokens = new Uint32Array(tokensArr.length); for (let i = 0; i < tokens.length; i++) { tokens[i] = tokensArr[i]; } return new TokenizationResult2(tokens, state); } })); } } </ins> <del> let model: TextModel; </del> <ins> class InnerMode extends MockMode { constructor() { super(INNER_LANGUAGE_ID); this._register(LanguageConfigurationRegistry.register(this.getLanguageIdentifier(), {})); } } </ins> <del> setup(function () { model = TextModel.createFromString('Das Pferd frisst keinen Gurkensalat - Philipp Reis 1861.nWer hat's erfunden?'); </del> <ins> const assertAutoTrigger = (model: TextModel, offset: number, expected: boolean, message?: string): void => { const pos = model.getPositionAt(offset); const editor = createMockEditor(model); editor.setPosition(pos); assert.equal(LineContext.shouldAutoTrigger(editor), expected, message); editor.dispose(); }; let disposables: Disposable[] = []; setup(() => { disposables = []; </ins> }); teardown(function () { <del> model.dispose(); </del> <ins> dispose(disposables); disposables = []; </ins> }); test('Context - shouldAutoTrigger', function () { <ins> const model = TextModel.createFromString('Das Pferd frisst keinen Gurkensalat - Philipp Reis 1861.nWer hat's erfunden?'); disposables.push(model); </ins> <del> function assertAutoTrigger(offset: number, expected: boolean): void { const pos = model.getPositionAt(offset); const editor = createMockEditor(model); editor.setPosition(pos); assert.equal(LineContext.shouldAutoTrigger(editor), expected); editor.dispose(); } assertAutoTrigger(3, true); // end of word, Das| assertAutoTrigger(4, false); // no word Das | assertAutoTrigger(1, false); // middle of word D|as assertAutoTrigger(55, false); // number, 1861| </del> <ins> assertAutoTrigger(model, 3, true, 'end of word, Das|'); assertAutoTrigger(model, 4, false, 'no word Das |'); assertAutoTrigger(model, 1, false, 'middle of word D|as'); assertAutoTrigger(model, 55, false, 'number, 1861|'); </ins> }); <ins> test('shouldAutoTrigger at embedded language boundaries', () => { const outerMode = new OuterMode(); const innerMode = new InnerMode(); disposables.push(outerMode, innerMode); const model = TextModel.createFromString('a<xx>a<x>', undefined, outerMode.getLanguageIdentifier()); disposables.push(model); assertAutoTrigger(model, 1, true, 'a|<x — should trigger at end of word'); assertAutoTrigger(model, 2, false, 'a<|x — should NOT trigger at start of word'); assertAutoTrigger(model, 3, false, 'a<x|x —  should NOT trigger in middle of word'); assertAutoTrigger(model, 4, true, 'a<xx|> — should trigger at boundary between languages'); assertAutoTrigger(model, 5, false, 'a<xx>|a — should NOT trigger at start of word'); assertAutoTrigger(model, 6, true, 'a<xx>a|< — should trigger at end of word'); assertAutoTrigger(model, 8, true, 'a<xx>a<x|> — should trigger at end of word at boundary'); }); </ins> }); suite('SuggestModel - TriggerAndCancelOracle', function () {


Question:
VSCode Version: Version 1.19.1 (1.19.1) 0759f77bb8d86658bc935a10a64f6182c5a1eebaOS Version: macOS, 10.12.6 Steps to Reproduce: TypeScript React, and Reproduces without extensions: Yes.
For the case: where the user has just typed , returns false since returns . This in turn is caused by having the following language ranges for the string : where = and = . These language ranges cause to take as the current word, which does not match against the known word patterns
Any update on this? The Ctrl-Space works and provides the correct autocomplete options for props with associated type. Would be nice if I didn't have to do that each time.
Have the same problem, but wonder about: "... autocomplete options for props ...". Is VS Code capable to autocomplete my custom from an imported component?

ModelRawLinesDeleted, ModelRawLinesInserted } from 'vs/editor/common/model/textModelEvents'; import { TextModel } from 'vs/editor/common/model/textModel'; <ins> import { LanguageIdentifier, TokenizationRegistry, IState, MetadataConsts } from 'vs/editor/common/modes'; import { MockMode } from 'vs/editor/test/common/mocks/mockMode'; import { LanguageConfigurationRegistry } from 'vs/editor/common/modes/languageConfigurationRegistry'; import { TokenizationResult2 } from 'vs/editor/common/core/token'; import { NULL_STATE } from 'vs/editor/common/modes/nullMode'; import { dispose, Disposable } from 'vs/base/common/lifecycle'; </ins> // --------- utils


Question:
VSCode Version: Version 1.19.1 (1.19.1) 0759f77bb8d86658bc935a10a64f6182c5a1eebaOS Version: macOS, 10.12.6 Steps to Reproduce: TypeScript React, and Reproduces without extensions: Yes.
For the case: where the user has just typed , returns false since returns . This in turn is caused by having the following language ranges for the string : where = and = . These language ranges cause to take as the current word, which does not match against the known word patterns
Any update on this? The Ctrl-Space works and provides the correct autocomplete options for props with associated type. Would be nice if I didn't have to do that each time.
Have the same problem, but wonder about: "... autocomplete options for props ...". Is VS Code capable to autocomplete my custom from an imported component?

suite('Editor Model - Words', () => { <del> var thisModel: TextModel; </del> <ins> const OUTER_LANGUAGE_ID = new LanguageIdentifier('outerMode', 3); const INNER_LANGUAGE_ID = new LanguageIdentifier('innerMode', 4); class OuterMode extends MockMode { constructor() { super(OUTER_LANGUAGE_ID); this._register(LanguageConfigurationRegistry.register(this.getLanguageIdentifier(), {})); this._register(TokenizationRegistry.register(this.getLanguageIdentifier().language, { getInitialState: (): IState => NULL_STATE, tokenize: undefined, tokenize2: (line: string, state: IState): TokenizationResult2 => { const tokensArr: number[] = []; let prevLanguageId: LanguageIdentifier = undefined; for (let i = 0; i < line.length; i++) { const languageId = (line.charAt(i) === 'x' ? INNER_LANGUAGE_ID : OUTER_LANGUAGE_ID); if (prevLanguageId !== languageId) { tokensArr.push(i); tokensArr.push((languageId.id << MetadataConsts.LANGUAGEID_OFFSET)); } prevLanguageId = languageId; } const tokens = new Uint32Array(tokensArr.length); for (let i = 0; i < tokens.length; i++) { tokens[i] = tokensArr[i]; } return new TokenizationResult2(tokens, state); } })); } } class InnerMode extends MockMode { constructor() { super(INNER_LANGUAGE_ID); this._register(LanguageConfigurationRegistry.register(this.getLanguageIdentifier(), {})); } } let disposables: Disposable[] = []; </ins> setup(() => { <del> var text = ['This text has some  words. ']; thisModel = TextModel.createFromString(text.join('n')); </del> <ins> disposables = []; </ins> }); teardown(() => { <del> thisModel.dispose(); </del> <ins> dispose(disposables); disposables = []; </ins> }); test('Get word at position', () => { <ins> const text = ['This text has some  words. ']; const thisModel = TextModel.createFromString(text.join('n')); disposables.push(thisModel); </ins> assert.deepEqual(thisModel.getWordAtPosition(new Position(1, 1)), { word: 'This', startColumn: 1, endColumn: 5 }); assert.deepEqual(thisModel.getWordAtPosition(new Position(1, 2)), { word: 'This', startColumn: 1, endColumn: 5 }); assert.deepEqual(thisModel.getWordAtPosition(new Position(1, 4)), { word: 'This', startColumn: 1, endColumn: 5 });


Question:
VSCode Version: Version 1.19.1 (1.19.1) 0759f77bb8d86658bc935a10a64f6182c5a1eebaOS Version: macOS, 10.12.6 Steps to Reproduce: TypeScript React, and Reproduces without extensions: Yes.
For the case: where the user has just typed , returns false since returns . This in turn is caused by having the following language ranges for the string : where = and = . These language ranges cause to take as the current word, which does not match against the known word patterns
Any update on this? The Ctrl-Space works and provides the correct autocomplete options for props with associated type. Would be nice if I didn't have to do that each time.
Have the same problem, but wonder about: "... autocomplete options for props ...". Is VS Code capable to autocomplete my custom from an imported component?

assert.deepEqual(thisModel.getWordAtPosition(new Position(1, 27)), null); assert.deepEqual(thisModel.getWordAtPosition(new Position(1, 28)), null); }); <ins> test('getWordAtPosition at embedded language boundaries', () => { const outerMode = new OuterMode(); const innerMode = new InnerMode(); disposables.push(outerMode, innerMode); const model = TextModel.createFromString('ab<xx>ab<x>', undefined, outerMode.getLanguageIdentifier()); disposables.push(model); assert.deepEqual(model.getWordAtPosition(new Position(1, 1)), { word: 'ab', startColumn: 1, endColumn: 3 }); assert.deepEqual(model.getWordAtPosition(new Position(1, 2)), { word: 'ab', startColumn: 1, endColumn: 3 }); assert.deepEqual(model.getWordAtPosition(new Position(1, 3)), { word: 'ab', startColumn: 1, endColumn: 3 }); assert.deepEqual(model.getWordAtPosition(new Position(1, 4)), { word: 'xx', startColumn: 4, endColumn: 6 }); assert.deepEqual(model.getWordAtPosition(new Position(1, 5)), { word: 'xx', startColumn: 4, endColumn: 6 }); assert.deepEqual(model.getWordAtPosition(new Position(1, 6)), { word: 'xx', startColumn: 4, endColumn: 6 }); assert.deepEqual(model.getWordAtPosition(new Position(1, 7)), { word: 'ab', startColumn: 7, endColumn: 9 }); }); </ins> });


Question: In , the comparison functions , , , and have misleading descriptions. For example, says "Check if is before this position." I think it would be more clear to say something like "Check if this position is before ", as that is when is returned. Likewise for the other three.

constructor(line: number, character: number); /** <del> * Check if `other` is before this position. </del> <ins> * Check if this position is before `other`. </ins> * * @param other A position. * @return `true` if position is on a smaller line


Question: In , the comparison functions , , , and have misleading descriptions. For example, says "Check if is before this position." I think it would be more clear to say something like "Check if this position is before ", as that is when is returned. Likewise for the other three.

isBefore(other: Position): boolean; /** <del> * Check if `other` is before or equal to this position. </del> <ins> * Check if this position is before or equal to `other`. </ins> * * @param other A position. * @return `true` if position is on a smaller line


Question: In , the comparison functions , , , and have misleading descriptions. For example, says "Check if is before this position." I think it would be more clear to say something like "Check if this position is before ", as that is when is returned. Likewise for the other three.

isBeforeOrEqual(other: Position): boolean; /** <del> * Check if `other` is after this position. </del> <ins> * Check if this position is after `other`. </ins> * * @param other A position. * @return `true` if position is on a greater line


Question: In , the comparison functions , , , and have misleading descriptions. For example, says "Check if is before this position." I think it would be more clear to say something like "Check if this position is before ", as that is when is returned. Likewise for the other three.

isAfter(other: Position): boolean; /** <del> * Check if `other` is after or equal to this position. </del> <ins> * Check if this position is after or equal to `other`. </ins> * * @param other A position. * @return `true` if position is on a greater line


Question: In , the comparison functions , , , and have misleading descriptions. For example, says "Check if is before this position." I think it would be more clear to say something like "Check if this position is before ", as that is when is returned. Likewise for the other three.

isAfterOrEqual(other: Position): boolean; /** <del> * Check if `other` equals this position. </del> <ins> * Check if this position is equal to `other`. </ins> * * @param other A position. * @return `true` if the line and character of the given position are equal to


Question:
It would be nice to invoke current line codelens actions without moving hands of from keyboard to mouse. It could be done via context ctrl+. where codelens actions are or from ctrl+p, or even new shortcut key which opens context menu which contains only codelens actions. They are sometimes available if extension implements them that way that they are to menus/context etc but this probably could be handled more generic way in vscode itself?
Hi! I just opened a PR with the ability to trigger codelenses with the keyboard. Hope you find this helpful as I do :D I appreciate any suggestions and comments from people coming to this issue

import { toDisposable, DisposableStore, dispose } from 'vs/base/common/lifecycle'; import { StableEditorScrollState } from 'vs/editor/browser/core/editorState'; import { ICodeEditor, MouseTargetType, IViewZoneChangeAccessor, IActiveCodeEditor } from 'vs/editor/browser/editorBrowser'; <del> import { registerEditorContribution } from 'vs/editor/browser/editorExtensions'; </del> <ins> import { registerEditorContribution, EditorCommand, ServicesAccessor } from 'vs/editor/browser/editorExtensions'; </ins> import { IEditorContribution } from 'vs/editor/common/editorCommon'; import { IModelDecorationsChangeAccessor } from 'vs/editor/common/model'; import { CodeLensProviderRegistry, CodeLens } from 'vs/editor/common/modes';


Question:
It would be nice to invoke current line codelens actions without moving hands of from keyboard to mouse. It could be done via context ctrl+. where codelens actions are or from ctrl+p, or even new shortcut key which opens context menu which contains only codelens actions. They are sometimes available if extension implements them that way that they are to menus/context etc but this probably could be handled more generic way in vscode itself?
Hi! I just opened a PR with the ability to trigger codelenses with the keyboard. Hope you find this helpful as I do :D I appreciate any suggestions and comments from people coming to this issue

import { EditorOption } from 'vs/editor/common/config/editorOptions'; import * as dom from 'vs/base/browser/dom'; import { hash } from 'vs/base/common/hash'; <ins> import { IQuickInputService, IQuickPickItem, IQuickPickSeparator } from 'vs/platform/quickinput/common/quickInput'; </ins> export class CodeLensContribution implements IEditorContribution {


Question:
It would be nice to invoke current line codelens actions without moving hands of from keyboard to mouse. It could be done via context ctrl+. where codelens actions are or from ctrl+p, or even new shortcut key which opens context menu which contains only codelens actions. They are sometimes available if extension implements them that way that they are to menus/context etc but this probably could be handled more generic way in vscode itself?
Hi! I just opened a PR with the ability to trigger codelenses with the keyboard. Hope you find this helpful as I do :D I appreciate any suggestions and comments from people coming to this issue

} }); } <ins> public getLenses(): CodeLensWidget[] { return this._lenses; } } export class ShowLensesInCurrentLineCommand extends EditorCommand { public runEditorCommand(accessor: ServicesAccessor, editor: ICodeEditor, args: any): void | Promise<void> { const quickInputService = accessor.get(IQuickInputService); const commandService = accessor.get(ICommandService); const notificationService = accessor.get(INotificationService); const lineNumber = editor.getSelection()?.positionLineNumber; const codelensController = editor.getContribution(CodeLensContribution.ID) as CodeLensContribution; const activeLensesWidgets = codelensController.getLenses().filter(lens => lens.getLineNumber() === lineNumber); const commandArguments: Map<string, any[] | undefined> = new Map(); const items: (IQuickPickItem | IQuickPickSeparator)[] = []; activeLensesWidgets.forEach(widget => { widget.getItems().forEach(codelens => { const command = codelens.symbol.command; if (!command) { return; } items.push({ id: command.id, label: command.title }); commandArguments.set(command.id, command.arguments); }); }); // We dont want an empty picker if (!items.length) { return; } quickInputService.pick(items, { canPickMany: false }).then(item => { const id = item.id!; commandService.executeCommand(id, ...(commandArguments.get(id) || [])).catch(err => notificationService.error(err)); }); } </ins> } registerEditorContribution(CodeLensContribution.ID, CodeLensContribution); <ins> const showLensesInCurrentLineCommand = new ShowLensesInCurrentLineCommand({ id: 'codelens.showLensesInCurrentLine', precondition: undefined }); showLensesInCurrentLineCommand.register(); </ins>


Question:
It would be nice to invoke current line codelens actions without moving hands of from keyboard to mouse. It could be done via context ctrl+. where codelens actions are or from ctrl+p, or even new shortcut key which opens context menu which contains only codelens actions. They are sometimes available if extension implements them that way that they are to menus/context etc but this probably could be handled more generic way in vscode itself?
Hi! I just opened a PR with the ability to trigger codelenses with the keyboard. Hope you find this helpful as I do :D I appreciate any suggestions and comments from people coming to this issue

} } } <ins> getItems(): CodeLensItem[] { return this._data; } </ins> } registerThemingParticipant((theme, collector) => {


Question:
It would be nice to invoke current line codelens actions without moving hands of from keyboard to mouse. It could be done via context ctrl+. where codelens actions are or from ctrl+p, or even new shortcut key which opens context menu which contains only codelens actions. They are sometimes available if extension implements them that way that they are to menus/context etc but this probably could be handled more generic way in vscode itself?
Hi! I just opened a PR with the ability to trigger codelenses with the keyboard. Hope you find this helpful as I do :D I appreciate any suggestions and comments from people coming to this issue

import { CancellationToken } from 'vs/base/common/cancellation'; import { IQuickPickItem, IPickOptions, IInputOptions, IQuickNavigateConfiguration, IQuickPick, IQuickInputButton, IInputBox, QuickPickInput } from 'vs/base/parts/quickinput/common/quickInput'; <del> export { IQuickPickItem, IPickOptions, IInputOptions, IQuickNavigateConfiguration, IQuickPick, IQuickInput, IQuickInputButton, IInputBox, IQuickPickItemButtonEvent, QuickPickInput, IQuickPickSeparator, IKeyMods } from 'vs/base/parts/quickinput/common/quickInput'; </del> <ins> export * from 'vs/base/parts/quickinput/common/quickInput'; </ins> export const IQuickInputService = createDecorator<IQuickInputService>('quickInputService');


Question:
With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.

import { IPartService, Position } from 'vs/workbench/services/part/common/partService'; const SPLIT_PANE_MIN_SIZE = 120; <ins> const TERMINAL_MIN_USEFUL_SIZE = 250; </ins> class SplitPaneContainer { private _height: number;


Question:
With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.

configHelper: ITerminalConfigHelper, shellLaunchConfig: IShellLaunchConfig ): ITerminalInstance { <ins> const newTerminalSize = ((this._panelPosition === Position.BOTTOM ? this._container.clientWidth : this._container.clientHeight) / (this._terminalInstances.length + 1)); if (newTerminalSize < TERMINAL_MIN_USEFUL_SIZE) { return undefined; } </ins> const instance = this._terminalService.createInstance( terminalFocusContextKey, configHelper,


Question:
With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.

} protected abstract _showTerminalCloseConfirmation(): TPromise<boolean>; <ins> protected abstract _showNotEnoughSpaceToast(): void; </ins> public abstract createTerminal(shell?: IShellLaunchConfig, wasNewTerminalAction?: boolean): ITerminalInstance; public abstract createTerminalRenderer(name: string): ITerminalInstance; public abstract createInstance(terminalFocusContextKey: IContextKey<boolean>, configHelper: ITerminalConfigHelper, container: HTMLElement, shellLaunchConfig: IShellLaunchConfig, doCreateProcess: boolean): ITerminalInstance;


Question:
With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.

} const instance = tab.split(this._terminalFocusContextKey, this.configHelper, shellLaunchConfig); <del> this._initInstanceListeners(instance); this._onInstancesChanged.fire(); </del> <ins> if (instance) { this._initInstanceListeners(instance); this._onInstancesChanged.fire(); </ins> <del> this._terminalTabs.forEach((t, i) => t.setVisible(i === this._activeTabIndex)); </del> <ins> this._terminalTabs.forEach((t, i) => t.setVisible(i === this._activeTabIndex)); } else { this._showNotEnoughSpaceToast(); } </ins> } protected _initInstanceListeners(instance: ITerminalInstance): void {


Question:
With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.

this._terminalTabs = []; this._configHelper = this._instantiationService.createInstance(TerminalConfigHelper); ipc.on('vscode:openFiles', (_event: any, request: IOpenFileRequest) => { // if the request to open files is coming in from the integrated terminal (identified though // the termProgram variable) and we are instructed to wait for editors close, wait for the


Question:
With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area. Probably the IDE should limit this to a defined maximum or something?
I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.
Thanks , I would agree that proper overflow behaviour is the way to go. Thanks!
I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..
Some terminal can be resized to a small size if they are not important. In some case, showing multiple terminals is just to notify the user whether they are running. Currently the minimum size of terminal is too large.
I suggest the minimum size of a terminal should be an option in Settings.

}).then(res => !res.confirmed); } <ins> protected _showNotEnoughSpaceToast(): void { this._notificationService.warn(nls.localize('terminal.minWidth', "Not enough space to split terminal.")); } </ins> public setContainers(panelContainer: HTMLElement, terminalContainer: HTMLElement): void { this._configHelper.panelContainer = panelContainer; this._terminalContainer = terminalContainer;


Question:
Issue Type: <bFeature Request</bWhen using a touch screen, I want to be able to interact with VSCode in an intuitive manner. When I touch the minimap, I expect the document to scroll immediately on touch-down, not on touch-up. Mouse-up makes sense for a mouse, but not for a touch. When I touch and drag the minimap, I expect the minimap to scroll with my finger. VS Code version: Code 1.22.1 (, 2018-04-06T02:26:57.615Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.487 --- <!-- score: 0.464 --- <!-- score: 0.449 --<!-- potentialduplicatescomment --
I haven't PR'd vscode before, if anyone who cares about this issue has tips on getting my PR ^^ merged and released I'm happy to put more work into it. I find it very frustrating not having touch-scrolling on the minimap, as I'm so used to it working in old-school Visual Studio!

import { ModelDecorationMinimapOptions } from 'vs/editor/common/model/textModel'; import { Selection } from 'vs/editor/common/core/selection'; import { Color } from 'vs/base/common/color'; <ins> import { GestureEvent, EventType, Gesture } from 'vs/base/browser/touch'; </ins> function getMinimapLineHeight(renderMinimap: RenderMinimap): number { if (renderMinimap === RenderMinimap.Large) {


Question:
Issue Type: <bFeature Request</bWhen using a touch screen, I want to be able to interact with VSCode in an intuitive manner. When I touch the minimap, I expect the document to scroll immediately on touch-down, not on touch-up. Mouse-up makes sense for a mouse, but not for a touch. When I touch and drag the minimap, I expect the minimap to scroll with my finger. VS Code version: Code 1.22.1 (, 2018-04-06T02:26:57.615Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.487 --- <!-- score: 0.464 --- <!-- score: 0.449 --<!-- potentialduplicatescomment --
I haven't PR'd vscode before, if anyone who cares about this issue has tips on getting my PR ^^ merged and released I'm happy to put more work into it. I find it very frustrating not having touch-scrolling on the minimap, as I'm so used to it working in old-school Visual Studio!

return Math.round(desiredSliderPosition / this._computedSliderRatio); } <ins> public getDesiredScrollTopFromTouchLocation(pageY: number): number { return Math.round((pageY - this.sliderHeight / 2) / this._computedSliderRatio); } </ins> public static create( options: MinimapOptions, viewportStartLineNumber: number,


Question:
Issue Type: <bFeature Request</bWhen using a touch screen, I want to be able to interact with VSCode in an intuitive manner. When I touch the minimap, I expect the document to scroll immediately on touch-down, not on touch-up. Mouse-up makes sense for a mouse, but not for a touch. When I touch and drag the minimap, I expect the minimap to scroll with my finger. VS Code version: Code 1.22.1 (, 2018-04-06T02:26:57.615Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.487 --- <!-- score: 0.464 --- <!-- score: 0.449 --<!-- potentialduplicatescomment --
I haven't PR'd vscode before, if anyone who cares about this issue has tips on getting my PR ^^ merged and released I'm happy to put more work into it. I find it very frustrating not having touch-scrolling on the minimap, as I'm so used to it working in old-school Visual Studio!

private readonly _mouseDownListener: IDisposable; private readonly _sliderMouseMoveMonitor: GlobalMouseMoveMonitor<IStandardMouseMoveEventData>; private readonly _sliderMouseDownListener: IDisposable; <ins> private readonly _sliderTouchStartListener: IDisposable; private readonly _sliderTouchMoveListener: IDisposable; private readonly _sliderTouchEndListener: IDisposable; </ins> private _options: MinimapOptions; private _lastRenderData: RenderData | null; private _selections: Selection[] = []; private _selectionColor: Color | undefined; private _renderDecorations: boolean = false; <ins> private _gestureInProgress: boolean = false; </ins> private _buffers: MinimapBuffers | null; constructor(context: ViewContext) {


Question:
Issue Type: <bFeature Request</bWhen using a touch screen, I want to be able to interact with VSCode in an intuitive manner. When I touch the minimap, I expect the document to scroll immediately on touch-down, not on touch-up. Mouse-up makes sense for a mouse, but not for a touch. When I touch and drag the minimap, I expect the minimap to scroll with my finger. VS Code version: Code 1.22.1 (, 2018-04-06T02:26:57.615Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.487 --- <!-- score: 0.464 --- <!-- score: 0.449 --<!-- potentialduplicatescomment --
I haven't PR'd vscode before, if anyone who cares about this issue has tips on getting my PR ^^ merged and released I'm happy to put more work into it. I find it very frustrating not having touch-scrolling on the minimap, as I'm so used to it working in old-school Visual Studio!

); } }); <ins> Gesture.addTarget(this._domNode.domNode); this._sliderTouchStartListener = dom.addDisposableListener(this._domNode.domNode, EventType.Start, (e: GestureEvent) => { e.preventDefault(); e.stopPropagation(); if (this._lastRenderData) { this._slider.toggleClassName('active', true); this._gestureInProgress = true; this.scrollDueToTouchEvent(e); } }); this._sliderTouchMoveListener = dom.addStandardDisposableListener(this._domNode.domNode, EventType.Change, (e: GestureEvent) => { e.preventDefault(); e.stopPropagation(); if (this._lastRenderData && this._gestureInProgress) { this.scrollDueToTouchEvent(e); } }); this._sliderTouchEndListener = dom.addStandardDisposableListener(this._domNode.domNode, EventType.End, (e: GestureEvent) => { e.preventDefault(); e.stopPropagation(); this._gestureInProgress = false; this._slider.toggleClassName('active', false); }); } private scrollDueToTouchEvent(touch: GestureEvent) { const startY = this._domNode.domNode.getBoundingClientRect().top; const scrollTop = this._lastRenderData!.renderedLayout.getDesiredScrollTopFromTouchLocation(touch.pageY - startY); this._context.viewLayout.setScrollPositionNow({ scrollTop: scrollTop }); </ins> } public dispose(): void { this._mouseDownListener.dispose(); this._sliderMouseMoveMonitor.dispose(); this._sliderMouseDownListener.dispose(); <ins> this._sliderTouchStartListener.dispose(); this._sliderTouchMoveListener.dispose(); this._sliderTouchEndListener.dispose(); </ins> super.dispose(); }


Question:
<!-- Do you have a question? Please ask it on --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.23.0-insiders x64 commit OS Version: Windows 8.1 x64 After update to latest version window is empty (only main menu bar is visible). Renderer process consumes 16-20% CPU but nothing is changing. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
can you run "" from the command line and see if any output is printed?
The output is here:
adding for the (maybe unrelated) spdylog stacktrace that shows up. can you share a screenshot how VSCode looks after it started like this?
!
does it make any difference if you run with "" from the command line?
That literal looks weird. It looks like the user has a problem in one of his variables, possibly . Whats the value of your HOMEPATH variable?
Visually nothing is changed. In console also nothing. is not presented. Username is , but profile folder named as .
does it make any difference if you run "" from the command line?
Yes. Window is opening like normal new profile. My profile is broken. Nice. ! UPD: Erased my old profile. Nothing. Same situation. So, trouble is Cyrillic symbols in path to profile folder.
to verify that can you use the argument with a folder that has the Cyrillic characters and see if you get the same results?
Yes. Launch with Cyrillic characters in path give same result.
it would be easier for me to reproduce if you could post the exact Cyrillic letters that you are using in here as text so that I can copy it.
Here it is: .
I can reproduce and the reason the workbench is not coming up is due to spdylog crashing very early. To reproduce run ""
Just to confirm, you could reproduce by using cyrilic in a path provided to ?
I can. Command: Result:
yes
I can confirm I have an identical problem. My username contains the character 'ø', which now makes the insiders build fail to start. Changing the to a path which does not contain that character fixes the issue. However, the Windows context menu action does not work, as the argument is only provided on the shortcut. The stable release (1.22.2) works as expected. EDIT: I fixed the context menu issue manually in the registry, so everything is back to normal for now :)
I pushed a workaround for now to not crash so badly when we fail to instantiate the spdylog writer. Turns out we already had code in place to protect from failing loads thanks to Alex, but the output channel was failing very early on. fyi maybe you want to quickly check my changes via The real fix probably needs to go into spdylog, pushing to May since this was already happening in stable.
This will break Output channels when not writing into file. When user switches between output channels, they will become empty as there is no way to retrieve content now
I was falling back to old way of writing into channels if fails. I removed this fallback this milestone . You can get that back. But I would really want to remove this fallback because for further enhancements to output channel which depends on spdlog.
this is not a real fix, I would expect some regressions. Previously VS Code would not start at all without my workaround. Do you think the current behaviour with my fix is worse than before? I think its clear that we will work on a fix for May.
IMO The better workaround would be to bring back my fallback . I was doing the same as you except that I fallback to old way of writing into Output channels. This will not have any regressions as it was there in last milestone. When we fix it in May, we can remove the workaround.
Sorry, I am confused. May I know if this issue is due to Loading of spdlog library OR spdlog fails to create a file
I see the workaround is if spldlog fails to create logger/file. So I think it is better to use my fallback.
Pushed the previous workaround I was using. As said, this will not break output channels if there is an issue creating spdlog logger.
I don't see issues running dev with a user-data-dir containing a non-ascii character (eg ) any more. I do not understand if this is because of your workaround or if the new spdlog version actually fixed the issue. Moving it to you in order to check if the issue is fixed already, since I don't understand how to repro.
I too do not see any issues after removing the workaround I before for the crash. Hence removed the workaround. To verify: Open VS Code using an user directory that has non-ascii character (eg ø) Verify that VS Code starts normally and the output channels are properly written Verify that there is no crash
Reopening this as the crash from spdlog is not fixed.
I still see following error in the console with our log files Edit: This is seen in the console even with the workaround. Workaround just mitigates it by falling back to old output channels. Logs will not work though.
Updated node-spdlog library to support in file names. Thanks to for hinting it. With this crash no longer occurs with non ascii or special characters (tested with all reported characters). Added a smoke test to launch VS Code with special characters in user data dir.

"native-watchdog": "0.3.0", "node-pty": "0.7.7", "semver": "^5.5.0", <del> "spdlog": "0.7.1", </del> <ins> "spdlog": "0.7.2", </ins> "sudo-prompt": "8.2.0", "v8-inspect-profiler": "^0.0.8", "vscode-chokidar": "1.6.4",