baygeldin
commented
5 years ago Hi!
To be honest, I'm not sure if rem.el is the best option for a such use case, because log-like buffers are expected to have a lot of text in them. The approach rem.el takes is more suitable for relatively small amounts of text (like maybe a couple of screens).
I've been developing an Org-mode plugin, but I wasn't sure about what UI exactly do I need. So, I realized that I need a straightforward way to structure the code that would make it easy to refactor and maintain it later (i.e. the performance wasn't the main goal). The idea is that I have a single function that maps my data to a string representation and then I just replace a buffer's contents with it on each action. What rem.el optimizes is the generation of a string representation (although it doesn't have to be a string, but it makes sense for text interfaces). The rendering part (in the sense of replacing buffer contents) is done by rem-bind helper which really just monitors actions calls, erases previous buffer contents and inserts a new string representation. Computers are quite fast nowadays, so it works without glitches :)
But when the string representation is huge and constantly growing, I doubt that the performance would be as nice. Of course, it's possible to narrow the string representation manually and implement the scrolling, but you would lose many benefits of having the whole text in a buffer (e.g. full-text search). The problem is that Emacs buffers don't have some kind of tree representation to which you can apply patches by inserting and removing elements (like in the browser), it's just a wall of text. Maybe we can calculate the difference between string representations and apply patches in a more granular fashion using some kind of diff and patch utilities, but I'm not sure if it will be significantly faster than just replacing buffer contents altogether.
Speaking of "how it works", let's imagine we have a bunch of pure functions and a single function that somehow combines them and maps our data to some representation. Each time we change the data, we just call the top function and it recalculates everything from scratch. Now depending on the complexity of underlying functions it might perform just fine or it might not. But it's a pretty clean structure! We put in the data and get the result. We assume that if we put the same data we get the same result. And we also know that this result is somehow a combination of what underlying functions produced. So, we might say that for the same data we call the same set of functions with the same parameters. If we change data a bit and call the top function again it will produce a (likely) different result using a different set of functions with different parameters. Usually, these sets of function calls will overlap (how much depends on how much we change the data), but since functions are dumb, they don't know it and recalculate overlapping parts again. What rem.el does is simply prevent overlapping parts from unnecessary recalculation and calculates only the difference. In rem.el terms the top function is the view and underlying functions are components.
alphapapa
Hi,
This looks very, very interesting! I read your documentation (good job on that, by the way), but don't fully understand how it works, so I'll just ask: would this be suitable for a log-like buffer, like an IRC chat room? For example, I've been working on
matrix-client.elfor a while, and after I worked on that for a while, I discoveredewoc.el, and I've been thinking about giving it a try for implementing the UI.Is rem.el suitable for that kind of use? If not, have you thought about it, and would it be possible to add support for it?
For example, in
matrix-client.el, each room has a list of message events, newest first. We manually render messages into the room buffer at the appropriate location when they arrive. It would be nice to have a higher-level solution that would simply render the list of message events to the buffer appropriately; that is, it would determine which messages are new and render them in the appropriate position in the message buffer (considering that events may arrive out-of-order), without re-rendering all of the messages every time (which would perform poorly, of course).Thanks.