RFC for a text based editor appropriate here? about powershell-rfc

[joeyaiello]

@DarwinJS most of the console editor purists on the PowerShell Team use vim.... 😄

Anyway, I personally don't think shipping a console text-editor as part of PowerShell is the right thing to do. Ideally, the OS should ship one (or many), and arbitrary shells should be able to use it (as is already the case on Linux).

Nano Server is kind of a special case because it doesn't have a fully functioning console host or pTTY (though I think if you're remoting in from a desktop machine over PSRP and not pure SSH, this isn't a problem). No idea if that work is planned right now, but I know we'll eventually need it for pure SSH scenarios.

Quick web search revealed this niche editor (though not mine! 😉) that's still being kept up-to-date: http://joe-editor.sourceforge.net/

Unfortunately, it's not on Chocolatey, but if you validate it's working on Nano I know you have some expertise in package building, @DarwinJS... (to anyone who doesn't know, he built the OpenSSH Chocolatey package to address a glaring hole on getting it onto Nano Server 👍)

[daviwil]

@DarwinJS We decided to ship the ISE Preview via the Gallery because the ISE is a core tool for PowerShell and it made sense to distribute it from there. However, we do not recommend that other applications be shipped via the Gallery, it's primarily meant for modules, scripts, and DSC resources.

[DarwinJS]

There is not a log of pickup of this on uservoice - despite it being an obvious need for those of us doing DevOps on the Windows platform.

If Nano editor can't be used due to GNU GPL - are there other OSS porting options?

What about the old Microsoft "edit" console editor - can that be resuscitated?

[DarwinJS]

I'm not keen on vi variants - maybe it's the neolithic age non-intuitiveness of every aspect of their operation - not sure :)

Having started in Windows I've always found nano to be much more friendly to learn and use for the last 15 years of managing the LAMP stack.

Since this would be the editor that Windows-only admins would need use, I would vote for something that is easier for them to use than vi variants.

[DarwinJS]

Linking this to the user voice submission: https://windowsserver.uservoice.com/forums/295047-general-feedback/suggestions/18128812-console-text-editor-for-nano-and-server-core-and

[SeeminglyScience]

@joeyaiello

If I'm remembering correctly, the way the psedit functionality works today is to kick off a local editor, do the editing in a local temp file, and then to stream it into a file over PSRP (though I don't know how continuously that file gets updated on the remote end). I don't think there's any reason why we can't make that work against a local Nano/Vim/emacs/Notepad/whatever.

I put together a basic proof of concept for this. If you use this command to connect to a remote machine, psedit path\to\file will open vim (or whatever is in $global:PSEdit) locally against a temporary file that represents the remote file.

The way PowerShellEditorServices does this without a proxy command is by implementing a custom PSHost and by using the IHostSupportsInteractiveSession.PushRunspace/PopRunspace methods to create the required event subscribers/commands. One way to allow something like this without requiring a custom host would be to add a public RunspaceChanged event to PSHost. InternalHost could then raise the event after invoking the external host's PushRunspace/PopRunspace implementation.

[daviwil]

Does Vim work on NanoServer? I'm looking into adding full PowerShell language support to Vim later this year; editing PowerShell with Vim on NanoServer would be an interesting scenario.

[SteveL-MSFT]

Is remote editing of files via VSCode acceptable?

[DarwinJS]

Yeah, but I would venture to guess most of the PowerShell team would be borderline, if not full-on Systems Programmers - not representative of the Windows system admins - many of which are having a rough time just getting to do more of their work in a console - let alone one with no text editor.

When the Microsoft Docker guy Niel Peterson did some demos on Linux at IT/DEV Connections he used Nano and made a comment about vi that I can't remember specifically, but resonated with.

Yeah, I also found this one: http://turtlewar.org/projects/editor/ - but I think with Nano being GNU license and the second most popular on Linux - it would make it a decent choice.

So I could come up with a one mile oneliner that pulls the nano.zip and drops it on core - but that wouldn't help on Nano Server.

I didn't originally mean that the editor would ship with PowerShell, but now that I'm thinking of it I DO think that is the best place.

It is the PowerShell enabled, remote-only Nano that is pushing the envelop on console mode only Windows - so I think it fits.

This would be the cat's meow:

• Nano text editor or a variant ships with PowerShell on all platforms.
• When the new nano editor is started on Nano Server - it reaches back over the remoting connection and kicks off a copy of nano text editor in the original machine and has it edit the file remotely like PSEdit does on Nano. (if the remoted from machine is not also Nano).

But it would be even better if it could just run on the far side of remoting.

@SteveL-MSFT - I was still writing this when you posted - but whether remote editing with VSCode / ISE or a new text mode editor - it would be nice if there was a stub on nano that could kick off the remote editor.

Feels really odd that there are many lightweight, console editors on linux and none on Windows.

[joeyaiello]

@PowerShell/powershell-committee talked about this yesterday. We agreed on two high-level statements:

• Nano Server probably needs a text-mode editor, but it doesn't belong in PowerShell. (Unfortunately, we don't own the decision on this one, but we're close to the Nano Server folks and we'll likely work to get this in their queue at some point.)
• psedit should work with arbitrary editors over PSRP. I believe this actually already works in ISE (though I haven't personally tried it against a Nano Server endpoint). /cc @daviwil @PaulHigin

If I'm remembering correctly, the way the psedit functionality works today is to kick off a local editor, do the editing in a local temp file, and then to stream it into a file over PSRP (though I don't know how continuously that file gets updated on the remote end). I don't think there's any reason why we can't make that work against a local Nano/Vim/emacs/Notepad/whatever.

As an aside, the fact that Nano (the editor) is GPL actually makes it much harder for us to ship it (and almost certainly precludes it from ever being included with Nano Server images).

[DarwinJS]

@joeyaiello - that's awesome you guys discussed it.

My experience of psedit so far is that you must initiate your remoting session to Nano from INSIDE ISE on the machine you are remoting from, then and only then does the psedit command interface properly with the ISE you remoted from on the source end.

If it can be initiated on Nano and start the editor off on my remoting source - I did not know that. Maybe my experiences are pre-RTM?

If Nano had it's own editor, the entire remote editing functionality would not be as necessary - but still be nice for large scripts where things like syntax highlighting would be a help.

Didn't know that about GPL. However, I also took a closer look and that Nano port also contains 4 cygwin DLLs - so it's a bit of a cheat and probably the reason that they don't keep providing newer versions in that format - they have to sidecar cygwin runtimes to deploy to Windows.

[DarwinJS]

@joeyaiello - I was talking with our team today and a key challenge in our multiplatform environment is that the even the installed editors on Server Core do not understand Linux vs Windows line endings - so they end up installing notepad plus plus.

If this idea goes into the base OS, is there any public place I should post a feature request - or is it Microsoft internal at that point?

Thanks.

[DarwinJS]

@joeyaiello - hey I just remembered that on one of the most recent PowerScripting podcasts that David Wilson was a guest and talked about the new capabilities he has been building to be shared between ise and VS Code.

At one point they talk about the distribution of the new ISE via PowerShellGallery - (a) that it is possible to deploy things other than PowerShell modules and (b) why it makes sense to do so when the ISE is no longer bound to the Windows or PowerShell release cycle.

Maybe that distribution model would work for a text mode editor for Windows Server?

https://powershell.org/2016/02/08/up-next-david-wilson-from-microsoft-talks-about-powershell-ise-vs-code/

[SteveL-MSFT]

@DarwinJS suggestions for Windows Server should go to their UserVoice

[DarwinJS]

@daviwil - thanks for the clarification! Enjoyed the podcast by the way.

Totally off the wall soapbox (but possibly related to your work) - it sure would be nice to have code snippets in an editor subsystem that does not require I store snippets in any special format or storage technology.

Every incarnation of a snippets subsystem for PowerShell editors always seems to require a custom file formats or storage mechanisms - I just want to dump my straight PowerShell code and other good code into a repo (which I don't mind replicating locally for the editor).

I could tolerate optional snippets metadata nested in comment based help or another comment block - but not have it required so I have to do it to every file just to index it as a snippet.

[daviwil]

@DarwinJS Thanks, glad you enjoyed it! I have heard a similar suggestion for snippets before. It is very likely that we could have a PowerShell-based snippets engine like Kirk Munro's SnippetPx. VS Code enables us to provide custom snippets from our own source so it seems possible to accomplish this. I'll look into it at some point in the future.

[DarwinJS]

This is still a need.

More examples:

• quick testing of fixes on a container or server core (before incorporating into automation code) - especially when these are buried in complex cloud environments where remoting is not an option
• AWS and Azure Cloud consoles - can't run remote editing services

/cc @joeyaiello @SteveL-MSFT

[mryanmurphy]

@DarwinJS the micro editor has solved the need for me, cross platform, OSS, and clearly inspired by nano's UI/UX. https://github.com/zyedidia/micro

[JaminShanti]

Other then what Microsoft has done on their command shell, powershell. None of there other binaries have gotten any updates in years, decades? Why are they so reluctant to add useful binaries to their operating system?

[bgshacklett]

@JaminShanti A built-in editor aside, what would you want to see that is not being covered by the work that has been done/is being done with PowerShell?

[DarwinJS]

@JaminShanti - while Microsoft has made it clear for well over a decade that native commands for operations are not an investment area - they have still been updating them in various ways. Even the CMD Shell language was receiving updates until about a decade ago. Recently they added tar and curl: https://blogs.technet.microsoft.com/virtualization/2017/12/19/tar-and-curl-come-to-windows/

However, the strategy for extensibility of the Operating System command set has been revolutionized by PowerShell because, unlike cmd.exe / native commands, Microsoft does not have to do major or minor releases of the OS to extend the environment - in fact anyone can extend it and even share those extensions with the community.

The reasons I am advocating for a native command line editor (which I do feel is higher priority than tar or curl) have been articulated earlier, but I would say the following are the strongest:

• technically CMD.exe remains the default Windows shell - it is what boots up in Server Core. Only Nano is the exception - but adoption seems lagging.
• as the industry has completed transformation to CLI only cloud servers (for the sake of density) - we should have a CLI only editor to reflect this deep and permanent reality.
• text editors tend to function as a swiss army knife for those who are still getting their feet wet in pure CLI operations so help to bridge people into pure CLI
• there are more and more "remoting" contexts where a background file exchange can't be done to remotely edit files in a local editor - whether constructed by our own making (guacamole, etc) or via new things like cloud shells. Many time these boundaries are due to good security practice.
• vs code is awesome - but as far as I understand a CLI version of it would be much harder than building something purpose specific
• the many "terminal" contexts that may need to be debugged would seem to benefit from using some code that has already been battle tested in many of these contexts - but also, long term resolution of any issues will take the same product ownership will that Microsoft is successfully exercising over OpenSSH.

[JaminShanti]

I’ll let you do the solutioning, I will describe what I need. I need some way, with the default OS, to edit non-binary files of a significant size in a powershell session.

Update: happy to see tar and curl. More binaries inbound!

[joeyaiello]

I think this is still very important, but we're closing as we think this is more something that should happen from within Windows as opposed to PowerShell.

[vexx32]

@joeyaiello wonder if it's worth reaching out to the Notepad team to see if they're game to add in a command-line version. They are always adding odd new features to that little app, after all! 😄

[SteveL-MSFT]

@vexx32 see https://twitter.com/richturn_ms/status/1104438712119640064