Can this be ported to MacOS?
Its pretty easy to build there, I've tried this on MacOS and Linux. The one thing that vexed me for something based on edit, was CTRL+P being hijacked for something that isn't print, is like we forgot about about CUA over the last 15 years.
Microsoft Edit
111–120 of 337 posts
Re: Microsoft Edit
#112Earlier quoted context omitted.
Telling people to use nano would of course have been next to impossible. Much easier to rewrite a DOS-era editor in Rust, naturally.
does nano support mouse usage? It doesn't seem to work for me (but maybe it just needs to be enabled somewhere) I guess they thought that inheriting 25 years of C code was more trouble than designing a new editor from scratch. But you'd have to ask the devs why they decided to go down that route
Yes, but you have to put `set mouse` into your nanorc.
Re: Microsoft Edit
#113Earlier quoted context omitted.
Yeah ... I don't think there's any overlap between "users largely unfamiliar with terminals" who want something easy to use, and 'Linux users who are sufficiently technical that they would even hear about this repo'.
The title is a bit confusing depending how you read it. Edit isn't "for" Linux any more than PowerShell was made for Linux to displace bash, zsh, fish, and so on. Both are just also available with binaries "for" Linux. The previous HN posts which linked to the blog post explaining the tool's background and reason for existing on Windows cover it all a lot better than a random title pointing to the repo.
But.. why?
Re: Microsoft Edit
#114Earlier quoted context omitted.
Telling people to use nano would of course have been next to impossible. Much easier to rewrite a DOS-era editor in Rust, naturally.
micro would have been an even better choice, the UX is impressively close to something like Sublime Text for a TUI, and very comfortable for those not used to modal editors.
Re: Microsoft Edit
#115Geniunely curious, how projects like these get approved in an org at the scale of Microsoft? Is this like a side project by some devs or part of some product roadmap? How did they convince the leadership to spend time on this?
Re: Microsoft Edit
#116I used to recommend micro[1] to people like those in the target audience of this editor. I wonder if that should change or not. -- 1: https://micro-editor.github.io/
There is also dte[1]. It hits exactly the same notch and offers an extremely lean editor with Unicode support, CUA key bindings and much more. It has replaced nano as my terminal editor. [1]: https://craigbarnes.gitlab.io/dte/
Re: Microsoft Edit
#117Re: Microsoft Edit
#118oh, the memories. gorilla.bas :)
Re: Microsoft Edit
#119Earlier quoted context omitted.
There is also dte[1]. It hits exactly the same notch and offers an extremely lean editor with Unicode support, CUA key bindings and much more. It has replaced nano as my terminal editor. [1]: https://craigbarnes.gitlab.io/dte/
Why are you opposed to learning vi which is already installed everywhere?
i know that i can press like 3-4 arbitrary buttons to mark a block to move it to a different place - how about i just mark it with my cursor and CTRL-X CTRL-V, like every freaking other program out there.
i appreciate that i got VI on freshly installed or secured servers, but for things i use daily, i just want it to be KISS. already counting on people answering 'but vim is easy and simple'. opinions differ i guess.
Re: Microsoft Edit
#120Earlier quoted context omitted.
It's for people that want to use the Windows Terminal to edit files. The old `edit` command has been unsupported on Windows since 2006, so there was no Microsoft-provided editor that could be used in the command line since then. It's impressive to see how fast this editor is. https://github.com/microsoft/edit/pull/408 > By writing SIMD routines specific to newline seeking, we can bump that up [to 125GB/s]
Is... this a meaningful benchmark? Who's editing files big enough to benefit from 120GBps throughput in any meaningful way on the regular using an interactive editor rather than just pushing it through a script/tool/throwing it into ETL depending on the size and nature of the data?
As developers, we rotinely need to work with large data sets, may it be gigabytes of logs, csv data, sql dump or what have you.
Not being able to open and edit those files means you cant do your job.