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.

[loosus]

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 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/

[rhubarb-geek-nz]

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.

There is no need for detailed messages about where to install applications from when all you have done is made a typo in your command line, neither should a shell be making any recommendations about what other software to install. At the command line, keep things simple and predictable, Making recommendations about things that it has no knowledge of is the role of ChatGPT.

[HotCakeX]

There is absolutely nothing wrong with making the command line smarter.
Suggesting alternative and related commands is actually very good feature to implement.

[scrutinizer80]

Bring back a proper full traditional TUI editor like good old EDIT, and include one or few of the *nix ones as an extra.
The DOS ecosystem used to have many topnotch full-fledged TUI apps. It's a real shame they're not available natively anymore.

[chrispollitt]

Agreed! It's a shame edit.exe was never ported to a 32-bit version.

[etna]

My two cents:

Windows definitely needs a CLI editor.

And it should be as drop-dead basic as possible. Something like a modern version of the old EDIT will be perfect, or if a little more complexity is desired, something like nano will be more than perfect.

Windows is primarily a GUI-driven OS. For anything more complex than editing a few lines of text, using a graphical text editor like Notepad with a mouse to click and drag-select chunks of text is the way to go and is definitely not the domain of a basic CLI text editor.

I definitely do not want anything like vi or vim in Windows forever. Overly complex with steep learning curves, and more importantly their userbase tends to be some of the most obnoxious kind that really should be kept far away and not be given any opportunities to stoke their egos.

[mixmastamyk]

Definitely should be a CUA-type editor with standard hotkeys, one of:

• Micro
• Yedit - Yori Edit

There should be an alias at least to "edit".

[noinkling]

Anything along the lines of Edit.com, nano (which is what I default to on Linux) or micro is fine, it should be simple and intuitive. The only "modern" feature I'd request is syntax highlighting.

[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.

[plante-msft]

will the new 'edit' ship as as part of the base Windows/WinPE image?

@maclabhruinn adding to @zadjii-msft's response above, our intention is for 'edit' to be provided as consistently as possible across Windows images, but different teams have different requirements and timelines, so it will be a process before we get to that state.

[fluentmoheshwar]

Awesome! <3

[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.

[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: ***@***.***>