jiebi/CodeConvo huggingface dataset:
In VS Code action items inside inputs are vertically aligned to top, in the Chat features they are centered in the middle. This happens when putting in a lot of text or pressing Shift+Enter. Panel: <img width="425" alt="image" src=""Inline: <img width="608" alt="image" src=""Quick: <img width="621" alt="image" src=""For Inline and Quick the action items to the right of the input box should also stick to the top.
Seems like we have a mix of top-aligned and overflow w/ scroll (see below). But I agree that we should be consistent as much as possible. But it does feel like a chat send button should generally but aligned to the bottom, no? We may even consider rendering the toolbar on its own row once we're into multiple lines. That would ensure the text isn't forced to fill a tiny space now that we have 2+ icons. Here's how Teams does it as an example: ! ! ! !
Would be awesome if the text could wrap around it, especially in the narrow search widget case, I've always wanted that but I think it would be a pain to implement.
Don't have a strong opinion about top or bottom, I think each can be justified on a case-by-case basis. but middle looks weird. :) For example, inline Chat may want to do top alignment as the icons would align with those outside the input field (poppet and close) Bottom would help with the wrapping.
When you open a recent project from the welcome screen, the last one remains opened in a tab. VSCode Version: 1.9.1 OS Version: macOS Sierra 10.12.3 Steps to Reproduce: a new VSCode window. a recent project from the welcome screen. project is opened and the welcome screen remains opened.
The current behavior was chosen in the hope that this would help new users by staying in the same context.
I agree that the welcome screen should be closed after taking an action from it. Especially in my case, where I prefer to use the setting, having to close the otherwise empty welcome window after opening from the 'Recents' list or via FileOpen feels like a bug.
You can just not show it at all. Or do you need any of the actions on it? (I'm trying to preserve the new user experience here which relies much more on guidance.)
It's ok showing the welcome screen, but it should be closed after opening a project from there.
With we change the Welcome editor to open in preview mode, this way it will close when the next editor opens. (If preview mode is not disabled in settings.)
This could be an additional value for the setting.
Hey, I could look into this. Got any tips on where I should start ?
Great: Add an additional enum literal here: Check for that literal and the 'open folder' condition here:
Hey , I've ran into some questions which you might be able to help me with: should I name the enum literal? I can't seem to come up with the right name would I check for the 'open folder' condition?
You could use . Check for no folder being open: . You can get at the context service by adding it to the constructor of the calling class, similar to:
Hey everything seems to be working now, just one last question which is confusing me: isn't the objective of this issue to NOT show the Welcome Page when opening a new project? So why is your enum suggestion welcomePageInEmptyWorkbench? What is happening right now after my additions is: upon opening a new project, no Welcome Page is shown. Is this right?
Show it only in the empty workbench. :)
Hey Now I'm getting upon opening a new window (empty workbench). Any ideas? I did the comparison as you said for no folder being open.
Is the ?
You can debug it either in VS Code or in the Developer Tools (Help Toggle Developer Tools in the window running from source).
Upon opening a new window, it isn't undefined (verified by a console log) but then it turns undefined (verified by the same console log). Edit: and immediately after Edit2: Found it! Seems like isWelcomePageEnabled() is called twice, once in the class constructor and the other one in the onReady method. I'll make the PR in a bit
! is not very discoverable. If it would be a submenu of the context menu, it would be much easier to tweak this setting.
...
I'm for making these types of settings more discoverable, however, I do not want to add these types of settings to the contextmenu. We mainly use the context menu to change the visibility of elements/features but we don't really use it to configure them/change appearance. Also, the context menu is already pretty full and I don't want to overload it.
I'm open to other ideas to make them more discoverable. Maybe a "configure" entry in the overflow menu of the toolbar?
Yeah I like the idea of an action in the "..." menu to configure all things editor related by narrowing down a settings search in the settings editor.
verification steps: Right click on the tab bar (not on a tab) At the bottom of the context menu there is an action "Configure Tabs...", press it Settings editor should open with tabs related settings
Testing From the API: What is the behavior supposed to be in the following cases: The pattern contains . The pattern contains and is false. The pattern is a regex and is false. The pattern contains whitespace and is true.
If regex is not on, it just looks for literally. I believe that this actually acts as if is true (if I'm interpreting code correctly). Any time that you have regex enabled and explicitly match a newline, it will be multi-line. I should probably document this. Any characters in the regex will also match the other case. ie: should also match all characters, not just lowercase letters. It will look for the whitespace, and will look for line boundaries on either side of the search string.
I can also add extra examples for corner cases so that this is more clear.
VSCode Version: Version 1.12.2 (1.12.2) OS Version: OS X E Capitan 10.11.6 Steps to Reproduce: integrated terminal <kbdctrl+`</kbdterminal: key combination <kbdctrl + j</kbdExpected Cursor moves back a word, this the behavior that iTerm and exhibit Actual Newline is sent, essentially the same as using <kbdreturn</kbd
doesn't seem to be in the path in for me?
It's in zsh which is in mac by default? So just type in
Works for me, if you remove the backtick from your command: Not
Oh that was a typo, I am using Hmm that works in the integrated terminal for you? Using zsh without a .zshrc: Expected (in iTerm): ! <kbdctrl + j</kbdcauses the cursor to jump back to the beginning of each word. Actual (in integrated terminal): ! Should have probably left this gif linger a bit longer but at the end it says: As if you had just pressed <kbdreturn</kbd.
FYI, I just tried rebinding <kbdctrl + j</kbdwith bash's native binding commands: Again this works in iTerm and but not in the integrated terminal. Expected Terminal screen should be cleared Actual Newline is sent, essentially the same as using return
Hm I doesn't seem to be working anymore, maybe I didn't test it right or something. I looked into it a little bit, it seems to work fine in the demo which is the underlying library used. so that's why it's happening. The question is why does it work in the demo but not VS Code. It definitely gets registered within zsh inside VS Code: <img width="430" alt="screen shot 2017-05-17 at 9 50 05 pm" src=""Stepping through the code nothing stuck out as misbehaving through when run inside VS Code; they appear to both be sending 'n'. Nothing in the seems to be wrong either.
Aw I was really of hoping it was something wrong with my local configuration. Also I got the same behavior when trying it on windows + cygwin with a fresh install of vscode, <kbdctrl + j</kbdnot being distinguished from newline.
Hey just wondering if there was any progress on this?
If this is low priority could one of the contributors point me a area/file that might be causing the issue? Thanks!
I can't look into it any further right now, I'm pretty stumped on where to go from here though. It's a pretty technical problem so it might not be the easiest thing to jump in to. If you want to you can start by cloning and trying to reproduce it using the demo. If you can reproduce it you can check what's sent to the backend by loading up devtools and debugging If works fine, it would be a matter of doing a similar exercise but figuring out why VS Code behaves different by debugging similar code.
(Copied from ) This was happening because ctrl+j translates to (see ) and since we normalized to all input to the pty, this was getting lost and converted to a new line. The fix here is to never "sanitize" data that has already been processed by (ie. key strokes and paste) as knows how to handle them. We only need to process text that we send directly to the terminal such as a script the user is running or text being pasted into vim, etc.
Hmm just updated to 1.14.1 and this still isn't working for me... !
This will only be in 1.15.
Oh okay thanks.
Issue Type: <bBug</bI have noticed that every time I try to open an image on vs code, I get the error stated on the title no matter what image file type VS Code version: Code 1.39.2 (, 2019-10-15T15:33:00.827Z) OS version: Darwin x64 18.7.0 <details<summarySystem Info</summary </details<details<summaryExtensions (21)</summaryExtensionVersion ------ html-snippets0.2.1 vscode-browser-preview0.5.9 rails0.13.1 vscode-gemfile0.0.2 solargraph0.21.1 vscode-eslint1.9.1 code-runner0.9.14 vscode-rufo0.0.1 vscode-gutter-preview0.23.0 atom-keybindings3.0.6 vsliveshare1.0.1056 debugger-for-chrome4.12.0 erb0.1.1 LiveServer5.6.1 ActiveFileInStatusBar1.0.3 slim0.1.2 html-preview-vscode0.2.5 highlight-matching-tag0.9.5 simple-ruby-erb0.2.1 quokka-vscode1.0.257 erb-vscode-snippets0.0.4 </details<!-- generated by issue reporter --
Please share a screenshot of the error. Also, does this reproduce in the with all ?
I'm having the same issue on a feshly installed copy.
Found out the issue to be with the image file name. If the file name has % symbol in it, vscode does not show the image. <img width="708" alt="Screen Shot 2019-10-30 at 12 17 40 PM" src="https://user-"If, i remove the % symbol in my file name, vscode displays the image properly. Tested this both in current stable mac release and the insider build. Do let us know if you observe the same pattern.
Even i am facing the same problem and my image file name does not contain % character , resolve my issue.
My file doesn't contain the % character either and it's not working.
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --When folded, folding ranges are displayed in the editor as a single line with darkened background. Hovever (as of ), on the minimap, the background of this line is not darkened. This makes it harder to navigate using the minimap. !
Either this isn't working or steps are non trivial
Ok, see this working unless I have render characters enabled
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --in my project, there are several extensions in our recommended , but vscode sneaks in recommendations that are not recommended by workspace, but by vscode itself: ! in this screenshot, the WSL extension is recommended by vscode, and the YAML extension is recommended by the workspace. you have to hover over the star icon to figure out which recommendations are actually relevant for this workspace. this makes it confusing for new developers who just want to install the extensions required for the workspace, and not random additional ones that vscode suggests. as a workaround, i can add these vscode recommendations to the array, but that's annoying because i would have to update that list whenever new recommendations show up.
VS Code shows workspace recommendations on the top followed by other recommendations. If you are not seeing in this order, can you please share the steps to reproduce?
i don't know if i could, since it seems to be some sort of recommendation algorithm that shows different results based on all sorts of unknown factors. (i feel like it'd be comparable to coming up with steps to reproduce an ad i saw in a social media feed.) but i'll give it a go
it seems that the docker and wsl extensions (ones made by microsoft) always appear above workspace recommendations. steps to reproduce: to the workspace recommended extensions a to trigger the non-workspace recommendation to the extensions tab and look at the recommended extensions list ! ! even if these were showing up in the correct order (workspace recommendations first), it's still extremely confusing and misleading to the user to use the exact same icon for two completely different types of recommendations. i get that microsoft wants to get as many people using their extensions as possible, but this seems comparable to an advertisement that is not clearly labelled as one.
I found out that there is a bug in showing them in the right order. Will fix that. I am not sure how much it makes sense to show different icons for different kinds of recommendations. It might be super noisy or confusing. I believe at present we have a right balance to show an icon for recommendation and explanation on hover.
<!-- Do you have a question? Please ask it on --- VSCode Version: 1.10.1 OS Version: macOS Is it possible for VSCode to support the following kinds of auto complete, please see screenshots Word completion: <img width="357" alt="screen shot 2017-03-07 at 10 23 19 am" src=""Member function completion: <img width="359" alt="screen shot 2017-03-07 at 10 20 22 am" src=""All auto-completions come with fuzzy matching. Steps to Reproduce:
Agree, actually fuzzy matching only works with camel Case, but in sublime and atom you can get completion by typing any middle letter of the target word. I still miss this feature in vscode
I like, tho will be some work and maybe some adjustment for folks that are used to our current filtering and ranking
This got implemented with <img width="280" alt="screen shot 2017-03-20 at 17 38 54" src=""
And this is valid for all languages then?
Yes, we have changed the default matcher to be more fuzzy.
VSCode: 11.0-insider I appear to be getting stuck in a recursive loop, and according to DevTools (I clicked Pause in the Debugger) it is happening in . I tested this with . I was able to reproduce this with a simple HTML file: After typing the opening and IntelliSense appears, trying to type an additional character will freeze the whole VSCode.
Thanks for the heads-up. You are right, there are situations in which it keeps recursing forever. I have implemented a different approach today and just pushed the last changes. Will be in tomorrows insiders.
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: head OS Version: n/a This is a bug/inconsistency in the VSC codebase, which is currently obscured because of the specific way the code is written. This wouldn't really matter, but when using a build step that generates files for dependencies, the gets evaluated down to and compilation fails. And overall, it'd be nice for the types to align in a sensible way. Steps to Reproduce: , replace with Expected: compiles fine Actual: there are a number of errors like Property 'getFirstLineText' does not exist on type 'never'. The intersection 'this &amp; IResolvedTextFileEditorModel' was reduced to 'never' because property 'capabilities' has conflicting types in some (2339)TextFileEditorModelIWorkingCopyIResolvedTextFileEditorModelthis.isResolved() is known to be true) says capabilities should be a readonly 2. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Since this seems to concern only you with your specific setup, wanna do a PR to fix this?
I would be more than happy to, but I'm not sure what approach you'd find (in)appropriate. could type in as a number instead of an enum (since checks against it are anyways done via bitwise-and) could change in to actually be 2 instead of 0 (though it seems like you also use 0 for this field in other places like , and somehow TSC doesn't care...) could add a enum value of 0 to , since it seems like that's how you use it. I'm leaning towards approach 3. What are your thoughts?
Yeah I think we can give 3. a try in a PR.
When a test fails, it might sometimes look like this: ! By pressing in both editors, I can get it to look like this, which is more helpful for long strings: ! It might be better to enable word wrapping by default for string comparisons.
Code pointer:
Is this issue up for grabs? I would love to implement this
Yep
Could you assign me to this issue?
No, only people in the Microsoft org can be assigned issues. You can open a PR without being assigned though
I agree this is a better default. Thanks Maybe a setting to make this customizable? Not sure how many people would care.
How do I update commonEditorOptions dynamically? Replace every usage of commonEditorOptions with ?
VSCode Version: Code - Insiders 1.8.0-insider (, 2016-12-09T12:05:39.439Z) OS Version: Linux x64 4.8.0-28-generic Extensions: Steps to Reproduce: an untitled file and add content: the cursor after the shift, press down and then end, the selection should be shift, press home, the selection should be but it is because the select went to the start of the wrong line.
This used to work till yesterday... something broke. I'm pressing <kbdend</kbdafter going 3 lines above, and the cursor goes to the end of the selectionStart line. !
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- Version: 1.60.2 Commit: Date: 2021-09-22T11:59:27.195Z (1 wk ago) Electron: 13.1.8 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 20.6.0 Steps to Reproduce: a large file with a long line to be scrollable over the file (x and y axis). right. on minimap. Actual: The minimap slider does not have full width. Expected: The minimap slider is always full width.
Could you please also add a screenshot, I am not sure what you are referring to.
Please check. https://user-
can I work on this issue. if yes code pointers to investigate.
PR welcome.
thanks
what would be the expected behaviour of the minimap for a horizontal scroll?
I think we could just remove that the slider moves horizontally and let it stay put.
I think it should be:
These lines of code should work if you support scrolling horizontally for the minimap slider. At this time, we can only scroll the minimap slider vertically.
Okay, I can do that but I think it would be much better if we allow horizontal scroll in minimap. what do you think about that?
Using regex expressions am unable to find empty lines. Tried both the end of line sequence. Copying the same text in sublime simple n finds all the blank lines.
That has been an issue for me for quite a while. Never really checked again if it's already working because I started to automatically open notepad++ again whenever I needed to replace newlines.
This problem could manifest if the lines are being split before searching as opposed to doing a full text search. Interesting side note; seems to work in find in files (Ctrl+Shift+F), just not in the find dialog (Ctrl+F).
Couldn't even find empty lines with ^$ (in case they were being split without EOL).
Looked at the code, it does indeed look at each line individually. I'm created a new issue for multi-line matching
Steps to Reproduce: The cursor should go back to the exact spot where it was before the jump. Instead, it goes one sport further back...
Can you provide more details like VS Code version, OS type and version etc. Also, sample code of what you are trying to do in your extension and a screencast/gif/video ?
Likely
There is no extension involved. This is vanilla behaviour. Using version 1.4 on Ubuntu 16.04. Related to , but not the same. This is likely to be very easy to fix (jumpToDefinition event should push the current cursor position to the history).
I agree we should record the current cursor position on certain actions like "Go to definition".
Pushed a change to improve this situation for the following cases: goto definition will store the current cursor location as history entry so that when jumping back you end up in the same line number opening another editor will now also store the current cursor in the history so that going back puts you to the exact same line number too
Version 1.74.0, when I open the developer tools, it becomes a floating window, which is very unfriendly for extension developers, please add at least one option to use the old layout. !
Was caused by an upstream electron bug with WCO Believe there are plans to restore the docking feature in the near future now that the electron issue is resolved.
I found that if you toggle OFF the setting, Developer Tools docking functionality is restored AND you also still get the WCO experience (perhaps that's a separate bug?). Suggest docking at the bottom instead of to the right if there's any visual conflict due to the aforementioned electron bug.
It work, thanks!.
The setting will be removed at one point, keeping the issue open to provide and dock options when WCO is enabled.
I manged to get it to dock again with 's workaround but I noticed in the dev tool now it shows the HTML for the VS code app instead of the file I have open in the preview !
Related Stack Overflow question:
This makes working on Windows really awful for me, I think the upstream bug is fixed.
To give some context, with WCO chromium has a bug in orienting devtools window when docked to the position where the Window controls are, basically they overlap making it harder to use the close, minimize or maximize button. Chromium always pop out the devtools window in PWA for this scenario and Electron inherited this by default. The fix in does not address the aligning behavior but rather provides a workaround that calling would be respected even in the WCO scenario rather than forcing to always detach. Now, on our end to incorporate this fix we need to change all our callsite with a mode otherwise we will default to detach as seen in this logic Say we chose as default and user later reposition it to right or left then this new state will be persisted to json file under the user data directory, in non WCO cases this saved preference will be applied next time when calling or without a mode value from the application side, that is how user's preferred position is applied. But in the WCO case, this does not take effect so we need a logic on VSCode side to read the preference value and adjust the start mode with it. I didn't want to make this change yet in core hence this issue remains open, I will tackle it in debt week.