Motivation about Pragtical Text Editor

[AlphonseVA]

Hiya,

I recently came across this repository and this looks extremely interesting because it looks like an actively maintained forked LiteXL with further extensible features.

What's the motivation an philosophy behind the creation of the Pragtical repository?

I might consider contributing to this repository instead of LiteXL repository in the future.

Thanks,
AlphonseVA

[jgmdev]

Greetings!

Thanks for your interest on the project! As @Jan200101 shortly described it to another user, Pragtical is "governed by technical improvements instead of ideals". Our motivations and philosophy is for the most part described on the project readme file, the name of the project was chosen based on that, here some bits from the README:

• governed through practice or action, rather than theory, speculation or idealism
• willing to see things as they really are and deal with them sensibly

As a result we belief that new features introduced through pull requests should be evaluated taking a practical approach, without going into lengthy idealistic discussions that slowdown progress, merging code when logical.

Now, let me add some background story to make the motivation clearer on why this project was forked from Lite XL.

TLDR: Many useful features were rejected by a minority (1 or 2 people) that belief Lite XL (XL which stands for Extra large) should remain minimal, even if those features proof useful and material for the core. There was a desire of freedom when contributing and merging useful work done by others when sensible and logical, moving the editor forward.

As you may already know, Lite XL was forked from Lite because rxi considered Lite to be a finished program. People wanted to add improvements and features to make the code editor better, but they were not accepted (like the improved font rendering which was one of Lite XL fork original motivation). Lite it self is a great concept, a modern looking code editor rendering on top of SDL with a lightweight and easy to use scripting language (Lua), not following the trend of many other editors that run on Web technologies, which adds a lot of bloat. But, the editor it self could see a bunch of improvements, Lite XL (the XL standing for Extra Large) was born, adding missing features to Lite and improving the overall experience and productivity which was great!

@franko the original forker of Lite XL steadily assembled a team from the active community contributors (where I was included), many people got pumped up and started contributing bug fixes and new features. Pull Requests were rapidly reviewed and merged when sensible, collaborative work achieved without much friction and releases published often with the newer fixes and improvements.

My first contribution to Lite XL was the process API (later rewritten by other contributors to replace the reproc backend), which was a requirement to my next contribution the LSP plugin. The process API was merged which let me move on to develop other useful features.

One of the things I wanted was to make Lite XL configuration more convenient, easy and accessible. At the time, configuration required scrapping all installed plugins and core config sources hunting for the right config values, which can be tedious for new and even some seasoned users. So first I needed to make writing UI components less time consuming and reusable, for which I started widgets with the intent of later shipping it as part of the core with an easy to use settings gui while also providing a reusable set of widget components to ease GUI development. While the idea was received nicely by people from the community, two contributors decided against not adding it as part of the editor it self which ended on a kind of forced additional addons release.

Then contributed a threading api to circumvent the limitations of lua coroutines with the initial idea of improving the performance when dealing with projects with several thousands of files on directory recursion for find files, project searching and a future project wide search/replace. The performance gains were measurable and speeds of 10x plus achieved. The idea of integrating the facility as part of the core was again rejected with the reasons given been: threads are dangerous or complicated, co-routines are better, too much C code for the core and even funny statements like the Linux kernel not providing real threads. I tried to convince them about the performance, technical improvements and advantages when properly used, but it resulted on useless discussions with the end result that such a feature should be a plugin and every component that relied on it an external plugin. Which didn't made sense to me given that project searching, replacing, etc... are such important features of a code editor and they need to perform well even for people who work on projects with several thousands of files.

Franko originally shipped LuaJIT builds of Lite XL which I enjoyed because of the performance improvements. But, at some point it was scrapped with reasons like: Lua 5.4 provided C facilities that some contributors wanted to use, Lua 5.4 performance been almost equal to LuaJIT (even if benchmarks proved the opposite), LuaJIT been tied to Lua 5.1, LuaJIT project not providing a tagged stable version, old LuaJIT been packed on linux distros, LuaJIT not working on MacOS, etc... So I worked on optional support of LuaJIT at compile time with a meson wrapper that allowed compiling to a specific and more recent LuaJIT commit, also integrated a lua 5.3 compatibility layer that took care of providing additional C api functions as correcting most runtime incompatibilities with newer Lua versions. Basically the optional LuaJIT support addressed most of the complains against LuaJIT, the Lite XL core practically worked perfectly with it while achieving a higher level of performance, but in the end that didn't matter and the idea was rejected with reasons including that the compatibility layer introduced too much code.

Later contributed document encoding detection and conversion support which is supported by many other popular text editors and required by the charset option of the editorconfig plugin. The code was also rejected because of the uchardet dependency (even if it is easy to compile) and the contribution scrapped as another plugin candidate.

Many ideas like these were been rejected for some time now by 1 or 2 people that took control on most aspects relating to the decision making of Lite XL. Pull Requests with time investment and good intentions have become a territory of "what if doing this is better that way, or this way, or this other way"... Don't get me wrong, planning for the best solution is great, but not when the end goal looks more like resistance that hinters progress and ends in useless discussions without any gains resulting in energy drainage. The situation got so funny that planning on including a 70kb icons font to improve and expand the available icons on the editor became a discussion of the editor becoming bloated and slow... Meanwhile I'm loading the 12MB size unifont as a fallback that provides many missing glyphs on every editor launch in just a couple of milliseconds...

In conclusion, because of the mentioned things above and other reasons not written (since the write up is already large) Pragtical was born with the idea of driving the development with a more welcoming and technical approach to collaboration and not an idealistic one (like minimalism).

[k8ieone]

Hey @jgmdev, thanks for mentioning this fork in the lpm-git package comments. I was wondering why the development in Lite XL has kinda stalled. Your explanation makes so much sense.

I'll be making the switch to Pragtical soon. Thanks for your awesome work!

[AlphonseVA]

Hey @jgmdev,

Thank you for the superb response and for stating out the philosophy of the Pragtical repository. I hope you would include documentation of the philosophy of Pragtical or how Pragtical would be different than Lite-XL somewhere in the repo when you have time.

I look forward to trying out Pragtical soon and possibly migrating to Pragtical from text editors and contributing additional plugins in my spare time. I am quite new to Lua so forgive me if I implemented bad coding styles or bad practices when I contribute.

Moving forward I can foresee some issues and initial concerns here:

• Coherency. There are would pending unmerged pull requests in Lite-XL repository which might be beneficial for Pragtical and vice-versa. Since Pragtical is a fork of Lite-XL, there might be a need to track PRs for feature equivalence?
• Collaboration. Like Lite-XL, there might be a need for a chat server or Discord or a place for contributors to discuss.

Thanks,
AlphonseVA

[AlphonseVA]

Thank you for the superb response and for stating out the philosophy of the Pragtical repository.

I am taking this back, it's listed on the intro page at https://pragtical.github.io/docs/intro

[jgmdev]

• Coherency. There are would pending unmerged pull requests in Lite-XL repository which might be beneficial for Pragtical and vice-versa. Since Pragtical is a fork of Lite-XL, there might be a need to track PRs for feature equivalence?

If you look at the commit history so far I have merged various of the open litexl PR's on Pragtical and applied several other fixes, now I'm looking forward to the project rework PR which I have working locally and the bitmaps font support.

• Collaboration. Like Lite-XL, there might be a need for a chat server or Discord or a place for contributors to discuss.

I guess we can register something on discord, but have been hesitant to do so

[k8ieone]

For a project-related chat space, I'd probably recommend Matrix over Discord.

[ShalokShalom]

@jgmdev I personally think, that this explanation of yours would do good to be linked on the README.

Currently, it goes not too much into the details of why it was forked. I perceive your explanation as very grounded, and insightful.

I do send a PR, if that is welcome.

[jgmdev]

@jgmdev I personally think, that this explanation of yours would do good to be linked on the README.

Currently, it goes not too much into the details of why it was forked. I perceive your explanation as very grounded, and insightful.

I do send a PR, if that is welcome.

If you think it would help others understands the motivation better and not cause any wars then sure.