sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: PowerToys
Issue: [PowerRename] Advanced string formatting
Labels: Idea-Enhancement,Product-PowerRename

# Summary of the new feature/enhancement

PowerRename isn't quite powerful enough for my use case. In an effort to restrain myself from writing a competing tool, I would like to propose the following feature to PowerRename: Advanced String Formatting

![image](https://user-images.githubusercontent.com/9853156/87214128-1a787000-c2f8-11ea-9a82-a13169bcb5d6.png)

<!-- 
A clear and concise description of what the problem is that the new feature would solve.
Describe why and how a user would use this new functionality (if applicable).
-->

# Proposed technical implementation details (optional)

Essentially, this feature would be powered by the C++ [fmt ](https://github.com/fmtlib/fmt) library. PowerRename will make available (at least) the following pre-defined format variables:

- `{fullname}` - full file name (i.e. "lorem.pdf")
- `{name}` - name without the extension (i.e. "lorem")
- `{ext}` - extension (i.e. "pdf")
- `{enum}` - current enum value

If both "Enumerate Items" _and_ "Use Advanced String Formatting" are checked, the user has the option of specifying the starting enum value and the step. If they specify a letter instead of a number as the starting enum value, it would increment the letter (i.e. A,B,C,D).

The other beauty of this, is that `fmt` is extremely powerful with its bracket expressions. This would take PowerRename to the next level. For example, you could do:

`0x{enum:04x} - {fullname}` with starting value `15`, step `1` you would get:
```
0x000F - lorem.pdf
0x0010 - ipseum.pdf
...
```

In short, it brings the full power of `fmt` to PowerRename

So I guess this is kind of two features, but they synergize pretty well. This would also likely close a few existing issues:
- #644
- #3814

I am willing to implement this and open a PR for it. However, I don't want to attempt making a PR without someone's blessing.
<!-- 
A clear and concise description of what you want to happen.
-->
Repository: excalidraw
Issue: Grid mode: Allow dot-sized circles
Labels: enhancement

The smallest circle in grid mode you can make is diameter 1. It would be nice to allow a small circle to represent a dot:

<img width="388" alt="Screen Shot 2020-07-10 at 20 47 23" src="https://user-images.githubusercontent.com/1473433/87215770-91a90680-c2ee-11ea-8496-32e4a170c679.png">

This is easier than making a tiny line (which works already when dragging, and also when using multi-point because subsequent points don't snap to the grid).

Related to #1810
Repository: neovim
Issue: 'completefilterfunc'
Labels: enhancement,complexity:high,core

# Intro

We had a discussion about this on gitter the other day, see https://gitter.im/neovim/neovim?at=5f07781c46c75b1e5e3524ff

Presently, all insert mode completion is based on exact prefix matches. This works great when you have a small list of candidates but as soon as your list of candidates grows large, it becomes frustrating to narrow down. You have to either type the exact prefix yourself or navigate the huge list.

I propose we add a new option `fuzzy` to `completeopt` that will enable fuzzy completion in all completion modes. i.e omnifunc, file completion and keyword completion would all become fuzzy. This would make it much simpler to narrow the completion list when it becomes large and is a standard feature found in nearly every other modern editor.

I am *not* proposing this become default as we want to avoid surprising existing users.

# Why can't this be implemented with a plugin?

The gitter link above discusses this in more detail but the problem is that plugins can only fetch the initial candidates fuzzily. As you type more characters, neovim narrows down the list of candidates itself instead of consulting whatever plugin is providing completions. Thus, as you type more characters, you have to provide the exact prefix to narrow down the list.

It may seem to work if you have autocomplete enabled in which case when the list is narrowed down to zero candidates, the plugin will repopulate the list with new candidates based on fuzzy matching but this results in awkward flickering. See https://github.com/neovim/neovim/pull/8184#issuecomment-377431559

# Implementation

We discussed that the current matching implementation is written in C and so difficult to extend. To implement this feature, it may be a good idea to switch the matching implementation to lua first and then add a fuzzy completoept. I'm not 100% sure as it may be easier to write only the fuzzy matching implementation in lua or reuse https://github.com/neovim/neovim/pull/8184/files which imports [fzy](https://github.com/jhawthorn/fzy).

Please let me know how you think this is best implemented.

I'm happy to lead this feature so feel free to assign me. I probably won't get to it soon though so if anyone else would like to take it off my hands, please feel free.

cc @Shougo @clason @fsouza
Repository: terminal
Issue: Copy on Select ignore trailing whitespaces
Labels: Issue-Bug,Area-TerminalControl,Product-Terminal,Priority-2

# Description of the new feature/enhancement

While copying on select, auto ignore trailing whitespaces on each line.

# Why?

In my `.vimrc`, I draw 80 column and 120 column line via background color like this: 

![image](https://user-images.githubusercontent.com/841969/87218091-388ab280-c382-11ea-8df3-8b37e0ff85d5.png)

```vim
function! SetColumnWarnOnResized()
  highlight Normal ctermbg=NONE
  if &columns > 120
    let &colorcolumn="81,".join(range(120, &columns), ",") " Set the column warns on 80 and 120+
  else
    let &colorcolumn="81" " Set the column warns on 80
  endif
endfunction
au VimResized * call SetColumnWarnOnResized()
call SetColumnWarnOnResized()     
```

When I select and copy these words in the screenshot above, Windows Terminal will fill my clipboard with many whitespaces like this (notice that wired whitespaces):

```
Some texts here...
And here...                                                                                                                                                         Notice the 80 col line in my vim --------------------------------------------->
And the 120 col line ================================================================================================>       
```

And this only happend sometimes (not always), I don't know if this is a bug?

# Related issues

This issues may relatives to these issues:

* #2944
* #3088
Repository: PowerToys
Issue: [Run] UAC dialog box doesn't get focus after hitting enter on "Run As Administrator" button
Labels: Issue-Bug,Product-PowerToys Run,Priority-3

```
Windows build number: 10.0.19041.329
PowerToys version: v0.19.1
PowerToy module for which you are reporting the bug (if applicable): Run
```

# Steps to reproduce

1. Set UAC Settings to "Do not Dim"
2. Launch PowerToys Run
3. Type name of any program that you would like to start
4. Hit "tab" button in order to focus on "Run As Administrator" button or use `Ctrl + Shift + Enter` shortcut

# Expected behavior

"User Account Control" dialog box appears with the action button "No" focussed. So you can use your keyboard to press either button on the UAC dialog box.

# Actual behavior

"User Account Control" dialog box appears above the PowerToys search box but the UAC dialog itself doesn't get focussed. The PowerToys Run search box stays focussed. So you cannot use your keyboard to press any button on the UAC dialog box.

If you run any program from the Windows Start Menu the UAC dialog gets focussed right after you hit the "Run As Administrator" button.

# Screenshots

![Hvf0jA1cl7](https://user-images.githubusercontent.com/290543/87225579-dd16ef80-c396-11ea-99b3-1e5a2290a721.gif)
Repository: rust
Issue: consider disallowing setting target_family if target_os=none
Labels: A-codegen,O-bare-metal

Should setting target_family require also setting target_os?

Currently, the `x86_64-linux-kernel` target sets target_family to "unix", but the os is "none". This is the only target which sets the family without the os. This can make it a little confusing/awkward when writing `cfg` expressions to properly cover targets such as these (sometimes the check for os="none" needs to appear before the family).

In practice today this isn't an issue because libcore, liballoc, and compiler_builtins do not ever check the family. AFAIK, the family doesn't have any other effects other than the `cfg` settings.

This issue came up during #74033 where I was adjusting some `cfg` expressions for building std for Cargo. I do not know if Cargo's build-std will ever support `x86_64-linux-kernel`, but I'd like to try to cover as many targets as possible and avoid special cases if they are not necessary.

@eddyb had some [suggestions](https://github.com/rust-lang/rust/pull/74033#discussion_r453144971) which I'll copy here:

> Does the Linux kernel even have an UNIX API inside of itself? That doesn't sound right but maybe I just haven't seen it before.
> 
> (To be clear, I'm thinking that family="unix" is as valid for inside an OS kernel as os="thatosname" - if os="none" is used then surely there should also not be a family? Maybe we should enforce that the family is derived from the OS name and therefore means "OS family")

cc @joshtriplett who I think might know a little about the `x86_64-linux-kernel` target, and @alex who introduced the target.  Perhaps they can shed some light why "unix" was chosen.
Repository: godot
Issue: Creating a trimesh static body from a mesh with blend shapes does not take blend shapes into account
Labels: enhancement,topic:core,topic:editor,confirmed

**Godot version:**
3.2.2


**OS/device including version:**
Linux Mint 20

OpenGL ES 3.0 Renderer: GeForce 940MX/PCIe/SSE2


**Issue description:**
When you have a model imported with blend shapes, and you create a trimesh static body from it, it ignores the blend shape settings you have provided and creates the static body as if all keys were 0.

So this is my model:
![image](https://user-images.githubusercontent.com/7745457/87229831-caf37c00-c3ab-11ea-94a2-3ca232227dc3.png)

But this is the collision shape:
![Screenshot from 2020-07-11 19-22-42](https://user-images.githubusercontent.com/7745457/87229865-068e4600-c3ac-11ea-9eb2-990dad5ac242.png)

**Little project:**
Open `res://level/lvl1.tscn` for the mesh

[snowball.zip](https://github.com/godotengine/godot/files/4907314/snowball.zip)
Repository: vscode
Issue: Add support for SteppingGranularity in the UI
Labels: feature-request,debug

Having https://github.com/microsoft/vscode/issues/90793 is fantastic (and we just shipped a version of the Julia extension that supports [this feature](https://www.julia-vscode.org/docs/v0.17/release-notes/v0_17/#Support-for-step-in-targets-in-the-debugger-1)).

So now I'm of course wondering whether we could also have built-in support for `SteppingGranularity` from the DAP in the UI? :)
Repository: godot
Issue: Wrapping is inconsistent in control nodes
Labels: bug,topic:gui

**Godot version:**
v3.2.2.stable.official


**Issue description:**
The wrapping reacts different in different nodes when the last character(s) on the line are spaces.
They all seem to have a different approach/method when wrapping.
![ISSUE](https://user-images.githubusercontent.com/52723367/87230772-49ebb300-c3b2-11ea-97d8-4467df68edca.png)

(I have used the exact same string on each one, and btw they occupy the same width)


The expected behaviour is to all nodes "react"/have the same output/format with the exact same string/text.
In my case, I needed some nodes to overlap and react the same as a TextEdit. But when the wrap reacts different, breaks it:
![demo](https://user-images.githubusercontent.com/52723367/87230906-2f660980-c3b3-11ea-95cb-71b7fdcd0459.png)



**Steps to reproduce:**
Add different text nodes (TextEdit, label, etc) wich ocuppies the same width and put a text with some spaces at the end of the line (when the wrapping should take effect). And see the different results in different nodes.
(But I've made a small project, wich is faster)

**Minimal reproduction project:**
[InconsistentWrap.zip](https://github.com/godotengine/godot/files/4907384/InconsistentWrap.zip)
Repository: flutter
Issue: [flutter_tools] flutter doctor does not recognize portapps version of Intellij
Labels: tool,t: flutter doctor,P3,team-tool,triaged-tool

I used to have a portable development environment, having a IntelliJ IDEA Ultimate installed in a external SSD drive (https://portapps.io/app/intellij-idea-ultimate-portable/).

The problem is when I run "flutter doctor -v", the flutter doesn't recognise the portable version (and I initially understand, because is not in the default directory). But the problem is that I haven't a option to do manually the search. The command "flutter config --android-studio-dir" doesn't work even if I use a Android Studio portable.

I have everything configured correctly in my external drive, including all system environment variables. Here is my current "flutter doctor -v" output:

`[√] Flutter (Channel stable, v1.17.5, on Microsoft Windows [Version 10.0.18363.900], locale en-GB)
    • Flutter version 1.17.5 at Z:\SDK\Flutter
    • Framework revision 8af6b2f038 (10 days ago), 2020-06-30 12:53:55 -0700
    • Engine revision ee76268252
    • Dart version 2.8.4


[√] Android toolchain - develop for Android devices (Android SDK version 30.0.1)
    • Android SDK at Z:\SDK\Android
    • Platform android-30, build-tools 30.0.1
    • ANDROID_HOME = Z:\SDK\Android
    • Java binary at: Z:\SDK\OpenJDK\bin\java
    • Java version OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_252-b09)
    • All Android licenses accepted.

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/docs/get-started/install/windows#android-setup for detailed instructions).

[!] Connected device
    ! No devices available

! Doctor found issues in 2 categories.`
Repository: pytorch
Issue: ConvTranspose1d layer behaviour under different channel numbers
Labels: module: docs,module: convolution,triaged

## 📚 Documentation

Documentation for [ConvTranspose1d layer](https://pytorch.org/docs/master/generated/torch.nn.ConvTranspose1d.html) does not contain even brief explanation of how channels are treated and how number of channels affect processing. 

Same goes for [Conv1d layer](https://pytorch.org/docs/master/generated/torch.nn.Conv1d.html) but it was at least covered in [this discussion](https://discuss.pytorch.org/t/understanding-convolution-1d-output-and-input/30764/2) and is somewhat more obvious. With transposed convolution it is easy to find dozens of sites, books and animations explainig how it happens but I have not found a single mention that happens when there is multiple input channels and how they are reduced to single output channel. There are several questions on discuss.pytorch.org which seem relevant:
1. https://discuss.pytorch.org/t/how-to-use-torch-nn-convtranspose1d-to-take-the-derivative-of-torch-nn-conv1d-function/32620
2.  https://discuss.pytorch.org/t/upsampling-convtranspose2d-getting-the-original-tensor-size/51936
3.  https://discuss.pytorch.org/t/understanding-conv2d-and-convtranspose2d/42142
4. https://discuss.pytorch.org/t/convtranspose2d-weight-shape/52528

In the end, I just created ConvTranspose1d layer, feed it with constant values and hypothesized that it:
1. applies transposed convolution to each input channel independently
2. sum results for each channels, adds bias and push it to output channel
3. multiple output channels just use different set of kernels and produce different values


cc @jlin27
Repository: deno
Issue: [Feature Request] Native API for "controlling terminal" stream
Labels: cli,public API,suggestion

In some cases, such as a [Git Credential Helper](https://git-scm.com/docs/gitcredentials#_custom_helpers), a script needs to get both program arguments through stdin, and prompt the user for data.

In Linux, this is done by opening [/dev/tty](https://linux.die.net/man/4/tty) which is, according to the manpage, a handle to the process' _controlling terminal_, which is a separate stream from stdin.

I have also noticed that Deno currently has no handle in its API for such a stream, so for now there's no cross-platform/native solution to this.

My suggestion is adding a `Deno.tty` handle to Deno's API, similar to the `Deno.stdin` handle, to allow for cross-platform usage of this feature.

Edit: On further research, according to [this page](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/146259) from the bottom of the internet, something like this could work easily for mac, linux and windows.
Edit2: On even [further research](https://en.wikipedia.org/wiki/Device_file#PC_DOS,_TOS,_OS/2,_and_Windows), i got the wrong Windows device name. Edited in the code snippet.
```
//Within the Deno namespace:
export const tty = Deno.build.os === "windows"?await Deno.open("CON:"):await Deno.open("/dev/tty");
```
Repository: bitcoin
Issue: Use of C++ undefined behavior in various `IteratorComparators`
Labels: Bug

**Expected behavior**

All C++ code to be 100% using legal C++ and not UB which can lead to subtle bugs if not now, then perhaps in the future.

**Actual behavior**

Use of undefined behavior in at least two places:

- https://github.com/bitcoin/bitcoin/blob/42fe6aad326f62c7e6ea12ee873149257f67ce5d/src/net_processing.cpp#L227
- https://github.com/bitcoin/bitcoin/blob/42fe6aad326f62c7e6ea12ee873149257f67ce5d/src/miner.h#L67

**Background**

Please see this part of the C++ specification: https://en.cppreference.com/w/cpp/language/operator_comparison

In particular I will quote the relevant section here:

> If two pointers are not specified to compare greater or compare equal, the result of the comparison is unspecified. The result may be nondeterministic, and need not be consistent even for multiple evaluations of the same expression with the same operands in the same execution of the program:

```c++
int x, y;
 
bool f(int* p, int* q) { return p < q; }
 
assert(f(&x, &y) == f(&x, &y)); // may fire in a conforming implementation
```

Note that in the above-linked section (which I admit is difficult to decipher) -- pointers are only specified to have a legal `<` or `>` comparison operations if the objects they point to either belong to the same array, or if the objects they point to live basically as members in the same object (i.e. as class members).  *This is unlike in C*.  The code will compile.. it will run -- but like the above section states, and the above sample program illustrates --  the results may be non-deterministic!

In practice it appears the code works in bitcoin for all known compilers and platforms -- but is not guaranteed to do so forever and may lead to subtle bugs in the future as compilers evolve or as `libstdc++` evolves.
Repository: go
Issue: proposal: sizeof: add bit sizes
Labels: Proposal,Proposal-Hold

See the tail of the (open) [CL 242018](https://go-review.googlesource.com/c/go/+/242018) for the (approved) proposal #29982. There are a number of use cases where bits, not bytes as `unsafe.Sizeof` and `sizeof.Xxx` speak in, are really useful and it is a shame that you have to manually derive them, `const UintBits = sizeof.Uint * 8`, as this is error prone. Instead we should expose constants for bit sizes too:
```go
package sizeof

const (
	bitsSize = size * 8 // 32 or 64

	BitsBool       = 8
	BitsByte       = Uint8
	BitsComplex64  = 64
	BitsComplex128 = 128
	BitsFloat32    = 32
	BitsFloat64    = 64
	BitsInt        = bitsSize
	BitsUint8      = 8
	BitsInt16      = 16
	BitsInt32      = 32
	BitsInt64      = 64
	BitsRune       = BitsInt32
	BitsUint       = bitSize
	BitsUint8      = 8
	BitsUint16     = 16
	BitsUint32     = 32
	BitsUint64     = 64
	BitsUintptr    = bitSize
)
```

We could derive `BitsXxx` from `Xxx * 8`, but the current format seems more terse and intuitive. As well, the names could use a suffix, `XxxBits`, instead of the current prefix, since we get custom ordering for blocked constants, but to me, prefixes displays better and follows other standard library conventions: `http.StatusXxx` and `xxx.ErrYyy`.

Depending on the use case, we could instead export a constant or function for deriving these values. While the former is still prone to user error, it should be intuitive for users familiar with `time.Duration`. The latter seems like a blocker because functions cannot be compile time constant:
```go
// Bits stores the number of bits in a byte.
//
// This is useful for converting byte type sizes into bits:
//	const UintBits = sizeof.Uint * sizeof.Bits
const Bits = 8
```
```go
// Bits converts byte sizes into bits.
//
// This is useful for converting byte type sizes into bits:
//	var UintBits = sizeof.Bits(sizeof.Uint)
func Bits(bytes int) int { return bytes * 8 }
```
Repository: go
Issue: proposal: sizeof: add synthetic, pointer-like types
Labels: Proposal

The (approved) proposal #29982, excludes complex and dynamic types from the new `sizeof` package. For primitive, value-like types (structs and arrays), this is in required, since they are of variable length. But synthetic, pointer-like types (channels, functions, interfaces, maps, slices, and strings) instead point to their data and are of constant size. Can we add the following types:
```go
package sizeof

const (
	Channel    = Uintptr
	Function   = Uintptr
	Int        = Uint
	Interface  = Uintptr * 2
	Map        = Uintptr
	Slice      = Uintptr + Int*2
	String     = Uintptr + Int
)
```

Technically one can calculate the `unsafe.Sizeof` any of these types today, but the intention of the `sizeof` package is to make that unsafe interface less necessary. Furthermore, while these types are more complex, we can add test cases to ensure that new architectures or changes to the implementation of these types are reflected in `sizeof`.
Repository: neovim
Issue: terminal-cursor disappears after quitting ranger and newsboat in nvim-terminal
Labels: bug,status:blocked-external,terminal

- `nvim --version`: 0.4.3
- `vim -u DEFAULTS` (version: 8.2) behaves differently? No
- Operating system/version: Arch Linux
- Terminal name/version: xterm 357
- `$TERM`: xterm

### Steps to reproduce using `nvim -u NORC` with `newsboat`

1. `nvim -u NORC +te`
2. `i`
3. `echo url > urls`
4. `newsboat -u urls`
5. `q`

### Steps to reproduce using `nvim -u NORC` with `ranger`

1. `nvim -u NORC +te`
2. `i`
3. `ranger`
4. open a file
5. `:q<cr>` (close nvim)
6. `q` (close ranger)

### Actual behavior

The cursor in the nvim-terminal is not visible anymore. It can be unhidden by executing

```
echo -en "\e[?25h"
```

### Expected behavior

The cursor should be visible after exiting newsboat.

### Notes

Might be related #2708
Repository: excalidraw
Issue: Context menu is breaking zoom on mobile
Labels: bug

This is not super easy to repro, but I eventually always get it:

1. Double tap to start text
2. Use two fingers to zoom out
3. Try until you get the context menu shown
4. Now zoom is broken and you can’t zoom back in

https://www.dropbox.com/s/yerpgypb4a3oj5k/Video%20Jul%2011%2C%2017%2049%2027.mp4?dl=0