Should we use namespacing in the CLI
See original GitHub issuehttps://github.com/microsoft/vscode/issues/92031 is requesting a terminal CLI to enable things like creating a new tab and splitting the current tab which would align with the capabilities of many terminals (including Windows Terminal) and enable splitting a terminal tab by running a command in the terminal.
Does anyone have opinions for or against this? If we want to go with this I think we should also do the same for extensions by deprecating/aliasing the current CLI and moving them to either code ext ...
or code extension ...
as it keeps growing and could be better organized:
Extensions Management
--extensions-dir <dir> Set the root path for
extensions.
--list-extensions List the installed
extensions.
--show-versions Show versions of installed
extensions, when using
--list-extension.
--category Filters installed
extensions by provided
category, when using
--list-extension.
--install-extension <extension-id | path-to-vsix> Installs or updates the
extension. Use `--force`
argument to avoid
prompts.
--uninstall-extension <extension-id> Uninstalls an extension.
--enable-proposed-api <extension-id> Enables proposed API
features for extensions.
Can receive one or more
extension IDs to enable
individually.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:7
- Comments:20 (17 by maintainers)
Top Results From Across the Web
Platform, default, and cli Namespaces (C++/CLI and C++/CX)
A namespace qualifies the names of language elements so the names do not conflict with otherwise identical names elsewhere in the source code....
Read more >create a namespace in c++/cli? - Stack Overflow
But I haven't seen any examples of creating my own. So I was wondering if there is a way to declare/create my own...
Read more >C++/CLI - Lesson 2: Data Types - FunctionX
The C++ Standard provides a namespace called std. The std namespace includes a series of libraries that you will routinely and regularly use...
Read more >Namespaces - Kubernetes
Namespaces are intended for use in environments with many users spread across multiple teams, or projects. For clusters with a few to tens...
Read more >get-namespace — AWS CLI 1.27.32 Command Reference
Do you have a suggestion to improve the documentation? Give us feedback. If you would like to suggest an improvement or fix for...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
As the CLI does more things (server distro, “gateway” mode, version management, terminal work, other things in the future…) I do not think the current model of free-floating flags works very well. Note that when I say CLI here I refer to the interface exposed to users, which is eventually the Rust CLI.
Currently there is top-level help for extension management and flags that only apply to extension management. Adding similar sections for all other functionality causes help to become increasingly verbose and less useful to users, and I think a
--help --verbose
option does not address the root problem and is obscure to users. I suggest adopting a subcommand approach, where based editor options are shown at the top level (socode --wait foo.txt
for instance still works) but the additional functionality I listed previously appears in a subcommand. If I’m a user who knows I want to do things with extensions, I can runcode ext --help
rather than trying tocode --help --verbose | grep -B 5 -A 5 -i extension
.This is the approach I recently took in https://github.com/microsoft/vscode-cli/pull/432 (this is exploration, not final set in stone.) That PR includes logic that handles things that became subcommands (
--(list|install|uninstall|)-extensions
,--status
) in a backwards compatible way.I personally would prefer to not introduce any more capabilities via the CLI other than:
code
is for)