Suggest to rename "Shell Command" to "Code Shell Command"

[weinand]

On testing #3241:

In the Command Palette "Shell Command" sounds very generic and it might be not clear what's behind this. I suggest to change it to "Code Shell Command" or "Code Command Line Tool" (which would even work on Windows).

[joaomoreno]

I'm not sure adding Code would make it less generic... We don't have the best product name... :/

[joaomoreno]

How does this sound?

System: Install shell command in PATH
System: Uninstall shell command from PATH

[egamma]

I suggest to make the description of the command more verbose:
Shell Command: Install command to launch Code in PATH

And Code would show in all the product flavors Code-insiders, Code-alpha.

[egamma]

May be even leave out the category 'System' or 'Shell Command'

[weinand]

"Install 'code-alpha' command line tool in PATH"

[egamma]

Better, but I don't like command line tool. This isn't really a tool but a command to launch code.

"Install `code-alpha' launch command in PATH"

[joaomoreno]

How about

Install 'code-alpha' command in PATH

[egamma]

👍

[joaomoreno]

SOLD!

[joaomoreno]

Unfortunately I can't do exactly this since at the point I require it I don't know whether the shortcut will be called code, code-alpha or code-insiders.

I will name the action Install 'code' command in PATH and simply inform the user that it is in fact code-alpha after it has been installed.

@bpasero The reason for this lies on the need to provide the label to the SyncActionDescriptor constructor. At that time, I don't know the name of the shortcut, since I get it from the context service.

[weinand]

@joaomoreno sounds good!

[bpasero]

@joaomoreno descriptors are static enough that you cannot create them if you need services. the point of F1 is to show descriptors and not instantiated actions.

[joaomoreno]

I get it. Irrelevant to this particular issue, I would actually like to argue against using descriptors. Here's what I observe:

With descriptors:

• We end up having more code overall
• All that code is loaded into memory on startup, since we're talking about sync descriptors. That is the action, its descriptor, the descriptor registry, and the action cache. All of that gets loaded into memory.
• An action, in its essence, is a simple JS object. The descriptor is another. You end up having 2 objects in memory. They last forever.
• We seem to optimize for time by not calling all the instantiation services into the actions before they are actually needed. We end up allocating twice the memory we need. It's the trade-off.

Without descriptors:

• All the code you need to write is the action itself
• Only the action code is loaded into memory
• The instantiation itself would happen at startup, possibly being intensive

I'm not really sure the performance benefits are so clear that the descriptors end up being the obvious choice. I might be wrong, but it would be a nice benchmark to test.

[bpasero]

I am all up for not having sync descriptors at all, I was just describing our status quo.