Pages

Thursday, July 25, 2024

A 5-day journey with Lite-XL

There's an ancient Chinese saying(which is also famous in Korea), 日新又日新, meaning that "renew myself day by day." With the saying in mind, occasionally I try new development environments and tools, as other good developers do.

During the time I was a bit skeptical about "modal editing" scheme, represented by Vim, changing modes-Insert, Normal, Visual- to do certain stuff. Why would I be concerned with the mode? If I can do everything without changing modes, wouldn't it save both time and my mental resources(e.g. being concerned with mode)?

With that in mind, I tried to search for a good substitute for my precious Vim and amid the search activity I found Lite-XL. Though I'm back to Vim, the 5-day journey with the Lua-based coding editor was impressive, so I'd like to leave a record to remember the fun during the journey.

Too small footprint

Literally. Like Vim, it has small footprint. Though memory consumption was a bit higher than Vim for fresh run, but compared with modern "heavyweight" IDE-like code editors, and considering that it's built in Lua, a versatile scripting language, it was impressive.

However, it also means that it barely has anything, like vanilla Vim. To be more productive, you need to install and configure plugins, e.g. LSP, indent guide, or highlighting same words of current selection in the document.

And where there's .vimrc in Vim, there's .config/lite-xl/* in Lite-XL. There are a handful of Lua scripts there, and you can add your own configurations and initializations as needed. Configuration is fully manual and in Lua, but you no worries even though you're not familiar with the language, like I do. Follow the instructions for each plugin and you'll be fine, though I had to be careful to not lose any details when reading them(maybe that's because I'm not an English speaker? ;) ).

Fully responsive, always

Lite-XL was always responsive with nice scrolling animations. Whether it be searching among files or dealing with command palette, it was always like shouting "I'm lightweight enough so that I can fly!".

LSP: some better, some missing

LSP plugin is satisfactory. Though the official github repository for Lite-XL LSP plugin says that it is WIP, but still most major features are already ready to serve, and the overlay was quite informative, and, most of all, non-interrupting. I'm sure you know what I mean if you saw messages in virtual texts when running Vim LSP plugins. Even showing overloads was better with Lite-XL.

However, its symbol search dialogs and commands were a bit confusing, and missed some small utilities I enjoyed(e.g. symbol search with full symbol list and their types). But that's fine - maybe I was just not familiar with new interface, and I didn't invest ,much time or efforts on changing my workflow for the unfamiliar interface.

Weapons hot keys (almost) everywhere

The developers must be concerned with their right hands traveling between keyboard and mouse, and they want to minimize using mouse.

Where there is a frequently used feature, there's a hot key dedicated for it. I'm sure that Lite-XL developers must use Lite-XL themselves on developing stuff and they're also "speed freaks", to NOT allow any time loss regarding your keystrokes.

The only thing I was confused was that window splitting - Lite-XL used `<Alt> + ijkl` while Vim used `Ctrl-W` with its famous `hjkl` combination. :P

Handling too big files is slow (feat. 4GB.txt)

It's rare but sometimes I have to deal with log files with a few GBs in size. Vim 9 handled them really well. It opened the file in a few seconds and the file is already ready to serve.

When I tried to open the same file with Lite-XL, it took a few minutes to open, and sometimes the editor lagged. I don't think that's simply a limit for scripting language, as I saw Visual Studio Code, written in Javascript, could handle the same file really well, except for memory consumption(lol).

Anyway, I think that's not the case for everyone, so I think you can safely ignore if you don't have to handle REALLY BIG text files.

Don't do git checkout on editing (huh?)

While opening some files with Lite-XL, I git checkouted my project, some open files changed, and the editor crashed(oops). I'm not sure whether I was just unfortunate or it was a bug, but anyway it happened.

Small, versatile, but a few oops

There's a joke in Korea that while women are enthusiastic about rating and reviewing restaurants, men write the review in only two occasions: it's so bad that you'd announce "don't go there it's enough only for me to be the scapegoat", or it's really great that you think "man it's damn great I want to spread the words so that the restaurant can sustain more."

For Lite-XL, this is the latter. It's damn great, especially if you're in thirsty for lightweight alternative against Visual Studio Code yet don't want to face the deep valley of learning curve for Vim(one thing: though I'm a Vim user, I don't think everyone needs to learn Vim for their maximum productivity. Rather, I'm against it - there are so many ways to accomplish your goals. Having such in mind, I think VS Code can satisfy and cover quite a lot of use cases and ways to do things, like choosing between Intellisense and clangd for assisting C++ development).

I had to return to Vim because I missed a few things(handling GB-size files was critical), but if you don't have to deal with big files, I strongly recommend to give it a try.

Friday, June 28, 2024

오늘의 얼라리요 20240628

오랜만입니다! 오늘도 또다른 '얼라리요' 건을 소개할까 합니다.

뭐, 별거 없죠? 문법도 괜찮고....... 하지만 사실 이 코드는 원래 이런 구조여야 했습니다:

뭐, 다들 이런 경우 한 번 씩은 경험해보지 않으셨으려나요?

Today's Oops 20240628

Long time no see! Today I'd like to share yet another OOPS moment.

Nothing much, huh? But the code should have been like following:

Well, don't tell me you had no chance to experience something like this. ;)

Tuesday, May 28, 2024

오늘의 얼라리요 20240528

예예. 잘 알고 있습니다. 제가 이 블로그에 글을 쓴 지가 몇 년이지만 포스팅은 거의 없지요. 그런데 어느날 갑자기 아이디어가 떠올랐습니다. 만일 자폭개그를 쓴다면 사람들이 빵 터져주지 않을까?

해서...... 첫번째 드랍 갑니다:

자, 이 코드에서 뭐가 잘못되었는지 찾아보세요. :D
(이 코드는 실행되지 않습니다.)

Today's Oops 20240528

Yes. I know. I know. I've been writing in this blog for years, but there are seldom postings. And all of sudden, an idea popped up: I think it might giggle someone if I push the "self-destruction" button myself by sharing my mistake during coding.

And here comes the very first drop:

Now, find what's wrong with the code above. :D
(it doesn't compile at all.)

Saturday, April 20, 2024

낯선 Rust에서 오래된 Object Pascal의 향기를 느끼다

요즘 새로운 프로그램을 만드는데, 이 참에 공부좀 해보자 해서 Rust로 만들어보고 있습니다.

아무래도 멘땅에 헤딩하다 보니까 고조할아버지 제삿날 종가집 시어머니급 잔소리를 늘어놓으며 사사건건 시시콜콜하게 간섭해대는 rust-analyzer와 싸우면서(?) 즐거운(?) 나날을 지내고 있습니다만...... 오늘 재미있는걸 하나 발견했습니다.

Rust에서는 이 구문을 오류로 보더군요.

이걸 수정하려면 이렇게 고쳐야 됩니다.

이 코드를 보니 예전 Object Pascal (Delphi) 시절이 생각나는군요. primitive type이 아니면 var 절에서 객체 변수를 선언한 뒤에 구현부에서 꼭 초기화를 시켜줘야 하고, 그렇지 않으면 바로 runtime error를 뻥뻥 토해냈는데, 구조가 완전히 똑같습니다. Rust도 마찬가지이긴 합니다만, 차이점이라면 메모리가 할당되지 않았다는걸 컴파일 타임에 발견해낼 수 있다는 정도일까요.

Pascal이란 언어는 자기 자신은 비주류인 주제에 온갖 잡다한(?) 언어들에게 무수한 영향을 끼치는군요. Java도 Python도 Javascript도 심지어는 Rust도 모두 다 Object Pascal의 구조를 일정수준 이상 차용해왔으니......

과거 해당 언어의 추종자로서, 아련한 기분이 듭니다.

See old Object Pascal from new Rust

Nowadays I'm working on a new application, and I thought it's a good chance to learn something new, I tried Rust.

As a newbie(or noob) in this area, I enjoy the time fighting against rust-analyzer that always-whining like Grouchy Smurf...... (lol) And today I found something interesting.

In Rust, the following is an error.

To fix, the first line should be changed like following.

Seeing the code reminds me of the good old days of Object Pascal (Delphi). If it's not an primitive type you've got to declare the variable in var clause and call constructor in implementation, or it'll emit runtime error. And Rust "inherited" the structure as it was, except for catching non-memory-assignment in compile time.

The programming language Pascal is a minor one as it is, it influences to too many other languages, like Java, Python, Javascript, and now Rust....... They all adopted at least some part of Object Pascal.

As a good follower of the language, I feel dim as I saw this.