Show HN: Lite – A small, fast text editor
github.com
github.com
SDL seems to offer font hinting which would somewhat solve the immediate problem, but I'm not sure it's being used properly here. With that said, text rendering is optimized for the current device's DPI, so maybe I'm just reading too much into a screenshot taken at a different DPI.
[1] https://user-images.githubusercontent.com/3920290/81471642-6...
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.
[1] https://arstechnica.com/features/2018/09/macos-10-14-mojave-...
i am still using a non-retina monitor for all of my day-to-day work. when i first installed mojave, it made my display look so bad that it gave me headaches. so i wiped my mac entirely and re-installed the previous version of macos. later, i learned that subpixel anti-aliasing is still there, it just takes some fiddling to get it back.
https://www.howtogeek.com/358596/how-to-fix-blurry-fonts-on-...
eventually, i will have to get with the program and buy a retina display. but i am thankful for this loophole that allowed me to put it off for awhile.
I’m so glad I did. Night and day difference.
This isn't true.
edit: though it uses Scintilla for the "engine" and I would assume its LOC count is not counted towards this limit.
For now, lite also lacks "open folder", but it shows tree view of current directory atleast
From textadepts FAQ:
Q: Why can’t Textadept handle HUGE files very well?
A: Textadept is an editor for programmers. It is unlikely a programmer would be editing a gigantic log file. There are other tools for that case.
But what it still doesn’t replace is my favorite editor EmEditor [0] (Windows only). Like every alternative I’ve checked out, Lite blocks for a long time when opening a multi-gb file. They aren’t FOSS and probably more expensive than any other text editor, but I’d love to know what they do to have such superior large file performance (the free version is fast, the paid version even supports streaming-loading of parts of the file).
Also the immediate UI library from the same author is very good and the examples are amazing.
To me this is simply mind-blowing.
(They weren't big files, of course, but still. Standards have slipped.)
Indeed standards have slipped or better say have been sacrificed at the altar of "quantity over quality".
For a simple "Hello, World!" string message, nowadays you need how many MBs of RAM.
Madness, complete madness!
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.
That said looking at the author's main.c this looks really nice as a shell for anyone looking to create a tool with lua scripting. Im going to download and study this one!
I.e. side-panel is too large, find+replace menu is modal and confusing.
Different approaches to extensibility can exist, all of them good in certain areas. Both Emacs and VS Code are extensible; which approach is better? You'll find different opinions.
You'll need, as a minimum, to specify a language to move "integration with favorite programming language" towards objectivity.
First, an open-ended survey among text editor users to identify the features/requirements that matter to them.
Second, tag and categorize those responses into a standardized list of features/requirements.
Third, survey users to determine both the relative importances of those features/requirements, as well as how well each editor meets their needs for each feature/requirement. Both of these can be done using Likert scales, most commonly giving a score between 1 (does not meet needs at all) to 5 (completely meets needs), with intermediate values being "mostly doesn't", "somewhat", and "mostly". Several hundred randomly chosen survey respondents will generally give you the statistical precision you need.
Companies do this all the time. It's bread and butter for many product managers and user researchers, to justify to execs why a particular feature ought to be built rather than other ones (combined with other factors like cost, risk, strategy, etc.).
And there you have it. To answer your specific question, to measure how well a text editor integrates with a programming language, you just ask its users to rate how well it does. Since user opinion is all that matters in the end, that's the objective answer.
When it comes to products, people's average evaluation is the objective answer. Because people's evaluations are what lead to usage, purchase, subscriptions, etc. There is no other "objective" answer.
There's nothing subjective about it. What users think about your product is your product in the marketplace. That's the entire meaning of "the customer is always right".
Satisfying user demand for a capability isn't a mathematics problem where there's some independently objectively right answer.
In other words, there's no objective product goodness/badness. Only what the customer wants. In that sense, the customer (market) is always right.
Inexperienced restauranteurs often experience the same shock. You don't cook the food you want to make, or that you think people ought to eat -- you cook the food people want to eat. Otherwise you'll go out of business.
It's a bad slogan that only portrays half of the reality of the situation.
Kate is a surprisingly good/fast editor nowadays.
I'm not expecting it to have any of the features I'm used to with VS Code or JetBrains products, but it's definitely going to replace notepad.exe for a fast look at any text file.
Supports `lite <path>` to open any file/folder, e.g. `lite .` opens up the current folder in a tree view with beautiful dark mode by default, single click on each file loads it instantly. Seeing beautiful, matte-style syntax highlighting for all popular formats I've tried: .html, .css, .js, .md.
Perfect minimal distraction-free editor for writing docs.
Thought I'd give this a quick try on my Windows machines, where my liteweight editor of choice is Notepad3.
A fresh start of Lite uses 10MB of memory, vs 3MB for Notepad3.
After opening a 27.5MB text file in each, Lite used 156MB of memory, vs 68 for Notepad3.
The functionality available in Notepad3 is also vastly superior. Lite is pretty spartan - it doesn't even appear to have a file/directory selection dialog to open files/folders with. I really like the default colour scheme/theme Lite ships with though.
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.)
Font Rendering does not seem to be as crisp as needed for a text editor. (on Windows at least)
I know Sublime is using DirectWrite to render fonts on Win32, this might be something to explore. Also, TrueType with subpixel antialiasing should give good results but might need some tweaking.
I'll follow this project and I might use it as my main editor once it is more mature :)
But upon starting it up I lost all windows decorations (KDE), had to restart my session and lost the things I was working on in my terminals.
How can launching an app cripples the whole desktop ? (not that this have anything to do with the app to me, it's a plasma thing)
First thing I look for was support for vim keybinding, could neovim be used as the backend editor ?
It's not the first time something like that happened to me but I would never have had the patience to investigate !
Can confirm unchecking that setting solved that problem.
Compositing should only provide the fancy effects like Wobbly Windows and window previews in the alt-tab switcher etc. Not sure why this is causing KWin to crash... You can use Alt-Shift-F12 by default to toggle compositing.
But if you're not doing anything more graphically intense than playing turn-based or slow-paced video games then I guess you can use that option to permanently leave on compositing.
[1] https://www.youtube.com/channel/UC1eJk1sWcUYvBwnn7v5RLaQ/vid...
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).
Which is written in C.
Most of the implementation is oddly in the "data" folder.
C version:
https://github.com/DigitalMars/me
D version:
https://github.com/DigitalMars/med
The source is so simple, the "extension language" is just editing the code.
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.
I wrote a short article detailing the technique here: https://rxi.github.io/200402.html
Windows, MacOS and GTK maintain internal pixmap buffer for a window.
And when needed you call InvlidateRect(wnd,rc) and receive WM_PAINT with cumulative rect to update.
Personally, I would create an abstraction that wraps couple of functions of GDI, CoreGraphics and Cairo and use it instead manual pixmap rendering. Will be faster and more flexible. All that UI can be rendered by just 2..3 functions FillRect, DrawText, MeasureText.
With dirty rectangles, it's the application's responsibility to minimize much of its drawing; the renderer will at best avoid copying bits where the target of the bits lies outside the drawing rectangle. The renderer can only optimize in situations where the entire call is understood as a full primitive, and it knows that the result will lie outside the dirty rectangle.
With rxi's approach, the application gets to define the commands which update the UI - which may be as complex as desired, as long as they have a calculable rectangle - and the cost of calculating that rendering can be skipped, without needing to query for dirty rectangles or doing any application-side conditional logic, beyond the layer that rxi wrote.
It's particularly powerful if the rendering primitives are higher level than those provided by the native APIs.
Check https://docs.microsoft.com/en-us/windows/win32/learnwin32/pa...
If your question is about unified wrapper for multiple platforms then wxWidgets will qualify : https://wiki.wxwidgets.org/Painting_your_custom_control
As my Sciter where I wrapped Direct2D/DirectX, Skia/OpenGL, CoreGraphics, Cairo, GDI+ into class graphics abstraction so rest of code is isolated from particular paltform/backend used: https://github.com/c-smile/sciter-sdk/blob/master/include/be...
Typically with dirty rectangles you would have to manage this state in the application code, for example, determining that line X was edited then updating the region for that line, or determining that view Y moved and updating a dirty rectangle based upon it's previous and current positions.
(Dirty rectangles are still perfectly common in desktop apps for when you e.g. drag a window back on screen after overlapping the edge, or if you scroll a window.)
You can get additional benefits from this approach, by doing multiple layers of it (e.g. having scrollable surfaces have their own tiles that precompute the inner-document-viewport-space rather than the outer-viewport-space, such that the inner tiles aren't invalidated by scrolling the outer viewport.) This technique ends up forming a tree of tiles, where tiles higher up the tree, when invalidated, re-render trivially by compositing tiles further down the tree into themselves. Thus, another name for this approach is a "precompositing tree."
The difference between this approach and dirty rects, is in the direction of information flow. In tile-based precompositing, the information only flows in one direction—from the user, through view-controller, into the DOM, to the tiles, and then out the display. Dirty rects, meanwhile, are a signal sent backwards, from the display system to the program, essentially telling it that the display system lost/discarded the information needed to re-draw an area, so could the program please send it over again. (The program doesn't even have to re-render in response; some dirty-rects implementations, like X11's DAMAGE extension, just involve the client application re-transmitting pixbuf data to the server from its own precomposited buffer.)
Also, dirty rects / screen-damage doesn't solve the problem of hardware not being fast enough; it solves the problem of hardware not having enough VRAM to do per-frame compositing from undamaged intermediates. In low-VRAM conditions, you can only keep around the final pre-composited image; and so any time you "damage" / make "dirty" a region of the screen (e.g. by removing an overdrawn element, which should have the semantics of revealing whatever was there before that element overdrew it) then you need to propagate a request back to the renderer to re-draw (and, for efficiency, re-draw just that region), because you don't just have an intermediate texture laying around for that window/stage-layer/etc. to re-source it from. If you did, then dirty-rects would never come into play, since you'd just re-composite everything each frame. (Which is cheap even on old-school CPU-only blitters—you just have to alternate which pixmap pointer you're basing your LOADs off of using either a rect-overlap check, or a mask-bitmap [which gets you 8 pixels' mask-states per LOAD.] Even the Gameboy can do it!)
That’s what I meant, yes. Interesting approach and impressive.
The technique does sound similar to me. Both (as I understand it) maintain a representation in memory of the final rendering and use a diff to determine which parts of the rendering to perform. The "virtual DOM" technique isn't strictly tied to a browser DOM, though the term is a reference to that, and React's (in particular) has been adapted to many other rendering targets.
I'd be happy to learn more if you'd be kind enough to explain what I misunderstood.
DOM based systems use so called retained mode rendering. But this one uses something that can be classified as immediate mode rendering.
Check https://docs.microsoft.com/en-us/windows/win32/learnwin32/re...
A virtual DOM, to me, means that the application renders by, every time, constructing data structures which are handed off to be reconciled with the display.
If, as in an HTML application, you render by means of a retained mode real DOM, then the reconciliation is via comparison of the virtual with the real. But that's not the only way to handle the output of the construction of a virtual DOM; it could figure out how those structures intersect with the dirty rectangle/s, and only render the subtree of the DOM which applies.
rxi's technique resembles a virtual DOM of depth 2 (1 root and everything is a child) and absolute positioning, though it's even closer to an OpenGL display list or combined vertex & command buffer. For that reason, I think it's a little bit of a stretch; not on the virtual DOM angle, but on the not particularly DOM-like nature of the drawing commands.
That's wrong. virtual DOM is always a parallel structure to real DOM - projection of it. That's by definition of it.
From vDOM authors: https://reactjs.org/docs/faq-internals.html
> The virtual DOM (VDOM) is a programming concept where an ideal, or “virtual”, representation of a UI is kept in memory and synced with the “real” DOM
No, it doesn't. I addressed this in the comment above. React's virtual DOM has been used to render:
- Plain HTML (e.g. server-side rendering) - Native UI framework objects (e.g. React Native) - Text-based interfaces (e.g. Ink) - Smart TV devices (e.g. Netflix's Gibbon) - Browser `<canvas>` elements - Markdown formatted text
And a whole bunch of other targets.
> DOM based systems use so called retained mode rendering. But this one uses something that can be classified as immediate mode rendering.
This seems orthogonal to the question? I'm not trying to be difficult, I sincerely don't understand why this would mean the two are "not even close".
React Native uses DOM, the only nuance is that that DOM is a tree of native widgets/windows which is a perfect DOM.
Again, virtual DOM is a projection of real DOM in one form or another. It could be a tree of anything that can be represented by attributed nodes and leaves.
DOM tree has nothing with rendering and pixels, that's why "not even close". By using virtual DOM you can update (by diffing) some tree that even has no visual representation in principle - it is pure data structure. Think about abstract XML config that can be reconciliated with its virtual DOM.
> The Document Object Model (DOM) is a programming API for HTML and XML documents.
I was unable to find any other usage.
In reality, I think it would be more accurate to refer to the virtual DOM (at least React's, I haven't spent much time familiarizing myself with other implementations with the same naming) as a virtual output data structure, where the output may be rendered to a screen, it may be rendered to a string serialization, or any other output... but the role it plays (when it performs well) is to optimize output over time by minimizing changes pushed to its destination. One of those output targets is the DOM.
You chose to respond to one of my examples among many non-DOM React renderers, but another one very much has everything to do with rendering and pixels, and that's canvas.
And pixels, to a software, are just another data structure. Software doesn't emit light from an LED or a diode, it just provides data to a hardware which produces physical side effects.
Honestly, this has been an enlightening discussion, but primarily because I've been reminded that my instincts for engaging dismissive comments on the internet are there for a reason. I don't hope to convince you, I don't think any further engagement would be productive, have a nice weekend.
Sigh. Virtual DOM has nothing with rendering.
Virtual DOM was introduced as a lightweight construct to generate and modify tree of nodes.
When the structure is generated it is used as a prototype for updating "master" DOM (or any other tree of nodes).
Any modern UI system is a tree of widgets/windows - child has one and only one parent. So vDOM can be applied as to HTML/XML DOM as to native UI tree of widgets/windows. That's why there are React, Native React and my native implementation of React in Sciter (https://sciter.com/docs/content/reactor/helloworld.htm) for that matter.
Just treat "DOM" as a short name for tree of nodes where each node has a) tag(or type or class) b) collection of attributes and c) collection of children. Nothing more, nothing less.
In any case, I have no idea where here is the place for "grid of pixels ".
I saw some comments here about a WASM renderer-based editor, I think there is something in Flutter that is similar, where Flutter uses Skia to render its components.
What are they talking about!?
I mean that as someone who has grown up with 3D shooters and is obsessive about tuning networks to the lowest possible ping times to improve latency for competitive gaming. I always turn triple buffering off because I can definitely feel the difference over double buffering.
Practically every editor I use updates with the maximum 60Hz refresh of my monitor, and that literally can't be improved upon any further through software alone. The exception is Microsoft Word, which does about 30Hz and I hate this, but it's a shitty WYSIWYG editor, not a simple fixed-width text editor.
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.
What is this mysterious difficulty people have with editing ~100KB text files!?
Either this forum is full of people editing insane multi-gigabyte files (By hand? Why!?) or they're doing it on their 486SX PCs for nostalgia reasons.
I seriously don't get it.
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.
Notably, they're all Windows native apps written in C++, with the exception of VS Code, which is partially JavaScript.
I've noticed that some of them struggle with huge (1 GB) files, but editing such as large file is a somewhat strange thing to do.
But I hope what I described makes sense to you. It's not about 1 GB files at all, it's about regular files. My suspicion is that it's mostly "side features" that start to grind when they get beyond a certain point.
To be more specific with one example, I've used another code editor that a simple "find all" operation will populate a results box. If you mess up your regex to be accidentally super-generic and it finds 100,000 results in your 20K-line file, it takes half a minute to load the results into the results box and become responsive again, with no "cancel" button.
Similarly weird edge cases in a syntax highlighter interacting with a half-finished line of code of yours causes something to choke up. That kind of thing.
Do you understand now? Again, you seem to just be lucky that you haven't encountered this kind of thing.
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 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.
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/
Also add other factors such as remote editing, say on a VPS with 512mb RAM with too many daemons running.
I really like the new VS Code remote-editing feature, where the GUI is local but you can work directly on the remote system.
Visual Studio has a vaguely similar "remote debugger" feature.
Generally I avoid remote development like the plague. As you said, the latency is quite noticeable through any kind of remote connection.
Pro tip for anyone using Windows: Modern versions limit RDP to 30Hz by default, irrespective of CPU power or available bandwidth. See this MS article on how to remove the limitation: https://support.microsoft.com/en-au/help/2885213/frame-rate-...
I always set this to 60 Hz on high-performance "workstation" VDI systems used by developers.
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.
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.
"Why are 2D vector graphics so much harder than 3D?"
https://blog.mecheye.net/2019/05/why-is-2d-graphics-is-harde...
Admittedly, not a 2D text engine, but I keep up with the research.
The difference between the blog post you linked and a programmer's text editor is night & day.
There's a huge difference between arbitrary 2D graphics and fixed-width text rendering. The former has crazy complex corner-cases, and also has to deal with all of the fun things 3D engines do such as arbitrary transformations and transparency.
A web browser has to deal with the arbitrary case, which is why Firefox's new Rust-based renderer took so many years of hard work to write. It's a complex beast.
A fixed-width text editor is more or less just putting sprites on a grid. Sure, there's subpixel alignment, antialiasing, and maybe even ligatures, but this is nothing really in comparison. They're all "local" issues where typically at most a few hundred pixels are affected per character update.
Or to put it another way, text editor rendering is "embarrassingly parallel". The screen can be split up into lines or char blocks and each can be drawn separately and updated individually when modified.
Compare this to 3D games that are pumping out 4K pixels every frame, updating all of them every time. Web browsers do the same thing, they have to update the entire screen every frame in a lot of scenarios and can manage this at 60 Hz too. Firefox and Chrome both can do this now for much more complex scenarios than text editing.
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...
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.
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).
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 write a lot of reports these days, and the Word editor interface drives me crazy. Like I said, it's slow, irrespective of the hardware. It can't even maintain a consistent 30 Hz on a high-end gaming rig when editing plain-text paragraphs with no special formatting. I suspect it's throttled internally, but it could just be badly written.
The editor is also very glitchy in the way it handles formatting. Lots of little annoyances just haven't been fixed and have been left there to fester for decades. It's all too easy to corrupt a document's styles to the point that the only reasonable fix is to carefully cut & paste all content into a new document, going through Notepad on the way to guarantee all hints of the original formatting are stripped.
I used textadept for a while, bought the book to support the author. It didn't work out for me.
Since I really like the looks of it, in case you do need help with keeping it maintained, I would love to help! Feel free to contact me at contact@taigi100.com
Good luck and I hope it all goes well with this text editor!
brew install lincerely/tools/lite
brew tap lincerely/tools; brew install lite git clone https://github.com/rxi/lite.git
cd lite
./build.sh
./lite
Fixed this with:
sudo apt install libsdl2-dev
Else it works as tingletech described also using Mint/Ubuntu.
Update: I can install this using brew install sdl2 https://medium.com/@edkins.sarah/set-up-sdl2-on-your-mac-wit...
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;
}
There should be a separate feature to handle higher-resolution screens.
Anyway, it feels really easy to change anything in this editor.
To make App bundles you have to create the following directory structure:
Lite.app
\- Content
\- MacOS
\- Lite (that's the executable file)
To add an icon you need a plist and a icns file [2].
I know it looks cumbersome, but it pays off when you need to bundle multiple files with your app.
-
[1] https://gist.github.com/mathiasbynens/674099
[2] https://stackoverflow.com/questions/1596945/building-osx-app...
also fonts are a bit big on retina screen.
Is there a config file where this can be changed?
I currently use Google Keep, which is incredibly slow
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.
- Too many frills
- Too slow
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...
There's a good post on the Visual Studio Code blog about why and when they moved on from an array of lines to a new structure based on a piece table.
https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...
It's two dynamic arrays, of hashes and values, whose sizes grow as powers of two.
Any plans of getting this into the arch repo?
(If by modern you mean actively developed)
Or are you drawing the line because Lua is a scripting language?
Is a WASM app that renders to WebGL native?
I guess the point is native should probably mean “using the toolkit the OS provides” and we should just use “performant” in most cases.
Native means using the native UI toolkit. Or if not about UIs, it can mean compiled to native machine code ahead of time.
People used to care about native vs non-native because of the look and feel.
Now people are complaining about performance, memory use, and startup times. Everyone would be happy using a non native toolkit if it was fast, used little memory and started quickly.
Why can't we be precise with our language? We're engineers, it seems critical to use precise terminology. If you don't like the look and feels let's discuss that, if you don't like the memory use, let's discuss that, if you don't like the distribution or install size, let's discuss that.
wxwidget guys on IRC used to showcase how their buttons titlebars and menus blended with the windows xp back in early 2000 but I'm sure they are past that at this point.
e.g. compare Telegram made in Qt Widgets with Signal made with Electron - the latter is incredibly slow to come up (and has broken text rendering) while the former is more or less instant on my machine (which is an overpowered i7...): https://streamable.com/m48hg7
fun fact: approaches such as Qt or also Flutter from what I could see can be more performant than some of the OS-provided UIs of some platforms - in particular Android is a pretty slow mess while Qt has seen a lot of work poured into running on <1Ghz devices.
But... this setup may be a lot simpler, but no different from Electron in that they are both scripting languages that eventually use C to render.
Also, you can’t just cherry pick an example. It’s very possible to write pretty fast interfaces using v8. Certainly going straight html/css is slow, but that’s not necessary and VSCode is a great counter example (not crazy fast, but faster than many “native” apps).
I think the HN crowd has invested so much emotional energy into hating electron they literally can’t think straight about it, including just admitting that this is no more native than any electron app.
In fact, if you take native to mean some combination of “using OS APIs” and “accessibility support and behavior similar to the OS”, then electron wins hands down because of the latter part: font rendering, text selection, input controls, copy and paste, everything mostly just works like native. It’s the Lua app that I’d say is far less native. It’s just a bit faster.
People don't use Electron to get a js runtime, they use it to get a web-like runtime. Any javascript (including WASM) app can run without electron in either node or in the bundled runtimes that OSX/Windows/Gnome/Whatever has, but the point of electron isn't to write JS, it's to write web-like code. For that it requires a browser in a predictable version, which is what electron gives you (albeit at a high cost.)
But one thing I think is being missed here is that Lua, Python, and other scripting languages are just a lot more resource efficient than electron, in terms of runtime size, memory usage, cpu usage, etc. A very highly optimized Electron app like VS Code might outperform a more run-of-the-mill Lua app, but that's an outlier.
If you want to compare them then compare node.js or JavaScriptCore to lua. Or compare Electron with a lua runtime that has a webkit/chromium engine integration.
I don't especially like Electron, and sometimes like writing lua, but the two are not solving the same problem or competing in the same space.
Edit: What does LAF stand for?
The rest of the application, being in Java, will often means it will have your typical JVM high memory usage and slow startup times.
What is the material difference?
This editor could have been written in js and use the exact same libs for rendering. If it used one of the smaller js runtimes (like quickjs) I'm guessing it would have been similar in size and pretty close in performance.
I don't get why you are conflating using a certain language with bundling a full browser (like electron does). It's two completely different things.
Not using a full blown web rendering engine (if that's the case) but OS painting (not necessarily GUI) APIs would make it much more native in my eyes...
It's more "native" because the stack is much shorter, much more direct. If it was more common to have plain JS interacting directly with input APIs and plain canvas, the argument for parity would be stronger. But it's just very rarely the case.
It is not running on a web browser shaped to act like a text editor instead.
It's a webscripting language. Which is totally fine but it will never be native.
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 think this is less true when you don't assume people know all about web tech already, IOW there would be less of a difference for someone coming into software dev completely naive of web tech.
> There needs to be focus on building tooling that enables rapid development of native applications.
Fully agree.
Move fast and break things has become the cancer of software engineering.
Because as you said "It's certainly not perfect yet"