[HN Gopher] Lite XL: A lightweight text editor written in Lua
___________________________________________________________________
Lite XL: A lightweight text editor written in Lua
Author : asicsp
Score : 121 points
Date : 2021-09-27 11:33 UTC (11 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Matthias1 wrote:
| This seems to just be a fork of Lite[0] that supports better text
| rendering.
|
| Lightweight GUI text editors are shocking hard to find. The
| primary reason I am not using Lite is the issues with Mac. So I'm
| definitely going to try using this.
|
| [0]: https://github.com/rxi/lite
| jcelerier wrote:
| lightweight and "good text rendering" are by essence
| incompatible, you need at the bare minimum the unicode database
| somewhere which is already at least a couple dozen megs. Add to
| this freetype and harfbuzz if you want text rendering to be
| consistent across platforms, an emoji font because it's 2021,
| and we're nearing 40 megs just for being able to render random
| text properly
| frankohn wrote:
| You are right here for the unicode part.
|
| In term of quality of the text rendering I think we managed
| to be pretty good without introducing too much complexity or
| dependency, just the Freetype library. We chose a very
| specific approach where we completely bypass the OS API for
| font rendering and we render ourselves the text using the
| freetype library.
|
| Otherwise, for the unicode part we are on the choice done by
| rxi. We support unicode but not every possible characters and
| we don't have, notably, support for Asian languages but we
| support russian, greek and some more unicode characters.
|
| For the moment we choose not go for the harfbuzz library so
| we don't have support complex text layouts and we don't
| support ligatures. The problem is that harfbuzz bring quite a
| lot of dependencies and complexity.
|
| In other term rxi chose a nice compromise to have most of the
| features needed by a coding editor with unicode support
| without bringing the huge complexity of having to support
| every possible language or text rendering features. With Lite
| XL we didn't deviate from this approach.
| romwell wrote:
| Are you the developer? Awesome!
|
| Could you explain what the differences between Lite and
| Lite XL are? At a glance, they look about the same.
| ComputerGuru wrote:
| Your statement is only not incorrect because you couched it
| with "if you want text rendering to be consistent across
| platforms" but that really has nothing to do with anything.
| Every major desktop OS has native text rendering APIs that
| you can link against without shipping any additional
| dependencies, _and they all work great_ if you 're on the
| latest OS. Just use the native APIs and you don't need to
| reinvent the wheel.
| jcelerier wrote:
| > Just use the native APIs and you
|
| cry because now your text is 2px longer on Mac than on
| Windows causing your paragraph to fold and breaking your
| layout and get user complaints that things aren't pixel-
| perfect between OSes. (if you never had that, well, you're
| a lucky person what else can I say ? for some it's a deal
| breaker.)
|
| > and they all work great if you're on the latest OS
|
| yes, I also have a few other kinks and fantasies. but for
| now, back to my macOS 10.9 and Ubuntu 14.04 users.
| ComputerGuru wrote:
| I can't tell if you're sarcastically agreeing with me or
| not, so in case you're actually serious:
|
| > cry because now your text is 2px longer on Mac than on
| Windows causing your paragraph to fold and breaking your
| layout
|
| Hopefully you don't expect everyone viewing this text
| file to only ever open it with the specific text editor
| make/model/version that you used to write it?
|
| > back to my macOS 10.9 and Ubuntu 14.04 users.
|
| Those operating system versions also provide more than
| acceptable text rendering _that the users are already
| using for everything else on their system_. Yes, the
| latest emoji won 't render. But if that really bothered
| your users, they'd have upgraded.
| jdonaldson wrote:
| I'm not sure why we can't manage to ship a unicode database
| and an open text rendering library with every user-facing
| computing device. At minimum, we need something for text like
| libuv that gives a platform abstraction on top of the various
| cross platform libraries and resources that are already
| provided, so they're not recreated ad nauseam.
| queuebert wrote:
| Since most people use only a fraction of the Unicode table,
| would it make sense to provide specific subsets as an on-
| demand download that is cached?
| wiz21c wrote:
| Oh, I'm surprised. Isn't most of this provided by the
| operating system itself ? I thought so.
| analognoise wrote:
| The wheel is rounder when we re-invent it in JS.
| contingencies wrote:
| Haha. Added to _taoup_.
| https://github.com/globalcitizen/taoup
| nikodunk wrote:
| I agree and will try it to. Question - I couldn't discern
| whether it has built-in terminal access? Or does that no longer
| qualify as lightweight?
| sigzero wrote:
| I do not think it has it built-in. There is a console plugin
| for running commands but I do not think that is a full blown
| terminal either.
| Snetry wrote:
| There is a plugin[1] that adds terminals but Lite-XL still
| has a shaky plugin api for anything extensive
|
| [1] https://github.com/benjcollins/lite-xl-terminal/#
| bityard wrote:
| I'm not familiar with either project but "just a fork" does not
| seem to be an accurate description. Lite-XL has many more
| commits and seems to be much more actively maintained. Lite's
| last commit was about 10 months ago, the last release more than
| a year ago.
| MarcusE1W wrote:
| I have used lite-xl a bit and how I understand it is that lite-
| xl aims to add a few comfort functions for the user (PRs are
| accepted for that) and lite (without -xl) gives you a very
| minimalist experience. So whatever you prefer you can choose.
| (Next to the already mentioned rendering changes)
| enticeing wrote:
| Textadept[1] is also quite nice, and configured (but not
| written) in lua. It seems to work fine in MacOS, but I haven't
| used it extensively.
|
| [1] https://orbitalquark.github.io/textadept/
| bachmeier wrote:
| An important thing to note: It has similar customizability to
| Emacs, but you write your functions in Lua rather than Lisp.
| It's more than a text editor.
| lr1970 wrote:
| > Textadept[1] is also quite nice, and configured (but not
| written) in lua. It seems to work fine in MacOS, but I
| haven't used it extensively. [1]
| https://orbitalquark.github.io/textadept/
|
| Straight from your link above:
|
| > "... the editor consists of less than 2000 lines of C code
| and less than 4000 lines of Lua code."
|
| So it is written in Lua and C (mostly for graphics widgets).
| stephc_int13 wrote:
| The font rendering of Lite was the main issue of the editor last
| time I checked.
|
| The project is impressively small and light, and quite snappy
| from what I can tell.
|
| I am a bit reluctant to switch editor again as I am happy with
| Sublime Text 4 and I don't need to change, but I think the
| approach here might be superior.
|
| I prefer using Lua than Python for configuration and
| customization.
|
| Very nice work!
| frankohn wrote:
| Many people are going to compare Lite XL to Sublime Text and
| VSCode so I would like to make a few comments about the
| comparison.
|
| Sublime Text is a more mature and has more resources than Lite
| XL. As far as I know it has a team of engineers dedicated to
| its development. It makes for an excellent editor and it is
| hard for Lite XL to compete. To my eyes the main reasons one
| *may* want to use Lite XL over Sublime Text are:
|
| 1. because Lite XL is free software 2. because customizing Lite
| XL using Lua is quite easy and fun
|
| If you are okay with being non free and you look at the
| features you may prefer Sublime Text and that's fine.
|
| Personally I moved from Sublime Text to Lite XL just because it
| isn't free. It is not only a matter of the cost of the license
| but also about the fact of being free software.
|
| If we speak about VSCode, it also has a ton of features more
| than Lite XL, a formidable set of plugins and growing and big
| company behind it with dedicated engineers so it is well placed
| to be much better than Lite XL. In reality, personally, I never
| used VSCode even before Lite XL, I was just using Sublime Text.
| The reasons I *personally* cannot tolerate to use VSCode is
| that:
|
| - it is slow to start, and it starts incrementally - the UI it
| is somewhat flickering, in the syntax highlighting and in the
| menu (for linux only) - it has a ton of popups, bells and
| whistles that are annoying to me.
|
| This is much a matter of personal preference. May people are
| tolerant to some slowness and some occasional flickering to
| have more features. In this case they may prefer VSCode and
| this is fine too.
|
| I personally prefer when the editor gets out of the way being
| fast, responsive and still nice on the eyes. In addition it is
| free software and easy to hack and this is very important too.
| BiteCode_dev wrote:
| Can you share with use what are the benefits of Sublime Text 4
| over version 3? I bought the licence for 2 and 3, but struggle
| to find a reason to upgrade.
| WD-42 wrote:
| The LSP project brings it up to par with vscode for auto
| completed and introspection, the adaptive theme that lets you
| change the ui/color theme depending on what mode your OS is
| ok is also great.
| BiteCode_dev wrote:
| Can you use Pylance with it?
| nisegami wrote:
| I believe Pylance is closed source but based on the open
| source Pyright. There appears to be a plugin for using
| Pyright with Sublime Text:
| https://github.com/sublimelsp/LSP-pyright
| jmiskovic wrote:
| It's great to see lite on front page - such an incredible feat of
| engineering, making a cozy editor in less than 5k LoC of Lua
| (plus the C host). Robust text editing, syntax highlighting,
| command palette, pane splitting and management, plugin support
| and more. Writing plugins is simple and powerful.
|
| The original lite and Lite XL are meant to run on desktops. I've
| recently started my own fork of lite[1] that allows it to run in
| VR environment. Once done I plan to use it as a competent editor
| for a VR-first development environment. I'm really digging the
| simplicity of Lua as a platform.
|
| [1] https://github.com/jmiskovic/lite-lovr
| bogwog wrote:
| This looks great! I've been looking for an open-source
| alternative to Sublime ever since the relatively underwhelming
| ST4 release.
|
| An interesting one I found was CudaText
| (https://cudatext.github.io/), which has a lot of features and is
| a solid editor but... it's written in Free Pascal. That's not a
| technology I want to deal with for what would be my #1 tool.
|
| I'll definitely be trying this out for myself soon, but it'd be
| helpful if you could include some side-by-side screenshots
| comparing the font rendering of your fork to the original,
| considering that's one of the main differences.
| webmobdev wrote:
| > but... it's written in Free Pascal. That's not a technology I
| want to deal with for what would be my #1 tool.
|
| I didn't understand your point and would appreciate some more
| clarifications. For me, even if we ignore the fact that Pascal
| and its derivatives are 20+ year old mature languages, why does
| the programming language really matter if the tool built with
| it works to your satisfaction, and as intended?
|
| In fact, _Object Pascal_ (and not Pascal) with FreePascal +
| Lazarus IDE is actually a smart choice here as it allows you to
| develop multi-platform application easily with the same
| codebase. That is how CudaText is available for nearly all the
| popular platform (and even on some of the niche platforms e.g.
| xBSD OSes). Check out the open source Lazarus RAD IDE -
| https://www.lazarus-ide.org/ as it is a hidden gem for multi-
| platform development that not everyone is really aware of.
| analognoise wrote:
| Free Pascal tech slaps.
|
| Honestly it crushes just about...well, everything. There's
| even a JS transpiler, it's lightning fast, and it's
| beautiful.
|
| If you evaluate it on its technical merits, it absolutely
| stomps. The community is AWESOME too - people just making
| things because they want to, not because it's some resume
| padding fad framework BS, there's a lot of people who
| understand the actual concepts and will talk to you about
| them.
|
| It is beautiful, and amazing. A 5-10MB executable, just like
| you had in 1998. Lightning fast. BGRABitmap and BGRAControls?
| STOMP.
| https://wiki.freepascal.org/BGRAControls#BGRAVirtualScreen
|
| Oh, you can draw natively just like you would on an HTML5
| canvas, but without the overhead of a browser?
| https://wiki.freepascal.org/BGRABitmap_tutorial_14
|
| FreePascal/Lazrus are practically a hidden weapon.
| bogwog wrote:
| > why does the programming language really matter if the tool
| built with it works to your satisfaction, and as intended?
|
| Because the reason I'm looking to move away from ST4 is
| because I was disappointed with the features and
| pace/direction of development. I want an open source text
| editor that I can customize however I want (and possibly
| embed in my projects), so something written in a language I
| have no interest in and/or dislike isn't going to work for
| me.
| pwdisswordfish0 wrote:
| Does Lua differ in that regard? Lua seems to be tolerated
| (as a necessary evil, for certain definitions of
| "necessary") more than it is actively enjoyed. Not obvious
| why Object Pascal wouldn't be viewed the same and couldn't
| be treated the same.
| folkhack wrote:
| Pascal was a big part of my learning to program (Turbo
| Pascal). Current day opinion on Pascal is that it's a
| dead language without much of an ecosystem. It's just the
| harsh truth.
|
| Lua ended up as a "DSL" in a ton of places for general
| scripting applications etc. When I say "DSL" I get that
| it's not, I'm just generalizing as to the _type_ of
| solutions that I 've personally seen Lua leveraged. With
| this sorta "Lua in random places" bit I feel lots of us
| have ran into it.
|
| When comparing Pascal to Lua I would be more comfortable
| with Lua for a modern solution - I would posit that very
| little greenfield development is happening in Pascal. Lua
| continues to be present in-industry.
|
| This entire comment is anecdotal and based on personal
| experience.
| webmobdev wrote:
| That makes sense - I didn't consider that you may want to
| change the code yourself.
| asicsp wrote:
| > _it 'd be helpful if you could include_
|
| I'm not the author, just sharing the repo here. I'd suggest to
| open an issue.
| pull_my_finger wrote:
| One thing that bothered me about Lite editor, was that you
| couldn't change your working directory in Lite. Is this
| fixed/implemented in Lite XL?
| bogwog wrote:
| Yeah, you can change the current folder with the `Core: Change
| Project Folder` command, and you can add/close folders with
| `Core: Add Directory` and `Core: Remove Directory`. (These are
| run with CTRL+SHIFT+P)
| widdershins wrote:
| Does this really warrant a fork? Couldn't better font rendering
| be merged into Lite? It's an interesting and quite new text
| editor. Getting traction for a new editor is hard, and having
| multiple forks seems like it could make it even harder.
| frankohn wrote:
| Author of the Lite XL fork here. The reason why I started a
| fork of Lite is that rxi, the author of the original project,
| refused to merge my proposition to improve the font rendering.
| He didn't want to bring too much complexity to the project.
|
| In more general terms the author or Lite, rxi, values a lot
| simplicity in term of coding implementation even when some
| things are unfriendly or annoying for the user. So my decision
| was to fork Lite to create an alternative project that has a
| different compromise between simplicity and user friendliness.
|
| Now Lite XL has a small but awesome group of contributors to
| the project. We still value simplicity and we are trying to
| keep a good balance between features and complexity of the
| implementation but our main goal for the editor is to be
| friendly and useful as a general purpose coding editor.
|
| I have a very high opinion of rxi. To me the original project,
| Lite, is a constant source of inspiration. Even if we have made
| a fork of its project we highly value the principles and
| software practices established by rxi.
| asicsp wrote:
| Here's the full reasoning mentioned in the README:
|
| > _The aim of Lite XL compared to lite is to be more user
| friendly, improve the quality of font rendering, and reduce CPU
| usage._
| biryani_chicken wrote:
| After using vscode for a while, lite is amazingly fast. It is now
| my default editor for things that don't need a specific vscode
| extension.
| jakearmitage wrote:
| What was actually improved? Hinting? Using harfbuzz?
| frankohn wrote:
| Lite XL use the freetype library for font rendering instead of
| the stb_truetype library.
|
| Using the freetype library we do hinting but only in the
| vertical axis and subpixel rendering and positioning along the
| horizontal axis. This is the so called "slight" hinting and it
| was used with subpixel rendering.
|
| The original Lite on the other side doesn't do any hinting and
| is not doing subpixel either, it just does grayscale rendering.
| buckbee wrote:
| In order to reduce complexity in the main project, can't you
| separate freetype into a tool that caches fonts as bitmap
| glyphmaps, and use the glyphmaps directly? That way, the
| editor itself doesn't need to worry about that.
| frankohn wrote:
| Looks like more complexity and that would prevent users
| from changing fonts in their preferences.
| jakearmitage wrote:
| Right now, how does it work? Does it build a glyphmap
| everytime the editor starts?
| [deleted]
| kruxigt wrote:
| Non rhetorical question: what is the reason for this to exist?
| How does it compare to other text editors such as Sublime?
| schipplock wrote:
| Textadept is another lua-based text editor (
| https://orbitalquark.github.io/textadept/).
| madis wrote:
| Why?
| jakearmitage wrote:
| Does this support multiple carets?
| hknapp wrote:
| I wish there was a lightweight GUI editor that supported LSP plus
| a few other IDE functions
___________________________________________________________________
(page generated 2021-09-27 23:02 UTC)