|
| bobajeff wrote:
| I was just trying this today. Unfortunately, it's lsp plugin
| isn't in an acceptable enough state for my tastes yet.
|
| Also it's doesn't open a proper open file dialog.
|
| Lapce (which also isn't yet to ready to replace vscode for me
| yet) seems to be more complete at this point.
| symisc_devel wrote:
| What GUI Library does the editor use?
| stephc_int13 wrote:
| Last time I looked it was simple software rendering on an SDL
| windows.
|
| As simple as it goes. I was impressed by how fast it was given
| that software rendering should be quite slow, but these days
| CPU are so powerful that this might not be a problem
|
| A simple OpenGL renderer could be added with minimal efforts I
| think.
| aethy wrote:
| It's a bit more complicated to add the OpenGL renderer,
| because of subpixel font rendering. You need to sample the
| framebuffer to do it correctly in all cases, as well as a
| custom shader. It's on the list of things to do, but as you
| say, CPUs are generally powerful enough these days; so it's
| not super high-priority at the moment.
| tmtvl wrote:
| But if OpenGL was used, wouldn't that have to go through Zink
| and MoltenVK for Apple? Or is there a Zink-like OpenGL
| wrapper for Metal?
| krapp wrote:
| SDL will let you push geometry directly without needing
| OpenGL now with its geometry API, and I think all of its
| drawing functions use that by default now. I don't know if
| that's adequate compared to OpenGL but it isn't entirely
| CPU bound. Dear ImGUI's SDL renderer uses it.
| kuon wrote:
| A quick look at the source seems to indicate SDL and freetype.
| eikenberry wrote:
| GUI based, not terminal based. In case you were curious as I was.
| anarchy89 wrote:
| Is it more lightweight than neovim and vim?
| WalterBright wrote:
| Here's another one with a very small footprint:
|
| https://github.com/DigitalMars/med
|
| It's the one I use every day. The executable on Windows is a
| little over a meg. It also works on Linux and Mac.
| kennywinker wrote:
| Med appears to be a command line text editor, while this is a
| gui text editor... different beasts entirely.
| nine_k wrote:
| Med is a _text-mode_ editor.
|
| If you want a _command-line_ text editor, try the classic ed
| [1] :-D This was a kind of editor you might have to use with
| a teletype that prints on paper.
|
| [1]: https://linux.die.net/man/1/ed
| xrayarx wrote:
| for Windows, Linux and Mac OS
|
| Derivative of lite editor
|
| Plugins
|
| Lightweight:
|
| We are currently around 3MB in size and takes about 10MB in RAM
| (can be lower). The whole thing is just Lua running on a
| rendering engine.
| rahen wrote:
| > What does lightweight mean?
|
| It would traditionally mean a program running as little code as
| possible (dependencies included) for a given task, instead of
| relying on piles of pre-made libraries and frameworks, which
| obviously creep way more features than required.
|
| However in this day and age, lightweight usually means it's not
| based on a web engine, although quite often it could still be
| huge and needlessly complex.
|
| edit - post was edited in the meantime
| d3nj4l wrote:
| How was the post edited in 10 minutes?
| xrayarx wrote:
| Sorry for the edit. I found their definition of lightweight
| and added that
| lexoj wrote:
| I like it, very fast, but it has some issue with idle CPU usage
| on my M1. It stays at 70% on idle whereas sublime at 0.0% when
| not used, opening the same project.
| Octoth0rpe wrote:
| Looks like it's a known issue: https://github.com/lite-xl/lite-
| xl/issues/1237
|
| Maybe try 2.2 when it comes out?
| aethy wrote:
| Yeah; unfortunately, none of the core dev teams work on Macs,
| so while being known, it's hard to fix on our end. We'll get it
| eventually.
| kstenerud wrote:
| They have packages for pretty much every platform except Debian.
| app4soft wrote:
| Try AppImage binary.
| snshn wrote:
| Debian takes forever when it comes to adding new packages. I'm
| talking years.
| dsr_ wrote:
| That doesn't prevent you from having a build path to create a
| .deb compatible with stable and making it available. In fact,
| that's a good way to improve your chances of getting into
| Debian proper.
| aethy wrote:
| If anyone's interested, I do have a `.deb` build here; but
| it's not an official one:
| https://github.com/adamharrison/lite-xl-
| simplified/releases/...
| xrayarx wrote:
| The aim of Lite XL compared to lite is to be more user friendly,
| improve the quality of font rendering, and reduce CPU usage.
|
| Plug-ins are not necessarily compatible
| bogwog wrote:
| The plugin system is a disaster in this project. Basically,
| each "plugin" is just a Lua script that can (and often does)
| modify absolutely anything in the editor, including core data
| structures and other plugins.
|
| The original Lite was an exercise in creating a minimal editor,
| which I think succeeded. This project tries to take that base
| and expand it to add a ton of features, but doesn't re-
| architect it to support that expansion. So instead, you have a
| big bowl of Lua flavored spaghetti.
|
| On the bright side though, it does seem like the maintainers
| are dedicated to keeping it working. So if you're looking for a
| text editor, you could do worse than Lite XL.
| aethy wrote:
| Honestly, the thing that made me step into this project was
| actually this plugin interface.
|
| Adding support for halfway decent Perl syntax highlighting
| took literally 5 minutes with no familiarity with the editor
| at all, and not having used lua in years.
|
| It was extremely straightforward and refreshing, compared to
| say, writing a plugin for something like Code::Blocks.
| jinwoo68 wrote:
| I'm not sure it's a bad thing that anything can be modified
| in Lua. One of the main reasons Emacs is so powerful is
| because almost anything can be customized in elisp. I haven't
| used Lite XL and this is just an uninformed general opinion.
| iza wrote:
| I use this on an ancient Chromebook because VSCode and Lapce feel
| sluggish in comparison. What it really needs is a plugin manager.
| aethy wrote:
| We actually do have one, about to be released:
| https://github.com/adamharrison/lite-xl-plugin-manager
|
| Comes with a plugin to provide a gui in lite-xl. Once this gets
| to 1.0, we'll probably start bundling it with the `addons`
| release.
| [deleted]
| vouaobrasil wrote:
| Can this thing even word wrap? Last time I checked out Lite or
| some variation it couldn't even word wrap.
| aethy wrote:
| Yes; F10 enables word wrap. It's a plugin included in the core.
| vouaobrasil wrote:
| Thanks a lot!
|
| Edit: just tried it, it works. But unfortunately it only
| wraps on character, so it won't work for me now. As a writer
| I was looking for something more lightweight than VS code,
| and Lite XL looks promising. I'll keep an eye on it.
| aethy wrote:
| This is configurable. I use it in my android fork that I
| use for creative writing, `write-xl` (in case you're
| interested, here: https://github.com/adamharrison/write-xl
| ; not really ready for public consumption). You can set the
| word wrapping configuration via your user plugin by doing:
|
| config.plugins.linewrapping.mode = "word"
|
| The full list of options is here: https://github.com/lite-
| xl/lite-xl/blob/master/data/plugins/...
| tmtvl wrote:
| Uses SDL for rendering the UI. While it makes it work cross-
| platform it unfortunately means it won't look like a native
| application. Then again, I don't think there's a C library which
| provides cross-platform native UI, only the Lazarus toolkit for
| Free Pascal and WxWidgets for C++.
| stephc_int13 wrote:
| "Native" means compiled code (likely C/C++/Rust/Zig) for some.
| And it means using platform-specific UI widget for others.
|
| I don't care too much about the UI widget style as long as the
| implementation is good and responsive. I tend to use app in
| fullscreen (F11) with minimal chrome and to be honest I kind of
| like when each app has its own UI style, especially if it can
| be user-configured with themes.
|
| Apple/macOS users tend to fall in the other category, following
| the Apple guidance, where all apps should look like they were
| made by the same company.
| Octoth0rpe wrote:
| > Then again, I don't think there's a C library which provides
| cross-platform native UI, only the Lazarus toolkit for Free
| Pascal and WxWidgets for C++.
|
| libui seemed like it was going to be this, but it looks like
| there haven't been commits in almost 2 years :(
|
| (I'm mostly replying to raise visibility on libui, maybe
| someone will discover it/help out a bit)
| sendfoods wrote:
| There's now libui-ng [1] which seems to be active and already
| has many wrappers
|
| [1] https://libui-ng.github.io/libui-ng/
| mhd wrote:
| I wonder if people actually remember how native apps are
| supposed to look like on any of the major platforms... Mac
| users, maybe. For all other platforms, churn and barely
| contained web apps are really wreaking havoc on the benefit of
| a uniform look and - most importantly - feel.
| tmtvl wrote:
| I'm a KDE user who really likes the classic Oxygen theme, and
| it's annoying when certain applications (e.g. Eclipse) just
| look way out of place. I managed to find a decent GTK port of
| the theme so even Emacs and Firefox are quite well-behaved.
|
| No idea what a Windows app looks like, though, I recently
| fixed my grandfather's Windows 8 laptop and immediately gave
| up trying to understand how theming is meant to work.
| Yasuraka wrote:
| I stopped using lite-xl a few months back over the lack of word
| wrapping, but it looks like it's in as of October/v2.1.0
|
| It's a good stopgap between vim and vscode
| aethy wrote:
| Yup, word wrap is now a configurable core plugin. There's still
| a few minor issues with it, but it mostly works as expected.
| the__alchemist wrote:
| How does this compare to Sublime? I ask because that's my
| simple/fast editor of choice currently.
| snshn wrote:
| Looks extremely promising, cross-platform.
| vbezhenar wrote:
| Can someone suggest an editor for macOS with smart text
| algorithms to allow work on unlimited file size or line length? I
| need to view unlimited text, switch between encodings (including
| hex) and I want editor with proper algorithms, so it'll work
| instantly and without loading entire file in the memory. Should
| support search with fast regex engine.
|
| Editing would be nice too. I imagine editing as a sequence of
| actions that editor remembers and can undo/redo (including
| search/replace) and saving is actually applying that sequence of
| actions to the original file in some smart way.
|
| Also I want it to start instantly, so I can use it as my general
| text file editor.
|
| Colours, autocompletions and other nonsense is strictly not
| needed. Just black text on white background.
|
| All those editors just die when I'm trying to edit a simple file
| of several hundreds GBs with lines of several GBs.
| xrayarx wrote:
| I would suggest to post your question as a ,,ask hn". More
| people would see your questions this way
| spicybright wrote:
| I would like that too. I'm sure lots of posters will have
| excellent suggestions.
| generalizations wrote:
| There's been a lot of Ask HN's recently. It'd be nice to have
| fewer.
| globalnode wrote:
| I'd also love something that works in this situation. I've been
| contemplating writing something that does this for a while now
| but it would take a fair bit of work for the fringe cases where
| I'd actually need it, so it hasnt been written yet :(
| acdibble wrote:
| HexFiend (https://hexfiend.com/) works well for files of
| enormous size but is only a hex editor.
| taf2 wrote:
| Does vi maybe help in this case?
| foresto wrote:
| It has been so long since I last used an editor that could
| handle very large files or long lines, that I'm struggling to
| remember one. Maybe SlickEdit? The Forte Agent newsreader?
|
| The Scintilla editor widget is the cross-platform core of
| several good code editors, but I don't think it qualifies in
| this area.
|
| I hope someone chimes in with an answer on any OS.
| kenferry wrote:
| You want BBEdit
| Daunk wrote:
| I've wanted to write a small text editor for a while - cause I
| feel like most editors don't fit my workflow - but I've been a
| bit too busy with work.
|
| I don't really care about fancy features or extensions. Let me
| just create "tasks" (for compiling and such) and let me execute
| these tasks with a single button, then let me see the output from
| these tasks that eventually execute some application/compiler
| etc. That'll let me use it for any language and task.
|
| I'd also preferably like to use I J K L as the cursor keys and
| toggle "Mode" (VIM style) with TAB.
|
| And the whole thing should just run in your terminal, which can
| already render text nicely.
| properparity wrote:
| Also been thinking this.
|
| What I want from a text editor is:
|
| - Like you said, running tasks with a button/keybind, easily
| customizable (Like I wanna open a config file, add a
| function/script, bind to key/create UI button, done, not make a
| "plugin" not compile an "extension" or anything like that)
|
| - Fuzzy finding/search - ripgrep and fzf can do that, so just
| bundle those I guess, or write my implementation of those.
|
| - Must start instantly, load files instantly, every action
| needs to takes at most 100 ms.
|
| - Be a "portable application", i.e it sits in a folder with
| everything it needs and I can copy that folder to any computer
| and be up and running with exactly the same configuration.
|
| and NOTHING else.
| aethy wrote:
| This is also my general hope for lite.
|
| - Configs in lite are all done in lua files, and there are
| two files that you can edit without ever having to create a
| plugin that are automatically loaded by the editor: your
| system wide user config (a lua file), and a project file
| (.lite_project). Both of these can bind keys, create buttons,
| add functions, and whatever you like, really.
|
| - Fuzzy finding we can do, but it's not great. We're doing
| some work on this, but at the moment, we'll probably
| disappoint you.
|
| - We should start pretty instantaneously on a vanilla config,
| though for large directory trees, there's an architectural
| issue that does make us take a bit longer, that hopefully
| will be resolved in a release or two. So if you have a
| smaller directory tree, then lite should be pretty quick; if
| it's large, perhaps hold off looking at it.
|
| - lite offers fully portable releases, and infact, I have an
| all-in-one build that bundles everything into a single,
| mostly statically linked executable; it's generally very
| flexible about how things are deployed.
|
| We tend to add almost all extra functionality via plugins; so
| if you don't want a particular feature, you can simply remove
| the plugin, and be done with it.
| proxysna wrote:
| Sounds like all you need is a plugin to call makefile targets
| from vim.
| Daunk wrote:
| That is a method I've been toying with. But it's still such
| as hassle to quickly prototype something this way.
|
| It's also near impossible to get I J K L working as the
| cursor keys in VIM without having some major interference.
| hiccuphippo wrote:
| I haven't used it but there is :make which works with a
| Makefile.
| nequo wrote:
| Maybe you'd have more success in Emacs?
|
| You could write elisp functions for your tasks and bind
| them to your prefered keys, with or without Evil.
| engfan wrote:
| Actually, using Org mode and the Hyperbole package in
| Emacs solves all the problems listed in easy to use ways
| except you get much more editing dunctionality rather
| than just the features requested. Don't reinvent the
| wheel; just learn something that runs everywhere and
| solves your problems. You start Emacs once and then
| rapidly edit files from the command-line by calling
| emacsclient, not restarting Emacs.
| nine_k wrote:
| Emacs is a great software ecosystem, with a very.flexible
| editor built in.
|
| With evil-mode, there's no excuse not to try it even if
| you find Vim's way of controlling input superior (which
| it as well may be).
| aethy wrote:
| I actually authored something for this to work with my workflow
| on lite-xl (I compile a mid-sized C++ codebase on the regular).
|
| It's still not really ready for release, but it's here, in case
| you're at all interested: https://github.com/adamharrison/lite-
| xl-ide ; it's a build system and debugger integration.
|
| The build tasks don't run in a terminal however; they move over
| to a build window at the bottom of the editor. The execution,
| however, by default, runs in whatever terminal you want to
| configure, so the actual program output does dump to an
| external terminal. Unfortunately, there is no truly integrated
| terminal as of yet.
| djur wrote:
| Is there a lightweight/fast editor that has native support for
| LSP? Is it even feasible to have a "native LSP editor" that
| doesn't rely on a plugin system, or is LSP so open-ended that
| you're always going to need some scripted support in the editor
| to make a particular language server work well? I'm thinking
| something akin to nvi or nano with LSP features added on.
| dadoomer wrote:
| You might want to check the helix editor. It has LSP support
| out of the box.
___________________________________________________________________
(page generated 2022-12-27 23:00 UTC) |