SDL has hinting because it uses freetype. But this program doesn't use that. It uses stb_truetype which does not support hinting.

Yes, the rendering implementation uses gray-scale antialiasing.

But system uses ClearType - compare rendering in window caption (rendered by Windows) and the text inside client area.

Gray-scale may work on high-DPI monitors, but on typical monitors it will be blurry.

But Apple and Microsoft still use ClearType even on high-dpi monitors.

For that matter, Sublime Text, that uses similar architecture (but Python instead of Lua), uses ClearType.

I have just downloaded it too and witnessed this issue, the text looks weird, like a little bit blurry, it would be perfect if it looked like on Sublime Text 3 or on this image https://i.ibb.co/qYCpx3x/1588859182372.gif

If you compare the SDL-rendered text to the window chrome (OS-rendered), they appear to be similar. It just looks like this is a screenshot of a low DPI display. Nonetheless, peeking at the repo's issues shows that high DPI displays haven't quite been figured out either:

https://github.com/rxi/lite/issues/46

That could possibly be a result of the image compression as well, no?

You might also be interested in kilo: https://github.com/antirez/kilo

Textadept is great. It's my daily driver. That's mostly because I was looking for something lightweight that I could configure to operate similarly on windows and mac.

Text adept lacks a "folder view". if it were not for it. and "open folder".

For now, lite also lacks "open folder", but it shows tree view of current directory atleast

Textadept is also very extensible with little effort.

Also "zile"

texadept is great, it can handle really large files where most other editors crash/die.

That's only because it doesn't do what editors have to do. Try writing some right-to-left text in lite and see what happens.

Wow, thank you for mentioning EmEditor, I used to keep it as a must-have app when used Windows, preferred it over UltraEdit, EditPlus etc, good memories. Nowadays it's all vscode though.

The resident memory was 10MB in my windows machine when I ran this. A strong reason for me to use this would be in a low powered device. I want to write markdown in a tiny editor like this. I want to run multiple projects side by side and this is good for that. If I'm a beginner trying do dev on a machine lower than 4G of RAM. So many more examples come to my mind. I'm pretty sure there are more

Also the immediate UI library from the same author is very good and the examples are amazing.

1. https://github.com/rxi/microui

2. https://floooh.github.io/sokol-html5/index.html

What would you say are top open source editors one would consider, and by what criteria should one benchmark the comparison?

While subjective criteria are perhaps most important (usability, integration with favorite programming language, extensibility), for technical quality perhaps there can be some meaningful numerical benchmarks. For example, the lag and memory use when opening a many-GB text file and editing the middle of it with syntax highlighting.

Supposedly editors using ropes are good at this.

And Textadept, which is also written in Lua.

Long time Kate user, though I dropped KDE years back in favor of Fedora XFCE. If one isn't in KDE world, Kate's paint latency when alt-tabbing back to a Kate window is incredibly, painfully slow.

kate has always been a really good piece of software. I would have used it a lot back in the late 90s if it had only had good vim emulation, everything else was excellent.

do you mean vs code has low latency?

The memory usage can be explained by what structure it uses for its buffer. It is a Lua table of lines. It is this splitting of the file into lines that causes the larger memory usage due to internal fragmentation.

Lite has a slightly smaller binary, however; but as someone whose regular text editor on Windows is notepad (the stock one, which is <100KB), I still find the fact that a text editor's binary is >1MB rather disappointing.

I do realise that both Lite and Notepad3 are significantly more featureful, but I'm not sure if the increase in resource consumption is proportional.

(For comparison, regular notepad uses <1MB of memory when holding nothing, and I don't have a 27.5MB text file to test with, but a 6.5MB one takes 17MB when loaded. In other words, the expansion factor is close to Notepad3.)

When I run this editor on Windows 10 the text appears to me as crisp as in any other editor I have available.

KDE disables compositing when SDL apps are opened to improve performance. It should return once the app is closed. You can disable this behavior in System Settings > Display and Monitor > Compositor and unchecking Allow applications to block compositing.

Also on KDE and it works fine — but I have composing turned off.

Because it has complete copies of Lua 5.2 (src/lib/lua52), stb truetype (src/lib/stb), and SDL2 (winlib/SDL2-2.0.10) checked in.

Excluding those, it's 1369 lines of C (.c or .h), and 5389 lines of Lua (.lua), and 112 lines of other files (license, readme, build scripts...); or 78.4% Lua, 19.9% C, and 1.6% other. I didn't count fonts or images (.ttf, .ico, or .inl).

It seems to include the entirety of Lua - https://github.com/rxi/lite/tree/master/src/lib/lua52

Which is written in C.

They have all of the lua implementation checked in, which they didn't write.

Most of the implementation is oddly in the "data" folder.

Probably because that C code is the embedded Lua interpreter. See the lua.h file, there's the copyright notice at the bottom.

If you check the C sources you'll find that it's Lua itself and libSDL.

In src/main.c at line 33 i had to add an ;.

As the editor is written mostly in Lua, with C taking care of the lower level parts, plugins can typically customise anything limited to what is exposed by Lua and the C API. Beyond adding custom commands, plugins can also do things like patch straight in the DocView's line-drawing function to draw additional content:

https://user-images.githubusercontent.com/3920290/80743752-7...

Or create their own custom "views":

https://user-images.githubusercontent.com/3920290/81343656-4...

The treeview at the left of the screen is implemented as a normal plugin, and like any other plugin can be removed from lite by simply deleteing the `treeview.lua` file.

Not even that: SDL just provides a pixel buffer, the application draws everything itself per-pixel. Lite uses a technique I refer to as "cached software rendering" which allows the application code to be written as if it's doing a fullscreen-redrawn when it wants to update, the renderer cache (rencache.c) then works out which regions actually need to be redrawn at the end of the frame and redraws only those. You can call `renderer.show_debug(true)` to show these redraw regions: https://youtu.be/KtL9f6bksDQ?t=50

I wrote a short article detailing the technique here: https://rxi.github.io/200402.html

Yep:

https://github.com/rxi/lite/blob/master/src/renderer.c

I didn't check but I would assume it's based on https://github.com/rxi/microui by the same author.

Also does it come with.vim keybindings :D

I dunno why you haven't encountered it, but it's a real thing.

I remember using one editor perhaps 8 years ago, and if I tried multi-cursor mode with more than ~40 insertion points (totally reasonable to edit 40 similar lines at a time), it took a couple of seconds to register each keypress.

Similarly, other editors wind up choking on syntax highlighting, or large files, or find & replace, or documentation lookup, or whatever.

The "mysterious difficulty" you mention is often literally several seconds of latency with, say, a 30,000-line file, whether it's with opening, scrolling, editing, or the other more advanced features already mentioned.

I'm honestly pretty baffled this isn't something you've encountered before. This isn't about hertz, it's literally about entire seconds or large fractions thereof.

I develop on a 2018 dual core 16GB RAM MacBook Air, which is a lot crappier spec-wise than your gaming rig (but not crappy enough that text editing ought to be a problem). Often typing in VSCode on a large TypeScript project can take hundreds of milliseconds to register my keystrokes, which may have to do with the machine being overloaded by too many Electron apps (switching from Chrome to Firefox as my main browser already feels better), or maybe it’s that the Typescript language daemon or an errant extension is doing too much work - whatever it is, I haven’t figured it out, and dropping in some replacement text editor that claims to be fast might be a quicker way to get my dev setup more tolerable than my current experience.

I recently got Neovim working with nvim-typescript but I would be lying if I didn’t say I missed the nice UI/UX of VSCode, nor that I’m annoyed at having to spend so much time configuring my editor and memorizing shortcuts instead of actually getting things done.

So to answer your question I think part of it is that my machine is just worse than yours, and part of it is that editing text is often doing more than just editing text - in my case keystrokes trigger static analysis of a large project.

The difference in "snappiness" between Sublime Text and VS Code is extremely noticeable. The startup time in particular is substantially slower on VS Code (not just on the initial startup but also upon loading new windows)

The reason I still use VS Code is because the additional features for coding make it worth the unfortunate performance cost, but whenever I'm just working with basic markdown files I always go to something like Sublime.

When I was running Linux one metric that mattered to me in choice of editor was the time it took to launch an editor from command line.

Anything spending time loading plugins or whatever before giving you text on screen and responding to commands is frustrating if the only requirement is to quickly tweak a setting in a config file or just viewing a text file.

I guess it’s less noticeable on windows since everything is GUI based and quite unresponsive by default. But when spending your days in a terminal you get used to a certain snappiness that’s noticeable once interrupted.

Edit: Btw an interesting in-depth analysis of typing latency with measurements https://pavelfatin.com/typing-with-pleasure/

While the reason could easily be that not everyone has the horsepower you're used to (I assume 60FPS at 4K requires a certain level of hardware), people often mean something other than high speed when they say "snappy": ease of use, good descriptive UI that gives you feedback on actions and their results, certain features that simplify tasks such as integration with other tools (git compilers, etc.).

Also add other factors such as remote editing, say on a VPS with 512mb RAM with too many daemons running.

I don't think screen frame rate is a good measure when it comes to measuring editor responsiveness.

For me the only time screen response comes in to consideration is for flicker.

Editors that flicker badly can be very annoying and very distracting.

My measure of editor responsiveness would be a count based measure of the numbers times you can find yourself waiting on the editor.

Now this waiting can happen for very many different editor actions, but it is most annoying for anything that is keyboard input related.

Snappy editors have very few of these wait points, whereas slow editors drive you mad as you find yourself constantly waiting for some action to complete.

> What are they talking about!?

You're missing the point with refresh rate, you could make the slowest implementation in the Universe have a snappy UI thread.

> What is this mysterious difficulty people have with editing

> ~100KB text files!?

Most editors will open the entire file into RAM, which is not such a problem unless is starts trying to index everything for searching, colourizing everything, etc, etc. What feels like a great feature for ~10kB source files starts to chomp away at CPU and RAM for some file >1MB as your editor tries to find patterns in some binary file.

> I mean, seriously: I'm playing Doom Eternal at 4K with a

> constant 60fps, no dips. That game is processing a decent

> chunk of a terabyte per second of data at that rate.

That's quite the powerful machine you have. Consider many people will operate with laptops and some of them are low-power, high battery life. Also consider that many will not just be doing that one thing. I know quite a few people now doing serious dev work from tablets... (They use build servers.)

Also, just because you do have the latest processor available doesn't mean that I expect a simple text editor to consume everything it has.

you may find this interesting:

"Why are 2D vector graphics so much harder than 3D?"

https://blog.mecheye.net/2019/05/why-is-2d-graphics-is-harde...

I use vim as my primary editor. I've tried a number of times to pick up VSCode. The functionality is there. The modal keybindings are there. But yet it lags and I can deal with it in the short term but over the course of a day my frustration mounts and I end up going back.

There's a difference as well between refresh/frame rate and input lag. It is very much possible for a game to have a consistent 60hz frame rate but yet lag. Lag can come from delays in the input subststem, it can come from buffering before display, it can come from the display itself.

Here's a good read: https://www.eurogamer.net/articles/digitalfoundry-2017-conso...

The suspicion may also be induced by other software.

Ever tried early RStudio (or even current) on a crappy work-issued laptop? And I don't mean R, I mean the UI elements.

This is a great piece of software, certainly more than a text editor. But it isn't as fast and snappy as a native editor, far from it. It's tolerable now, but it used to be pretty bad on non beefy hardware.

At the same time, native IDEs did not have that issue at all.

This is a thing man.

I'm running a Pentium powered notebook and VS Code runs like a dog.

Another factor to consider is you might be running other things in parallel to editing your files (terminal watching and compiling code, a web browser for viewing output, etc).

try pretty much any electron app, try a web browser on mobile (these days even a simple google search sometimes freezes my phone for a few seconds with the message "unresponsive script") if you can't feel it maybe you got used to it, but try some CLI program and you'll see the difference.

> The exception is Microsoft Word, which does about 30Hz and I hate this, but it's a shitty WYSIWYG editor

Was the shitty there qualifying WYSIWYG (as in WYSIWYG editors are definitionally shitty) or qualifying MS Word (as in MS Word is a shitty editor)?

If the latter, do you have suggestions for good WYSIWYG editors?

I also think Howl is pretty nice unknown gem.

Someone made a formula: https://github.com/lincerely/homebrew-tools

   brew install lincerely/tools/lite

Or

   brew tap lincerely/tools; brew install lite

on catalina os x; I just went

  git clone https://github.com/rxi/lite.git
  cd lite
  ./build.sh
  ./lite

and an app did start up, but the text gets cut off in the editor window, and I can't quit the app from the menu

  sudo apt install libsdl2-dev

  brew install sdl2

  static double get_scale(void) {
          float dpi;
        SDL_GetDisplayDPI(0, NULL, &dpi, NULL);
  #if _WIN32
          return dpi / 96.0;
  #elif __APPLE__
          return dpi / 72.0;
  #else
          return 1.0;
  #endif
  }

  static double get_scale(void) {
          SDL_DisplayMode dm;
          SDL_GetDesktopDisplayMode(0, &dm);
          return dm.h * scale / 786.0;
  }

    Lite.app
    \- Content
        \- MacOS
           \- Lite (that's the executable file)

Nice project. Would be nice to change the key binding on mac to use the Command key instead of control. It is one of those habit and mental shift when using mac vs linux/windows.

Is there a config file where this can be changed?

Seriously. I'm all for lightweight text editors, but the ability to open a folder and a way to start a new text file is minimum viable product.

I love the mobile and web versions of Simplenote from Automattic--decent searching, basic markdown, perfect sync. But I do wish the Windows/Linux clients weren't Electron. There's a good native Mac client at least.

Try my Sciter Notes ( https://notes.sciter.com ).

It uses database for storing stuff but you can map books to folders on hard drive. And those folders can be under control of DropBox, GoogleDrive etc. So you can read shared stuff on any device using browser there.

Have you tried Notion(https://www.notion.so/)?

Lite has far less functionality than notepad.

My Lua isn't strong, but I think this is what you're looking for:

Data structure initialization: https://github.com/rxi/lite/blob/master/data/core/doc/init.l...

How insertion works here, which illuminates how the table is used: https://github.com/rxi/lite/blob/143f8867a13a35f5688ad7c9771...

Check out this paper. It talks about the different ways to manage the data structures for text editors.

https://www.cs.unm.edu/~crowley/papers/sds.pdf

Look at ropes - https://en.wikipedia.org/wiki/Rope_(data_structure)

I can't say exactly when, but I was writing it in itself before I made the initial commit on the public repo, so at least 6 months ago. Every change I made since then (in addition to the plugins I wrote) would have been written in lite itself.

GNU Emacs

(If by modern you mean actively developed)

See this thread.

https://news.ycombinator.com/item?id=23127741

There was a moment, years ago, when I used VS Code to edit text files because it was faster than Sublime and Notepad++. These days I open it begrudgingly.

Yay! Someone else on a Windows ARM machine! I have a Samsung Galaxy Book S.

I like Vim (and I've tried Emacs), but there's certainly still room for a small, hackable text editor that can be used with the same intuition that applies to the rest of a modern computer. Vim and Emacs keybindings require a time investment (that some people find worth it) to learn and get comfortable with.

It's written in Lua and doesn't use the OS GUI APIs and widgets anywhere. I'm not sure I understand what makes this more "native" than Javascript.

I 100% agree with you, but the R&D time for something like this would eclipse an equivalent effort in Javascript/web tech.

There needs to be focus on building tooling that enables rapid development of native applications. GTK is a good example. Glade is a perfectly fine editor, but the underlying tooling for GTK is a mixed bag.

I completely dislike the "isn't made is js/web/electron tech" argument

Because as you said "It's certainly not perfect yet"