sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Edit Context: Screen Reader Users Feedback
Labels: accessibility,editor-edit-context

Pinging @jooyoungseo, @rperez030 and @meganrogge 

Recently we have been working on adopting the EditContext API (https://developer.mozilla.org/en-US/docs/Web/API/EditContext_API) within VS Code. The EditContext is a new DOM property that can be set on DOM elements which decouples text input from the textual mutations of the DOM element. Essentially when the user focuses a DOM element on which an EditContext is set and types, the EditContext fires 'textupdate' events, and it is up to the user to mutate the DOM element with the changes from this event. 

There are several reasons why we have adopted this API:
- This API has allowed us to greatly simplify the code which handles text input events.
- This API has allowed us to close numerous IME related bugs
- This API can allow us to emit customized typing information from the input events 

We have an experimental setting which enables the EditContext API with ID `editor.experimentalEditContextEnabled`. We would like to ask @jooyoungseo and @rperez030 if when you have time you could try the setting with a screen reader and let us know if you see any issues on typing in the various inputs of VS Code (could be the editor, the panel chat input, the SCM view, the quick input, ie any input that accepts text insertions). We would like to gather feedback from screen reader users before enabling this setting by default.
Repository: vscode
Issue: Allow use of custom menu with native titlebar (on Linux and Windows)
Labels: feature-request,system-context-menu

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

_This is my attempt to find a suitable workaround to #224515, given that we will probably not see a proper resolution to that bug for a long time if ever. **I have implemented a proof-of-concept and intend to submit a PR for this shortly.**_

Add a "Force Custom Menu Style" option - boolean, default false.

![image](https://github.com/user-attachments/assets/3156e7d7-b65d-4733-a906-2a7711337115)

If false, behavior is unchanged. If true, and "Title Bar Style" is "native", and we're running on Linux or Windows (notably: not Mac*, not web), then we display the OS native title bar, but we display the custom menu bar below it, taking care not to repeat the window title. Of course, it affects context menus as well as the main menu bar. The result: a pleasant user experience while using the native title bar.

![force-custom-menu-contextmenu](https://github.com/user-attachments/assets/9ef42631-2ae2-41e3-a2ef-5150d98e19e8)
_Debian 12, MATE_

Compare with the screenshots from [my comment here](https://github.com/microsoft/vscode/issues/224515#issuecomment-2282198197) - unfortunately I can't show the same menu, since I understand it's not possible (not allowed) to use the Marketplace from an unofficial build of VS Code, but hopefully it should still illustrate the point.

By default, you'll also get the "Command Center" and "Layout Controls" showing up next to the menu, since this menu bar is really just the custom title bar, forced to be displayed. The above screenshot, showing the classic "separate title bar and menu bar, with no additional clutter" layout, was accomplished by just using the existing settings to hide these items.

_(*I have assumed that this isn't applicable on Mac, based on basic knowledge of the Mac interface and various comments in the VS Code source, but I don't use Mac myself, so I have no way to test this. If someone else finds a reason why it'd be useful to have this feature on Mac as well, then feel free to enable it there.)_
Repository: node
Issue: Any idea when Single executable application feature will reach stable status?
Labels: question,experimental,single-executable

### Affected URL(s)

https://nodejs.org/api/single-executable-applications.html

### Description of the problem

I notice that Single executable applications are still described as under "Active Development". Is there any sense when this might progress to at least a release candidate?
Repository: ollama
Issue: OpenAI o1-like Chain-of-thought (CoT) inference workflow
Labels: feature request

Well, I am surprised that the "main" and "great" new feature of the new OpenAI o1 model is actually doing say "more sophisticated" inference workflow while employing something like Chain-of-thought process. Basically I understand it that even a "dumb" model can perform much better when it "thinks more" during inference. The great news they are telling us is that by "thinking more" you can get smarter, which is probably very true also for humans.

The o1 model is probably trained to come up with its own CoT workflow for any given prompt, but I think it could be interesting to try to even hardcode some kind of workflow which any standard LLM model may try to follow during inference. Basically let the model analyze the prompt from various perspectives first and then try to judge on what type of "inference workflow" it should employ.

The hardcoded workflow could look like this:
1. Prompt is submitted to the model.
2. The model asks itself couple of hard-coded questions about the prompt, maybe: 
- is that some light conversation (needing soft-skills like empathy etc)
- does it look like a science problem (math, physics etc.)
- can I break the prompt down to subtasks - if yes, the workflow will feed each subtask into the model separately, then combine the result etc.
- is the problem easy/hard
- do I have all information I need (do I need to ask the user for further input/clarification)
3. The workflow would run, maybe in multiple iterations on various its levels, maybe trying to fit some "quality checks" for the answer
4. The output is presented to the user (the "hidden" thinking may be optionally viewed by user)

Anyone having the same feelings as I do about the CoT thing? Looks like even a hard-coded process may give some interesting results.
Repository: next.js
Issue: Headers function causing an empty page to be returned when using Optional Catch-all Segments
Labels: bug,Runtime,Partial Prerendering (PPR)

### Link to the code that reproduces this issue

https://github.com/hugohammarstrom/next-ppr-headers-repro

### To Reproduce

1. Deploy repo to vercel
2. Go to root path
3. Go to any other path and see that the page works as expected

### Current vs. Expected behavior

When using the headers() function in a page using [Optional Catch-all Segments](https://nextjs.org/docs/pages/building-your-application/routing/dynamic-routes#optional-catch-all-segments) the root returns a completely empty page. In some cases the page flickers with the correct page before returning to an empty page again. This seems to only affect the root page.

This worked previously but as of a few days ago this error started happening.

### Provide environment information

```bash
Node.js v20.17.0

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.5.0: Wed May  1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000
  Available memory (MB): 65536
  Available CPU cores: 10
Binaries:
  Node: 20.17.0
  npm: 10.8.3
  Yarn: 3.6.1
  pnpm: N/A
Relevant Packages:
  next: 15.0.0-canary.159
  eslint-config-next: N/A
  react: 19.0.0-rc-5dcb0097-20240918
  react-dom: 19.0.0-rc-5dcb0097-20240918
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Partial Prerendering (PPR), Runtime

### Which stage(s) are affected? (Select all that apply)

Vercel (Deployed)

### Additional context

I've tried downgrading the canary version to a version that I know it worked on but I'm still seeing this error. My guess is that this is something in the vercel runtime.

I've seen a couple different error messages(in different canary versions) in the logs.
`Error: invariant: cache entry required but not generated`
`Error: Invariant: postponed state should not be provided when fallback params are provided`
`Couldn't find all resumable slots by key/index during replaying. The tree doesn't match so React will fallback to client rendering.`
Repository: vscode
Issue: Web: `detectFullscreen` false positive on a display without dock and title area
Labels: bug,help wanted,good first issue,workbench-window,confirmed,web

If you run insiders.vscode.dev on a PWA in Linux with multiple monitors and WCO enabled, the window controls are on top of the icons on the right.

![image](https://github.com/user-attachments/assets/82dd3065-ae27-4f3e-95d6-0acd443a7a34)

The issue is that there is a bad premise in dom.ts.

```ts
	if (targetWindow.innerHeight === targetWindow.screen.height) {
		// if the height of the window matches the screen height, we can
		// safely assume that the browser is fullscreen because no browser
		// chrome is taking height away (e.g. like toolbars).
		return { mode: DetectedFullscreenMode.BROWSER, guess: false };
	}
```

The problem with this is that if you are on a Linux machine with a secondary screen (so no task bar), with the App running as a PWA and with window controls overlay enabled, then the regular - non full screen but maximised window will be the same height as the screen height.

As such it will falsely report being fullscreen and the window controls will render on top of the icons, since the css includes:

```css
.monaco-workbench.fullscreen .part.titlebar .window-controls-container {
    display: none;
    background-color: transparent;
}
```

There is a secondary issue that window.screen seems to be faulty on Chrome/Linux too which means sometimes it gets the wrong screen, and that results in the PWA actually rendering correctly which makes this tricky to debug.
Repository: material-ui
Issue: Load order of @emotion/styled and @emotion/react is important since 6.1.0
Labels: bug 🐛,external dependency,package: material-ui

### Steps to reproduce

~~Link to live example: (required)~~

Steps:
1. `npm create vite@4.4.5`
2. `npm install` in the freshly created project
3. `npm install @mui/material@6.1.0 @emotion/react@11.13.3 @emotion/styled@11.13.0`
4. Edit `vite.config.ts` to look like below
6. Run `npm run build`
7. Run `npx serve -s dist`
8. Open `localhost:3000` and check the console output to see the error

`vite.config.ts`

```ts
import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
  build: {
    minify: false, // to be readable
    rollupOptions: {
      output: {
        manualChunks: {
          emotionStyled: ["@emotion/styled"],
          emotionReact: ["@emotion/react"],
        }
      },
    },
  },
})

```

### Current behavior

When using manual chunks in the rollup config, to reduce the individual chunk size, the order in which the chunks are build matters since MUI v6.1.0.

We add manual chunking to improve load times. Usually we simply do so by placing every dependency in it's own chunk and that worked very good till MUI v6.1.0 (reverting back to MUI v6.0.2 works fine).
The issue is broken down with the chunking settings below. When changing the order of both entries, everything works just fine.

Broken:
```ts
        manualChunks: {
          emotionStyled: ["@emotion/styled"],
          emotionReact: ["@emotion/react"],
        }
```

Works:
```ts
        manualChunks: {
          emotionReact: ["@emotion/react"],
          emotionStyled: ["@emotion/styled"],
        }
```

In Firefox the error message is:
> Uncaught ReferenceError: can't access lexical declaration 'React' before initialization

![image](https://github.com/user-attachments/assets/f8a6db61-6366-4db7-ac01-18baf567c5cd)

`React` is imported from the `react` chunk.

### Expected behavior

Manual chunking should not effect the startup of MUI.

### Context

_No response_

### Your environment

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  System:
    OS: macOS 14.6.1
  Binaries:
    Node: 20.17.0 - ~/.n/bin/node
    npm: 10.8.2 - ~/.n/bin/npm
    pnpm: 8.11.0 - /opt/homebrew/bin/pnpm
  Browsers:
    Chrome: 128.0.6613.138
    Edge: Not Found
    Safari: 17.6
  npmPackages:
    @emotion/react: ^11.13.3 => 11.13.3 
    @emotion/styled: ^11.13.0 => 11.13.0 
    @mui/core-downloads-tracker:  6.1.0 
    @mui/icons-material: ^6.1.0 => 6.1.0 
    @mui/material: ^6.1.0 => 6.1.0 
    @mui/private-theming:  6.1.0 
    @mui/styled-engine:  6.1.0 
    @mui/system:  6.1.0 
    @mui/types:  7.2.16 
    @mui/utils:  6.1.0 
    @types/react: ^18.2.15 => 18.3.7 
    react: ^18.2.0 => 18.3.1 
    react-dom: ^18.2.0 => 18.3.1 
    typescript: ^5.0.2 => 5.6.2 
```
</details>


**Search keywords**: rollup chunks vite React emotion
Repository: PowerToys
Issue: Ctrl WIN V combination for Plain Paste interfere with Win 11 sound outup/source switcher
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.8

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

Advanced Paste

### Steps to reproduce

Trying to open sound output config window with Ctrl WIN V does nothing if Power Toys enable Plain Text pasting with same combination

### ✔️ Expected Behavior

Different keyboard combination like Alt WIN V

### ❌ Actual Behavior

Conflicting features 

### Other Software

_No response_
Repository: PowerToys
Issue: feat: Activate region shortcut for FancyZones
Labels: Needs-Triage

### Description of the new feature / enhancement

Provide an assignable keyboard shortcut to each zone, which will activate the topmost window in the assigned zone when pressed.

### Scenario when this would be used?

This would provide an easy way to switch applications on large workspaces.  When you are working across multiple monitors, or even one very large one, you might have 5-10 applications to work with.  This becomes less efficient as you have more applications that you are working with.  Alternatively, you can use the mouse, but it would be nice to be able to do all this without taking your hand off the keyboard.

### Supporting information

_No response_
Repository: ollama
Issue: Moshi /moshiko /moshika speech text foundation LLM by KyutAI
Labels: model request

Hi,

KyutAI finally released their moshi model. It's a "speech text foundational model", kinda like the promised gpt-4o but it outputs text at the same time as speech.


Here's their link: https://github.com/kyutai-labs/moshi

Here's the hf link: https://huggingface.co/collections/kyutai/moshi-v01-release-66eaeaf3302bef6bd9ad7acd

It exists in several version and some are already quantized
Repository: rust
Issue: cargo doc --examples doesn't pick up default features or report failure
Labels: T-rustdoc,A-rustdoc-scrape-examples

I think this is all working correctly, but I'd like to record the issue in case it trips up anyone else.

If you have a project with default features, and an example requires one of those default features to be enabled, then `cargo doc --examples` will give an overly general warning, fail to generate example documentation, and possibly fail to complete other generation tasks, but the invocation will report success.

E.g., suppose the correct invocation to run an example is `cargo run --example hello-world --features=defaultfeature`. If you omit the `--features` flag you'd see an error like this:

```bash
error: target `hello-world` in package `mypackage` requires the features: `defaultfeature`
Consider enabling them by passing, e.g., `--features="defaultfeature"`
```

This tells you exactly what to do, and all is good. But if you try a related `cargo doc` command `cargo doc --examples`, you get this error:

```bash
warning: target filter `examples` specified, but no targets matched; this is a no-op
```

This also makes sense; it's a batch command that doesn't have a `cargo run` equivalent, so it reasonably suppresses the error messages that caused the build of one example bin in the batch to fail.

But if a developer isn't really paying attention, a document-the-world command like `cargo doc --no-deps --examples --workspace` will appear to succeed, but generate only some of the expected documentation (in my case, it built my subcrate documentation but not the top-level crate, which was just enough for my build script to succeed without my noticing that it had actually failed to complete).

Apologies for this long-winded report; there might be a more concise description of undesirable behavior (perhaps "cargo doc --examples --workspace fails to complete if required features aren't specified"?). I have solved the issue for my own purposes and wanted to spew the whole story here in case it provides more search terms for someone else to find it.
Repository: vscode
Issue: Settings : `editor.cursorSurroundingLines` misleading default
Labels: bug,editor-core


Type: <b>Bug</b>

Settings : `editor.cursorSurroundingLines` displays the default as being 0 while it is in fact 5. any input between 0 (included) and 4 (included) seems to be ignored anyway and processed as being "5"

VS Code version: Code 1.93.0 (4849ca9bdf9666755eb463db297b69e5385090e3, 2024-09-04T13:02:38.431Z)
OS version: Linux x64 6.10.6-200.fc40.x86_64
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|AMD Ryzen 7 5800H with Radeon Graphics (16 x 4441)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_graphite: disabled_off<br>video_decode: enabled<br>video_encode: disabled_software<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: disabled_off<br>webnn: disabled_off|
|Load (avg)|2, 2, 1|
|Memory (System)|13.49GB (6.67GB free)|
|Process Argv|--crash-reporter-id 65116bd1-1c78-4041-a566-c113afd1dba7|
|Screen Reader|no|
|VM|0%|
|DESKTOP_SESSION|gnome|
|XDG_CURRENT_DESKTOP|GNOME|
|XDG_SESSION_DESKTOP|gnome|
|XDG_SESSION_TYPE|wayland|
</details><details><summary>Extensions (27)</summary>

Extension|Author (truncated)|Version
---|---|---
vscode-neovim|asv|1.18.12
github-markdown-preview|bie|0.3.0
markdown-checkbox|bie|0.4.0
markdown-emoji|bie|0.3.0
markdown-footnotes|bie|0.1.1
markdown-mermaid|bie|1.25.0
markdown-preview-github-styles|bie|2.1.0
markdown-yaml-preamble|bie|0.1.0
gitlens|eam|2024.9.1905
codespaces|Git|1.17.3
copilot|Git|1.231.0
copilot-chat|Git|0.20.2
remotehub|Git|0.64.0
vscode-github-actions|git|0.26.5
vscode-pull-request-github|Git|0.97.2024091904
debugpy|ms-|2024.10.0
python|ms-|2024.14.1
vscode-pylance|ms-|2024.9.1
remote-containers|ms-|0.386.0
remote-ssh|ms-|0.115.2024091615
remote-ssh-edit|ms-|0.86.0
vscode-remote-extensionpack|ms-|0.25.0
azure-repos|ms-|0.40.0
remote-explorer|ms-|0.5.2024081309
remote-repositories|ms-|0.42.0
remote-server|ms-|1.6.2024081909
pdf|tom|1.2.2

(1 theme extensions excluded)

</details><details>
<summary>A/B Experiments</summary>

```
vsliv368:30146709
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492cf:30256860
vscod805:30301674
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
962ge761:30959799
pythongtdpath:30769146
welcomedialogc:30910334
pythonnoceb:30805159
asynctok:30898717
pythonmypyd1:30879173
2e7ec940:31000449
pythontbext0:30879054
accentitlementst:30995554
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
dsvsc021:30996838
da93g388:31013173
a69g1124:31058053
dvdeprecation:31068756
dwnewjupytercf:31046870
impr_priority:31102340
nativerepl2:31139839
refactort:31108082
pythonrstrctxt:31112756
flighttreat:31134774
wkspc-onlycs-t:31132770
wkspc-ranged-t:31125599
fje88620:31121564

```

</details>

<!-- generated by issue reporter -->
Repository: rust
Issue: `#[diagnostic::on_unimplemented]` fails to trigger when certain impls are present
Labels: A-diagnostics,T-compiler,A-suggestion-diagnostics,D-diagnostic-infra

Consider the following code:

```rust
#[diagnostic::on_unimplemented(note = "A custom Foo message!")]
trait Foo {}

#[diagnostic::on_unimplemented(note = "A custom Bar message!")]
trait Bar {}

impl<'a, T> Bar for &'a T {}

fn takes_foo<T: Foo>(_t: T) {}
fn takes_bar<T: Bar>(_t: T) {}

fn main() {
    takes_foo(());
    takes_bar(());
}
```

I would expect the `#[diagnostic::on_unimplemented]` note to be present in the error output for both calls in `main`. However, what I get instead is:

```text
error[E0277]: the trait bound `(): Foo` is not satisfied
  --> src/main.rs:13:15
   |
13 |     takes_foo(());
   |     --------- ^^ the trait `Foo` is not implemented for `()`
   |     |
   |     required by a bound introduced by this call
   |
   = note: A custom Foo message!
help: this trait has no implementations, consider adding one
  --> src/main.rs:2:1
   |
2  | trait Foo {}
   | ^^^^^^^^^
note: required by a bound in `takes_foo`
  --> src/main.rs:9:17
   |
9  | fn takes_foo<T: Foo>(_t: T) {}
   |                 ^^^ required by this bound in `takes_foo`

error[E0277]: the trait bound `(): Bar` is not satisfied
  --> src/main.rs:14:15
   |
14 |     takes_bar(());
   |     --------- ^^ the trait `Bar` is not implemented for `()`
   |     |
   |     required by a bound introduced by this call
   |
note: required by a bound in `takes_bar`
  --> src/main.rs:10:17
   |
10 | fn takes_bar<T: Bar>(_t: T) {}
   |                 ^^^ required by this bound in `takes_bar`
help: consider borrowing here
   |
14 |     takes_bar(&());
   |               +
```

While the custom note is emitted for `Foo`, it's not for `Bar`. The culprit seems to be the impl of `Bar` for `&T`, which leads rustc down the wrong path and has it suggest only that borrowing is an option. However, that's [not always the right suggestion](https://github.com/google/zerocopy/issues/1296).

cc https://github.com/google/zerocopy/issues/1296, https://github.com/google/zerocopy/pull/1682
Repository: godot
Issue: C# Exported Array<Node> is null
Labels: needs testing,topic:dotnet

### Tested versions

4.3 stable

### System information

Godot v4.3.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1070 Ti (NVIDIA; 31.0.15.3623) - AMD Ryzen 7 2700X Eight-Core Processor (16 Threads)

### Issue description

I have a larger project, that uses C# for all the scripts. Everything works fine when I start the game from the editor. When I export it, I get several errors, that I was able to trace back to that an exported variable is null, instead of being set to the value that is stored in the scene.
This applies to exported variables, that are made of a Godot.Collections.Array<Node>, where <Node> can be Node or any other Script that inherits from Node.
If I replace the Array<Node> with Node[], the export is working fine.

### Steps to reproduce

Unfortunately, I was not able to create a MRP, as the issue did not persist in a minimal project. So unfortunately, I do not know how to reproduce, but I can share the code with one or two people who want to investigate the issue.

### Minimal reproduction project (MRP)

I was not able to create a MRP and don't want to publically share my project, but I can share the code with one or two persons who want to investigate the issue.