Wren or Lua as a scripting language for my ick text editor?

>>106127837 (OP)
>Wren
I don't know. It seems dead and I have never heard of it. I would stick/choose the tried and true Lua. Also, neat selection feature.

>>106128010
Apparently, wren is by the "Crafting Interpreters" guy. Does a language need to be constantly improved/worked on? If it werks, it werks. Lua is good because it probably has better D binding. Wren D binding last been updated years ago and I don't know if it's good or not, but, again, who cares if it werks. Lua is fine, Wren just seems a tad bit nicer.

>>106128094
>Wren just seems a tad bit nicer.
How so?
>Does a language need to be constantly improved/worked on?
I would think so, since there is no such thing as a perfect language.

>>106128213
Well, array index starts with 0. But also syntax looks like a mix of Ruby and JS to me, which I prefer personally. I don't even know Lua, will have to quickly read up on it. Not that it's a problem, I guess I'll still go with Lua, because it just seems a lot more established and I don't plan on like writing all the plugins/scripts in it myself, just provide the api.

>>106128213
you don't need perfect
you need good and stable.
you don't wanna end up like a fucking webdev where the churn is so extreme that things that break every 2 months are considered long lasting.
The language is also not the thing that solves your problems. Its the tool you use to solve your problems yourself and the problem isn't constantly changing.
There are almost no new ideas. Everything has already been tried in the 60s and 70s.
Imaging buying a hammer every two weeks because it became obsolete in the meantime.

Lua is a good scripting language

I would choose lua purely due to the fact that its way more established and has way better tooling availible.
There's formatters, libraries, a very nice language server with a nice system for type annotations, a jit compiler.
Lua also has coroutines, which super nice.
Easily the best scripting language.

You should also look at TCL though

>>106128273
I was hoping you would end your drivel with a food analogy.

>>106127837 (OP)
JavaScript.
>NOOOOOOOO JAVASCRIPT BAD
it's better than your tranny lua garbage and actually has users.

>>106128273
Yeah, I agree. In fact I would even question what's the point of writing a text editor, there's vim and emacs and also a bunch of more modern ones. I started it just because, but the more I kept working on it and the more I learned about how other editors are designed, the more I realized how basically retarded they all are. I like Vim and been using it exclusively for 20 years, I think, but my god it turns out its cos and design in general is a mess. And even newer editors like Helix appear to be quite retarded in their internal design decisions. Feeling just a little bit hopeful this effort may result in something I might me compelled to use myself one day.

>>106128318
I tried Tcl a few years ago or so. It seemed nice on paper, but actually coding in it was kinda meh. Too much brain rewiring for too small a reward. I wanted to replace Bash with it, but I knew Bash so well that I eventually just decided it wasn't worth it.

If you need your scripting language to be fast: Lua
If you want wide adoption and accessibility: Python or JavaScript
If you don't want to deal with another language, don't care about sandboxing, and want max performance: native Shared Objects/Dynamic Link Libraries as plugins
If you want sandboxing and to be a weirdo: native plugins compiled to WebAssembly

>>106128375
I'm thinking this: Lua binds to my editor's provided API. Then others can write plugins in Lua or just call their scripts/binaries written in whatever from Lua and do all the processing and then pump it back into Lua and ick.

i saw your editor few weeks ago, i made mine with all the features notepad has in 2 days, what's taking you so long retard?

>>106128408
constant mind masturbation about pointless timewasting "projects"

>>106128408
I dunno, tell what you're writing yours in? I'm literally writing it from scratch in D and Raylib and notning else, so basically drawing pixels on screen. You?

>>106128428
not gonna dox myself but i use a graphical library aswell, and i have everything yours has + ui hierarchy + ui elements from scratch, everything

you're just draggin it on with pointless "UYHUIOOO SHOULD I USE X OR Y" instead of finishing the project and moving on to something more useful

>>106128452
Show the code, mine is at https://code.qount25.dev/qount25/ick

>>106128475
i got nothing to prove, i'm just calling out your timewasting trann-ysm, masturbating each other with pointless faggotry

>>106128500
No one's proving anything here, but you're being extremely homosexual in a bad way (also known as being a fagget), because anyone can just say "i built what you built, but did it in two days". Well, show your demo and your code or gtfo sonwe can chrck it out and see how it's exactly the same or better than the OP.

Lua is the way to go. 5.1 or luajit.

Have you looked at SCI (small clojure interpreter). Same base that's used for babashka. I always thought it'd be a good for for a text editor. Sort of the choice a modern emacs-like would make.

>>106127837 (OP)
I'm also working on a text editor and tried the scripting language part with lua. In the end it was not worth the hassle and I just removed it because I can just write in anything that I want. Unless you would want someone else to be able to extend it.
Just starting to use this thing at work, heres the code https://github.com/eemed/sanedit.

>>106129488
That's interesting, I think I'll feed your code to ChatGPT to get the overview and how it differs from ick. Asking ChatGPT how my implementation and design ideas are different from that in othet editors really helpedme understand my own code and text editor landscape in general better. I see you mention the reason for your interest in text editors is opening large files. It's funny because from the beginning it was low priority for me - I just figured for programming it'd be unusual to have a very large file and even if you were searching logs, they'd also normally be relatively small, because of logrotation.

I don't speak Rust, but I took a look at some of the files in your repo and they look extremely readable, which is great.

>>106129398
Unfortunately I can't say I'm a fan of lisp, so that's a no go for me. Sorry. Nothing wrong with emacs. Maybe I'll study it someday to get inspired, though.

>>106127837 (OP)
>modalslop
Into the trash

>>106129488
Also, am I not seeing it, or are there no unit tests?

>>106129628
I can direct you to the most interesting parts. Syntax highlighting done using parsing expression grammars that are jit accelerated. regex and glob can be converted to peg als. the buffer implementation is similar to vscode (piecetable but the pieces are in a rbtree), there is a blog post about "new vscode buffer" somewhere. Otherwise its pretty standard modal editor with LSP features

>>106129731
its a hobby project, I test by running the thing. there are test at the end of the files if i deem it worthy

>>106129756
Yeah, I'm surprised you got with it so far without thorough testing (no offense, some people here think testing is a meme, so maybe they're right). I test almost everything and, btw, D, like Rust, allows unit tests in the same file as main code, so I just put unittests right next to each function and instruct Vim to fold them by default. Very comfy, you might want to try it.

I wonder how you implement commands, I've looked at it briefly and on the surface it looks similar to me, but I'm particularly proud of my context system, which allows easy bundling of commands like "2wd". Anyway, I'll check your code more closely soon.

What was the most difficult part so far, would you say?

>>106129845
The code is in so small segments in each action(= thing that changes editor state), that testing implementing test felt wrong, it almost always works or it doesnt. Also if I would to write more test I would do it per action for example test comment lines action. Probably should add some if any potential employer takes a look.
Buffer and PEGs impls took the most time, most challenging probably constant architectural changes because I didnt yet know what I needed. Now that the architecture is good its very easy to add anything.
So my advice would be to ease on the testing or atleast test per action not per function. Also there is no bugs if you dont find them which makes me feel like its perfect

>>106129975
I'm firmly on the unit test side though. Hear me out: tests aren't just to prove to you that your function works as expected now. It's there to help you be confident in the future, that some new changes you introduce don't break the established behavior. Tests also unironically help me reason about edge cases, which in an editor are plenty. Having said that, I can see how someone else is capable of establishing some different kind of discipline for themselves wherein writing code in a certain way makes things reliable and easy to reason about even when changes are introduced. But I do definitely love my tests.

In any case, looks like a great project. I'll give it a try, will compile and run.

>>106129975
Btw, I really like your Rust code, it's very simple to read. It looks less messier than mine and mine isn't particularly messy. I, of course, love making fun of Rust as much as the next anon here, but people complaining about Rust being insane and unreadable should unironically be sent to view your code as proof of the opposite.

>>106130084
Its just too much work and slows progress for me.

kino

>>106127837 (OP)
What about Squirrel or Neko or Mruby?

>>106128321

kill yourself retard, lua is faster than your garbage poorly designed js.

> "muh ecosystem"

ahh yes the excuse given by retards such as yourself when they cant even write a function to determine whether a number is even or odd and resort to running npm install isEven

kek.

>>106129641
>inspired
*LISPired

Seriously tho, clojure is not a bad idea.
On paper lua seems like a perfect choice, but in reality no one will realistically learn a general purpose programming language just for configuring something
A lot of programs use lua for configuration and I just can't bother learning lua for nothings, so I end up going by trial and error and intuition obtaining (if any) mediocre results and then move on to another piece of sw
The same argument applies to wren, even worse

Counterintuitively you will have better luck by going with a GPL that also has a big market share. Even going with C will be better in the long term

That or you can either
> expose some communication API that's language agnostic and/or provide small libraries for most used languages (you could easily automate these steps with AI) a la Acme
> make your code modular in a way that can be modified from source (like the yed "your editor" editor)

>>106132288
> no one will realistically learn a general purpose programming language just for configuring something
I don't know about that, people learn vimscript and it's pretty retarded. Also, my configs are simple ini-like files with very simple custom format, I'm not planning on using Lua for configuration, only planning it for actual scripting and communication with the api. And don't get your argument, wouldn't people need to learn clojure also? I mean I get that its lisp, but Lua isn't exactly rocket science either, looks extremely familiar to anyone who worked with Ruby, JavaScript etc. Also can probably be vibecoded easily, so it's not like you have to actually learn it.

>>106132288
Do not listen to this retard.