[HN Gopher] Show HN: Ecode - A minimalist and fast open-source c...
___________________________________________________________________
Show HN: Ecode - A minimalist and fast open-source code editor
Hi HN! I've been working on a code editor and I think that it's
mature enough to catch some interest. It's using a custom GPU
accelerated GUI written in C++. Currently implements some
interesting features: LSP, terminal, auto-completion, linters,
formatters, custom keybindings, plugins and more. It's a hobby
project but still intends to be an alternative to other popular
code editors like Sublime, Kate, Lapce, Lite XL (and takes
inspiration from them). The project was born as a playground for
the GUI I'm developing (eepp GUI) and is advanced enough to
currently be my main code editor, but it's a work in progress, and
many features are still pending. Some minor hints on how to use it:
Folders are used as project (and .gitignore is used to ignore
files) The wheel icon on the top-right has all the options you
need (Ctrl/Cmd + M to show). Some keybidings to navigate any
project (navigation is keyboard driven): Ctrl/Cmd + K = Locate
Files Ctrl/Cmd + Shift + F = Global Search Ctrl/Cmd + Number (Go
to tab #)
Author : SpartanJ
Score : 210 points
Date : 2023-01-10 05:21 UTC (17 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| feiss wrote:
| The editor looks fabulous, great job! although I am actually very
| excited and impressed with the eepp GUI framework.. it's pretty
| sick! I wish we had more like this in rust..
| progx wrote:
| The most important point is expandability. Did it has an API or
| is it planned to add an API to extend the editor?
| SpartanJ wrote:
| Author here: The editor can be expanded via plugins and several
| features are presented as plugins (LSP, linter, formatter and
| auto-complete). But the plugins API it's not as friendly as
| other editors since I want to keep some control over the
| plugins. I think we already have many editors very expandable
| but also with very little to no control over the
| plugins/extensions environment, and that ends up creating a big
| mess for the final product (inconsistent UI, bad
| implementations, etc). Currently the plugins can only be
| implemented with C++ native code and new plugins will need to
| be merged into the project. I would like to keep control over
| the new features and supervise that the implementations are
| correctly done (mainly I care about plugins not locking the UI
| thread). I understand this can be bad for some but I want to
| keep a certain vision that needs some kind of control over the
| end product.
| Deukhoofd wrote:
| A third of the linked github readme is about how to do plugins.
| marssaxman wrote:
| Thanks for sharing. I'm going to give it a try.
| breadchris wrote:
| was ed not light enough? it is the standard editor.
| diceduckmonk wrote:
| > designed for modern hardware with a focus on responsiveness and
| performance
|
| Not sure why a text editor needs modern hardware to be
| performant. I'm working on a text editor myself, and aspire to
| vim on the performance front as it is fast as one would
| reasonably want. If anything, my physical body is the bottleneck.
| There are edge cases such as really large files (100+ million
| lines) or ones having super long lines that makes certain data
| structures choke, but vim can do random access on 180m line files
| just fine on my M1.
|
| Point being, performance is a weak selling point to switch text
| editors, and I question whether it should even be predicated on
| "modern" hardware ( GPU accelerated rendering ? ). The selling
| point has to be something else. This is why the editor wars is a
| dichotomy between Emacs and Vim. Emacs strives for many things,
| but speed isn't one of them, and that's perfectly okay. The main
| selling point of my editor, built for myself, is native support
| for Org-like files without the rabbithole of Emacs.
| gigatexal wrote:
| Yeah -- while not mainstream compared to VSCode -- it'll take
| something very big and impactful to move me away from neovim +
| alacritty. It works amazingly well.
| noloblo wrote:
| What is neovim + alacritty
| bloopernova wrote:
| neovim is a fork of vim. https://neovim.io/
|
| alacritty is a terminal application.
| https://github.com/alacritty/alacritty
| gigatexal wrote:
| What blooper said.
|
| I use alacritty as a gpu-accelerated terminal and neovim
| plus the LSP stuff from VSCode
| gazsp wrote:
| I'm on Kitty + Lunarvim. Nice and fast / responsive.
| imiric wrote:
| Performance in text editors used for programming is important.
| If there's a delay between pressing a key and something
| happening, it's a worthwhile goal optimizing for that. Consider
| how many things can happen in modern editors with a single key
| stroke: changing large blocks of text, executing a macro,
| rendering syntax highlighting, communicating with an LSP
| server, rendering code completion, executing plugins, etc. All
| those things should happen in as few milliseconds as possible
| for the experience to be considered "responsive".
|
| I use Emacs on a daily basis, and even with the recent native
| compilation change and relatively few packages, some common
| actions feel noticeably slower than in Vim or other editors. Is
| this a dealbreaker? No, I made a conscious decision to get the
| flexibility of Emacs at the expense of performance, but I would
| jump at the opportunity to use something with the same
| featureset that _does_ prioritize performance. It's not about
| how productive it would make me, but how enjoyable the
| experience of using it would be.
| Aeolun wrote:
| > Point being, performance is a weak selling point to switch
| text editors
|
| You've never worked with IntelliJ I see. If someone builds the
| exact same thing but any amount faster I'll switch in a
| heartbeat.
|
| I'm using Zed more and more, even though it has barely any of
| the features I use, purely because it's so fast.
| z3t4 wrote:
| Text rendering is very expensive. That's why you need hardware
| acceleration.
| kwhitefoot wrote:
| It's amazing then how much writing of both code and prose I
| and many others did on machines that were much less capable
| than today's. I wrote considerable amounts of code on the Z80
| Apple II add on in the early '80s and never felt that the
| editor was too slow. My wife wrote a novel on our Osborne 1
| (CP/M, Z80, 5 1.4 inch floppies) in Wordstar. Speed was never
| a problem for editing.
| naasking wrote:
| > It's amazing then how much writing of both code and prose
| I and many others did on machines that were much less
| capable than today's.
|
| Sure, on machines with low resolution screens with simple
| fonts and no anti-aliasing. I'm not saying accelerated
| graphics are necessary for text editors today, just that
| the context has changed considerably so the comparison
| isn't obviously fair.
| CyberDildonics wrote:
| Are you really trying to say that 100 times the pixels
| (and a lot less in a window that isn't full screen)
| cancels out 10,000-20,000 times the CPU power (per core)?
| naasking wrote:
| CPU speed isn't the limit, memory speed is. Apple II's
| 1MHz to DDR4's 1600MHz is 1600x increase, so more modest
| than CPU gains.
|
| Apple II's display was 280x192 with 6 colours in high res
| mode, which is ~107kB of raw pixel data (Apple II didn't
| store this all in RAM). An RGBa display at 1080p is least
| 105MB of raw pixel data. That accounts for the 1000x
| difference right there. Add a few extra features like
| anti-aliasing, more sophisticated layout management,
| syntax highlighting, etc. and it all seems to track.
|
| Finally, there are other sources of perceptible
| differences in UI/UX due to the growing depth of the
| software stack:
|
| https://danluu.com/input-lag/
| Aeolun wrote:
| Bitmap rendering is incredibly fast. Old computers were so
| slow it was the only viable method.
| CyberDildonics wrote:
| If it's so expensive, why were computers a 10,000 times less
| powerful able to do it well?
| z3t4 wrote:
| They only supported the ASCII characters and a few
| sizes/colors that was pre-rendered.
| Semaphor wrote:
| Most people use neither Emacs, nor Vim [citation needed, but
| I'd bet some money on it]. And for me, performance is most
| certainly a selling point.
|
| The main reason I use my windows text editor (EmEditor [0])
| despite having no formatting and only barebones syntax
| highlighting, is that it's faster than any other editor I've
| ever seen (though I think the large file handler tops out at
| 256 GB). Well, that and its superior CSV handling, though
| Notepad++ comes close with plugins ;)
|
| [0]: https://www.emeditor.com/
| anticodon wrote:
| I've seen voting results on one of niche Linux sites, and was
| surprised that majority of users use vim/neovim or vim
| bindings in other editors/IDEs.
|
| But I'm pretty sure that most Windows users wouldn't use any
| editor resembling vim.
| dividedbyzero wrote:
| Visiting niche Linux sites often enough to take part in
| such a poll is probably introducing a very strong selection
| bias here.
| [deleted]
| microflash wrote:
| Always happy to see new source code editors.
|
| > Lightweight multi-platform C++ code editor designed for modern
| hardware
|
| Maybe change this description. At first blush, I thought this was
| a "C++ code editor" rather than an "editor written in C++".
|
| My favourite languages, Java and SQL, are not in the supported
| languages list but hopefully support can be added with LSP.
| [deleted]
| SpartanJ wrote:
| Author here: Thanks for the suggestion! I forgot to change it
| in the repository description! It's already fixed.
|
| > My favourite languages, Java and SQL, are not in the
| supported languages list but hopefully support can be added
| with LSP.
|
| For the moment I only implemented syntax highlighting for the
| languages. Adding linter and LSP support is trivial. May be you
| can collaborate by adding it (it's just a configuration, take a
| look at the plugins section).
| christophilus wrote:
| This looks great. It's nearly impossible for me to leave Neovim
| at this point, but I do miss a good git-aware minimap, and I miss
| the VS Code git diff / integration.
|
| I'd love to find an editor that has those features while being as
| light and snappy as Neovim with the same ability to split,
| navigate, and do all the things without leaving the keyboard.
| anticodon wrote:
| Though not a minimap, I use gitsigns plugin for neovim that
| shows changed lines in the gutter. I wouldn't be surprised if
| there's even minimap plugin somewhere.
| carderne wrote:
| Here it is (haven't used it but looks that part):
|
| https://github.com/wfxr/minimap.vim
| SpartanJ wrote:
| Author here: Git integration plugins will come later, but it's
| planned. I hope the project gets enough visibility to get some
| collaborators :)
| hatmatrix wrote:
| So the extendable functionality is enabled with C++? If it were
| emacs lisp I would be right there already. :)
| SpartanJ wrote:
| Author here: That's correct. It's partially intentional, since
| I want to keep some control over the plugins ecosystem. I think
| it's explained somewhere in the README file: Extendable
| functionality but in a controlled environment. New features and
| new plugins are accepted, but the author will supervise any new
| content that might affect the product quality and performance.
| antiframe wrote:
| So there's currently no mechanism by which I can extend Ecode
| without your involvement?
| SpartanJ wrote:
| That depends on what you want to extend. You can expand the
| capabilities of the LSP, linter, and formatter by adding
| new configurations. You can also create new color themes
| for the editor and the terminal. You can also customize the
| UI (it won't be that easy, but you can). But, if you want
| to create a new plugin... since it's native code you'll
| need to at least fork the repository and create the plugin
| on your own repository. I don't plan to be a dictator, just
| a supervisor. And of course, I'm more than open to getting
| new collaborators (this is the main reason I'm publishing
| it), that would be great. I just want to ensure that my
| application branch is "safe" (no malicious code, no
| horrendous implementations, etc).
| [deleted]
| bmn__ wrote:
| I have carefully set up my desktop environment the way I like it,
| specifically the way menus are displayed, colours, fonts, icons,
| keyboard shortcuts, notifications. Ecode does not even make a
| single attempt to adhere which was not acceptable when Winamp
| came out and certainly not acceptable in 2023. I have to strain
| to read the text because it's so small and I have no recourse
| against that problem. Stop "skinning" software, it is literally
| easier to do nothing and then the software will automatically do
| the correct thing and follow the rules.
|
| When I paste in text, it only shows squares, afaict only a few
| scripts like Latin or Cyrillic work. The input method editor does
| not work correctly, I can't see what I'm typing.
|
| Unusable, into the rubbish bin it goes.
| SpartanJ wrote:
| Author here: Besides the fact that you were very rude with your
| comment I'll give you my point of view.
|
| > I have carefully set up my desktop environment the way I like
| it, specifically the way menus are displayed, colours, fonts,
| icons, keyboard shortcuts, notifications. Ecode does not even
| make a single attempt to adhere which was not acceptable when
| Winamp came out and certainly not acceptable in 2023.
|
| I understand what you want, but it's not an easy task I it's
| not something I care anymore. It's technically possible to
| create a theme that looks almost exactly like anyone's desktop
| but I don't think it is worth it. eepp, the underlying
| technology behind ecode is more like HTML+CSS. All the styling
| is done via CSS and the layouting with XML, and it's more
| similar to the web technology than native desktop widgets (such
| thing stopped to be a thing in every OS except macOS).
|
| > Stop "skinning" software, it is literally easier to do
| nothing and then the software will automatically do the correct
| thing and follow the rules.
|
| Then you don't understand the problem.
|
| > When I paste in text, it only shows squares, afaict only a
| few scripts like Latin or Cyrillic work.
|
| The README file clarifies this. For the moment I don't support
| wide-characters (Chinese, Japanese, Korean, etc) and the editor
| only supports UTF-8. I'll add support for it at some point.
| Wide-characters are only supported in the terminal for the
| moment.
|
| > The input method editor does not work correctly, I can't see
| what I'm typing.
|
| I guess you're referring to IME support. It's still pending.
|
| > Unusable, into the rubbish bin it goes.
|
| I have no problem with critics, but this is not the way to have
| a conversation about an open-source application. At least take
| the time to read the README and understand that this is work in
| progress. Such comments like yours are a waste of time.
| masterof0 wrote:
| You made a very nice editor, dismiss that clown. You are
| clearly also a great person. Do you have a channel for us to
| provide feedback or interact with the community? like a
| Matrix server, or should we just open issues in your repo?.
| SpartanJ wrote:
| Thank you for your kind words! Almost no one knew the
| project until some hours ago so there was no community to
| communicate with, there's nothing available for the moment.
| I would love to have a place to chat if people is
| interested in the project. As for now, just open new
| issues, we can use that for feature requests, ideas, and of
| course bug reports.
| btown wrote:
| Just jumping in to say that you sound like an amazing
| maintainer and a really great person, for responding so
| constructively to something so toxic. Building one's own UI
| engine is not for the faint of heart, and the amount of
| features and cross-platform compatibility you've built is
| quite a feat! I'll be following the project, and don't let
| comments like this one get you down.
| SpartanJ wrote:
| Thank you for the support! I really appreciate it!
| E39M5S62 wrote:
| There's no need to be that dismissive and rude.
| rd07 wrote:
| I am happy to see one more open source GUI text editor that aims
| to be fast, minimalist, yet has some essential features (at least
| for me) like LSP support, minimap, and terminal support. I hope
| this editor will have a good plugin manager in the future.
| worldsavior wrote:
| The title is misleading. Yes, a code editor, but for game
| development. It includes a graphics module, physics and other.
| For a code editor, it's not minimalist. For a game development
| code editor, maybe minimalist.
| SpartanJ wrote:
| Author here: No, you're incorrect. It's a general purpose code
| editor. What you are describing is the underlying technology
| used to create the editor. eepp (the library) currently is more
| like a Qt alternative (not at the same level, much work needs
| to be done yet), it's not used as a game engine (but it can be
| used), I simply changed my focus over time.
| worldsavior wrote:
| What about the graphics module? It seems there are features
| that aren't needed for other than game development? Btw, it's
| still a pretty nice editor :)
| SpartanJ wrote:
| Thanks for the compliment! The graphics module is the core
| of the application (the UI consumes the Graphics module for
| all the rendering). There are two modules that aren't
| currently being used in ecode: physics and audio. I'll keep
| the audio module for the moment (it's very tiny and doesn't
| add new dependencies, and I'll probably use it for optional
| notifications). The physics module it will be probably
| moved apart as a complementary module as I did already with
| the "Maps" module for this release.
| worldsavior wrote:
| I understand. Love it.
| [deleted]
| Semaphor wrote:
| For anyone confused why there's no source:
|
| > Currently, the source code is located at the eepp project
| repository. [...] At some point, it will be migrated to this
| repository.
|
| -- https://github.com/SpartanJ/ecode#source-code
| [deleted]
| alganet wrote:
| The demo is impressive for something running on a browser.
| > Planned Features > > ... > Multi-
| cursor support > ...
|
| I can't live without that though. SublimeText spoiled me, my
| editing flow is heavily based on multiple cursors.
| vageli wrote:
| Could you expand on your use case? Are you writing the same
| thing across multiple lines? I've only gotten tripped up on
| multiple cursors when I somehow activate them.
| Cort3z wrote:
| Also not author of original comment, but I use it for "stupid
| data transforms" all the time. Like formatting some stuff for
| a spreadsheet. I find it faster than writing a script most of
| the time
| tiagod wrote:
| I cant speak for the commenter you replied to, but I find it
| great to transform data without any tooling.
|
| As an example, if I have some tabular data, I can quickly
| turn it into JSON. Find-replace can also add a cursor to each
| result which is very helpful. Many other code/data
| transformation tasks are also made trivial with multiple
| cursors.
| alganet wrote:
| My main use cases:
|
| - Replacing variable and function names: I have Ctrl+D bound
| to "Mark Next Occurrence", which creates a multiple cursor
| and replicates the selection I have on my main cursor to the
| next following similar thing. Instead of changing a name and
| then search/replace it afterwards, I selectively mark the
| next occurrences within the scope I'm in and change them all
| at once.
|
| - Editing multiple similar expressions: If I want to add a
| new parameter to a function, I can multi-select
| `existingParam,` (including the comma) and add the new
| parameter to multiple occurrences within a scope.
|
| - Ctrl-based multi navigation: I use Ctrl + Arrow Keys to
| skip words a lot. In combination with multiple cursors, it
| allows each cursor to skip words individually. This is useful
| for the previous use case (editing parameters) when each
| parameter might have a different name (and therefore a
| different length).
|
| - Several alignment and formatting things: This is hard to
| explain in text. I use it to align the ` = ` sign in repeated
| variable assignments, to manage indentation, etc.
|
| I can do most of these things using other tools if needed (I
| did before multiple cursors). The parameter editing is often
| a vi "showcase" scenario, which I consider to be much more
| effective using mc than repeating actions or macros.
|
| I don't place cursors with a mouse, I don't add cursors below
| or above or any other feature. Just "select the next
| occurrence" or "select all occurrences".
| SpartanJ wrote:
| Author here: This is interesting to me. I usually solve all
| the multi-cursor usage with a range based search and
| replace (that it's supported in ecode by selecting the
| range and Ctr/Cmd + F to search and replace over that
| range). I would like to see how it's used by other users to
| have a better idea on how it should behave a multi-cursor
| feature. If you know how to record a video of you editing
| in the way you explained it would be awesome to see it.
| Thanks
| seanw444 wrote:
| This is also how I go about it in Doom Emacs. I guess
| either way solves the same problem, just differently.
| alganet wrote:
| Sure can do!
|
| Here it is: https://streamable.com/vwj0hs
|
| I did three things there:
|
| 1. Replace the prefix of several variables from `$mock`
| to `$stub`
|
| 2. Added a prefix to all properties of the object `$r`,
| which left the camelCasing missing an uppercase letter, I
| selected that letter on all properties and used
| "Transform To Uppercase" action on VSCode to camelCase it
| properly back again.
|
| 3. Aligned some keys of two arrays. I selected them,
| placed some minimal spacing, then hit `Home` to align the
| cursors to indentation, then used `Ctrl+Delete` to trim
| the added spaces.
|
| I'll try the range based search, I never used something
| like that and might like it.
| SpartanJ wrote:
| Thank you very much! Indeed it looks really useful. I
| hope I can implement it soon.
| joshstrange wrote:
| I use for things that I could do with find and replace
| (often requiring regex) but I find it faster/easier to
| just use multiple cursors. With multiple cursors I can
| convert a PHP array to JSON or JS very easily or take a
| list of params and turn it in to an object. I do this
| often when creating client-side TypeScript interfaces for
| the data the server is going to spit back at me. Example:
|
| * I just select `public` on my first PHP class property
|
| * Use multiple cursors to select all `public`'s that are
| before the properties I want (Normally by adding 1
| selection at a time since I only want the props, not the
| public methods)
|
| * Arrow over right 3 times (Now my cursor is right before
| the property names, after the `$`, this is PHP remember)
|
| * Hold shift + control
|
| * Arrow once more to the right (now the variable names
| are selected)
|
| * Hit Cmd+c (copy all variable names)
|
| * Open new IMyInterfaceDTO.ts file
|
| * Type `export interface IMyInterfaceDTO { <cursor is
| here now> }`
|
| * Paste in all my variables between the `{}`
|
| * Select the new-line between each variable (I want a
| cursor before each variable name)
|
| * Then add in `: string;` after each variable (string is
| the most common, I then manually change it to
| number/boolean/etc on the props that need it)
|
| Done, now I have a TypeScript interface that matches my
| php class that gets turned into JSON.
|
| Here is an example of what I'm talking about:
| https://cs.joshstrange.com/jlH4BnT3
|
| Yes, I could accomplish the same thing with find and
| replace using a regex but this lets me see each step of
| the transformation and react easier. Maybe if I was a
| regex pro I'd feel differently but this method works
| really well for me and how my brain works. I know it's a
| lot of steps but I do it reflexively almost on autopilot
| verses having to stop and think about a regex.
| SpartanJ wrote:
| Awesome, it really helps me to visualize the usefulness
| of the feature. Thanks for taking the time to explain it.
| alganet wrote:
| Oh, I completely forgot about copying and pasting
| multiple cursors. I'm a hardcore user of that as well.
| SpartanJ wrote:
| Author here: I guess this is gonna be one of the most requested
| features. It will come sooner than later, but it's not a
| feature I use very often, that's probably the only reason it's
| not implemented yet.
| iddan wrote:
| More than just multi-cursor the workflows VSCode offers with
| them (selecting all occurrences, selecting the next
| occurrence) are vital for my work.
| pjerem wrote:
| Aren't those workflows operated by LSP Rename action rather
| than multi cursor ? Since Ecode supports LSP, if you only
| need to rename things, you should be good without multi
| cursor.
| panekj wrote:
| LSP only applies to programming languages and specific
| configuration files, it's useless when you edit files
| such as JSON/YAML/etc.
| makapuf wrote:
| indeed. LSP are for high latency, high impact, careful
| changes. multicursor edits (with sublime for me) are for
| those "replace all the str_something with
| string_something in the next 3 lines, quick"
| Kab1r wrote:
| There are LSP servers for YAML (and by extension JSON)
| alganet wrote:
| I'll keep it on my watch list!
|
| It already marks several of my editor checkboxes (LSP
| support, fast global search/replace, real time tree view,
| etc). I'll say it again, it looks very impressive.
| timeon wrote:
| I'm using Sublime and as Druid fan I'm following Lapce but this
| one looks good too.
| ilrwbwrkhv wrote:
| Same. Lapce is the hottest new editor and might be the only one
| to get me to switch away from sublime.
| LoganDark wrote:
| > as Druid fan I'm following Lapce
|
| Doesn't Lapce use a custom wgpu renderer, and not Druid? Or did
| that change at some point?
| panekj wrote:
| We use fork of Druid that uses OpenGL. It was wgpu before
| instead of OpenGL but there were issues and limitations with
| it.
| timeon wrote:
| I think it has own fork of Druid but there may be plan to use
| Xilem.
| panekj wrote:
| yes, we plan to switch to Xilem when it's ready for us
| conaclos wrote:
| From the Lapce's README [1]:
|
| > Lapce is written in pure Rust with a UI in Druid
|
| [1] https://github.com/lapce/lapce
| candyman wrote:
| This is a little off topic but related because I keep looking at
| these source code editor posts. I have always been looking for a
| little "sidekick" editor that is always in the background that
| you can invoke with a ctrl-<char> and it at least maintains just
| a single local data store. (It's not a general purpose text
| editor like Sublime.) Sort of like the old Notational Velocity
| but able to be invoked very quickly anytime. The file could just
| be synced across computers using Dropbox or similar but it would
| be nice if it also allowed simultaneous editing of the file.
| sintezcs wrote:
| In modern days it's kinda shocking when you see a new UI app that
| was built without using the HTML+JS+Electron bullshit. Big
| respect for that!
| [deleted]
| stonogo wrote:
| I have apparently completely lost touch with what people mean by
| 'minimalist' these days. Can someone help me understand why that
| word is applied here?
|
| Looking over the feature list and the ReadMe, this editor seems
| really attractive and checks most of my boxes for a good main
| editor, but I hit that word and cannot figure out what I'm
| missing here...
| chii wrote:
| presumably they meant visually minimal (not that i would
| agree...). It is indeed minimal compared to say, intellij IDEA,
| or even VSCode.
| SpartanJ wrote:
| Author here: Yes, that's what I meant. I agree it's not the
| most appropriate adjetive to describe the editor. But one of
| my intentions is to keep the UI as clean as possible (I'm not
| a fan of cluttered editors with several panels on screen all
| the time).
| jasonlotito wrote:
| Considering IntelliJ has different setups, you'd have to
| compare the zen or distraction mode of IntelliJ with the
| minimalist setup here, which seems to be more cluttered than
| what JetBrains is offering.
| SpartanJ wrote:
| Author here: You can hide everything in the editor
| (minimap, line number info, side panel, etc). I guess could
| add a Zen mode that hides everything at once for
| simplicity. The editor will remember your view settings, so
| it's very doable to have a zen mode by default.
| [deleted]
| robinsonb5 wrote:
| I think in 2023 "minimalist" just means "not written in
| something like Electron"!
|
| While this certainly doesn't match my idea of minimalist
| either, it does look interesting - I'm always enthusiastic
| about projects that target systems beyond Windows and Linux -
| and this one can run on Haiku.
| ilrwbwrkhv wrote:
| And thank goodness for that. Electron is the scourge of
| modern software and causes global warming.
| robinsonb5 wrote:
| I think it has some fierce competition there - in fact I
| might even argue that modern software itself is the
| scourge!
| stevedekorte wrote:
| Would love to see one of these that used Miller Columns for
| navigation, and supported VSCode task and launch files.
| nerdponx wrote:
| What code editor _does_ support Miller columns?
___________________________________________________________________
(page generated 2023-01-10 23:02 UTC)