This is the next installment of threads in my project log series since the imageboard was completed >>27187, and ran out of motivation for the calendar-based forum >>27553, leaving it as merely a (relatively complete) calendar. The idea this time around is to make something of a GNU Emacs replacement, but broken up into a number of tightly coupled smaller packages. Namely the approach is going to be "frames" over "windows" where windows are controlled by a programmable tiling window manager and run in Xephr for individuals who don't want to replace their window manager. Further there will be a command processor for mapping keybindings to functions and command names to functions. Next there will be a prompt package which will be responsible for prompting the user, more likely than not this will be either at the cursor position or in the center of the display. Lastly, the text editor itself will be responsible for very little beyond saving and reloading state, and rendering the text buffer; these two functionality will likely also be split into separate packages.
Presently, the implementation is in C, Xlib, Cairo, and Pango but is little more than a demo to edit and render text taken from various tutorials glued together only started yesterday afternoon. It is however already capable of indexing in text based on pointer events, so it seems the stack will be powerful enough to write the gui. Am likely to start with morphing the present program into the prompt package and once have the basics of the centered view created (this would be something akin to dmenu) am likely to begin rewriting in Common Lisp. Don't yet know how to handle the interprocess communication ideally it would be bidirectoinal and work well with programs not written in Common Lisp, though this latter point isn't the biggest priority. Getting the interprogram communication right is going to be critical for having the environment work well overall. Anyway that's all for now.
>>27796>Presently, the implementation is in C, Xlib, Cairo, and Pango but is little more than a demo to edit and render text taken from various tutorials glued together.The demo was extended a little today with an added keybinding for escape and keyboard based navigation for a single line. There was also some refactoring done, switching from calloc to static buffer sizes, and a simple bug fixes to do with using memcpy instead of memmove. Lastly a visual cursor was added.
The next two major hurdles are going to be positioning the window, and translating the Cairo surface to show only the correct portion of the Pango layout. The simplest way to implement the latter can think of at the moment is to maintain a second cairo surface large enough to fit the full Pango layout and to copy rectangles from the large surface to the xlib surface. Haven't implemented let alone instrumented this yet, but it sounds like for large buffers it would be slow. An optimization would be to perform these same functions but only render N lines at a time where N is computed from the window height divided by the line-spacing. Unfortunately the minimum, and maximum font-width is not available to allow for a similar optimization in width.
Smaller tasks that might be completed before these others is configuring various attributes of the windows such as hinting for the title, grabbing the mouse and keyboard, and accepting clipboard usage. In fact it may even be reasonable to complete some of this tonight.
>>27805>minimum, and maximum font-width is not availableI haven't used pango in a long time, but with monospace fonts the minimum and maximum should be the same, besides the rare exception, which can be ignored for the sake of simplicity. even if the api doesn't give you a width, I think you can take an arbitrary glyph or whatever it was called and take the width from there. as long as it is a monospace font you can pretend this isn't a terrible idea
if it isn't monospace, I'm sure the api must have a call to measure without actually rendering
>27812>if it isn't monospace, I'm sure the api must have a call to measure without actually renderingHaven't implemented it yet, but think you're right. Think you can create a layout with just the relevant lines without a surface to render on and then get the pixel extents. This would results in renders with everything correct except for the exceptional cases where the line-height isn't respected. Another optimization might be to force wrapping if lines are too excessively long (e.g. thousands of characters), though this would be unlikely to be implemented initially.
>>27805>Smaller tasks that might be completed before these others is configuring various attributes of the windows such as hinting for the title, grabbing the mouse and keyboard, and accepting clipboard usage. In fact it may even be reasonable to complete some of this tonight.Got the clipboard to work this evening, and a name displayed in the WM but that was all.
Have decided its best for my health to avoid imageboards entirely, even though this one is tame (probably because its a small technology board on a site dedicated to left-wing poliltics). Further developments on this project can be found at
https://codeberg.org/jung/excerpts once the project has an initial commit.
It will be licensed AGPLv3>>27938>Please finally give us a good IDE.Will try my best.
>>29884The other major change being to rewrite it in Common Lisp of course.
Would have already helped some with doing proper instrumentation.
>>29884This could also solve the issue with not being able to determine the correct size of the horizontal component of the viewport.
Or perhaps even the need to have a second buffer which is a slice of the other at all; because it's just the right size.
Although you'd probably need to create custom "empty" glyphs with the geometry set to the offset at each line (for when you've moved horizontally).
>>29885Started to rewrite with alien technology yesterday.
>>29884>It's also using the Xlib backend instead of the OpenGL one.cl-cairo2 doesn't have support for OpenGL so looks like we'll be sticking with Xlib. If the incremental updating etc. goes well it shouldn't really be necessary however on modern machines.
>>29906One idea is just use the same method but with search in the beginning.
Only problem is it might be too slow.
>>29907Got basic text rendering today, just in a line. Handling of pango items but no way to easily specify attributes atm.
Arabic renders in a janky fashion without this and Mongolian apparently requires transformations to render correctly at all.
Would be very clearly better off writing this renderer in C and then using CFFI. The pango library doesn't really wrap SWIG much unless am missing something.
Assume it's not very painful to do this.
>>29923Some common lisp later and have a complex implementation of a simple algorithm that was in my notebook.
The idea was to only render glyphs which need to be on the screen, and only "shape" for glyphs that are in lines on the screen.
Arabic and other connected scripts are borked because of rendering glyph by glyph.
Seems need to separate by LogAttr is_word_boundary or similar (
https://docs.gtk.org/Pango/struct.LogAttr.html ).
Really this should have come up in the design process for the algorithm, but oh well.
>>29924Writing in an alien language can be difficult!
Finally got all of the bugs sorted in the render!
The ASCII doesn't really show off the engine completely.
There's certainly some pressure to implement caching however.
Especially considering this was part of the whole reason for the re-implementation.
The algo avoids rendering words unless part of them is visible to the left.
There is still some work required to have this same behavior happen to the "right".
These things should be easily enough implemented now that the basic framework is in place.
Really still seem to need a non-idealist plan,
>>30021Wrote primitive caching. Also more primitive optimization for cluttered overlong lines.
It will probably be difficult to do this last thing correctly.
>>30039Worked on handling a edge case today with vacant lines. My "solution" was not satisfactory.
It only tries to render things which are within the view-port.
Next thing on the list is to try to make a cached generator. The idea is that this would fix the problem with having to shape overlong lines. Might not be able to program this for a second.
>>30045Even with a hot cache only rendering what's necessary on a medium fast machine it's too slow.
More cold stuff.
Programmed and it turned out that a bulk of this was in marshaling and unmarshaling data.
Was able to half the consing, total-run-time, and nearly the real-time just by removing unused slots.
Pulling out the window attribute xcb calls (which never would have guessed) also took off 20 times real-time for small buffers.
And hot stuff.
The remaining problem is the lack of a cache generator.
Combined with running this for the full text instead of just the relevant view-port.
Together this meant it was taking way too long to shape up the characters for long documents.
Fixing this makes it too fast to create a flamegraph for even for large documents.
… but am sort of getting ahead of myself.
Evaluation took:
0.396 seconds of real time
0.336208 seconds of total run time (0.265805 user, 0.070403 system)
84.85% CPU
751,316,483 processor cycles
8,931,360 bytes consed
Evaluation took:
0.239 seconds of real time
0.151740 seconds of total run time (0.094207 user, 0.057533 system)
63.60% CPU
452,475,538 processor cycles
3,799,744 bytes consed
Evaluation took:
0.010 seconds of real time
0.021974 seconds of total run time (0.021974 user, 0.000000 system)
220.00% CPU
23,525,682 processor cycles
694,528 bytes consed
Evaluation took:
0.010 seconds of real time
0.018074 seconds of total run time (0.018074 user, 0.000000 system)
180.00% CPU
15,426,824 processor cycles
490,880 bytes consed
Unique IPs: 9