Open devanshj opened 4 years ago
Hey @chrmarti, this proposal (and the ready implementation) fixes a pretty annoying bug in git extension that has 112 upvotes and is 3 years old, not to mention it's a small change which is no-brainer & is pretty straight-forward. So I guess the reward to investment ratio is high enough that it would be great if you can prioritize it a little thanks :)
@devanshj Please have patience and don't ping us. As you can see there are 5k issues and 200 PRs open, on top of all the monthly releases. There's a lot to work on. We'll get to it in time.
FWIW I wouldn't call it a "feature-request" (I'm not requesting a feature) it's more of a "bugfix" (I'm providing a bugfix that involves adding a feature) because it's part of the process of getting this PR (which literally is a bugfix) merged.
To answer the bot, #40295 (the issue that gets fixed by this proposal & PR) already has 114 upvotes and the api feature request has 25 upvotes.
Also how I would want (it's okay if that's not what y'all want) this to proceed is that this should be added to current or next month (anything other than backlog really) milestone because clearly it makes the cut to be in them, that is what I was trying to say in the initial ping.
I was just going to open a ticket to simply make the git commit box multiline... how do I vote for this issue?
I was just going to open a ticket to simply make the git commit box multiline... how do I vote for this issue?
The 👍 you did counts as a vote afaict so you're good! Also this already has enough votes in the issues I've linked the reason I opened this is to discuss the api and track the lifecycle of it according to the guildlines. So actually you should also 👍 this which imo is the actual "feature-request".
Just started coding my extension for VSCode, it lacs basic UI input methods. No multiline inputs, no way to design a simple dialog box (we need to use Electron apps like the Color Palette is using and do IPC...). I'm surprised VScode extension API lacks so many basic features.
Feature needed, pleaaaase :)
2022 - still no multiline inputs hahah
Now it is 2023, and we are still waiting for this feature. 😶
By the way, ChatGPT suggests using input.multiline = true
to enable multiline inputs. 🤣
Yeah, nobody from MS gives a flying F***
Any update on this?
Yeah BIG FU
@isidorn is this something that can be brought up for consideration? Looks like @eamodio already has a PR ready with an implementation.
Any update?
Any Update??
Any update?
Problem
Currently there's no way to take a multiline input via
showInputBox
. We need one because we useshowInputBox
to take the commit message (which can be multiline) in git extension. (#40295, #39969)Solution APIs
TLDR: allow passing a
multiline
property to theshowInputBox
options- **PROPOSED** API: Allow passing a `multiline` property to the `showInputBox` options. - Problem: Users can have `{ multiline: true, password: true }` which won't work because it's a textarea. More importantly in future there could be more options applicable to only multiline (eg an option mapping to textarea's `row` attribute) or to only singleline - **PROPOSED** Solution: It's okay just document it - Solution: It's okay just document it and throw an error if such case arises - Solution: make the type of options like ```{ multiline?: false, password?: boolean } | { multiline?: true, password?: false }``` - Problem: Terrible typescript inference and error message ergonomics if the options are not literal - Problem: It's typescript-only solutiton - API: Have another function called `showMultilineInputBox` that takes options only applicable to it (meaning doesn't take `password` property as option) - Problem: Feels a little overkill especially at the moment as we only one option (ie `password`) exclusive to singleline. It would have been okay if we had a bunch of options only exclusive to multiline eg `maxHeight`, `autoGrow`, `initialRows`, etc. or bunch of options exclusive to singleline
Solution Behaviors
TLDR: when
multiline
is set to true,showInputBox
shows a multline quick input where the user hits shift+enter to insert a newline and works exactly like current quick input- **PROPOSED** Behavior: Allow users to insert a newline with shift+enter instead of submitting - Prior art: In chrome developer console enter executes the code but shift+enter inserts a newline. As in, usually afaik in scenarios where enter is already taken, shift+enter mimics the "usual" enter behavior. I guess it's also [popu](https://twitter.com/jaffathecake/status/1290306529539821568)[lar](https://twitter.com/rauschma/status/1095298670017343488) convention. - Behavior: Allow users to insert a newline with enter instead of submitting and have shift+enter submit it. - Problem: The behavior is not "additive" to singleline behavior as user would expect enter to submit it in multiline also as it does in singleline - Behavior: Allow users to insert a newline with enter instead of submitting and have a button to submit it. - Problem: Kinda kills the whole point of "quick input" you'll have to press tab to focus to button and hit enter, foreign to quick action ui and not additive to singleline behavior
Implementation
For currently proposed api and behavior: #98042, demo
cc @jrieken @chrmarti @joaomoreno