jiebi/CodeConvo huggingface dataset:
Code change:
For: scoped keybinding service scoped progress service For the title area and the editor itself. This requires a common parent (or the editor-container itself) to be reparented instead of the editor moving around. Enables more scenarios around menu and command contributions for contexts.
I merged this to master: title container, editor container, progress bar widget and the instantiation service are now within a new container that gets reparented when a) you move an editor around or b) you close editor group LEFT when LEFT | RIGHT exist and RIGHT becomes LEFT as well as for when you have 3 editors open and you close the left or center group. Is there a way to verify this works for the scenario you disabled late before we finished June milestone? I remember you reverted a commit and I am not sure if this can be now reverted back again. !
I can verify
LGTM - will push the revert revert commit
Verified via

Related discussion:
text: private rochade(from: Position, to: Position): void { <del> // Move editor to new position </del> <ins> // Move container to new position const containerFrom = this.silos[from].child(); containerFrom.appendTo(this.silos[to]); const containerTo = this.silos[to].child(); containerTo.appendTo(this.silos[from]); // Inform editor </ins> const editor = this.visibleEditors[from]; <del> editor.getContainer().offDOM().build(this.silos[to].child()); </del> editor.changePosition(to); // Change data structures
Code change:
For: scoped keybinding service scoped progress service For the title area and the editor itself. This requires a common parent (or the editor-container itself) to be reparented instead of the editor moving around. Enables more scenarios around menu and command contributions for contexts.
I merged this to master: title container, editor container, progress bar widget and the instantiation service are now within a new container that gets reparented when a) you move an editor around or b) you close editor group LEFT when LEFT | RIGHT exist and RIGHT becomes LEFT as well as for when you have 3 editors open and you close the left or center group. Is there a way to verify this works for the scenario you disabled late before we finished June milestone? I remember you reverted a commit and I am not sure if this can be now reverted back again. !
I can verify
LGTM - will push the revert revert commit
Verified via

Related discussion:
text: // Distance 1: Swap Editors if (Math.abs(from - to) === 1) { <del> // Move editors to new position let editorPos1 = this.visibleEditors[from]; editorPos1.getContainer().offDOM().build(this.silos[to].child()); editorPos1.changePosition(to); </del> <ins> // Move containers to new position const containerFrom = this.silos[from].child(); containerFrom.appendTo(this.silos[to]); const containerTo = this.silos[to].child(); containerTo.appendTo(this.silos[from]); </ins> <del> let editorPos2 = this.visibleEditors[to]; editorPos2.getContainer().offDOM().build(this.silos[from].child()); editorPos2.changePosition(from); </del> <ins> // Inform Editors this.visibleEditors[from].changePosition(to); this.visibleEditors[to].changePosition(from); </ins> // Update last active position accordingly if (this.lastActivePosition === from) {
Code change:
For: scoped keybinding service scoped progress service For the title area and the editor itself. This requires a common parent (or the editor-container itself) to be reparented instead of the editor moving around. Enables more scenarios around menu and command contributions for contexts.
I merged this to master: title container, editor container, progress bar widget and the instantiation service are now within a new container that gets reparented when a) you move an editor around or b) you close editor group LEFT when LEFT | RIGHT exist and RIGHT becomes LEFT as well as for when you have 3 editors open and you close the left or center group. Is there a way to verify this works for the scenario you disabled late before we finished June milestone? I remember you reverted a commit and I am not sure if this can be now reverted back again. !
I can verify
LGTM - will push the revert revert commit
Verified via

Related discussion:
text: newRightPosition = Position.LEFT; } <del> // Move editors to new position let editorPos1 = this.visibleEditors[Position.LEFT]; editorPos1.getContainer().offDOM().build(this.silos[newLeftPosition].child()); editorPos1.changePosition(newLeftPosition); </del> <ins> // Move containers to new position const containerPos1 = this.silos[Position.LEFT].child(); containerPos1.appendTo(this.silos[newLeftPosition]); </ins> <del> let editorPos2 = this.visibleEditors[Position.CENTER]; editorPos2.getContainer().offDOM().build(this.silos[newCenterPosition].child()); editorPos2.changePosition(newCenterPosition); </del> <ins> const containerPos2 = this.silos[Position.CENTER].child(); containerPos2.appendTo(this.silos[newCenterPosition]); </ins> <del> const editorPos3 = this.visibleEditors[Position.RIGHT]; editorPos3.getContainer().offDOM().build(this.silos[newRightPosition].child()); editorPos3.changePosition(newRightPosition); </del> <ins> const containerPos3 = this.silos[Position.RIGHT].child(); containerPos3.appendTo(this.silos[newRightPosition]); // Inform Editors this.visibleEditors[Position.LEFT].changePosition(newLeftPosition); this.visibleEditors[Position.CENTER].changePosition(newCenterPosition); this.visibleEditors[Position.RIGHT].changePosition(newRightPosition); </ins> // Update last active position accordingly if (this.lastActivePosition === Position.LEFT) {
Code change:
For: scoped keybinding service scoped progress service For the title area and the editor itself. This requires a common parent (or the editor-container itself) to be reparented instead of the editor moving around. Enables more scenarios around menu and command contributions for contexts.
I merged this to master: title container, editor container, progress bar widget and the instantiation service are now within a new container that gets reparented when a) you move an editor around or b) you close editor group LEFT when LEFT | RIGHT exist and RIGHT becomes LEFT as well as for when you have 3 editors open and you close the left or center group. Is there a way to verify this works for the scenario you disabled late before we finished June milestone? I remember you reverted a commit and I am not sure if this can be now reverted back again. !
I can verify
LGTM - will push the revert revert commit
Verified via

Related discussion:
text: const titleAreaControl = instantiationService.createInstance<ITitleAreaControl>(useTabs ? TabsTitleControl : NoTabsTitleControl); titleAreaControl.create(container.getHTMLElement()); titleAreaControl.setContext(context); <del> titleAreaControl.refresh(); </del> <ins> titleAreaControl.refresh(true /* instant */); </ins> silo.child().setProperty(SideBySideEditorControl.TITLE_AREA_CONTROL_KEY, titleAreaControl); // associate with container }
Code change:
For: scoped keybinding service scoped progress service For the title area and the editor itself. This requires a common parent (or the editor-container itself) to be reparented instead of the editor moving around. Enables more scenarios around menu and command contributions for contexts.
I merged this to master: title container, editor container, progress bar widget and the instantiation service are now within a new container that gets reparented when a) you move an editor around or b) you close editor group LEFT when LEFT | RIGHT exist and RIGHT becomes LEFT as well as for when you have 3 editors open and you close the left or center group. Is there a way to verify this works for the scenario you disabled late before we finished June milestone? I remember you reverted a commit and I am not sure if this can be now reverted back again. !
I can verify
LGTM - will push the revert revert commit
Verified via

Related discussion:
text: // Move to valid position if any if (moveTo !== null) { this.editorGroupService.moveGroup(position, moveTo); <del> // To reduce flickering during this operation we trigger a refresh of all // title controls right after. POSITIONS.forEach(p => { this.getTitleAreaControl(p).refresh(true); }); </del> } // Otherwise layout to restore proper positioning
Code change:
VSCode Version: 1.3.0-Insider OS Version: MacOSX 10.11.5 Steps to Reproduce: document with long lines (longer then screen width to the right and move the cursor to accordingly -Cursor is invisible
Unless I'm misunderstanding the issue, this is expected behaviour. How would you expect the editor to behave? This happens on every editor. If you'd like your long line to wrap, you can control that by setting the configuration to .
No, this has nothing to do with wrapping long lines. My cursor is literally invisible: !
Interesting, but I still can't reproduce... Can you provide a screencast or similar?
Where is your focus? The cursor blinks/is rendered only when the editor is focused
I tried reproducing it with new files, but I'm unable to. This happens with a few xsl files at work. I'll try to see if I can get a 100% reproducible file. The focus is in the active editor. I'm only moving the cursor to the right. Screencast: ! EDIT: The cursor is only visible for as long as it doesn't surpass the last character that was visible in the initial view region of the editor
Thank you for the gif! I've never seen that before. Do you see any errors in the console () ? I've quickly tried with a file with these contents but could not reproduce: Other things that might be relevant: does this reproduce when running code without extensions (close it completely and launch with ), did you customize the font and/or picked a different theme?
I found a way to reliably reproduce this issue. The missing piece was, that it only happens when you have split the main editor. I can't reproduce it with just one editor visible. Launching with doesn't help. I did try with the default user settings and theme as well, but without success. I managed to nail it down to the following steps to reproduce this issue: vscode random file (doesn't matter) the editor with (this is important) random code/text with long lines in one of the 2 editor panels
Forgot to mention: unfortunately there are no errors in the devtools console.
I'm also seeing this issue. VS Code 1.3.0 commit Windows 10.0. Edit: Oops, didn't notice that a fix was already committed yesterday.
can you try my solution in ?
Yes, but disabling extensions doesn't help. This issue only occurs when you have more than a single editor view. See:
We decided to fix this by removing the property from the tabs container. The visual impact is that if you use a theme that introduces a custom background color, it will only be picked up for the active tab. E.g. for our themes "red" and "abyss": ! ! To verify: be on windows have 2 groups open at least have enough tabs open to cause scrolling activate a tab that is at the end of the tab list in group one find a long line and arrow right verify the cursor is not lost
can I ask you to verify this on Windows using this 1.3.1 stable build: Thanks!
I verified this.

Related discussion:
text: private _readOnly: boolean; private _cursorBlinking: editorCommon.TextEditorCursorBlinkingStyle; private _cursorStyle: editorCommon.TextEditorCursorStyle; <del> private _canUseTranslate3d: boolean; </del> private _isVisible: boolean;
Code change:
VSCode Version: 1.3.0-Insider OS Version: MacOSX 10.11.5 Steps to Reproduce: document with long lines (longer then screen width to the right and move the cursor to accordingly -Cursor is invisible
Unless I'm misunderstanding the issue, this is expected behaviour. How would you expect the editor to behave? This happens on every editor. If you'd like your long line to wrap, you can control that by setting the configuration to .
No, this has nothing to do with wrapping long lines. My cursor is literally invisible: !
Interesting, but I still can't reproduce... Can you provide a screencast or similar?
Where is your focus? The cursor blinks/is rendered only when the editor is focused
I tried reproducing it with new files, but I'm unable to. This happens with a few xsl files at work. I'll try to see if I can get a 100% reproducible file. The focus is in the active editor. I'm only moving the cursor to the right. Screencast: ! EDIT: The cursor is only visible for as long as it doesn't surpass the last character that was visible in the initial view region of the editor
Thank you for the gif! I've never seen that before. Do you see any errors in the console () ? I've quickly tried with a file with these contents but could not reproduce: Other things that might be relevant: does this reproduce when running code without extensions (close it completely and launch with ), did you customize the font and/or picked a different theme?
I found a way to reliably reproduce this issue. The missing piece was, that it only happens when you have split the main editor. I can't reproduce it with just one editor visible. Launching with doesn't help. I did try with the default user settings and theme as well, but without success. I managed to nail it down to the following steps to reproduce this issue: vscode random file (doesn't matter) the editor with (this is important) random code/text with long lines in one of the 2 editor panels
Forgot to mention: unfortunately there are no errors in the devtools console.
I'm also seeing this issue. VS Code 1.3.0 commit Windows 10.0. Edit: Oops, didn't notice that a fix was already committed yesterday.
can you try my solution in ?
Yes, but disabling extensions doesn't help. This issue only occurs when you have more than a single editor view. See:
We decided to fix this by removing the property from the tabs container. The visual impact is that if you use a theme that introduces a custom background color, it will only be picked up for the active tab. E.g. for our themes "red" and "abyss": ! ! To verify: be on windows have 2 groups open at least have enough tabs open to cause scrolling activate a tab that is at the end of the tab list in group one find a long line and arrow right verify the cursor is not lost
can I ask you to verify this on Windows using this 1.3.1 stable build: Thanks!
I verified this.

Related discussion:
text: for (var i = 0, len = this._secondaryCursors.length; i < len; i++) { this._secondaryCursors[i].render(ctx); } <del> if (this._canUseTranslate3d) { this._domNode.setTransform('translate3d(0px, 0px, 0px)'); } else { this._domNode.setTransform(''); } </del> } }
Code change:
There is now a better Intellisense plugins for Vscode PHP: and . In it's known issues it says "There may be duplicate suggestions for functions or variables. This is because VS Code has it's own (very limited) code-completion support for PHP, and there is currently no way to turn this off." This indeed is annoying, the vscode suggestions are too broad and are just noise compared to accurate entries by crane.
It should be possible to uninstall the VS Code php extension.
fyi
I think crane still uses vscode's syntax highlighter for PHP. So if one were to remove VSCode's internal PHP extension, would it also remove the syntax highlighter? P.S. I think simple options would suffice, e.g. "", so it could be turned off.
Yes - but we can also think about splitting our extension into one part that does highlighting and bracket config and another that does completions. That would allow for more freedom.
This is now annoying the testing of proper language server in here : Quote: P.S. I think the option would be a simplest thing to implement for now.
Related
Any update on this?
I have been holding back the PHP IntelliSense release with intelligent completion for over a month now because it is useless if VS Code just spams the completion list with countless functions that do not make sense in the context. When will we get the option to disable or uninstall the built-in PHP completion?
I agree it makes sense to provide a temporary option to disable this. Just submitted a PR here:
Also just checking - at this point in time, is there anything else about the built-in support that is interfering with the experience? (hover, signature help, etc.?)
thanks for looking into this. Signature help is being implemented right now, iirc there is no built-in hover. It would be great if all of them could be disabled (everything except syntax highlighting).
I pushed the PR and changes the setting name for the code completion to "". If disabled, hover and signature help are also disabled.
I don't think the setting achieves the desired result. Setting to I no longer get completion suggestions even from PHP Intellisense extension. If have to use to trigger the completion suggestions list.
I don't think this is related, this only removes the built-in completion provider.
So something else which controls the display of suggestions list from extensions like php intellisense is broken?
Part of the January build. Add to your settings to disable all completions from the built-in PHP extension.

Related discussion:
text: "type": "object", "order": 20, "properties": { <ins> "php.builtInCompletions.enable": { "type": "boolean", "default": true, "description": "%configuration.builtInCompletions.enable%" }, </ins> "php.validate.enable": { "type": "boolean", "default": true,
Code change:
There is now a better Intellisense plugins for Vscode PHP: and . In it's known issues it says "There may be duplicate suggestions for functions or variables. This is because VS Code has it's own (very limited) code-completion support for PHP, and there is currently no way to turn this off." This indeed is annoying, the vscode suggestions are too broad and are just noise compared to accurate entries by crane.
It should be possible to uninstall the VS Code php extension.
fyi
I think crane still uses vscode's syntax highlighter for PHP. So if one were to remove VSCode's internal PHP extension, would it also remove the syntax highlighter? P.S. I think simple options would suffice, e.g. "", so it could be turned off.
Yes - but we can also think about splitting our extension into one part that does highlighting and bracket config and another that does completions. That would allow for more freedom.
This is now annoying the testing of proper language server in here : Quote: P.S. I think the option would be a simplest thing to implement for now.
Related
Any update on this?
I have been holding back the PHP IntelliSense release with intelligent completion for over a month now because it is useless if VS Code just spams the completion list with countless functions that do not make sense in the context. When will we get the option to disable or uninstall the built-in PHP completion?
I agree it makes sense to provide a temporary option to disable this. Just submitted a PR here:
Also just checking - at this point in time, is there anything else about the built-in support that is interfering with the experience? (hover, signature help, etc.?)
thanks for looking into this. Signature help is being implemented right now, iirc there is no built-in hover. It would be great if all of them could be disabled (everything except syntax highlighting).
I pushed the PR and changes the setting name for the code completion to "". If disabled, hover and signature help are also disabled.
I don't think the setting achieves the desired result. Setting to I no longer get completion suggestions even from PHP Intellisense extension. If have to use to trigger the completion suggestions list.
I don't think this is related, this only removes the built-in completion provider.
So something else which controls the display of suggestions list from extensions like php intellisense is broken?
Part of the January build. Add to your settings to disable all completions from the built-in PHP extension.

Related discussion:
text: ﻿{ <del> "configuration.validate.enable": "Whether php validation is enabled or not.", "configuration.validate.executablePath": "Points to the php executable.", </del> <ins> "configuration.builtInCompletions.enable": "Enable/disable built-in PHP completions.", "configuration.validate.enable": "Enable/disable built-in PHP validation.", "configuration.validate.executablePath": "Points to the PHP executable.", </ins> "configuration.validate.run": "Whether the linter is run on save or on type.", "configuration.title": "PHP" }  No newline at end of file
Code change:
There is now a better Intellisense plugins for Vscode PHP: and . In it's known issues it says "There may be duplicate suggestions for functions or variables. This is because VS Code has it's own (very limited) code-completion support for PHP, and there is currently no way to turn this off." This indeed is annoying, the vscode suggestions are too broad and are just noise compared to accurate entries by crane.
It should be possible to uninstall the VS Code php extension.
fyi
I think crane still uses vscode's syntax highlighter for PHP. So if one were to remove VSCode's internal PHP extension, would it also remove the syntax highlighter? P.S. I think simple options would suffice, e.g. "", so it could be turned off.
Yes - but we can also think about splitting our extension into one part that does highlighting and bracket config and another that does completions. That would allow for more freedom.
This is now annoying the testing of proper language server in here : Quote: P.S. I think the option would be a simplest thing to implement for now.
Related
Any update on this?
I have been holding back the PHP IntelliSense release with intelligent completion for over a month now because it is useless if VS Code just spams the completion list with countless functions that do not make sense in the context. When will we get the option to disable or uninstall the built-in PHP completion?
I agree it makes sense to provide a temporary option to disable this. Just submitted a PR here:
Also just checking - at this point in time, is there anything else about the built-in support that is interfering with the experience? (hover, signature help, etc.?)
thanks for looking into this. Signature help is being implemented right now, iirc there is no built-in hover. It would be great if all of them could be disabled (everything except syntax highlighting).
I pushed the PR and changes the setting name for the code completion to "". If disabled, hover and signature help are also disabled.
I don't think the setting achieves the desired result. Setting to I no longer get completion suggestions even from PHP Intellisense extension. If have to use to trigger the completion suggestions list.
I don't think this is related, this only removes the built-in completion provider.
So something else which controls the display of suggestions list from extensions like php intellisense is broken?
Part of the January build. Add to your settings to disable all completions from the built-in PHP extension.

Related discussion:
text: 'use strict'; <del> import { CompletionItemProvider, CompletionItem, CompletionItemKind, CancellationToken, TextDocument, Position, Range, TextEdit } from 'vscode'; </del> <ins> import { CompletionItemProvider, CompletionItem, CompletionItemKind, CancellationToken, TextDocument, Position, Range, TextEdit, workspace } from 'vscode'; </ins> import phpGlobals = require('./phpGlobals'); export default class PHPCompletionItemProvider implements CompletionItemProvider {