Gui

[Kethku]

I noticed that your website references creating a gui with skia/skulpin. That sounds very similar to my architecture for neovide which is a gui for neovim.

A not broadly stated goal for neovide is to eventually expose the graphical parts as a swappable front end for other text editors such as what helix looks like. I was curious if you are interested in such a collaboration. Getting a gui right is hard work (as I've found out), I think collaborating would be great for both use cases!

Are you planning on exposing a gui protocol ala neovim's? If so what would that look like/what features do you think would be useful for helix that are unique to helix? The editor looks very cool btw!

[archseer]

Hey! The skulpin mention was specifically after I looked at neovide, it seemed like a good fit. @norcalli wanted to experiment on a new frontend as well.

I'm a bit apprehensive on exposing a GUI protocol, they're either too vague and the client needs to re-implement a lot of the handling, or they're very specific and every client ends up the same. I don't have a solid opinion yet so we'll see. Right now the idea is that helix-view would provide most of the logic, and a frontend would just be another crate wrapping everything with a UI -- that needs some work right now though because commands are currently sitting directly in helix-term.

[Kethku]

That makes good sense. One thing thats been on my list for a while is to split neovide into the neovim gui, and a front end renderer so that other apps could build their own rendering. Then you could integrate it as a crate without having to do all the painful font rendering and such. Let me know if something like that would be interesting for your use cases or not. In any case, if you end up going the skia route, I'm happy to help out if you run into problems. Awesome project

[Kethku]

The more I think about it, the more I am interested in trying out something like this. You mentioned that commands are currently located in the helix-term. Are you suggesting that they would need to be moved into helix-view in order for a gui crate to consume and produce them? Are you interested in a PR which attempts that kind of refactoring?

[archseer]

So there's a few sets of changes necessary:

• helix-view needs to be refactored to have it's own generic key/style/color structs. Fix previous broken refactor key into helix-view #345 is a start but it depends on crossterm. Using generic structs would let us drop the crossterm dependency from helix-view.

• helix-term commands.rs need to be moved into helix-view. The problem there is that the context depends on the compositor written for the TUI, and some commands directly manipulate it by pushing in new components.

  The solution here is to make the compositor a trait so that each frontend can implement it's own. The new trait would have methods like cx.compositor.popup() so that we can manipulate UI without directly referencing the types. But I'm not sure how to handle cases like these

  helix/helix-term/src/commands.rs

  Lines 3084 to 3086 in fd1ae35

  	let contents = ui::Markdown::new(contents, editor.syn_loader.clone());
  	let mut popup = Popup::new(contents);
  	compositor.push(Box::new(popup));

• There's a bit of lsp code in term/src/application.rs that would be better off shared somewhere.

With these changes helix-view would end up holding most of the code, and -term would simply be a tiny frontend implementing the compositor & components.

[Kethku]

I'm looking into step 2 now that step 1 has merged. Let me first say back to you what I think I understand you to mean for how we might move the commands out of helix-term. Then I will propose a slightly different strategy with some benefits and drawbacks.

Gui as a component drawer

The solution here is to make the compositor a trait so that each frontend can implement it's own. The new trait would have methods like cx.compositor.popup() so that we can manipulate UI without directly referencing the types. But I'm not sure how to handle cases like these

So what I think you are suggesting is that each frontend would create a custom compositor type which implements the Compositor trait. This trait would have functions on it for each of the custom components that are implemented in the helix-term crate today. Your example is popup, but I'm guessing this would also require picker, prompt, spinner, menu etc.

Some pros for this approach:

• Custom more native UI can be implemented for each of these effectively giving more control to the gui
• The gui can implement surfaces however they like. Doesn't have to have everything on a strict grid
• This is a relatively small change assuming all of the components can be implemented as functions

Some negatives that come to mind:

• Adding new components requires implementing them in every front end (probably just term and gui, but who knows maybe multiple front ends are created)
• Guis could be very different in feel from each other. Would configs work the same in all of them? Neovim has this problem because often a config that works great in one gui is a complete mess in another
• Theres a relatively large implementation burden for the guis. Even though popup and prompt are basically just rendering text in a window of some sort, they would both have to be implemented in the front end

Gui as a render surface

If we look at Neovim's approach instead, it works by defining a basic set of rendering capabilities that the gui must provide and then implements components and such on top of those basic systems. At the simplest, a neovim gui renders a single grid of characters and all of the components and such are drawn by neovim on top of that. A quick and dirty gui can be built in a couple days if you target that system.

If however more gui extensions are implemented, the rendering becomes slightly more complicated. Rather than drawing a single grid, multiple grids can be defined and drawn to. This gives the gui some more freedom to effect the size and positioning of the rendered windows, but components are still done just using that basic framework. Popups are just smaller windows which render text into them. Floating terminals are implemented on floating windows with text just the same as a dialog box.

This also separates innovation in the editor from implementation in the gui. Components can be introduced without requiring them to be implemented in every front end.

Some benefits:

• Guis are pretty simple. Basically they are just a rendering system which components can depend on to do their drawing
• Guis don't need to be updated to add new components
• Many guis can be created which benefit from upstream updates and changes. Can start to build an ecosystem if there is desire to

Some drawbacks:

• Guis can only innovate so far as the interface allows. It would require some creativity to let guis do special rendering for a given type of component
  -- maybe this can be fixed by giving each rendered window a "purpose" flag which lets the gui special case a certain component
• Pretty significantly different approach to the current architecture. Would maybe require some intermediate steps
• Likely locks guis into a grid based interface. I personally feel this is nice because it simplifies design and such, but I can understand why others would prefer more flexibility.

Thoughts

This has been a bit ramble-y. I hope my point was at least somewhat understandable. I'm interested in your thoughts.

[CodingMadness]

would you that now ( i am a new user to the world of terminal-emulators/editors ) that NeoVide can be used inside for instance, Helix-Editor now?

[pickfire]

@Kethku If anyone were to take on GUI probably you are the one that is most familiar with it since you did neovide. My thought is that we may want it as a render surface but with custom components. It is useful in doom emacs where you can draw something not available in the terminal.

Like you can see on the left, green for new lines, yellow for modified line. And one more you can see is a single red dash for removed lines, I don't think we can easily render these in terminal.

Before getting into GUI, like neovide I see an issue is that users may not be able to access terminal. Which will break some users workflow. I usually do edit and then ctrl-z to run some shell commands. If we only do a GUI for helix, what if users want to run commands? Do we want to provide like sort of rendering for terminal?

There is also another possibility, getting neovide to have helix backend? Not sure how hard is that but from current viewpoint, helix does not have anything, but yeah neovide currently seemed to only be drawing the same thing as terminal, in some places it would be good to have certain way of drawing which is not possible in terminal.

[Kethku]

Before getting into GUI, like neovide I see an issue is that users may not be able to access terminal. Which will break some users workflow. I usually do edit and then ctrl-z to run some shell commands. If we only do a GUI for helix, what if users want to run commands? Do we want to provide like sort of rendering for terminal?

To be honest, a good terminal emulator inside of helix sounds wonderful. I personally rarely dip into a terminal emulator outside of the one contained within neovim. But I think thats a large can of worms that doesn't need to happen now. What I'm interested in helping with is just making sure the design of helix is conducive to gui front ends in the long run even if its not ready yet.

There is also another possibility, getting neovide to have helix backend? Not sure how hard is that but from current viewpoint, helix does not have anything, but yeah neovide currently seemed to only be drawing the same thing as terminal, in some places it would be good to have certain way of drawing which is not possible in terminal.

I'm definitely thinking about ways to make more full fledged guis using Neovide's rendering system. What I would LOVE is to split Neovide in half so that the rendering part is just a crate which provides channels for sending draw commands and receiving input/events from the window. Then the renderer would handle everything else. Integrating that crate with an editor backend would just require writing some glue.

Neovide isn't there yet because there are lots of neovim specific-isms that would need to be moved around, but I think it would be valuable to do because features built for one editor backend would likely be useful for others.

To be honest though its kinda a pipe dream at the moment. What I was thinking in the short run is to just recreate something like neovide's rendering system for helix specifically in order to get off the ground, and then think about unifying the two later if there is interest. That way I don't impose further constraints on this project that don't really benefit this project long term

[archseer]

Like you can see on the left, green for new lines, yellow for modified line. And one more you can see is a single red dash for removed lines, I don't think we can easily render these in terminal.

This is doable using box drawing characters (I imagine emacs is using the same thing). https://github.com/archseer/snowflake/blob/e616d7cb24d85cf6b17b77c3e0cb1ef6c4212414/profiles/develop/neovim/init.vim#L294-L299

[archseer]

If we look at Neovim's approach instead, it works by defining a basic set of rendering capabilities that the gui must provide and then implements components and such on top of those basic systems. At the simplest, a neovim gui renders a single grid of characters and all of the components and such are drawn by neovim on top of that. A quick and dirty gui can be built in a couple days if you target that system.

I was a bit undecided between the two approaches. While the neovim approach works, it leads to most frontends looking very similar. (For example, while I'm aware of Neovide and looked at it's source, I haven't actually used it yet because I didn't have enough reasons to switch.)

A character grid is a good start but is limiting if we want to experiment with inline decorations (see the CodeMirror 6 examples). These might be variable sized or won't fit perfectly in the character grid. Another example would be rust-analyzer's clickable code action links that are embedded into the view.

We're also limited by the terminal in that it's hard to render 0 width multiple selections (cursors) so selections are always 1-width or more (see #362 for more context).

I'm not even sure if the component drawer approach is flexible enough, since we might want to use completely different component types on different frontends. I guess we could allow for frontends to provide their own sets of commands that would augment the defaults with different UI. Maybe it's okay for the frontends to share the same core/view but end up being slightly different (similar to scintilla, or codemirror embedding)

I've been keeping the built-in component list short: https://github.com/helix-editor/helix/tree/master/helix-term/src/ui

Feel free to join us on Matrix to discuss further! (https://matrix.to/#/#helix-community:matrix.org, make sure to join #helix-editor:matrix.org if you can't see it on the list)

---

Before getting into GUI, like neovide I see an issue is that users may not be able to access terminal. Which will break some users workflow. I usually do edit and then ctrl-z to run some shell commands. If we only do a GUI for helix, what if users want to run commands? Do we want to provide like sort of rendering for terminal?

We won't only be doing a GUI, a helix-term is still going to be the primary implementation. (Well, one of two, I'd like to have the skulpin implementation as "officially supported" too). Down the road we'd want to embed a terminal, but that's quite a bit of work.

[kryzet]

Why would you want multiple different frontends in the first place? I cannot imagine why one would create multiple of these solely for cosmetic purposes, but I can see why it would make sense for writing a more efficient frontend layer without forcing the text editor's developers into an overhaul process that stagnates work on the editor's core.

[archseer]

I'd also like to get @cessen's opinion here as well

[Kethku]

I was a bit undecided between the two approaches. While the neovim approach works, it leads to most frontends looking very similar. (For example, while I'm aware of Neovide and looked at it's source, I haven't actually used it yet because I didn't have enough reasons to switch.)

This is a very reasonable critique of Neovim's approach. To me the difference between the two depends almost entirely on if you want to maintain the canonical gui for helix or if you want there to be many different guis which use helix as the backend. If you imagine the main helix gui is basically the only one people will use, then I agree it makes a lot of sense to have component aware logic in the gui because it can tweak the experience to feel just right. There would still be reimplimentation of logic between the terminal and gui front ends, but hopefully that wouldn't be too bad.

However if you want to enable many different front ends, I think that strategy falls apart a bit because any time you want to tweak the behavior of a given component, you have to convince all the front ends to also update their implementations. Its harder to innovate like that.

I'm definitely biased given that neovim is what I've spent the most time with, but I think the vision of a gui api which can be implemented very simply as just a grid, but then augmented with optional extensions if the gui developer wants to customize a given type of behavior is beautiful. It means that if somebody wants to make a gui which is just simple tweaks off the terminal experience, they can pretty easily. And if they want to make something that completely reworks the user experience, thats possible too with a little more effort.

A middle ground

If you are interested in building an ecosystem where multiple groups can implement guis if they want to, then it seems to me that a great way to do this would be to implement the grid based approach. Basically move all the component logic into helix-view, and tern helix-term into a super thin rendering surface. Basically just cursor moves and text on a grid. Then each of the components could be implemented as extensions optionally. If the gui wants to customize the dialog box, theres a trait they can implement for their gui which takes over drawing of dialog boxes completely. And a different trait for taking over markdown renders etc etc etc

This solution would be very similar to neovim's extension model where guis can re implement the tabline or message rendering if they want to, but the difference is that helix's implementation would be implemented with components as the basis from the start. Rather than hacking in extensions for features editors would like, helix has the benefit of starting from scratch and thinking about components as first class extension points.

---

All that said, these are just some quick thoughts. I'm happy to help out whichever way you end up going.

[CBenoit]

I'll pin this issue because it seems to me it could use more visibility. We currently pin two issues out of the maximum of three, so I went ahead.

[cessen]

A character grid is a good start but is limiting if we want to experiment with inline decorations (see the CodeMirror 6 examples). These might be variable sized or won't fit perfectly in the character grid. Another example would be rust-analyzer's clickable code action links that are embedded into the view.

I think for the document text itself, we'll want to stick with a character grid.

The short justification is: it allows the editor back-end to control text layout. The architecture I'm imagining is basically: the back-end is given the grid dimensions, it computes where to place each element within that grid and passes that information to the front-end, and then the front-end renders the described grid (wherever and however it wants). This keeps the flow of data really simple, and especially avoids the front-end needing to send text layout information back to the back-end for things like cursor movement commands (...which also applies to off-screen text thanks to multiple cursors).

In other words, it lets us keep all of the core commands in Helix independent of the front-end. Conversely, if text layout is computed by the front-end (which I think would be more-or-less required if we forego a grid), then the back-end will have to query the front-end when executing any commands that involve text positioning.

So the grid would essentially act as a text layout API between the front-end and back-end, letting us keep as much code as possible compartmentalized in the back-end. (And as a bonus, that also avoids having to rewrite the layout code for each front-end.)

but is limiting if we want to experiment with inline decorations

I don't think it's quite as limiting as you might think. The back-end would control where things are placed on the grid, but the front-end decides how to render them. So, for example, an inline element could be rendered as a fancy, nice-looking button by the GUI front-end, as long as it fits in the grid area allocated to it by the back-end.

And the front end could provide a list of "size factors" for the various kinds of inline elements, so that the back-end can ensure to allocate enough grid spaces for each kind of element.

We're also limited by the terminal in that it's hard to render 0 width multiple selections (cursors) so selections are always 1-width or more (see #362 for more context).

I have some ideas about this, that I think will be easier to demonstrate with a prototype once I've completed work on #362. Although I realize that might not be especially convincing right now, ha ha.

[cessen]

If we look at Neovim's approach instead, it works by defining a basic set of rendering capabilities that the gui must provide and then implements components and such on top of those basic systems. At the simplest, a neovim gui renders a single grid of characters and all of the components and such are drawn by neovim on top of that. A quick and dirty gui can be built in a couple days if you target that system.

After re-reading this, I realized I might want to clarify: I'm only talking about individual documents, not the entire GUI layout, when I'm discussing the character grid. As far as I'm concerned, the front-end can render everything else however it wants. I'm not totally sure how we would present an API for the remaining commands (e.g. file finder, etc.), but I'm not too worried about us being able to work it out.

[valignatev]

Like you can see on the left, green for new lines, yellow for modified line. And one more you can see is a single red dash for removed lines, I don't think we can easily render these in terminal.

This is doable using box drawing characters (I imagine emacs is using the same thing). https://github.com/archseer/snowflake/blob/e616d7cb24d85cf6b17b77c3e0cb1ef6c4212414/profiles/develop/neovim/init.vim#L294-L299

FWIW, emacs can actually draw bitmaps on its fringe and in modeline, it's not restricted to whatever unicode supports: https://www.gnu.org/software/emacs/manual/html_node/elisp/Fringe-Bitmaps.html

Of course, it only works in GUI mode. I'm really interested in a proper gui for the editor as well, but I don't have anything particularly productive to add to the discussion, mostly subscribing for the thread with this emacs remark :)

Of course it would be cool to have a gui that supports custom shaders and all that crazy stuff to fully utilize its hardware acceleration capabilities (if we take neovide as a mental base, I mean)

[kryzet]

Hello from YouTube!

[DoctorRainer]

@7ombie well, anything will do at start. But it should be extendable to implement those requests

[7ombie]

@DoctorRyner - Why though?

If I were taking a crack at this, I'd implement the renderer for a terminal emulator, and use it to directly render the Helix state, just dropping the pretense of communicating with an old terminal over a serial connection. I'd obviously consider Helix-specific requirements, like rendering many cursors, anchors and selections in various colors, but would leave it there.

That implementation would permit extensions, like rendering any texture with dimensions that are multiples of the character-cell dimensions over a rectangular block of characters (with alpha-blending). With that, you could render a PDF document or HTML page somewhere else, then pass the resulting texture to Helix to view it in the editor, but the output would not be interactive (it's just a bitmap), and it would be inline (so would scroll with the text it is blitted over).

That implementation would not permit arbitrarily dividing the screen into graphical panels (with fancy tabs and drop shadows) that can be sized in single-pixel increments, nor rendering interactive graphics inside the panels.

I'm suggesting a custom shader (maybe a hundred lines of code per platform). You're talking about a full graphical user interface. I don't see the former as a viable starting point for implementing the latter.

[Rudxain]

Speaking of scope, should this Issue be turned into a Discussion? Or (at least) have an associated Discussion, and repurpose this Issue as a tracker?

[aretrace]

should this Issue be turned into a Discussion

@Rudxain yes

[go2null]

Wanted to link to the discussion over in Lapce, a Rust GUI modal editor similar to Helix.

• Consider kakoune/helix editing model lapce/lapce#281

The discussion is about ultimately pairing a terminal and a GUI editor, with the goal being a common/shared workflow in best-of-class terminal/GUI apps.

[heyakyra]

Really wish this would get implemented. Is it hard? I've never written any Rust but I feel like if this were a beginner-friendly task it would have already been done

[ShalokShalom]

You might want to link directly to this discussion from the website.

Currently, it still links to the issue.

https://helix-editor.com/

[Rudxain]

Done!

[karmakarmeghdip]

Is there any update on this? Having a GUI in Windows would be kinda nice as using it in the terminal is kinda slow when scrolling. Vello gives excellent performance as a renderer and text rendering is also quite nice in it.

[Adhishtanaka]

what if helix use gpui UI framework to build it ui?

[jokeyrhyme]

Why not to just use TUI?

#11783 (comment)

[ShalokShalom]

why waste effort rewriting the whole UI in a GUI toolkit just to get rounded borders around UI elements.

You can get rounded elements around UI elements with a TUI (thanks to Nerd fonts)

[theNoof]

you can get that without nerdfonts too:

╭───╮
│   │
╰───╯

(looks better in terminal

[ShalokShalom]

you can get that without nerdfonts too:

╭───╮
│   │
╰───╯

(looks better in terminal

In TuiOS?

[theNoof]

oh, i dont know?
but those are normal unicode characters; if it supports those, it supports box-drawing (i think)

[jokeyrhyme]

i wanted to collect together a list of desirable editor features that are easier to implement or can only be implemented in a GUI

such a list can then be used to help evaluate GUI toolkits or other aspects of work elsewhere

try to restrain your excitement (yep, me, too, i need to restrain myself, haha) and reply to this thread only with GUI editor features :)

[Adhishtanaka]

• Extension panel for easy plugin and theme management
• Drag and drop support for files
• Panels for class trees, symbol outlines, and project layout

[lheckemann]

• Less lossy keyboard interface (e.g. ctrl-shift-a distinguishable from ctrl-a)
• Support for proportional (non-monospace) fonts, which can be nice when working with prose
• Support for varying fonts within a buffer (also good for prose -- e.g. have headings in markdown actually be larger)

[kryzet]

• Processing raw keystrokes instead of upper or lowercase letters for controlling and navigating the editor
• Rendering text for languages with non-Latin alphabets, as rendering such text in the terminal results in distorted text (or in the case of Arabic, even disconnected text, which makes reading the text harder and slows down the reader a lot, even if they were a native speaker). This would also allow for RTL or bi-directional text rendering where it is possible to render text for different languages in different fonts (e.g. English in Iosevka Sans or Iosevka Quasi-Proportional, and Arabic in Noto Sans Arabic).

[kryzet]

• The editor's UI behavior does not rely on an external program that actively changes, comapred to a GUI library/framework. Take wxWidgets as an example; Windows could be updated and its GUI standard elements could change, and wxWidgets could be updated, but Helix would still look (roughly) the same throughout all of these updates. However, a terminal emulator could change, and there's more than one terminal emulator per OS supported by Helix, so the number of emulators changing and with already differing behavior that Helix has to somehow tolerate to show the same content the same way in all of them presents a monumental task for the Helix maintainers, even if contributors were to help.

[cessen]

Multiple vertical-bar cursors (current consoles can at most do one, and even that is not supported universally). This is useful for:

• Indicating visually that the editor is in insert mode, beyond just the mode line.
• Serving as a basis for true zero-width cursor support in insert mode, if we choose to ever support that. See e.g. some of the discussion in The Great Line Ending & Cursor Range Cleanup #362.

[ShalokShalom]

This thread is to collect, and discuss possible implementation scenarios.

[ShalokShalom]

Thats what this discussion is uniquely set to solve. 👌🏻

[CodingMadness]

Thats what this discussion is uniquely set to solve. 👌🏻

so this means you guys still not have began to develop one, okay xd

[cynthia2006]

Well, how many people do actually use TuiOS? And, I'd like to disagree here. GUI and TUI could never compare.

[ShalokShalom]

How is the amount of users important for this specific adoption?

And true, TUI is much easier to implement and maintain. I see space for both, a TUI and a GUI.

[kryzet]

Consider #11783 (reply in thread)

[m0n99]

I’ve noticed this in Neovide: scrolling is line-snapped, and near the end of a scroll animation the viewport snaps back to a line boundary, causing a small but noticeable jitter during frequent vertical scrolling.

I hope Helix could support pixel/sub-line scrolling to avoid this snapping behavior and make GUI scrolling feel smoother and more consistent.

[go2null]

Just came across this: https://github.com/OlaProeis/Ferrite?tab=readme-ov-file#tech-stack

• egui: https://github.com/emilk/egui

[go2null]

There is also floem created for Lapce

[paulocoghi]

I recommend Floem as well

[kryzet]

We should somehow collect this and other recommendations made throughout this discussion.

• Recommendation by @rydb: Gui #11783 (comment)

[rydb]

What about Dioxus for Helix UI? It supports all major targets(Desktop, Mobile, Web, Native*), supports hot-patching app state/UI for sub-second iteration, and it ties in pre-existing html + css/tailwind knowledge that a lot of potential contributors already have.

E.G: Sample Projects
https://github.com/un4ckn0wl3z/dioprocess
https://github.com/temidaradev/rusic
https://vulkan-driver-1-4-cts-report.kbz8.me/

*Native is still a very new target and has memory leak issues, but Helix could target Desktop, and then change to Native once that's resolved.

[Hypnoes]

I think you guys are too caught up in what GUI framework to use and how to implement it. Actually, separating the UI as an independent part and communicating with the Editor itself in the form of a protocol is already very valuable for this refactoring. Once this is settled, using TUI, GUI, or specific GUI frameworks (like GPUI, WebGPU) will be independent tasks later on. The important reason for this is that, combined with the stabilization of the Extension ABI in #3806 (i.e., supporting extension interfaces like scheme, wasm, and native), Helix editor will complete its evolution from a file-editing-centered editor (function) like vi/nano, to a folder-centered project development and debugging tool like vscode/zed, and then to a highly customizable and extensible system like emacs.

[Hypnoes]

Alright, I've just finished reading, and WASM has been ruled out. Hmm, that's fair and acceptable to me. Actually, I'm quite intrigued by the idea of using Scheme for configuration—I’ve never been fond of TOML anyway. So, let it be. That said, whatever form the plugin system takes shouldn’t conflict with my earlier proposal.

[cynthia2006]

The problem is that Helix isn't feature-complete, thus developing a protocol implies to standardize it, which bars from rapid development, and might become a mess.

(See https://xkcd.com/927/)

[kryzet]

@cynthia2006 made a good point here. Also, I don't think the plugin system should have anything to do with the user interface, and probably not the work done on it, either.

[anuragl2h]

It is better to have a gui for user friendly interface and file managing with in editor debug and run features

[TureBentzin]

What I would agree with is approachability in the age of ultra feature rich IDEs for new users. For "experienced" users the file pickers are just fine.

What do you mean with "run features"?

[cynthia2006]

@TureBentzin He means “run profiles”. It implies that compilation aspect is handled inside Helix. To me, it is just unnecessary and would make Helix bloated like JetBrains' overengineered IDEs.

[TureBentzin]

@TureBentzin He means “run profiles”. It implies that compilation aspect is handled inside Helix. To me, it is just unnecessary and would make Helix bloated like JetBrains' overengineered IDEs.

Oh then I absolutely agree. Some people just don't understand the difference bewerten Text editors and IDEs. It's a very different thing...

[Abdillah]

Helix will be an extensible text editor, it will be possible to make it into IDE with plugins.
Moreover, VS Code still categorizes as editor but provide a base debug & run capability that implemented for each language by plugins. So, I don't think that features is out of scope.

[cynthia2006]

@Abdillah Then again, Helix is not VS Code or Neovim; it's a simple but powerful text-editor that just works for small-scale projects without much demands.