When clicking the 10 left-most pixels of the editor, the cursor was
moved to the beginning of the line. When clicking the 10 right-most
characters of the editor, the cursor was moved to the end of the line.
This is not correct in RTL. Clicking the left pixels should move the
cursor to the left. Clicking the right pixels should move the cursor to
the right.
The test was failing on Windows because the regex only matched Unix-style
forward slashes (/). Added platform-specific regex patterns to handle both
Windows backslashes (\) and Unix forward slashes (/).
Fixes the failing Windows tests in PR #281536.
chat: fix content getting cut off/sticky scroll stopping
We never (apparently) correctly fired a content height change after the model got attached to the code blocks. We did did this is the CodeCompareBlockPart, just not the standard code block.
Also add an event on 'toolbar.onDidChangeMenuItems' -- don't this this ever caused issued but saw that when investigating.
Closes#276807
* Initial plan
* Fix terminal voice support to auto-accept text like editor
- Terminal voice now immediately sends text when recognized
- Matches editor dictation behavior where text is accepted after recognition
- Clears ghost text and input after each segment for continuous dictation
- No longer requires pressing Escape to accept transcribed text
Co-authored-by: meganrogge <29464607+meganrogge@users.noreply.github.com>
* Update decoration position after sending text segment
- Ensures microphone icon is correctly positioned after each recognized segment
- Decoration position is based on input length, so needs update after clearing input
Co-authored-by: meganrogge <29464607+meganrogge@users.noreply.github.com>
* switch order
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: meganrogge <29464607+meganrogge@users.noreply.github.com>
Co-authored-by: meganrogge <merogge@microsoft.com>
This PR actually fixes an issue experienced when monaco-editor (the npm package) is used in a website loaded using Firefox on Linux.
By using quotes, the `'monospace'` family causes Firefox to load "Noto Arabic" on my system. Should be noted I have a _clean_ Fedora 43 installation, with the default Gnome 49 installed fonts. `monospace` without the quotes resolves to Noto Sans Mono, as expected.
I see absolutely no difference for default font rendering inside Chromium-based web views. Testing with monaco-editor in Google Chrome and VSCode inside Electron.
Most Gnome-based Linux distros moved away from the Droid font-family, and are currently using the Noto font-family, but I'll leave that up to you guys. `monospace` (without quotes) properly resolves to Noto.
I've tracked where this `'monospace'` value came from, and it seems to have been added in https://github.com/microsoft/vscode/commit/b99f4148788ae790c6621ed62550e78be29408d7
as part of not using Courier New on Linux. Seems like an oversight from my end.
Sandeep Somavarapu
Connor Peet
Lee Murray
Justin Chen
Simon Siefke
Dmitry Guketlev
João Moreno
Remco Haszing
Alexandru Dima
Benjamin Pasero
Rob Lourens
Copilot
Dmitriy Vasyura
NriotHrreion
odinsam
Raymond Zhao
Avi Vahl
Megan Rogge
Bhavya U