sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: neovim
Issue: Jumping into a file inside of a JAR ZIPfile doesn't run Autocommands
Labels: bug

### Problem

I have a deps.edn Clojure project and I want to jump into standard-library function sources using `vim.lsp.buf.definition`.

The sources are located in file
```
zipfile:///home/user/.m2/repository/org/clojure/clojure/1.11.1/clojure-1.11.1.jar::clojure/core.clj
```
So the editor has to open that zipfile, then open the file inside of it and seek to a line.

What happens is that first I see this message:

![image](https://github.com/neovim/neovim/assets/1641263/c8d01bdf-7753-4a5c-9e86-30413ca20943)

Then I press Enter and see the source file at line 0:
![image](https://github.com/neovim/neovim/assets/1641263/53579831-f134-4c6c-b1be-a93585f0c6bc)

Then if I go back to the previous source file and activate `vim.lsp.buf.definition` again.
But now the location in the file is correct (I tried to jump into function `fnil`):
![image](https://github.com/neovim/neovim/assets/1641263/78d16108-ddcc-40b0-8e47-81a2b0087700)


And then I can type `:filetype detect` and suddenly the syntax highlighting works properly (both: LSP and non-LSP one):
![image](https://github.com/neovim/neovim/assets/1641263/afaf8c0c-5944-420a-ae01-075854488dbc)


### Steps to reproduce

If possible I wouldn't want to produce the config. 

### Expected behavior

Expected: 
The highlighting and the line number should be picked up even if the buffer was not encountered from before.

### Neovim version (nvim -v)

v0.9.2

### Vim (not Nvim) behaves the same?

I didn't test

### Operating system/version

6.1.55-1-MANJARO

### Terminal name/version

kitty 0.29.2

### $TERM environment variable

xterm-kitty

### Installation

system package manager
Repository: vscode
Issue: Provide a nice way for webviews to hook into editor features
Labels: feature-request,webview

The GitHub Pull Request Extension makes use of webviews to show a PR description:

<img width="1266" alt="image" src="https://github.com/microsoft/vscode/assets/38270282/6aef64a8-bac0-4b8a-bca9-e2f278312b30">

As you can see, there's an input box for a comment. That comment box would greatly benefit from being able to show editor completions. Link detection and hovers would also be nice to have. 

Currently, the best way to get editor completions would be to embed a monaco editor in the webview; however, this could provide a strange experience for the user since it will look like a VS Code editor, but behave differently. It's also a lot of work for an extension author. 

Ideally, there'd be a simple way to embed a VS Code editor within a webview. Then, all the user's shortcuts, completions, hovers, etc. would work exactly the same as they do in any VS Code editor.
Repository: terminal
Issue: Active screen buffer size is out of sync
Labels: Product-Conpty,Area-Server,Issue-Bug,Priority-2

### Windows Terminal version

current main branch

### Windows build number

10.0.19045.3448

### Other Software

_No response_

### Steps to reproduce

- Run WT with any profile
- Run the following c++20 code (creates additional screen buffer and make it active)
- Resize the current pane (e.g., split pane)
- Press any key to exit
- Check the current size report - it is not valid
- Run any TUI app just to be sure (e.g. wsl mc )

```cpp
#include <string>
#include <windows.h>

int main()
{
	auto len = DWORD{};
	auto rec = INPUT_RECORD{};
	auto inf = CONSOLE_SCREEN_BUFFER_INFO{};
	auto inp = ::GetStdHandle(STD_INPUT_HANDLE);
	auto out = ::GetStdHandle(STD_OUTPUT_HANDLE);
	auto alt = ::CreateConsoleScreenBuffer(GENERIC_READ | GENERIC_WRITE, 0, 0, CONSOLE_TEXTMODE_BUFFER, 0);
	::SetConsoleActiveScreenBuffer(alt);
	::GetConsoleScreenBufferInfo(alt, &inf);
	auto msg = "current size: " + std::to_string(inf.dwSize.X) + "x" + std::to_string(inf.dwSize.Y)
	         + "\nchange pane size and press any key\n";
	::WriteFile(alt, msg.data(), msg.size(), &len, 0);
	while (true)
	{
		::ReadConsoleInputW(inp, &rec, 1, &len);
		if (rec.EventType == KEY_EVENT && rec.Event.KeyEvent.bKeyDown) break;
		else if (rec.EventType == WINDOW_BUFFER_SIZE_EVENT)
		{
			::GetConsoleScreenBufferInfo(out /*not alt*/, &inf);
			msg = "current size: " + std::to_string(inf.dwSize.X) + "x" + std::to_string(inf.dwSize.Y) + "\n";
			::WriteFile(alt, msg.data(), msg.size(), &len, 0);
		}
	}
	::SetConsoleActiveScreenBuffer(out);
	::GetConsoleScreenBufferInfo(out, &inf);
	msg = "current size: " + std::to_string(inf.dwSize.X) + "x" + std::to_string(inf.dwSize.Y) + "\n";
	::WriteFile(out, msg.data(), msg.size(), &len, 0);
}
```

### Expected Behavior

After run
```
current size: 106x20
change pane size and press any key
current size: 51x20
```
After exit
```
PS D:\sources\test\size_test\x64\Debug> .\cpp20app.exe
current size: 51x20
PS D:\sources\test\size_test\x64\Debug>
```

### Actual Behavior

After run
```
current size: 106x22
change pane size and press any key
current size: 106x22
```
After exit (the size has not changed despite the pane split!)
```
PS D:\sources\test\size_test\x64\Debug> .\cpp20app.exe
current size: 106x21
PS D:\sources\test\size_test\x64\Debug>
```
wsl mc:
![image](https://github.com/microsoft/terminal/assets/11535558/fda13e1b-d209-4913-854f-181aef6035d6)
Repository: ant-design
Issue: Menu "theme" prop does not have effect inside of a dropdown
Labels: 🐛 Bug,Inactive

### Reproduction link

[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/menu-dark-inside-dropdown-c6rnrz)

### Steps to reproduce

1. Use menu inside a dropdown via 'menu' prop
2. Set 'theme=dark' inside of the menu prop

### What is expected?

The menu should be dark themed

### What is actually happening?

The menu styling is exactly as with the light theme

| Environment | Info |
| --- | --- |
| antd | 5.10.2 |
| React | 18 |
| System | NixOS |
| Browser | Chrome Version 116.0.5845.179 (Official Build) (64-bit) |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: vscode
Issue: "terminal.integrated.macOptionIsMeta" does not bypass dead-keys in "ABC - Extended" keyboard layout
Labels: bug,confirmation-pending,terminal-input

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 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. -->
- VS Code Version: 1.83.1
  Commit: f1b07bd25dfad64b0167beb15359ae573aecd2cc
  Date: 2023-10-10T23:57:32.750Z
  Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.83.1 Chrome/114.0.5735.289 Electron/25.8.4 Safari/537.36
- OS Version: macOS Sonoma 14.0 (23A344) 

Steps to Reproduce:

1. On macOS, switch to the "ABC - Extended" keyboard layout
2. In VSCode, turn on `terminal.integrated.macOptionIsMeta`
3. Open the integrated terminal
5. Type various key chords involving Meta, such as `Meta+p`/`Meta+n` for browsing through command history.
6. The outcome: the command line is intermittently littered with unapplied dead-keys, such as `,,˜,˜,,˜`. In particular, this makes some terminal applications such as vanilla Emacs unusable.

In contrast, if you switch to another QWERTY keyboard layout such as "Unicode Hex Input", this problem does not appear. Ideally, "ABC - Extended" should be supported just as well.
Repository: godot
Issue: Light shadow artifacts in low-resolution 2D game
Labels: discussion,topic:rendering,topic:2d

### Godot version

v4.1.2.stable.flathub [399c9dc39]

### System information

Godot v4.1.2.stable (399c9dc39) - Freedesktop SDK 23.08 (Flatpak runtime) - X11 - Vulkan (Mobile) - dedicated NVIDIA GeForce GTX 1660 SUPER (nvidia) - Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz (8 Threads)

### Issue description

I am working on a low-res (384 x 216) pixel game using the mobile renderer, and I have a problem with the light occluder producing weird artifacts. This effect increases with the distance to the light source.

Minimal reproducible example scene:

![Skärmbild från 2023-10-25 15-30-10](https://github.com/godotengine/godot/assets/970037/d5555ce2-e017-4d6d-bc4c-1ecb10489c50)

If we zoom in a bit on the lamp and the LightOccluder2D there are stripes of what looks like some kind of inverted anti-aliasing going on, the further we get from the light source.

![Skärmbild från 2023-10-25 15-32-33](https://github.com/godotengine/godot/assets/970037/fa72e59b-4e0e-4eaf-a6c5-b7b4334a454a)

![Skärmbild från 2023-10-25 15-34-54](https://github.com/godotengine/godot/assets/970037/72be5638-5b42-4705-9206-ee073d10c7ad)

The closest I get to removing this effect is when setting Cull Mode to CounterClockWise. That makes the artifacts go away on the top side but adds them to the bottom side instead.

![Skärmbild från 2023-10-25 15-36-20](https://github.com/godotengine/godot/assets/970037/8070136f-d234-4d19-ba2e-a8a80e384ed1)

Misc observations:
- Scaling the width of the point reduces the effect on the horizontal sides of the occluder but increases the effect on the vertical sides, and vice versa.   
- This all works fine if I switch to the gl_compatibility renderer.


### Steps to reproduce

1. Start the MRP
2. Select the 2D view
3. Zoom in on the top right right side of the occluder. Artifacts should be visible.
4. Run the "game". Artifacts should be visible.


### Minimal reproduction project

[occlusion_test.zip](https://github.com/godotengine/godot/files/13178220/occlusion_test.zip)
Repository: godot
Issue: `Camera3D.unproject_position` becomes too imprecise for `Vector2.is_equal_approx` for results close to zero
Labels: discussion,needs testing,topic:3d

### Godot version

v4.2.beta.custom_build [06d5189] (latest master)

### System information

Godot v4.2.beta (06d5189) - Windows 10.0.22621 - GLES3 (Compatibility) - NVIDIA GeForce RTX 3050 Laptop GPU (NVIDIA; 31.0.15.3598) - 11th Gen Intel(R) Core(TM) i5-11400H @ 2.70GHz (12 Threads)

### Issue description

When a Camera3D node's set to perspective mode, it is possible for `Camera3D.unproject_position` to return a result that should be zero when analyzed mathematically, yet fail to be considered approximately equal by `Vector2.is_equal_approx`. See below for the experiment setup.

### Steps to reproduce

1. Create a new 3D scene.
2. Add a SubViewport and set its screen size to (400, 200).
3. Add a Camera3D as the SubViewport's child, and set its FOV to 120.
4. Add a built-in script to the Camera3D node and paste the following:
```gdscript
extends Camera3D

var try_equal_approx = true

func test_print(actual : Vector2, expected : Vector2):
	var diff = (expected - actual).abs()
	print("Actual = " + str(actual) + ", Expected = " + str(expected) + ", Diff = " + str(diff))
	if try_equal_approx:
		assert(actual.is_equal_approx(expected))

var SQRT3 : float = 1.7320508
# Called when the node enters the scene tree for the first time.
func _ready():
	print("[TOP LEFT]")
	test_print(unproject_position(Vector3(-SQRT3, SQRT3 * 0.5, -0.5)), Vector2(0, 0))
	test_print(unproject_position(Vector3(-2 * SQRT3, SQRT3, -1.0)), Vector2(0, 0))
	print("[CENTER]")
	test_print(unproject_position(Vector3(0, 0, -0.5)), Vector2(200, 100))
	test_print(unproject_position(Vector3(0, 0, -100.0)), Vector2(200, 100))
	print("[BOTTOM RIGHT]")
	test_print(unproject_position(Vector3(SQRT3, -SQRT3 / 2, -0.5)), Vector2(400, 200))
	test_print(unproject_position(Vector3(2 * SQRT3, -SQRT3, -1.0)), Vector2(400, 200))
```
5. Play the scene. You should see the `assert` statement stopping the application when the script executes the [TOP LEFT] section of the code. The return value of `unproject_position` here should show up as `Vector2(0.000024, 0.000017)`.

This isn't necessarily a bug: Considering there's epsilon-scaling, this case here is an extremely minor edge case - unprojecting from any point that's not this close to the camera frustum's left and up edges would work perfectly fine. The [BOTTOM RIGHT] section's absolute difference is actually greater but thanks to epsilon scaling it still falls within the range to be considered approximately equal.

It is however an edge case being covered by my WIP unit test for Camera3D, so I need to know if this is considered acceptable/expected behavior.

### Minimal reproduction project

N/A
Repository: vscode
Issue: Maximize Workbench Editor
Labels: feature-request,workbench-editors,layout

We want to allow users to not only maximize an editor group, but also the editor itself across the workbench.
I suggest to add the following command which can be added to the double click action of editor tabs:

`Toggle Maximize Editor` (Naming still open)

Double clicking the first time:
- Stores current state: visibility of Side Panels & Auxiliary Bar, ...
- Maximizes Editor Group
- Hides Side Panels & Auxiliary Bar

Double clicking the second time:
- Unmaximize Editor Group
- If the visibility of at least one panel/bar has been shown in the meantime:
  - Do not restore saved state
 - If all panels are still hidden
   - Restore the visibility of the panels that were initially visible
Repository: TypeScript
Issue: Class parameter incorrectly treated as bivariant
Labels: Bug,Help Wanted

### 🔎 Search Terms

class parameter generic bivariant constructor typeof extends

### 🕗 Version & Regression Information

- This is the behavior in every version I tried



### ⏯ Playground Link

https://www.typescriptlang.org/play?ts=5.3.0-dev.20231026#code/C4TwDgpgBAggRgZ2AJwIYGNirgGwgYQHsA7JZAV00OQB4BLUrY9aAXigG8BfAPinexkMwKMQgB3KAAoAsACgAkADoVqZAHMEALlEQAbhGQBtALryAlPz4MkqZhHnzQkKAElGdlgHkAZjXQkZJTA1Hys8goBjBRUyFAQAB7AEMQAJgiwiCjC2HhE0cHU9MQ+hlA2TCx8APzlHvZQOmIGyI5y6DioCBkAYoSEnBGpEB1q0HBqOijkDnJcbaPdUAAKyIQhNGBrIfFJKemZQpi5BIHTsfyH2ce4pwWxfBxDI53I0BWeEDrutva+m9tCDx5PM5PIAPTgqBeADWTnA0Bgl1W60IRgARB97OizHJIVACQA9aptfGw+EuABCyMBNGcEEIPigfSBGKxLBxEKhRJJYLxUPJcnpUHwlyRiWSaQy1Nq02gOh8qBwCFm+J5pKhABUABZ0DIIbWEcg4VJQODQRXK2bCgBaNNRu0lBxRG3pjOZ-RqUDljSglpVXIJUGJQA

### 💻 Code

```ts
type AbstractableConstructor<instance = {}> = abstract new (
	...args: never[]
) => instance

type InstanceOf<constructor> =
	constructor extends AbstractableConstructor<infer instance> ? instance : never

class Foo {
	declare bar: true
}

class Proto<proto extends AbstractableConstructor = AbstractableConstructor> {
	declare instance: InstanceOf<proto>
}

// Ok
type A = Proto["instance"]
//   ^? {}

// Ok
type B = Proto<typeof Foo>["instance"]
//   ^? Foo

// Ok
type C = A extends B ? true : false
//   ^? false

// This should be false
type Z = Proto extends Proto<typeof Foo> ? true : false
//   ^? true
```


### 🙁 Actual behavior

`proto` is treated as bivariant with no structural comparison, resulting in `Z` evaluating to `true`.

### 🙂 Expected behavior

`proto` should be treated as covariant as only its return type is used, or compared structurally, resulting in `Z` evaluating to `false`.

### Additional information about the issue

_No response_
Repository: ant-design
Issue: Antd Menu Item doesnt accept ref
Labels: 💡 Feature Request,Inactive,unconfirmed

### Reproduction link

[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/top-navigation-antd-5-10-2-forked-ptx5kw?file=/demo.tsx)

### Steps to reproduce

Open the link and you will notice that the ref in menu 1 is throwing an error

### What is expected?

Should be able to pass ref for menu items

### What is actually happening?

Menu items doesnt accept ref

| Environment | Info |
| --- | --- |
| antd | 5.10.2 |
| React | 18.2.0 |
| System | Windows 11 |
| Browser | Google Chrome |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: rust
Issue: Tracking Issue for NEON FCMA intrinsics
Labels: O-Arm,T-libs-api,A-SIMD,C-tracking-issue,O-AArch64

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(stdarch_neon_fcma)]`

This is a tracking issue for NEON intrinsics under the `fcma` feature.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// core::arch::{arm,aarch64}

fn vcmla*(..);
fn vcmlaq*(..);
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #...
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: rust
Issue: Tracking Issue for NEON I8MM intrinsics
Labels: O-Arm,T-libs-api,A-SIMD,C-tracking-issue,O-AArch64

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(stdarch_neon_i8mm)]`

This is a tracking issue for NEON intrinsics under the `i8mm` feature.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// core::arch::{arm,aarch64}

fn vsudot*(..);
fn vusdot*(..);
fn vmmlaq*(..);
fn vusmmlaq*(..)
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #...
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html