← Back to context

Comment by arghwhat

1 year ago

Yay for finally having a default text editor that works over ssh. Managing windows servers over ssh is a bit of a pain without.

They could just have packaged nano, but oh well.

48 comments

arghwhat

Reply
p4bl0  1 year ago

I wholeheartedly agreee. Nano is quite awesome, it is battle-tested and already has more features than needed for a basic text editor. Actually, Nano is too often frowned upon as too-basic, but is actually has a few advanced features that basic editors do not have (e.g., keyboard macros). I'd argue that Nano is simple rather than basic :).

I tried discussing it here a few months ago but it did not took off: https://news.ycombinator.com/item?id=41289773

  • Sammi  1 year ago

    I love nano and used it as my terminal editor on Linux.

    Edit seems super approachable to newbies with it's mouse support in the menus. I love that and would love to see it in nano.

red_admiral  1 year ago

I was about to say, I use nano regularly, both locally and over ssh (to machines which have it installed, which is pretty much all of them). This looks nice and I love old-style console UIs, I fondly remember EDIT.COM and NC.EXE, and still use `mc` regularly with one pane pointing at a sshfs.

Ages ago I had to maintain a .BAT file, editing in EDIT.COM, that threw stuff at EDLIN.COM (roughly MS version of `ed`). Those where the ... not-so-good old days.

These days, with windows versions of `nano` and `busybox` you have some power tools without a full linux install.

zozbot234  1 year ago

This could be a great text-mode IDE with the addition of some LSP, tree-sitter and DAP support. There is already an open issue about possibly adding support for tree-sitter grammars for fast syntax highlighting, but they do mention that this requires some sort of optional plugin system to avoid bloating up the codebase severely (for example, the tree-sitter grammars within the Helix editor take up hundreds of megabytes, which is obviously unacceptable here).

6c696e7578  1 year ago

I am truly behind the times. I didn't know you can ssh into a Windows system.

yjftsjthsd-h  1 year ago

Ah, that makes sense then; I was really confused at first because I couldn't figure out why Windows would want a built-in text-mode editor. I suppose if folks are seriously using SSH to access Windows machines ... then I have other questions about why not RDP, but if that's a real thing people are doing then adding a built-in editor for them makes sense.

  • arghwhat  1 year ago

    SSH is ubiquitous, lightweight, and now works for all machines equally.

    SSH is integrated with everything and can be used to manage, transfer files/mount remote folders, forward ports in either direction, or proxy any network traffic through the remote end for debugging/access. You can open a remote folder directly in vscode, Zed or similar over SSH.

    RDP to a standard Windows server (this was previously called "core" - having a desktop environment is a non-default add-on now) is silly as you're RDP'ing to solely see a cmd.exe window that asks you to use console-based configuration (sconfig.exe).

    RDP to a windows server with "Desktop Experience" is silly because it is comparatively sluggish, streaming a (likely unaccelerated) video feed of heavier GUI applications vs. sending just a few text strings back and forth during editing.

    Not to mention that containerized windows has no graphical stack and requires a text-centric workflow.

  • luma  1 year ago

    This might be the most obvious use case: https://learn.microsoft.com/en-us/windows-server/administrat...

    I'm a powershell bigot and spend most of my windows admin life in a terminal (or vscode) so my take is to simply use psremoting but ssh is there if you need.

    • arghwhat  1 year ago

      I prefer SSH because it fits into a standard workflow with far larger ecosystem (my file manager and editors can browse SSH directly, traffic can easily be routed over SSH in either direction), and is already what I'd use for the majority of servers and machines.

      psremoting would be limited specifically to remote PowerShell on windows, which is comparatively limited. Even if I was purely a Windows admin I'd consider the SSH approach more powerful.

      1 reply →

90s_dev  1 year ago

Or kilo[1]

[0]: https://github.com/antirez/kilo/

  • bpshaver  1 year ago

    Or Micro[0]

    [0]: https://github.com/zyedidia/micro

    • jftuga  1 year ago

      Micro is nice because it is a single-file, stand-alone executable that has mouse support, macro record/playback and syntax highlighting. (I haven't checked Nano recently). It is great for making quick edits to json configs, shell scripts, python scripts, etc. Syntax highlighting and line numbering are key. If I need to make a really quick edit, it is much faster to use this than waiting for VS Code or PyCharm to load. You also stay focused. By this I mean, your eyes don't leave the terminal window that you are currently working in. This allows me to more quickly complete the task at hand.

rendaw  1 year ago

I was impressed that they actually looked at other editors in the ecosystem, I wasn't expecting that. Aside from WSL stuff does Windows distribute any other 3rd party utilities?

TZubiri  1 year ago

It's such a simple program that it's better to roll a proprietary program that is well integrated with windows

You can use nano over wsl if you want

  • arghwhat  1 year ago

    > You can use nano over wsl if you want

    No, not when ssh'ing to a server to manage it. Pulling in a Linux VM to get a simple text editor also makes no sense.

    There is also nothing to integrate - it's a basic text editor for a terminal with no fancy features. It either edits text or it doesn't.

    • TZubiri  1 year ago

      you gotta make sure that hotkeys get passed in every keyboard configuration. Ctrl, CTRL Shift, Ctrl Caps, Alt, how do tabs work? Etc..

      That something looks simple but is actually difficult is an error we all make

      2 replies →

niutech  1 year ago

They could've just shipped YEdit, which is open source: http://www.malsmith.net/edit/ but there is NIH syndrome in MS.

  • zadjii  1 year ago

    Yedit actually was written by a Microsoft employee :P

    It had some problems however with handling unicode (iirc). Basically, shipping yedit would have required a huge re-write of its underlying text buffer. In the end the discussions we had with Malcom concluded that just writing a new one was probably easier and more maintainable in the long run.

lysace  1 year ago

Now that they have a text editor that can be used in a terminal:

Calling it: 2025 will be the year of Windows on the server. /s

  • dijit  1 year ago

    Aside from Windows being... "windows" (IE; graphical) and the whole "we will do our own paradigm for nearly everything including file paths (UUNC included) and encoding..." Windows is actually pretty stellar if you're writing high performance software.

    You can go really far with IOCP and it's so nice to write compared to the contemporary kqueue (BSD) or epoll. I will admit to not trying IO_Uring myself though.

    Also the Windows system probes predate any kind of bpf and are easier to use than dtrace.

    This is the maximum amount of love I will ever send in Windows' direction though. Everything else is ball-busting.

  • toast0  1 year ago

    It's not my idea of a good time, but Windows pioneered some stuff that's really handy for servers.

    Receive side scaling[1] is super handy at high volume, and it came from Windows. And Windows has better apis for it than I saw in FreeBSD or Linux when I needed it (I didn't look too closely at Linux though, so maybe it was there).

    [1] https://learn.microsoft.com/en-us/windows-hardware/drivers/n...