How people develop these actually? Like how do they start?

[wanton flume]

I went through this app known as ghostty which is terminal emulator written in zig, which uses gpu to render. The author uses another library which is written by himself known as xev which is a non blocking io. Like the author knows core concepts like OS, Terminal (PTY, TTY), GPU programming, Threads, Async IO. These are independent concepts and very hard concepts.

https://github.com/ghostty-org/ghostty/

[prisma whale]

Generally one starts with the basics. A good old hello world.
From there one branches out into other topics, like file reading, or networking, or just prodding at rendering graphics, audio or whatever.

With enough fooling around one finds out various tricks and gets experienced in the language but mainly in how to approach a project.

Personally I spend around 50% of the time pondering layout/structure, reading documentation and writing my own for the project.
Actually coding happens when one knows how to roughly approach the project at hand.

[bleak garnet]

Ghostty wasn't built in a day its been worked on for 3-4 years at this point (maybe even longer)

like the readme states for libxev it was influenced by io_uring and other async event libraries like libuv so its not a totally new concept.

There are also multiple resources to learn about low level terminals and xterm is MIT licensed so there is alot to study from there

Ghostty has evolved significantly since its early days back then it was a glfw only application

[wanton flume]

oh

[wanton flume]

I wonder how people started when there were no resources. It's damn hard

[prisma whale]

I can also agree with @bleak garnet.
Projects are rarely a "write once and it works" type of deal. Usually one does improvements and additions over time, restructure and over time get something working.

[bleak garnet]

https://vt100.net/emu/dec_ansi_parser
for example this is a good resource on state management a terminal needs to do

[wanton flume]

Thanks

But how many days I keep on reading docs, reading source code. Like it's kind of demotivating.

I literally don't know the core concepts and if I start learning them it will take years

[bleak garnet]

computing was also alot simpler back then not saying what people did wasnt hard there is so much built on top of other things in the modern world

[wanton flume]

brick by brick

[prisma whale]

I normally go back and forth.

I am currently writing an HTTP server myself.
So I read documentation for a given function, write the code to make it do the most basic thing it is supposed to do. See if it works, if I understand it.

Each aspect of a project has its own "hello world" project of sorts, where one learns the thing at hand.
Later on one can combine these puzzle pieces of knowledge into a unified project.

[wanton flume]

I thought to write Vim like txt editor in zig.

[bleak garnet]

You should pick some area you are interested in and explore it. Like you just said brick by brick you accumulate knowledge in a domain you work in.
For example my career is in the embedded space so I have no clue what the web dev scene really looks like

[wanton flume]

oh

[wanton flume]

Is it your hobby project or professional project in a company?

[bleak garnet]

at a company, I don't do too much in my free time

ghostty is probably my most active freetime project actually

[wanton flume]

Oh so you contribute to ghostty?

[bleak garnet]

I have a few small changes, its a good codebase to see alot of zig
https://github.com/ghostty-org/ghostty/commits?author=rhodes-b

[wanton flume]

Nice bro

[bleak garnet]

https://github.com/neurocyte/flow
flow would be a good reference to learn from if you get stuck etc its a modal based editor written in zig

[wanton flume]

thanks

[wheat marlin]

I do want to caution you from thinking you will achieve something close to vim, it has been actively worked on for decades.

you can certainly get the fundamentals down, infact, i would say that part is rather easy, compared to fleshing it out into something usable for serious programming.

[wanton flume]

Shortcuts + theming + cursor movement + highlight+ lsp + file finder + pattern matching isn't that it?

[prisma whale]

One feature I would enjoy to see in text editors is the ability to scroll past the start.
At least most modern text editors allows one to scroll past the end until the last row is at the top of the document view. It would be wonderful to scroll the other way until the document start is at the bottom of the document view.

[wanton flume]

I thought that today something like upper+3 moves up 3 lines

[wheat marlin]

"isnt that it" is quite the understatement, I think you are underestimating how hard some of those are. That being said they certainly have niave solutions that are a lot easier to implement that a fast efficient responsive implementation.

[wanton flume]

Up + ^ to goto start

[wanton flume]

🙂🙂

[wheat marlin]

some of that is certainly easy to do, but it depends on less easy things.
for example cursor movement itself is quite easy, but it has a lot of edgecases you will encounter.
rendering it in the correct location is semi dependant on how you store the data for a file too. which gets complicated if you want large files to still be responsive when editing them.
and it gets really complicated if you want to add undo/redo.

[wanton flume]

I just create a virtual surface basically [height][width]. Based on the scroll I will print

[wanton flume]

For undo redo i thought of tree. Because I got a problem while using visual studio code or others. When I undo 5 times and write then the code which I undoed firstly will disappear. So I thought this ru which basically redo the undo.

[wheat marlin]

yes but you also have to make the file contents match with the scroll, which depends on how you store it, which depends on the things i mentioned.

you dont have to make it responsive for large files, nor implement undo/redo. its just an example of what is more complicated than you might have thought at first, its totally possible you are more aware than i think, in which case ignore me :)

[wanton flume]

Oh

[wheat marlin]

undo/redo interact heavily with how you store the file contents, on their own they are fairly easy, but together they become a big headache. that ofc depends on your knowledge of the topic and experience with similar data structures that known solutions use.

but you can also just forgoe that feature, in the name of working on other features you can add with less pain :)