sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: TextStyle : Background color not applied for `whitespace` after the Text. 
Labels: framework,engine,a: typography,c: rendering,has reproducible steps,P2,found in release: 3.3,found in release: 3.4,team-engine,triaged-engine

Im curious related to the question on [stackoverflow](https://stackoverflow.com/a/73924070/12838877). 
the `backgroundColor` property on `TextStyle` is not applied for the whitespace after the character except space. I dont know this is a bug or anything else.

as you can see the image below,
first: `Foo` only have background blue until the last `o` character,
second: `Foo` wrap with `Container` with background  amber, and the `space` is there.
third:  I try another invisible character with `\u200e`, the `backgroundColor` of `TextStyle` is applied.
last: Text only `whitespace`, there's no `backgroundColor` from `TextStyle` is applied. 

**Actual results:** <!-- what did you see? -->
![image](https://user-images.githubusercontent.com/33835308/193460482-21bfcdad-2b51-40ad-a081-f23ec429f15f.png)

## Steps to Reproduce
<details>
<summary>Example code</summary>

```dart
import 'package:flutter/material.dart';

const Color darkBlue = Color.fromARGB(255, 18, 32, 47);

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData.dark().copyWith(
        scaffoldBackgroundColor: darkBlue,
      ),
      debugShowCheckedModeBanner: false,
      home: Scaffold(
        body: Center(
          child: Column(mainAxisAlignment: MainAxisAlignment.center, children: [
            const Text(
              '   Foo    ',
              style: TextStyle(
                backgroundColor: Colors.blue,
                color: Colors.white,
              ),
            ),
            const Divider(),
            Container(
              color: Colors.amber,
              child: const Text(
                '   Foo    ',
                style: TextStyle(
                  backgroundColor: Colors.blue,
                  color: Colors.white,
                ),
              ),
            ),
            const Divider(),
            Container(
              color: Colors.amber,
              child: const Text(
                '       \u200e',
                style: TextStyle(
                  backgroundColor: Colors.blue,
                  color: Colors.white,
                ),
              ),
            ),
            const Divider(),
            Container(
              color: Colors.amber,
              child: const Text(
                '        ',
                style: TextStyle(
                  backgroundColor: Colors.blue,
                  color: Colors.white,
                ),
              ),
            ),
          ]),
        ),
      ),
    );
  }
}
```
</details>

Is there any workaround to apply background color of `TextStyle` for whitespace?
Thanks in advance.
Repository: three.js
Issue: Stringified DracoLoader body fails to load with vite ``build.keepNames: true``
Labels: Loaders

**Describe the bug**
When using vite.js configured with ``keepNames: true`` and glTF transform with draco compression and referencing a local ``draco_decoder.js`` at runtime we receive a ``Uncaught ReferenceError: m is not defined`` error.

Probably caused by [this section](https://github.com/mrdoob/three.js/blob/d081c5a3501d272d19375fab1b01fedf9df29b22/examples/jsm/loaders/DRACOLoader.js#L256-L266) in DRACOLoader

**To Reproduce**

Steps to reproduce are [described here](https://github.com/vitejs/vite/issues/10290) with a minimal repo that produces the error [here](https://github.com/marwie/vite-3-issue-x-is-not-defined). 


***Code***
Please see this repository [here](https://github.com/marwie/vite-3-issue-x-is-not-defined)

***Live example***
[live example](https://uploads.needle.tools/bugreports/vite_h_is_undefined/)

**Expected behavior**
Mesh gets decompressed

**Screenshots**
![image](https://user-images.githubusercontent.com/5083203/193461737-39972dd4-f45b-4d65-9b47-c577d6f23fd7.png)


**Platform:**

 - Device: any
 - OS: Win10
 - Browser: Chrome
 - Three.js version: r144
Repository: stable-diffusion-webui
Issue: If restore face is ON to generate txt2img I will have RuntimeError error
Labels: bug-report

**Describe the bug**

If restore face is ON to generate txt2img I will have RuntimeError error

I have finished downloaded everything and restart not help.

**To Reproduce**
Steps to reproduce the behavior:
1. Go to 'local stable diffusion web ui'
2. Input few correct prompt in txt2img with default argument
3. Tap Generate

**Expected behavior**
Images has been generated successfully 

**Actually Result**

I have error below

>   File "E:\stable-diffusion-webui\modules\ui.py", line 136, in f
>     res = list(func(*args, **kwargs))
>   File "E:\stable-diffusion-webui\webui.py", line 60, in f
>     res = func(*args, **kwargs)
>   File "E:\stable-diffusion-webui\modules\txt2img.py", line 41, in txt2img
>     processed = process_images(p)
>   File "E:\stable-diffusion-webui\modules\processing.py", line 367, in process_images
>     x_sample = modules.face_restoration.restore_faces(x_sample)
>   File "E:\stable-diffusion-webui\modules\face_restoration.py", line 19, in restore_faces
>     return face_restorer.restore(np_image)
>   File "E:\stable-diffusion-webui\modules\codeformer_model.py", line 76, in restore
>     self.create_models()
>   File "E:\stable-diffusion-webui\modules\codeformer_model.py", line 63, in create_models
>     face_helper = FaceRestoreHelper(1, face_size=512, crop_ratio=(1, 1), det_model='retinaface_resnet50', save_ext='png', use_parse=True, device=devices.device_codeformer)
>   File "E:\stable-diffusion-webui\repositories\CodeFormer\facelib\utils\face_restoration_helper.py", line 109, in __init__
>     self.face_parse = init_parsing_model(model_name='parsenet', device=self.device)
>   File "E:\stable-diffusion-webui\repositories\CodeFormer\facelib\parsing\__init__.py", line 19, in init_parsing_model
>     load_net = torch.load(model_path, map_location=lambda storage, loc: storage)
>   File "E:\stable-diffusion-webui\venv\lib\site-packages\torch\serialization.py", line 713, in load
>     return _legacy_load(opened_file, map_location, pickle_module, **pickle_load_args)
>   File "E:\stable-diffusion-webui\venv\lib\site-packages\torch\serialization.py", line 938, in _legacy_load
>     typed_storage._storage._set_from_file(
> RuntimeError: unexpected EOF, expected 1942397 more bytes. The file might be corrupted.

**Desktop (please complete the following information):**
 - OS: Windows 10
 - Browser chrome
 - Commit revision 1877a3767ed7502c25245c3de3449b22067db74c

**Additional context**
Add any other context about the problem here.
Repository: stable-diffusion-webui
Issue: Textual Inversion: Support resizing the smallest dimension to 512 and then randomly cropping a 512x512 piece from the images each training iteration
Labels: enhancement

Textual Inversion should support resizing the smallest dimension to 512 and then randomly cropping a 512x512 piece from the images each training iteration, rather than requiring 512x512 inputs only.




`torchvision.transforms.RandomCrop`


https://pytorch.org/vision/main/generated/torchvision.transforms.RandomCrop.html
Repository: excalidraw
Issue: rethinking the defaults
Labels: discussion

I think it's a good idea to review whether our default settings and values are the most useful.

I think we should especially review `text align` & `stroke width`.

# generic elements

| setting          | current default | ok/proposal |
|------------------|-----------------|:-----------:|
| stroke color     | black           |      ✅      |
| background color | transparent     |    ✅?       |
| fill             | hachure         |    ✅        |
| stroke width     | thin            |    bold?     |
| stroke style     | solid           |      ✅      |
| sloppiness       | artist          |      ✅      |
| edges            | sharp           |      ✅      |

# arrows

| setting          | current default | ok/proposal |
|------------------|-----------------|:-----------:|
| arrowhead end    | arrow           |✅ / triangle?|

# text

| setting          | current default | ok/proposal |
|------------------|-----------------|:-----------:|
| font size        | medium          |      ✅?    |
| text align       | center          | left?       |
Repository: neovim
Issue: Prepare for version 1.0
Labels: enhancement,project-management,code-standards

_This post lists the conditions for declaring Nvim `v1.0`. This is not a roadmap; the project roadmap is here: https://neovim.io/roadmap/_

# What is the plan for 1.0?

Stick to 0.x until the following conditions:

1. we have a full picture of what the RPC API and Lua APIs look like, this means conventions for:
    - function signatures (all RPC functions should have `opts` param and return a `Dict` to ensure ability to augment them without breaking back-compat)
    - naming conventions, `:help dev-api` `:help dev-lua`
    - https://github.com/neovim/neovim/issues/22287
    - https://github.com/neovim/neovim/issues/19624
    - https://github.com/neovim/neovim/issues/18585
    - https://github.com/neovim/neovim/issues/11311
    - https://github.com/neovim/neovim/issues/19918
2. Remove `vim.opt`/`vim.opt_local`/`vim.opt_global`
3. Redesign the "remote plugin" concept: https://github.com/neovim/neovim/issues/27949
4. Redesign `--remote` https://github.com/neovim/neovim/pull/18414
5. ✅ `:checkhealth` reports use of deprecated RPC and Lua APIs.
6. `:lua foo.<tab>` completion should not suggest deprecated things. 
    - https://github.com/neovim/neovim/issues/21660
    - https://github.com/neovim/neovim/issues/31376

# 1.0

Release 1.0 when we have fully-specified conventions for RPC API and Lua stdlib.

- During 0.x, and continuing through 1.x, we will aggressively deprecate interfaces. This means:
    1. they will be listed in `:help deprecated`, and
    2. where possible they will be flagged by `vim.deprecate()`.
- No APIs will be removed from the RPC API during 1.x.
- Deprecated RPC APIs **emit warnings** in some visible place when used.

# 2.0

- REMOVE all deprecated things in the 2.0 release. See also `:help api-contract`.
- Create `nvim_xx` functions that alias all `nvim_xx2` functions.
    - Deprecate the existing `nvim_xx2` names.
    - Example: `nvim_exec` will alias `nvim_exec2`. `nvim_exec2` will still exist but will be deprecated, and clients using `nvim_exec2` can easily migrate to `nvim_exec`.
Repository: PowerToys
Issue: Option to disable Alt menu acceleration
Labels: Idea-New PowerToy,Needs-Triage

### Description of the new feature / enhancement

On windows when you press and release the ALT key you can navigate the menu by pressing keyboard key. Their is sadly no settings to disable this feature in Windows.

It would be nice if PowerToys come to the rescue and provide a settings to do just that.

A lot of peoples already tried to desactivate this behaviour but mostly failed. In my knoweldge their is only this script for autokey that works https://github.com/TaranVH/2nd-keyboard/blob/master/Taran's_Windows_Mods/Alt_menu_acceleration_DISABLER.ahk 

### Scenario when this would be used?

Alt key is often used in softweare as a shortcut or mouse combination. The problem is sometimes you may perhaps start an action and then change your mind or simply don't do the shortcut correctly. In that case windows will fire up the menu acceleration witch is very distrubing.

### Supporting information

- https://www.youtube.com/watch?v=vRld4bVFrpU
- https://github.com/TaranVH/2nd-keyboard/blob/master/Taran's_Windows_Mods/Alt_menu_acceleration_DISABLER.ahk
Repository: rust
Issue: enable "go to exact" for rustdoc
Labels: T-rustdoc,C-feature-request

I would really like something like `go_to_exact` in rustdoc that we could add for the `::` redirects. I don't think we can just add `go_to_first` always because e.g. <https://docs.rs/tokio?search=tokio::span&go_to_first=true> goes to the `tokio::spawn` docs.

_Originally posted by @Nemo157 in https://github.com/rust-lang/docs.rs/issues/1830#issuecomment-1244136700_
     

Add a query `go_to_exact` which will only use `go_to_first` if the match is "exact", what "exact" means should be determined.
Repository: godot
Issue: Property Inspector input box edit/tab flows are unexpected
Labels: discussion,topic:editor,usability,topic:gui

### Godot version

4.0-beta2

### System information

Pop!OS

### Issue description

When we go into the property inspector, and go to something Like the `MarginContainer`s Theme overrides -> Constants

We're presented with 4 input boxes to enter data, and in this case they also have an checkbox for an unexplained reason. (no idea if they are relevant to this problem)

![general properties](https://user-images.githubusercontent.com/2107834/193466464-08905bf2-cc2f-40ad-9da4-f1100151c8cd.png)

When editing these, one would assume that they can `[tab]` to move between the cells, and this does indeed work if the cell was highlighted and not in edit mode. However when being in actual edit mode (where the text/number inside is highlighted and keyboard focus is given to the box) `[tab]` no longer correctly functions to move edit focus between cells.

Editing a single cell
![editing single cell](https://user-images.githubusercontent.com/2107834/193466604-d4bd8226-8542-439f-bf2e-3b2dcce72676.png)

After hitting tab
![image](https://user-images.githubusercontent.com/2107834/193466692-5fc041c1-f27e-4d91-bc7a-0a68ec38a118.png)

Observations:
* The input box appears to be taking focus of all keys
* You can only leave edit focus via `[enter]`, mouse click outside of the cell or `[esc]`
* You can only enter edit focus via `[enter]` and mouse click
* `[Tab]` movement behaves closer to expectation if you manually enter / leave focus around the data entry
* `[Tab]` movement can sometimes enter edit focus, but its finicky and requires that there isn't currently edit focus

Video showing all this fun

https://user-images.githubusercontent.com/2107834/193468929-520a8199-9541-47e0-9dfa-23878cf833b1.mp4




### Steps to reproduce

**Case 1: Tab out of edit**

Steps:
* Enter edit into an input field
* Perform valid data entry
* `[Tab]` away from input field

Expected results:
* Data is taken correctly
* Next dialog is properly selected
* Data input moves to next field if appropriate

Actual results:
* Data input is taken correctly 
* Both dialogs are highlighted
* Data input is still on original field

**Case 2: Entering edit**

Steps:
* obtain the field focus (blue highlight) (if you enter edit mode, close it by click, or `[enter]`
* type valid input characters / numerals

Expected results:
* field fully enters edit mode
* valid characters replace previous input

Actual results:
* nothing happens

**Case 3: Aborting edit**

Steps:
* enter edit into a field
* alter the input
* hit `[esc]` to close the edit focus

Expected result:
* Altered input is discarded reverting back to the original value

Actual result:
* Altered input is saved

### Minimal reproduction project

Should be reproducible by adding a `MarginContainer` to any empty project
Repository: rust
Issue: Don't give "no rules expected the token" errors for macros that failed to parse
Labels: A-diagnostics,A-macros,T-compiler,D-verbose

Given the following code: <https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=293168337d6a7ce2c74a82461e536bad>

```rust
macro_rules! foo {
    ($t:type) => {};
}

foo! { Option<bool> }
```

The current output is:

```
error: invalid fragment specifier `type`
 --> src/lib.rs:2:6
  |
2 |     ($t:type) => {};
  |      ^^^^^^^
  |
  = help: valid fragment specifiers are `ident`, `block`, `stmt`, `expr`, `pat`, `ty`, `lifetime`, `literal`, `path`, `meta`, `tt`, `item` and `vis`

error: no rules expected the token `<`
 --> src/lib.rs:5:14
  |
1 | macro_rules! foo {
  | ---------------- when calling this macro
...
5 | foo! { Option<bool> }
  |              ^ no rules expected this token in macro call

error: could not compile `playground` due to 2 previous errors
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
error: invalid fragment specifier `type`
 --> src/lib.rs:2:6
  |
2 |     ($t:type) => {};
  |      ^^^^^^^
  |
  = help: valid fragment specifiers are `ident`, `block`, `stmt`, `expr`, `pat`, `ty`, `lifetime`, `literal`, `path`, `meta`, `tt`, `item` and `vis`

error: could not compile `playground` due to previous error
```

Because telling me the call to the macro is invalid doesn't make much sense when that's impossible to fix without fixing the macro first.

---

Non-minimized mistake I made that inspired me to open this issue: <https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=aa7ce077f0b05e2af987f72539983e87>
```rust
macro_rules! impl_for_optional_bool {
    ($($t:type,)+) => {$(
        unsafe impl IsZero for $t {
            fn is_zero(&self) -> bool {
                // SAFETY: This is *not* a stable layout guarantee, but
                // inside `core` we're allowed to rely on the current rustc
                // behaviour that options of bools will be one byte with
                // no padding, so long as they're nested less than 254 deep.
                let raw: u8 = unsafe { core::mem::transmute(*self) };
                raw == 0
            }
        }
    )+};
}

impl_for_optional_bool! {
    Option<bool>,
    Option<Option<bool>>,
    Option<Option<Option<bool>>>,
    // Could go further, but not worth the trait lookup overhead
}
```
Repository: neovim
Issue: focus the previous window when closing a window
Labels: enhancement,documentation

### Feature already in Vim?

no

### Feature description

my usecase is:
```
$ nvim
:vs
:sp
<c-w>J
```
so now there are three split windows (winnr: 1, 2, 3), and 3 is the current window. when i close 3, the cursor will go to 1, but actually 3's previous window (`<c-w>p`) is 2.

this is always not an expected behavior to me, i once opened [an issue for this in trouble.nvim](https://github.com/folke/trouble.nvim/issues/189).
of course, i can use a simple autocmd to do this, but i'm wondering if this could be a good default to be added to nvim
```
 api.nvim_create_autocmd("WinClosed", {
  nested = true,
  callback = function(args)
    if api.nvim_get_current_win() ~= tonumber(args.match) then return end
    vim.cmd.wincmd("p")
  end,
})
```
Repository: neovim
Issue: Error in syntax highlighting function call (regression)
Labels: bug-vim,syntax,needs:vim-patch

### Neovim version (nvim -v)

NVIM v0.8.0-1210-gd367ed9b2

### Vim (not Nvim) behaves the same?

no, vim 9.0.354

### Operating system/version

Linux 5.19.12-arch1-1

### Terminal name/version

alacritty 0.10.1

### $TERM environment variable

alacritty

### Installation

Arch Linux Pacman

### How to reproduce the issue

Create a test.vim file with the following contents and open it.

```vim
lua <<EOF
print(a)
EOF

echo vim
```



### Expected behavior

Within `<<EOF ... EOF` syntax is highlighted as Lua, after `EOF` highlighting returns to Vim.

Neovim v0.7.2:

![image](https://user-images.githubusercontent.com/481465/193473919-c785df19-4238-494b-a222-86669d2df1bb.png)


### Actual behavior

The closing parenthesis is matched as `luaParenError`. The error affects the remainder of the file, in particular `EOF` doesn't mark the end of the Lua highlighting.

Neovim v0.8.0:

![image](https://user-images.githubusercontent.com/481465/193473937-2abdcb14-5669-4aae-b950-980ce6ca483d.png)

I've seen this affect [other languages](https://github.com/TovarishFin/vim-solidity) as well so it doesn't appear to be a problem with the specific syntax files.
Repository: pytorch
Issue: torch.remainder and torch.fmod produce wrong results
Labels: module: numerical-stability,triaged,module: correctness (silent)

### 🐛 Describe the bug

For some inputs, torch.remainder and torch.fmod produce wrong results, especially for integer datatype. When converting the int32 input to float32, they can produce correct results.

I suspect this might be caused by type promotion.

Reproduce code:
```
import torch
import numpy as np

input = torch.tensor(1693446850, dtype=torch.int32)
other = torch.tensor([7285], dtype=torch.int16)

# test the apis with int input (wrong results)
r = torch.remainder(input, other)
print(r)
r = torch.fmod(input, other)
print(r)
r = np.fmod(input.numpy(), other.numpy())
print(r)

input = input.to(torch.float32)

# test the apis with float input (correct results)
r = torch.remainder(input, other)
print(r)
r = torch.fmod(input, other)
print(r)
r = np.fmod(input.numpy(), other.numpy())
print(r)
```
Output:
```
tensor([3895], dtype=torch.int16)
tensor([-3390], dtype=torch.int16)
[4890]
tensor([4952.])
tensor([4952.])
[4952.]
```

### Versions

```
Collecting environment information...
PyTorch version: 1.13.0.dev20220923+cpu
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.6 LTS (x86_64)
GCC version: Could not collect
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.17

Python version: 3.7.13 (default, Mar 29 2022, 02:18:16)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-4.15.0-176-generic-x86_64-with-debian-buster-sid
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.21.6
[pip3] torch==1.13.0.dev20220923+cpu
[pip3] torchaudio==0.13.0.dev20220923+cpu
[pip3] torchvision==0.14.0.dev20220923+cpu
[conda] numpy                     1.21.6                   pypi_0    pypi
[conda] torch                     1.13.0.dev20220923+cpu          pypi_0    pypi
[conda] torchaudio                0.13.0.dev20220923+cpu          pypi_0    pypi
[conda] torchvision               0.14.0.dev20220923+cpu          pypi_0    pypi
```
Repository: godot
Issue: Glitchy 3d models in SpatialNode been child of CanvasLayer
Labels: bug,topic:3d

### Godot version

3.5.stable

### System information

Linux 5.19, GLES3

### Issue description

_(May be just my ignorance because I am just installed Godot and have <20 hours in engine)_
3D model got flattened when drug&drop as **MeshInstance**(because I don't need physics in menu) them in **Spatial Node**, child of **CanvasLayer**. I'm trying to do 3D Main Menu background for kinda _game_. I haven't had problems with importing models before and created fine scene to do basic game test.

_Scene with my stone model_
![image](https://user-images.githubusercontent.com/45757429/193474416-0ac6039a-651b-4270-9dc8-c5af72d5cf31.png)

_CanvasLayer Scene with **stone.obj** and **stone.tscn** for test both methods_
![image](https://user-images.githubusercontent.com/45757429/193474548-99e84c7d-25f4-48d2-8166-f38a835a6331.png)
I followed guy on YT but as usual they have everything ready before video and working 100% correct :/

![image](https://user-images.githubusercontent.com/45757429/193474972-77b74342-ad76-45dd-b9fc-02273a494a82.png)

I can change size manually but... :D
I think I just did something wrong, issue with my action algorithm but where I should ask help?

### Steps to reproduce

1. Create new scene with main **CanvasLayer node**;
2. add child **Spatial node**;
3. drug&drop 3d model\scene as **MeshInstance**.

### Minimal reproduction project

_No response_