Default CLI Editor - Feature Exploration!

[plante-msft]

Windows Feature Exploration: Default CLI Text Editor

Please Provide Feedback!

Please let us know what you think about this feature by commenting on this issue! We’d love to hear your ideas and feedback!

Let us know:

• Do you want to see a default CLI editor in Windows? How would it improve your experience?
• Do you use a CLI editor today? If so, which do you use and why?
• Are there alternative solutions or CLI editor-related features you’d like to see?

Overview

This issue is suggesting that Windows should once again ship with a CLI editor installed inbox by default. 32-bit versions of Windows ship with edit, but 64-bit versions of the OS have no CLI editor installed inbox. A CLI editor is a core tool for system admins, developers, and power users – providing an immediate viable option here is an important quality-of-life improvement.

Solution

There are countless available CLI editor options across operating systems today, each with their own sets of advantages and disadvantages. The goal would be to install the selected editor(s) by default such that their commands work out-of-the-box. Example editors include but are not limited to:

• Edit
• Pico
• Nano
• Vim
• Emacs
• etc.

Installing one or more of these editors by default will offer immediate CLI text editor capabilities on all Windows machines, preventing the need for additional installs or workarounds when operating on local machines, remote connections, or Windows containers.

Alternative

Improve error handling such that the shell will recognize editor commands that fail due to missing package and recommend the proper install solution. See below for an example using Vim.

Actual:

Alternative Solution:

[237dmitry]

It’s a pity that Windows doesn’t have edlin or edit or any other console editor out of the box. I think this needs to be fixed.

On Windows I usually use the internal Far editor, much less often the micro editor.
For Linux, respectively, mcedit and also micro (works better than its Windows version)

[deafpolygon]

I would much rather see a modernized version of Edit, rather than bringing it back. This is 2023, almost 2024! A modal take on Nano (similar to vim) would be lovely, but with extensibility in mind (perhaps by supporting PowerShell language for scripting).

[johnlaur]

including exposing API's for community extension/plugin support, available via win-get

total nonsense; ship a basic editor first. It's indeed completely stupid that you can install windows server in a CLI-only configuration and not have the ability to edit a text file on the system.

It wouldn't be very microsoft-y to ship a 3rd party program as their default though that is the obvious fast turn solution. If they end up doing something from scratch, my suggestion would be for them to adapt notepad.exe to have a CLI mode.

[MovGP0]

I think that top bar might be improved. Ie. there might be a switch-mode button on the top left (as well as an keyboard shortcut), that switches what the bar does.

It might provide the [file/edit/search/...] mode, but also switch to an open file tabs mode, an "build and run" mode for development, an version control mode, an search bar mode, and maybe an hidden menu mode, providing more screen estate for the open file(s).

[rhubarb-geek-nz]

I think it is absolutely great that people want a console mode IDE like Turbo Pascal or Microsoft Programmer's Workbench from the 1990s. However the topic is really about a replacement for "edit.com" that was removed. We are in the situation where we can't even edit a ten line configuration file using the console in an emergency. All the features regarding emojis, syntax highlight, auto-complete, multiple files, split-windowing, plugins, git integration, build environments can all be supported by non-default software accessible by downloads or WinGet.

[maclabhruinn]

Well said, @rhubarb-geek-nz - you are spot on!!
The aim of the current project is not to design the most wonderful, feature-packed programmers' text editor imaginable. People can use VSCode, or their own preferred editor, for that.
The aim of the current project is to give the operating system a basic text editor facility, replacing the old edit.com feature which was lost in the move to 64 bit Windows. This would allow administrators to edit configuration files, etc, enough to resurrect a disabled server, or configure a headless server over ssh.

[awakecoding]

I would really like it if we could have an equivalent of nano built-in to Windows. Maybe call it nanopad as an alternative to notepad ;)

[Alaknar]

Micro would be perfect for this. It's like nano but uses Windows shortcuts.

[designatedsuccessor]

If Microsoft can't directly ship nano with Windows, I think Microsoft ought to recreate a program that looks and works suspiciously similar to it and call it edit.exe.

Sidenote: I know this wasn't asked, but I wish this editor could be the start of a bigger project making all the CLI commands/programs in Windows more robust and consistent in behavior.

[BearzRobotics]

There is already a nano.exe built for windows that is a single executable.

https://sourceforge.net/projects/nano-for-windows/files/

[skywind3000]

Nano can't take care of windows line break characters: CR LF

And can't display CJK characters correctly on Windows:

[eggplants]

Try nano-win

[deepankarsharma]

+1 for emacs

[teuben]

For ages I've also use micro-emacs. There was a time I used VMS and Unix on a daily basis, and learned to compile micro-emacs. It also compiled on DOS. Right now Linus Torvalds keeps one in https://github.com/torvalds/uemacs - which is my fallback when I wind up on a system where emacs isn't installed.

[miketheitguy]

Having a VIM port would make all the Linux geeks happy and not constantly lay it on thick to Windows folks.

[skywind3000]

Vim has got official windows daily build: https://github.com/vim/vim-win32-installer

while NeoVim doesn't work very well on windows:

• [windows] duplicated items in v:oldfiles neovim/neovim#25033
• Neovim destroying certain symlinks on windows neovim/neovim#23808
• Pasting from Windows clipboard to Ubuntu WSL terminal freezes nvim neovim/neovim#20396
• vim.fn.stdpath() can return unsupported 8.3 DOS filenames neovim/neovim#25019

NeoVim lacks Windows devs to take care of compatibility issues:

[dertuxmalwieder]

Vim works just well on Windows.

[reynoldsa]

It sure does; I think some opposition to it would come from its esoteric keyboard controls. It's not very familiar to anyone who grew up only using GUIs.

[meshula]

I use nvim all the time on windows, fine as a daily drive. Bugs get fixed.

[boltlessengineer]

Huge neovim lover, but I would like Vim as default terminal editor for Windows.
Too many neovim plugins requires nightly version of neovim these days, making hard to have stable neovim version.
Having Vim as default will be fine. It will gain quite of Windows users in vim community, and they will hopefully contribute to Neovim’s compatibility problems.

[snickler]

+1 for nano. The easiest to use IMO.

[maisondasilva]

+1 nano is simpler

[hnorkowski]

This one is the more modern nano: https://micro-editor.github.io/

[dgellow]

Nano with LSP support and more conventional keybindings would be ideal

[tigerinus]

nano is GPL.
How about pico by U of Washington

[Stanzilla]

Add vim, nano and emacs. they are the top 3 and their file sizes are not too big for that to be an issue. (I did not check if all three have working Windows ports).

Anything else, like only adding one of the three would spark endless discussions on why you picked on over the other.

[darkain]

QB64!?

https://qb64.com/

[AdityaMitra5102]

QB64 just hit my nostalgia hard and idk, now incorporating a text editor like that would be really cool.

For the time being, I just have cygwin installed and I have nano.

[stlee42]

even though it looks like a TUI, it is actually a GUI application that simulates a TUI. You cannot run QB64 in a terminal. ¹

Footnotes

1. https://blogsystem5.substack.com/p/the-ides-we-had-30-years-ago-and] ↩

[tomzorz]

There should be definitely something that's a nano equivalent, to make sure anyone can use it. But it'd be also nice to have something more advanced and standard, e.g. vim

[DHowett]

Honestly, I'm a big fan of @malxau's modernized port of edit. It's quick, it uses a familiar TUI design for Windows users, and by gods is it small.

[miketheitguy]

I like a lot of the lightweight editors. But I think perception and tooling is important. I personally have always preferred nano on Linux. But I'm an outlier and a Windows guy. The Linux first folks I know are more vim/emacs oriented. With at least in my circles vim being way more popular.

I think vi/vim is included by default on nearly every Unix distribution. I think it's a good idea to keep with history in these interactive shell scenarios. Even if I'd personally think nano would work for 90% of the issues (same with edit, for that matter).

[237dmitry]

modernized port of edit

Could you share its github url? I could not find.

PS. I found it, Yedit, on this page

[nunix]

haha, just posted it on X too, take Edit and apply some charm.sh for some nice modernized TUI components

[healeyio]

Having any command line text editor reliably available out of the box on every windows system would be appreciated. But the right answer is vim.

[Alaknar]

The "right" answer?

Anyone who uses vim already has enough knowledge to handle installing and configuring it on their own. For the remaining 90% of the population it would be useless.

Things like nano or especially micro would be much better because there's zero learning curve.

[jdrch]

Agreed. vi, vim, and their derivatives are extremely painful to use.

[rmcnew]

"Agreed. vi, vim, and their derivatives are extremely painful to use."

Only if you don't know how to use them.

The vi / vim style of editing is logical and powerful, but does take some effort to learn and understand:

https://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118

Plugins for vim style input exist for most IDEs because it works:

https://stackoverflow.com/questions/700186/text-editors-with-vim-mode/34957851#34957851

[jdrch]

some effort to learn and understand:

Effort well spent if you're a programmer, but very inefficient if you're a non-programmer user just trying to edit a simple .conf file every now and then.

[christian-korneck]

I think vi/vim is the defacto default that you even find on the CLI of appliances with a proprietary OS and most "IT pros" are familiar with it, even if it's not their default editor of choice.

So I think you should consider shipping at least vim. In an ideal world I'd wish for nano, vim, emacs to be available.

Regarding vim, it would be nice if it came preconfigured with some sane defaults for windows, i.e. yanking to the windows clipboard, etc.

[skywind3000]

I have made a vi-clone for Windows CLI, it is only 62KB and can run in a local terminal or via a ssh session:

even on windows7 and xp:

repo:

• https://github.com/skywind3000/zvi

[essentialexch]

Based on BusyBox, yes? Then it's GPL'ed and not UTF-8 compatible...

[christian-korneck]

thanks. I have been using the official vim windows version for years and it is very mature. Even though it is a lot larger compared to your busybox approach. I think there would be massive benefits from vim (or some other CLI editor) being preinstalled ootb. Especially because ssh'ing or powershell remoting into windows boxes has become a common thing.

[grawity]

The Micro editor seems like a good candidate: It feels more modern than nano, with hi-color support and the same basic keyboard shortcuts as Windows does (such as Ctrl-C to copy or Ctrl-S to save, unlike nano's arcane hotkeys)... and, well, also the name.

Either way, it should be a relatively basic notepad-clone, not just because Editor Wars but also because of the update schedule – bundling Vim wouldn't just annoy Emacs users, it'd also annoy Vim users who will want a more up-to-date version of Vim because the inbox one will inevitably end up being two years old...

[miketheitguy]

Sure. But that bundling problem can be solved with oneget. So as long as the port is maintained.

[csdibiase]

I end up installing some version of micro on all the windows boxes I should time on. It's simple and light and exactly what I need from a CLI editor

[jdrch]

Sure. But that bundling problem can be solved with oneget. So as long as the port is maintained.

Oneget is no longer maintained.

[andrewtchilds]

Which editor most closely matches Windows’ native keyboard shortcuts for text editing? Whichever one that is has my vote.

[Alaknar]

That would be Micro.

[snickler]

The more I look at the comments and ponder, I have to ask: Who is the target audience for this feature? Windows users? Or Linux users?

[miketheitguy]

I'd say the target use case is remote ssh access to windows. This is a very big gap right now on Windows Server and results in either having to remotely map a cifs share, upload a pre-edited file via copy-item -ToPSSession, or remotely RDPing into the box and firing up notepad.

I'm merely saying that for most use cases this is already solved. I personally use nano, but there are great many folks that reflexively use vi/vim and call it a day. Those tools won the "default" war ages ago on *nix platforms. vi, for example, is on my ubiquiti edgerouter and not nano. (I did install nano later).

Nonetheless, the only real problem is maintenance of the releases. And if the maintenance of OpenSSH is any indication, Microsoft doesn't have a good track record here. (Perpetual beta release ftw).

[zcobol]

https://nano-editor.org/dist/v2.5/NT/

[17castlest]

How about Tilde?

https://github.com/gphalkes/tilde and https://os.ghalkes.nl/tilde/

This uses the common Windows keyboard shortcuts so should be easy for any windows CLI user to adapt to. For me, it has replaced vi as my go-to editor on Linux.

[chrissolo92]

Tilde, like vim and nano, is licensed under the GPL(3) license, and therefore cannot be pre-installed as part of Windows. Editors with MIT or other truly free licenses would be better suited for this. Or a completely new development under the MIT license would also be better.

[mixmastamyk]

Looks quite cool but there is no Windows build currently. I think that disqualifies it for now.

[maclabhruinn]

This is what we had; what we lost; and what we need again - in a native 64-bit implementation:

[cos1110]

This is exactly the ideal editor that Windows needs.

Though other programmers want the VIM approach. This is legit as well, but the point is that they have lots of great open source choices already.

Unfortunately there is no other choice related to that simple terminal based text editor.

[ejaquay]

According to Microsoft third party notices the Microsoft Edge Browser contains the GNU Bison Parser which is GPL. Vi versions 1.1 and later are actually BSD. If a vi clone is the choice I would rather it be not be Vim but instead a minimalist clone of vi. Key is keep is simple and very light weight.

…

On Mon, Jan 1, 2024, 9:02 AM chrissolo92 ***@***.***> wrote: Tilde, like vim and nano, is licensed under the GPL(3) license, and therefore cannot be pre-installed as part of Windows. Editors with MIT or other truly free licenses would be better suited for this. Or a completely new development under the MIT license would also be better. — Reply to this email directly, view it on GitHub <#16440 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFIUKNHSBIWAR5MUJL72O6TYMK6ZBAVCNFSM6AAAAABALVNE4KVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TSOBXGQ3TG> . You are receiving this because you commented.Message ID: ***@***.***>

[ishepherd]

👀

When they say "made by GNU Bison 2.4.2". does that get them out from a GPL violation?

(And if so why do they even need Bison's license notice?)

---

[essentialexch]

It's not a GPL violation. GNU Bison allows for the parser generated by the tool to be included in non-free software.

https://www.gnu.org/software/bison/manual/html_node/Conditions.html

The parser does have certain notification requirements - which they are meeting by including that statement.

The Bison Parser is a very narrow carve-out.

[oising]

I wish people would stop wasting space posting a preference for vi/vim/neovim/emacs and other extremely opinionated editors. It's just not going to happen.

[mixmastamyk]

It does not disqualify micro, which is a CUA editor sans menu.

Opinionated is not the right description either, they merely have an interface developed before PC standardization in the mid 80s.

[maclabhruinn]

which is a CUA editor sans menu

You might need to go back and re-read the CUA specification (IBM document SC26-4351) because menus are an integral part of CUA. Just having CUA style key bindings doesn't make it a CUA app. And why should we settle for a Windows system editor which doesn't have menus? Menus are one of the most common elements in the 'Windows, Icons, Menus, Pointer' (WIMP) design pattern. A system editor in Windows should be immediately familiar and usable for anyone whose dominant experience is in using Windows.

[mixmastamyk]

In terms of importance, standard key bindings are very important. A visible menu? I'd list that very low on the list of priorities. Others might disagree.

In my own post I recommended micro and yedit. Both are good enough and ready to go.

[rhubarb-geek-nz]

A visible menu? I'd list that very low on the list of priorities.

The idea of CUA is that every program works the same, all show menus, all show consistent dialogs, all use the same keyboard mappings. That way there are no surprising behaviours and you don't have to remember anything because the menus tell you what you can do. The accelerator keys were for advanced users, they were not intended to be the only way to do something.

There is nothing worse than a text editor which gives you no clue how to use it, such as vi. That might have been state of the art in 1976 but standards have moved on from then. Even for seasoned users, having a menu gives you confidence that you can confirm how to do something and know what options are available, especially when you are in the middle of a stressful edit of a vital configuration file and want to simply copy a few lines.

[maclabhruinn]

A visible menu? I'd list that very low on the list of priorities.

A lot of posters here overlook the fact they are NOT the target audience for this feature.

An editor which is built-in to Windows needs to work as much as possible like a regular Windows application, so it can be quickly and easily used by ANY Windows user, at any level of knowledge and experience. We should not be targeting only developers and administrators with 20 years experience on Linux, who use and prefer editors which don't work like regular Windows applications.

Sure, experienced developers and admins can easily move back and forth between Windows, Linux, Mac OS, and vim, nano, micro etc. What about the juniour admin who has been assigned a ticket to resurrect a dead Windows server at 2:00am? We must absolutely avoid forcing them to get onto Stack Exchange in the middle of this task, so they can figure out how to save a file, or exit the editor. They need an editor that just does the job with the absolute minimum of fuss. Like the old 'edit' command, for example ...

If the default system editor has menus, that won't block an experienced dev or admin who knows vim. They'll still be able to use the editor. No vim user ever looked at a File menu and wondered "hey, what does this 'Exit' option do???"

The obverse is not true: a novice user with only experience of Windows applications cannot easily work out how to use an editor without menus, because menus is the user interface idiom to which they are highly accustomed.

Yedit is nice, I guess it depends if Malcolm Smith wants to hand over his code to Microsoft. Since Malcolm is ex-Microsoft himself, there could be all kinds of, uh, emotional issues there .

[malxau-msft]

Yedit is nice, I guess it depends if Malcolm Smith wants to hand over his code to Microsoft. Since Malcolm is ex-Microsoft himself, there could be all kinds of, uh, emotional issues there .

Whoa. For the record:

1. As far as I know, I still work for Microsoft. Please let me know if you have any news I should be aware of. I am on the opposite side of the company though, so what's happening here doesn't really relate to my day job.
2. I don't have any emotional involvement about which editor to include. I'm reading all of the comments here daily, thinking about all of them, and trying to not push the discussion in any direction. I do passionately believe Windows should include a TUI text editor, and will actively work with and support anyone trying to make that happen, regardless of the editor or editors chosen. (For context, I use vim as a programmer's editor, including at work, have used Microsoft's matching funds to donate to Bram's requested charity, and have contributed to the Windows port of elvis. Yedit's source code includes vim footer tags to define indentation.)
3. My tools are licensed under MIT because when I started, Microsoft had a policy that employee open source projects should be. I always assumed this was done specifically to ensure Microsoft could use employee open source code, even if employees leave with, uh, emotional issues. That always seemed logical and ethical to me.

[maclabhruinn]

10,000 apologies, Malcolm! I stupidly misunderstood a comment from a while ago on the Old Timers group. I'm very glad you haven't been RIF'ed :-) Unlike myself.

Yedit is close to a perfect solution, here. I guess it would depend on whether MS want to leverage your code, or develop new code, in-house, from scratch. Obviously I don't have any visibility of that any more, since MS and I parted ways.

As I remarked above in this thread, I used vim for several years, sent money multiple times to ICCF, and I received a couple of nice emails form Bram, thanking me for my donations. So in general terms, I'm quite a vim fanboi. But I don't think any vi-like editor would be a good solution as the default text-mode system editor in Windows. Such an editor should be "Windows-like", not drawn from other UI paradigms.

[skywind3000]

If yedit can fix CJK characters display errors, it will be perfect:

[plante-msft]

Thank you so much to everyone for engaging with this feature exploration! Your passion has generated a ton of excitement in our own team, and I’m happy to share our proposed direction, which is that we will work with Malcolm Smith (malxau), the maintainer of Yedit, to ship Edit in Windows! We plan to do this by forking the Yedit code to a new OSS repo on GitHub, under Microsoft (like terminal or powertoys).

Why this direction?

• We do not want to interfere with Yori / Yedit and the platforms and users it supports, and there are certain changes we need to implement before a version can be shipped in Windows including:
  • CJK + Emoji support.
  • Localization support.
• Top pieces of feedback that helped shape our decision:
  • The editor should have intuitive and “Windows-like” feel.
  • The editor should be lightweight.
  • And honestly, the surprising but welcome amount of love for Edit!

What about your favorite editor such as Vim or Emacs?

• We will continue to investigate ways to get users their favorite tools without additional download/install actions, but at this time we wanted to prioritize a lightweight and simple solution to satisfy basic use cases across Windows.
• The PowerToys team has shipped Command Not Found as part of PowerToys as an example of improved error handling to help developers get the tools they need faster – check it out here! Releases · microsoft/PowerToys (github.com)

We will continue to update this thread with more info, including timelines once they are ironed out, but I promised more info early in the new year so we’re doing our best to get it to you 😊. Again, I cannot thank everyone enough for the feedback and energy around this feature.

[jwarwick-bry]

The idea of being able to pretty much out-of-the-box do something like this:

  enter-pssession -computername webapp01.contoso.com
  cd \apps\webapp1
  edit appsettings.json
    <<alter some configuration parameter, save>>
  Restart-Service "webapp1" 

is appealing. Is there a possibility of some kind of auto-detecting special non-terminal mode that would allow for simple text editing over enter-psession? Or is that just too single-line oriented to work?

[rhubarb-geek-nz]

You could do that with a standard SSH session.

PowerShell is really not designed for streaming byte data as used by interactive text editors, it really is request/response. The PowerShell pipelines are nothing like the bidirectional byte streams used for terminals..
You might be able to do an equivalent of edlin, but I don't know if the session concept of pssession is robust enough to manage an editor session.

[oising]

This would require a line editor, like edlin. There is no terminal emulation using psremoting. It's completely custom.

[skywind3000]

any update? roadmap? @plante-msft , could you please share more information about it?

[chrispollitt]

Love to get an update!

[onemannoplan]

Why not ship with multiple? There's no reason you can't have a terminal version of notepad (maybe nano?) and something more advanced like Neovim and something that wants to be everything and not extensible like the Amp editor written in Rust.

[maclabhruinn]

'Something more advanced' is fine, if the user wants it. But there's no reason to include it in the base Windows installation.

Among other problems, the basic Windows image is already bloated with a tonne of semi-superfluous stuff which (a) increases the attack surface and (b) takes up disk space. We don't want to compound that, with even more unnecessary stuff. That's okay for a user running Windows on their own laptop, but it's a pain in the bum for spinning up VMs and containers, in the data centre.

If you want neovim or amp, just download and install them, same as today.

The requirement here was for a character text editor to replace the missing edit.com, which existed in 32-bit Windows. Edit.com was a very basic editor, but it was ALWAYS available, even when there was not GUI and no Internet connectivity.

The requirement wasn't to provide a general purpose programmers editor, for people who happened to prefer editing in a terminal window. That requirement is already well-catered for, with many existing and easily-installed options.

[rhubarb-geek-nz]

There's no reason you can't have a terminal version of notepad (maybe nano?)

That is what the Yedit fork will provide.

and something more advanced like Neovim

WinGet for anything else.

[ElijahTailor]

I use
bash -c "nano file.txt"
Missing a built-in text editor, or even a bunch of them with an ability to choose the default one, like vi, vim, nano and launch them by "edit" command.

[ejaquay]

Menus are terminal dependant. You can not expect a remote terminal to support an extensive set of control codes. Even cursor positioning can be difficult under these circumstances.

…

On Tue, Jan 2, 2024, 5:42 PM Andrew McLaren ***@***.***> wrote: which is a CUA editor sans menu You might need to go back and re-read the CUA specification (IBM document SC26-4351) because menus are an integral part of CUA. Just having CUA style key bindings doesn't make it a CUA app. And why should we settle for a Windows system editor which doesn't have menus? Menus are one of the most common elements in the 'Windows, Icons, Menus, Pointer' (WIMP) design pattern. A system editor in Windows should be immediately familiar and usable for anyone whose dominant experience is in using Windows. — Reply to this email directly, view it on GitHub <#16440 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFIUKNGBYFJDAFWC7IVZCODYMSELXAVCNFSM6AAAAABALVNE4KVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TSOJXGQ3TI> . You are receiving this because you commented.Message ID: ***@***.***>

[skywind3000]

Not a problem, a lot of terminal editors have got menus:

yedit, turbo, mcedit

[tidux]

This is what termcap, terminfo, and libraries like curses are for, allowing developers to write TUI applications without hardcoding a specific terminal. Obviously it shouldn't depend on any features not available in Windows Terminal, but Windows Terminal supports enough for an Edit clone.

[ricje]

I personally use a win64 build of Neovim from the windows terminal and love it! Thinking about it, I would definitely not mind having a terminal version of vscode but, anything less powerful than those would not be used at all by me.

[skywind3000]

@plante-msft , any update for this? can't wait to try the new CLI editor.

[mcexit]

I'm really not keen on the idea of shipping a "recreation of the MS-DOS 5 editor" with modern Windows.

The current details about It would be fine as an "easter egg" for those that want a nostalgia feel to reminisce on the past, but it is a terrible proposal. Trying to even find information about the editor leads me to a non-SSL site from the 90s, and then mentions it is part of Yori on GitHub, where the author complains about GitHub enforcing 2FA. Why on earth would users want to use a MS-DOS editor in this time and age? I seriously doubt Microsoft can fork, modernize and maintain their own text editor to compete with the likes of those that users actually want to use like Neovim, Helix, Kakoune,

Why not just pick one of those, Helix being my favorite, and do what normal people and companies do and include attribution/disclosures with Windows?

[mcexit]

It doesn't have to compete with anything because you are already free to install whatever text editor you like.

I've read this thread and it is pointless to include a "recreation of the MS-DOS 5 editor" in modern Windows then. The whole point was to have an editor that users actually want to use. Is it really that hard to compare YEdit/ vs Helix¹/Neovim²/Micro³/etc. and see for yourself?

Like I said, do you want a CLI editor users actually want, or an easter egg that brings you nostalgia?

Footnotes

1. https://github.com/helix-editor/helix ↩

2. https://github.com/neovim/neovim ↩

3. https://github.com/zyedidia/micro ↩

[maclabhruinn]

The use case here isn't to provide a programmers' editor, which people might like to use to edit code or other complex text-processing tasks.

The use case is to provide a minimally viable character mode editor which system administrators etc can use to edit configuration files, perform maintenance tasks, or resurrect a damaged server. Possibly while working in very onerous conditions, like standing up in front of a rack in a darkened data centre at 2:00am on a Sunday morning, while the customer is losing thousands of dollars a minute. In other words, the use case is exactly to replace the 16-bit editor which was available in 32-bit Windows, but is not in 64-bit Windows. For this role, it's important the editor uses mainstream Windows UI idioms, like CUA-style drop down menus and key bindings, modeless operation, etc, so it can immediately be used by anyone. Straight away, that precludes anything in the vi tradition.

For users who really like Vim, or Micro, or Helix, or any other editor, that's fine: you are able to download and install any editor you like. There is no reason for <insert your favourite editor here> to be included in the universal base image of Windows.

[jdrch]

The use case here isn't to provide a programmers' editor, which people might like to use to edit code or other complex text-processing tasks.

The use case is to provide a minimally viable character mode editor which system administrators etc can use to edit configuration files, perform maintenance tasks, or resurrect a damaged server. Possibly while working in very onerous conditions, like standing up in front of a rack in a darkened data centre at 2:00am on a Sunday morning, while the customer is losing thousands of dollars a minute. In other words, the use case is exactly to replace the 16-bit editor which was available in 32-bit Windows, but is not in 64-bit Windows. For this role, it's important the editor uses mainstream Windows UI idioms, like CUA-style drop down menus and key bindings, modeless operation, etc, so it can immediately be used by anyone. Straight away, that precludes anything in the vi tradition.

For users who really like Vim, or Micro, or Helix, or any other editor, that's fine: you are able to download and install any editor you like. There is no reason for <insert your favourite editor here> to be included in the universal base image of Windows.

Appreciate you explaining this for like the 100th time. Amazing people claim to have "read" the thread and then hop in suggesting Helix 🤡

[razielanarki]

so... when will we have one? 🙊👼

[naikrovek]

I've read this thread and it is pointless to include a "recreation of the MS-DOS 5 editor" in modern Windows then. The whole point was to have an editor that users actually want to use.

No! It isn't! The point is to have an editor that you can use when you need a console text editor and you don't already have something else installed. Like with a Windows container.

If you want [your favorite editor] then install it. This is for people who are fine with "terminal notepad" and they don't want to worry about keeping their favorite editor updated. Microsoft will maintain this and you won't need to worry about it.

This is not anyone wanting to crap on your favorite editor, this is Microsoft wanting people to be able to edit files in the console/terminal without needing to install a 3rd party editor first.

You say you read the thread, but I'm not sure you did. To be fair there are many distinct threads here and many people seem to be missing an understanding of what was asked.

[tidux]

As a feature request, can we make sure the editor can read from stdin as a file? Something like this would be good: PS C:\> appcmd list site | ConvertFrom-XML | filtering_step_goes_here | edit.exe - I know for IIS users in particular the ability to have a proper editor to wrangle config files would help avoid the need for enabling the full Desktop Experience on Windows Server, which can help pack cloud instances a little tighter to save money.

…

-- ***@***.*** SDF Public Access UNIX System - http://sdf.org

[maclabhruinn]

Yep - editing config files on a headless IIS server is exactly the kind of use case they are looking at, for this project.

I kind of like the idea of the editor accepting input from stdin. But @rhubarb-geek-nz is correct: this could be a bit difficult to get right, in PowerShell. The PowerShell pipeline passes objects, not a raw byte stream like the pipeline in CMD.exe. For maximum versatility the editor would want to accept a byte stream from stdin; and PowerShell users might have to add some kind of RedirectStdInput operator to caste the PowerShell pipeline output into a byte stream, not an object. Sorry, I haven't checked what the exact syntax would be in PowerShell; would have to futz around with it for a while.

[rhubarb-geek-nz]

This is one of those features where it increases complexity for a very minor use case that never existed in the original edit.com. Both the keyboard input and the file come from stdin. So when does the file end and the human input begin? So now you have to change to using the "controlling terminal" for keyboard input rather than stdin, in the case of Windows using the special device "CON:" or /dev/tty on UNIX based systems. If you want to do this, use some existing vi port. I hope the editor we are talking about keeps to the basics and stays simple. I hope the priority would be for an editor that works well over an SSH session rather than trying to get it to work in a powershell pipeline.

[maclabhruinn]

Yep, agree ... probably why I said "I kind of like the idea" :-)

It Would Be Nice™ ... but as you correctly note, simplicity and speed of actually delivering the solution are the top priorities.

[tidux]

So when does the file end and the human input begin?

The whole file is read, the pipe is closed, stdin goes away and then reattaches to CON, and then window drawing starts? This doesn't seem that hard, at least for a proper terminal. If cmd/conhost has some bug that prevents this from working it should be fixed.

[rhubarb-geek-nz]

This doesn't seem that hard, at least for a proper terminal.

It isn't so much as a "can it be done" as a "should it be done". Yes it could be implemented there are no technical barriers except effort, increasing complexity and additional maintenance. But adding such a feature goes against the goals of "like for like replacement", "keep it simple", "do one thing well", "stick with CUA UI principles" and "not having modes".

[malxau]

Tidux, can you explain more about when you’d want to read from stdin? Is this to modify the output, or is this to browse and search the output? Personally I think there’s an interesting observation here. The version of `more` in Windows is…uhh, minimal. If there was a version of more that added capabilities for searching, navigating, copying, saving, etc, would it make sense to use CUA? If it did make sense to CUA, is it really a distinct tool? There’s a whole lot of secondary observations too. As others have been saying, Powershell objects are not text. If the goal was to interactively navigate Powershell output, and output consisted of objects with reflection, maybe the best tool isn’t a text tool at all. Also, there may be good reasons for an editor to load files asynchronously anyway (to ensure a responsive UI), but if they did that, they’d be well on the way to being a substitute for `more`.

[rhubarb-geek-nz]

To demonstrate the principle of "doing one thing well", here is a simple example of doing less in a Visual Basic Script that can be run with cscript.exe. The advantage of that is that you can use less with any editor you want by using an environment variable, just like git.

Dim StdIn, oShell, fso, FileName, TmpFolder, oFile, TmpPath, Command, Editor

Set StdIn = WScript.StdIn
Set oShell = CreateObject("WScript.Shell")
Set fso = CreateObject("Scripting.FileSystemObject")

FileName = fso.GetTempName()
Set TmpFolder = fso.GetSpecialFolder(2)
Set oFile = TmpFolder.CreateTextFile(FileName)
TmpPath = fso.GetAbsolutePathName(TmpFolder)
Set TmpFolder = Nothing
FileName = TmpPath & "\" & FileName

Do While Not StdIn.AtEndOfStream
	str = StdIn.ReadLine
	oFile.WriteLine str
Loop

oFile.Close
Set oFile = Nothing

Editor = oShell.ExpandEnvironmentStrings("%EDITOR%")
Command = Editor & " " & FileName

oShell.Run Command,1,true
Set oShell = Nothing
fso.DeleteFile FileName
Set fso = Nothing

And wrapped with a batch file

@echo off
cscript /nologo "%~dp0less.vbs"

Then you can happily do

C:\Users\foo>set EDITOR=notepad.exe
C:\Users\foo>dir | less

It would take more to support console editors by opening the special "CONIN$" device, but the point is; do that once in 'less' and then let any editor be used, rather than every editor having to have a special 'less' mode.

[whindsaks]

For bonus points, put the VBS script inside the batch file as a polyglot.

For sadness points, Microsoft is removing VBS/WSH soon.

[rhubarb-geek-nz]

This is a cheap and cheerful less that uses simple Win32 console API, happily works over SSH, even on Window 10 IoT and can be used with any console or GUI editor.

[gr79]

Tidux, can you explain more about when you’d want to read from stdin? Is this to modify the output, or is this to browse and search the output? Personally I think there’s an interesting observation here. The version of more in Windows is…uhh, minimal. [...]

After finally adding sudo and a simple text editor (hopefully soon?), more should be the next candidate for a refresh together with an improved man command for old commands (similar to what PowerShell has done but for legacy commands as well as others).

[rhubarb-geek-nz]

Easter Egg time - this is not the FreeDOS edlin, it was built win32 first. Can be used over SSHD.