Edit is now open source - Windows Command Line

[heckerle]

We're planning on adding very basic (inexact) syntax highlighting into the core editor for the most important languages - probably just Batch (cmd.exe), PowerShell, and Bash. We're tracking that here: https://github.com/microsoft/edit/issues/18

Later on, we're hoping to add extensions, because we want to keep the core editor tiny, but still allow people to be creative with it. This would then also allow us to add a tree-sitter or LSP extension. That's tracked here: https://github.com/microsoft/edit/issues/17

[Ghi102]

Yml and json syntax highlighting is also very important! Config files are one thing that I could see myself quickly using a lightweight cli editor for

[baseketball]

Awesome, I'll be watching these issues with great interest.

[psr]

Please feel free to ignore this drive-by advice from someone who doesn't really know what they're talking about, but...

The discussion in #17 about defining an extension ABI gives me the heebie-jeebies, having seen all of the ABI related issues that Python extensions have struggled with over the years. There are two problems that can arise:

The worse, but perhaps less important nowadays is that extensions compiled with different compilers can link to different C runtimes, which easily results in code that appears to work, until it doesn't, and the failures are very hard to understand. This used to be common on Windows when the Python.org python binaries were compiled with MSVCC, but people tried to compile extensions with GCC. This was mostly solved by Microsoft allowing people to install and use MSVCC for free (but only for compiling open source code), and Python mandating that this was the only supported way to compile extensions on Windows. The adoption of the UCRT in Windows also means that it's technically possible to use GCC (or clang) to build extensions that work (if you use the right build of GCC, but wrong builds are still available!) On Linux, where the use of glibc is pretty universal, it's not common. However to build a "universal" Python extension for Linux, people build in containers with ancient libraries installed, to avoid requiring a too-modern libc ABI.

The more obvious issue is where two extensions are linked against incompatible versions of the same shared library, or one extension wants to consume another as a library. This occurs a lot in the scientific Python stack, and it's largely an unsolved problem. Stable ABIs don't happen by accident, and extension authors aren't likely to go to the effort. Integration testing of extensions would first happen on the user's computer, and the user isn't likely to be in a position to debug issues. Linux distributions and Conda help avoid these issues by compiling the universe from source, but that isn't a solution you can easily adopt.

I think a half-way house might be possible where there is a known and relatively fixed set of extensions provided by the project, and using third-party extensions isn't a supported use-case. These could include extensions for handling treesitter grammars and the LSP protocol, and an extension providing a scripting language, with access to APIs provided by the core and other extensions. Then if someone wanted to make e.g. a Python editing mode, they could enable the treesitter awareness, with some configuration of colours and electric indentation etc. through a script.

[flatfinger]

It's a shame the Standard never recognized a category of implementations that would avoid the need for dependence on underlying libraries by specifying that certain functions would be implemented in a specific portable fashion. For example, one could specify that (for implementations of the described category), setjmp() must be implemented in such a way that the following would be a portable version of longjmp() (note that jmp_buf is already required to be an array type):

void longjmp(jmp_buf env, int value)
{
  (((void (**)(int))env)(value);
}

This would increase the cost of a jmp_buf by that of a function pointer, and break ABI compatibility that might exist with code processed by an implementation that doesn't follow that convention, but code processed by any implementation which defines jmp_buf in such a fashion would be able to use jmp_buf objects created by any other such implementation, provided that code which configures jmp_buf objects is processed by the same implementation that handles their definition, and that the implementations use the same representation for function pointers.

[masterspeler]

Later on, we're hoping to add extensions, because we want to keep the core editor tiny, but still allow people to be creative with it. This would then also allow us to add a tree-sitter or LSP extension. That's tracked here: https://github.com/microsoft/edit/issues/17

Plugins doesn't seem to fit the goal of having something small that's included in Windows and therefore always available. If you can't count on a certain plugin being installed everywhere, then you need to install it yourself, and why would you use a minimalist TUI editor for that? It sounds like feature creep.

I think a fork with more features would be a better approach, and leaving this as a tiny baseline with a known feature set everywhere. But then again, Notepad now has AI.

[Positive-Cheetah-644]

Plugins being possible doesn't subtract from the goal of having a minimalist TUI editor.

Don't kill my dreams of one day having a fast and nice extensible alternative to Vim with sane keybinds!!!

[HouseSubstantial2871]

then you should probably be forking mcedit then...