171–180 of 191 posts
Why didn't they make this a package available ia winget? Did it have to be part of the OS?
Could be installed with
winget install Microsoft.EditYay 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.
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?
Hey all! I made this! I really hope you like it and if you don't, please open an issue: https://github.com/microsoft/edit To respond to some of the questions or those parts I personally find interesting: The custom TUI library is so that I can write a plugin model around a C ABI. Existing TUI frameworks that I found and were popular usually didn't map well to plain C. Others were just too large. The arena allocator e…
> Since Zig is not internally supported at Microsoft just yet (chain of trust, etc.) Is there something about Zig in particular that makes this the case, or is it just an internal politics thing?
Hey all! I made this! I really hope you like it and if you don't, please open an issue: https://github.com/microsoft/edit To respond to some of the questions or those parts I personally find interesting: The custom TUI library is so that I can write a plugin model around a C ABI. Existing TUI frameworks that I found and were popular usually didn't map well to plain C. Others were just too large. The arena allocator e…
> So, why not have fun learning something new, writing most things myself? I definitely learned tons working on this, which I can now use in other projects as well. Because presumably you should have been doing it mostly for the benefit of Windows users, and wasting time because it’s a fun personal learning exercise means those users would suffer getting an underpowered app
Earlier quoted context omitted.
Distinguishable from the tool of that name, that came with the operating system (and prior Microsoft ones) for many years, that it is deliberately intended to provide a rough workalike 64-bit replacement for?
If it’s not the same then it’s a bad idea to give it the same name. Imagine searching for a tutorial or a bug fix.
Or command names that are common words like MORE, BREAK, DATE, CALL, IF, MODE, MOVE, PROMPT, SORT, TIME, COPY, and PATH for that matter.
What you are telling us is that the only way that you can think of to look this stuff up is by putting single words into a general-purpose WWW search engine. Instead of the intelligent way of finding the index of a command reference for Microsoft operating systems and looking up the EDIT command there. Microsoft has published its own command reference for decades, and there have been many others, including entire books on commands in Microsoft operating systems, for even longer.
Hey all! I made this! I really hope you like it and if you don't, please open an issue: https://github.com/microsoft/edit To respond to some of the questions or those parts I personally find interesting: The custom TUI library is so that I can write a plugin model around a C ABI. Existing TUI frameworks that I found and were popular usually didn't map well to plain C. Others were just too large. The arena allocator e…
I already expressed my appreciation on the repo, but was promptly shushed by your colleague for Incitement Of A Language War, hehe.
I'm impressed by the architecture and implementation choices, especially the gap buffer and cursor movement. It seems we've independently arrived at the same kinds of conclusions on how to min-max a text editor: minimal concepts with maximal functionality.
Others have asked about Zig. I would love to hear more about the work you did in C. Did you start in C? What are some reasons why you didn't continue with C? If you had continued in C, with hindsight, what would have been most annoying? What was clearly better in C? Again, with hindsight, what would have been the best parts of following through with C? I see that you are C-cultured as well (Chris Wellons' blog) and some of the upsides of Zig that you mention I would have guessed you could have elegantly solved in C using Chris' insights. I'm very curious how with such expert advice available you still sought elsewhere and preferred it. Looking forward to hear about the C-side of the story.
Good luck with the project, and see you on the repo :)
Hey all! I made this! I really hope you like it and if you don't, please open an issue: https://github.com/microsoft/edit To respond to some of the questions or those parts I personally find interesting: The custom TUI library is so that I can write a plugin model around a C ABI. Existing TUI frameworks that I found and were popular usually didn't map well to plain C. Others were just too large. The arena allocator e…
In the Zig version did you use my zigwin32 project or did you go with something else? Also, how did you like the Zig build system vs rusts?
Earlier quoted context omitted.
> What do you like about Zig more than Rust? It's been quite a while now, but: - Great allocator support - Comptime is better than macros - Better interop with C - In the context of the editor, raw byte slices work way better than validated strings (i.e. `str` in Rust) even for things I know are valid UTF8 - Constructing structs with .{} is neat - Try/catch is kind of neat (try blocks in Rust will make this roughly e…
I think files as struct makes lots of sense. As it doesnt have to treat files in any special way then.
i will say the struct files (files which are not a namespace struct.. that is, they have field values) are a bit weird, but at least the syntax is consistent with an implicit surrounding bracket.
Hey all! I made this! I really hope you like it and if you don't, please open an issue: https://github.com/microsoft/edit To respond to some of the questions or those parts I personally find interesting: The custom TUI library is so that I can write a plugin model around a C ABI. Existing TUI frameworks that I found and were popular usually didn't map well to plain C. Others were just too large. The arena allocator e…
The quirkiness of Zig is real. I'd love for Zig to win out but it's just too weird, and it's not progressing in a consistent direction. I can appreciate you falling back to Rust.
I've maintained a project in zig since either 0.4 or 0.5 and i dont think this is the case at all. supporting 0.12 -> 0.13 was no lines of code, iirc, and 0.13->0.14 was just making sure my zig parser could handle the new case feature (that lets you write a duff's device).
zig may seem quirky but it's highly internally consistent, and not far off from C. every difference with c was made for good reasons (e.g. `var x:u8` vs `char x` gives you context free parsing)
i would say my gripes are:
1. losing async
2. not making functions const declarations like javascript (but i get why they want the sugar)
Earlier quoted context omitted.
> So, why not have fun learning something new, writing most things myself? I definitely learned tons working on this, which I can now use in other projects as well. Because presumably you should have been doing it mostly for the benefit of Windows users, and wasting time because it’s a fun personal learning exercise means those users would suffer getting an underpowered app
Fun-shaming a passionate developer who, beyond their job description, delivered an editor that checks all the required boxes (small binary, fast, ssh-support, etc.) in just 4 months, while working on weekends and even Christmas, and calling it "wasting time" is incredibly upsetting. I'm grateful to work with people who value that kind of initiative.
Of course the app doesn't check all boxes, plenty of features other editors have had years to add simply couldn't be added even if you work on Christmas (by the way, is also entirely driven by the NIH decision to write from scratch and not than that doing a 3 language mock)
And I'm not shaming the fun, I'm saying that that's not a good justification for shipping a worse app to the millions in a professional setting