lhecker

...huh, true. It's weird what kind of mistakes one can do sometimes. This one was almost comically on the nose.

Yup! echo is a CMD builtin and doesn't exist as a dedicated executable.

I apologize for asking, but did you also understood the "Shell conflicts" section as being the complete list of utilities? The project ships the majority of core utilities (~75%).

lhecker

2 ay öncediscuss

Any command not listed under the "Shell conflicts" section is included. In my testing `ln` works great.

lhecker

2 ay öncediscuss

It should work on Windows 10. If you're using PowerShell, you do need to have v7.4 or later installed, however.

lhecker

2 ay öncediscuss

We actually open-sourced DOS sort and published a port of the DOS find command. The suite then dispatches to the GNU/DOS variant based on heuristics. The installer allows you to pick what variant to use by default if the invocation is ambiguous.

lhecker

2 ay öncediscuss

> I would have liked to see head, tail, tr, uniq, and cut.

The project includes all of those. Or were you talking about the past?

lhecker

2 ay öncediscuss

As hex4def6 said, the idea was that DOS command conflicts are not a good idea, while overriding PowerShell builtins in interactive sessions (PSReadLine) is acceptable, if not a good idea. We open-sourced DOS sort and published a port of the DOS find command. The suite then dispatches to the GNU/DOS variant based on heuristics.

lhecker

2 ay öncediscuss

The intent was simply to give people coming from macOS and Linux more of the CLI tools they're familiar with. In other words, agents weren't the focus at all. But if it ends up helping them, that's a good added benefit of course.

lhecker

geçen yıldiscuss

The plan is indeed to make it extensible if time and popularity permits it. LSP would be an extension itself, however, instead of being built into the editor. We want to retain a lean core editor so people can ship it everywhere (e.g. even into small Docker images).

lhecker

geçen yıldiscuss

It's indeed Maple Mono. I love that font!

lhecker

geçen yıldiscuss

That's a fair workaround for my specific example. But I believe it's possible to contrive a different example where such a solution would not be possible. Put differently, I only tried to convey the overall idea of what I think is a shortcoming in Rust at the moment.

Edit: Also, I believe your code would fail my second section, as the `convert` function would have difficulty accepting a `[u8]` slice. Converting `[u8]` to `[MaybeUninit<u8>]` is not safe per se.

lhecker

geçen yıldiscuss

Back then (a year ago?) I simply included the Windows.h header into a Zig file. Is that not possible anymore? It worked great back then for me IIRC!

Overall, I liked the build system. What I found annoying is that I had to manually search for the Windows SDK path in build.zig just so I can addIncludePath it. I needed that so I can add ICU as a dependency.

The only thing that bothered me apart from that was that producing LTO'd, stripped release builds while retaining debug symbols in a separate file was seemingly impossible. This was extra bad for Windows, where conventionally debug information is always kept in a separate file (a PDB). That just didn't work and it'd be great if that was fixed since back then (or in the near term).

lhecker

geçen yıldiscuss

Abstracting away the `assume_init` is a great idea! I think I could use something like that for the editor. The only concern I have is that the `read` function is templated on the parameter type. I'd ideally _really_ prefer it if I didn't need two copies of the same function to switch over `[u8]` and `[MaybeUninit<u8>]` due to different return types. [^1] I guess the approach could be tuned to avoid this?

Personally, I also like the simpler approach overall, compared to the `BorrowedBuf` trait, for the same reasons outlined in the article.

While this possibly solves parts of pain points that I had, what I meant to write is that in an ideal world I could write Rust while mostly not thinking about this issue much, if at all. Even with this approach, I'd still need to decide whether my API needs to take a `[u8]` or a `Buffer`, just in the mere off-chance that a caller may want to pass an uninitialized array further up in the call chain. This then requires making the call path generic for the buffer parameter which may end up duplicating any of the functions along the path, even though that's not really my intention by marking it as `Buffer`.

I think if there was a way to modify Rust so we can boldly state in writing "You may cast a `[MaybeUninit<T>]` into a `[T]` and pass it into a call _if_ you're absolutely certain that nothing reads from the slice", it would already go a long way. It may not make this more comfortable yet, but it would definitely take off a large part of my worries when writing such unsafe casts. That's basically what I meant with "occupy my mind": It's not that I wouldn't think about it at all, rather it just wouldn't be a larger concern for me anymore, for code where I know for sure that this requirement is fulfilled (i.e. similar to how I know it when writing equivalent C code).

Edit: jcranmer's suggestion of write-only references would solve this, I think? https://news.ycombinator.com/item?id=44048450

[^1]: This is of course not a problem for a simple `read` syscall, but may be an issue for more complex functions, e.g. the UTF8 <> UTF16 converter API I suggested elsewhere in this thread, particularly if it's accelerated, the way simdutf is.

lhecker

geçen yıldiscuss

What I meant is that if I write a UTF8 --> UTF16 conversion function for my editor in C I can write

  size_t convert(state_t* state, const void* inp, void* out)

This function now works with both initialized and uninitialized data in practice. It also is transparent over whether the output buffer is an `u8` (a byte buffer to write it out into a `File`) or `u16` (a buffer for then using the UTF16). I've never had to think about whether this doesn't work (in this particular context; let's ignore any alignment concerns for writes into `out` in this example) and I don't recall running into any issues writing such code in a long long time.

If I write the equivalent code in Rust I may write

  fn convert(&mut self, inp: &[u8], out: &mut [MaybeUninit<u8>]) -> usize

The problem is now obvious to me, but at least my intention is clear: "Come here! Give me your uninitialized arrays! I don't care!". But this is not the end of the problem, because writing this code is theoretically unsafe. If you have a `[u8]` slice for `out` you have to convert it to `[MaybeUninit<u8>]`, but then the function could theoretically write uninitialized data and that's UB isn't it? So now I have to think about this problem and write this instead:

  fn convert(&mut self, inp: &[u8], out: &mut [u8]) -> usize

...and that will also be unsafe, because now I have to convert my actual `[MaybeUninit<u8>]` buffer (for file writes) to `[u8]` for calls to this API.

Long story short, this is a problem that occupies my mind when writing in Rust, but not in C. That doesn't mean that C's many unsafeties don't worry me, it just means that this _particular_ problem type described above doesn't come up as an issue in C code that I write.

Edit: Also, what usefulcat said.

lhecker

geçen yıldiscuss

I don't know why, but I'm quite certain it's neither of the two. If anything, it has probably to do with commitment: When a company as large as MS adopts a new language internally, it's like spinning up an entire startup internally, dedicated to developing and supporting just that new language, due to the scale at which things are run across so many engineers and projects.

lhecker

geçen yıldiscuss

I intended for this editor to be cross-platform and didn't want to take on a large runtime dependency that small Docker images or similar may not be willing to bundle.

lhecker

geçen yıldiscuss

I did use Copilot a lot, just not its edit/agent modes. I found that they perform quite poorly on this type of project. What I use primarily is its autocompletion - it genuinely cured my RSI - and sometimes the chat to ask a couple questions.

What you expressed is a sentiment I've seen in quite a few places now. I think people would be shocked to learn how much time I spent on just the editing model (= cursor movement and similar behavior that's unique to this editor = a small part of the app) VS everything else. It's really not all that difficult to write a few FFI abstractions, or a UI framework, compared to that. "Pressure to ship" is definitely true, but it's not like Microsoft is holding a gun to my chest, telling me to complete the editor in 2 months flat. I also consider it important to not neglect one's own progress at becoming more experienced. How would one do that if not by challenging oneself with learning new things, right? Basically, I think I struck a balance that was... "alright".

lhecker

geçen yıldiscuss

What I imagined is that people could load runtimes like node.js as a plugin itself in order to then load plugins written in non-native languages (JavaScript, Lua, etc.; node.js being an extreme example). I wonder if WASM could also be one such "adapter plugin"?

But plugins are still a long way off. Until then, I updated the issue to include your suggestion (thank you for it!): https://github.com/microsoft/edit/issues/17

lhecker

geçen yıldiscuss

Indeed, we have our own bootstrapped Rust toolchain internally. I think this has to do with (legal) certifications, but I'm not entirely sure about that.

Submissions

Microsoft Edit 2.0.0 – A compiler for syntax highlighting

comments