11–20 of 337 posts
Earlier quoted context omitted.
That may be the written goal, but I doubt that's the actual reason the project exists.
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'.
Earlier quoted context omitted.
That may be the written goal, but I doubt that's the actual reason the project exists.
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 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.
1. By the author - https://news.ycombinator.com/item?id=44034961 2. Ubuntu Publication - https://news.ycombinator.com/item?id=44306892
And this post.
Fun. I must admit I don't really know who this is for , but it seems fun.
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]
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?
Earlier 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?
--
Earlier 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?
Earlier 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?
What turbo vision brought to the game was movable, (non) modal windows. Basically a lot of rewriting that array in a loop. Pretty snappy. I made a shitload of money with that library.
Earlier quoted context omitted.
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?
Who cares? It’s fun. Programming can be fun.