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.
>>27807What a creepy post.
>>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.
>>27815How do you plan on implementing abort (C-g). My current approach is killing off all commands currently executing within a buffer by checking for the exit condition on wakeup and every potentially non-terminating loop condition.
>>27819Liked the idea of using an interrupt to recycle a thread, handled in a wrapper. Maybe having ownership/batching for undo items and generalize the kill-ring to arbitrary storage so that pending changes can be automatically reverted. Would then need a special command to implement full abort (including undo) (C-u C-g). Programmers would need to be careful to reuse (or even free) the (now persistent) state. Really need to think about it more though, beyond the interrupt, this all sounds a bit too convoluted, and a bit like a functional memory-leak-atron.
>>27796Was nearly able to get away with using a single surface, and two layouts, one for the full buffer, and one for the visible lines. Made a demo of something like this but there is a seemingly unresolvable bug with the text overrunning or underrunning the window (because the surface is rendered twice). Also made a demo using two surfaces and this fixed the bug with text overrunning, but made the program quickly jump to the gigabytes in memory upon edits, and flicker with edits got beyond a sentence in length. Hopefully this is just a matter of not handling resources correctly.
>>27898Actually managed to catch the memory leak now.
Have a less interesting bug which don't know how to solve: when the image surface that am copying from becomes greater than or equal to the surface am copying cairo doesn't seem to copy at all, and the screen is left blank. Any ideas on this would be appreciated. Other than this still haven't implemented verticle smooth scrolling, only horizontal because of a completely flawed approach to computing the offset into the character Y. Overall this project is turning out to be more difficult and time consuming than expected. bumped because slid.
>>27919It seems the screen blanking only happens with certain characters, (it noticiably doesn't happen when the buffer ends in an 'M', or and 'H'). My best guess is that the program needs to do a better job of truncating the string of the layout for rendering.
>>27924It actually seems to happen especially with the 'T' glyph in my font.
>>27929
Have mostly just been adding back functionality that was removed, or broken in recent iterations. Added back the cursor and the functionality to optimize by taking the horizontal slices, fixed a bug where the input buffer would delete everything to the end of the buffer if insertion or deletion wasn't at the end, and added the automatic movement of the viewport with the arrow keys, home, end, and backspace keys when at the edge of the viewport.
Would like to in the next few posts implement selection, and copying. This would put the implementation on par with a nano or pico editor. Of course to implement even a redumentary GNU Emacs is going to require implementing most of the subprograms.
>>27930Should have included in this list text region highlighting, and opening/closing of files which are also required for implementing something like a pico or nano editor.
Please finally give us a good IDE
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.
Would be kino to have a hotkey that toggles between the classic IDE mode of viewing your code, files, and console output, and only having your code
>>28079I'm almost sure you can already achieve this with both neovim and emacs
>>28079>>28080 is right. In emacs you can save the current layout to register n with C-x r w n, make the current window take over the entire screen with C-x 1 and reload the previous layout with C-x r j n.
>>28080>>28082They're not IDE's though. Emacs could qualify as one but i fucking hate it. Jetbrains 4 life
>>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).
>>29886You wouldn't add "empty" glyphs but rather render each line with an offset somehow because you'd always need partial or zero glyphs at the beginning.
>>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.
>>29920>MongolianTaking this joke seriously is a bit dangerous…
Was told by my superiors am not ready for this.
And told paper and pencil would probably help.
>>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