Damn you are awesome alpha xD (and a good motivator to learn lisp ngl, after haskell that is… have been sleeping on it for far to long 😒)

In reply to Mist

Damn you are awesome alpha xD (and a good motivator to learn lisp ngl, after haskell that is… have been sleeping on it for far to long 😒)

I would recommend learning Lisp before Haskell. I became interested in them at around the same time.

In reply to alphapapa

In reply to Mist

Damn you are awesome alpha xD (and a good motivator to learn lisp ngl, after haskell that is… have been sleeping on it for far to long 😒)

I would recommend learning Lisp before Haskell. I became interested in them at around the same time.

The thing is that I am intereted in haskell more than lisp, but I think you are right tbh!

In reply to human
lisp is perfect, expect it's performance lol

Lisp can perform very well. See e.g. SBCL

In reply to @alphapapa:matrix.org
Lisp is more powerful anyway ;)

In reply to @gilganix:matrix.org
Really? In what ways?

That's a very large topic, and I'm afraid I don't have time to write about it now. You can find many discussions on the web about the power of Lisp in general. For Elisp specifically, cl-letf is an example of a powerful tool that you can use to, e.g. redefine a function within a certain form, so it only takes effect in the context you need. Few other languages let you do something like that.

Another example of Lisp's power in general is a NASA mission where the software on a rover encountered an error, and thanks to Lisp, NASA was able to remotely redefine the function that produced the error, then continue execution from where it left off, all over a radio link across space. No need to recompile and redeploy software, etc. Powerful interactive debugging and condition handling.

In reply to alphapapa

In reply to @gilganix:matrix.org
Really? In what ways?

That's a very large topic, and I'm afraid I don't have time to write about it now. You can find many discussions on the web about the power of Lisp in general. For Elisp specifically, cl-letf is an example of a powerful tool that you can use to, e.g. redefine a function within a certain form, so it only takes effect in the context you need. Few other languages let you do something like that.

Another example of Lisp's power in general is a NASA mission where the software on a rover encountered an error, and thanks to Lisp, NASA was able to remotely redefine the function that produced the error, then continue execution from where it left off, all over a radio link across space. No need to recompile and redeploy software, etc. Powerful interactive debugging and condition handling.

Oh that is a very cool feature indeed! Was not aware of it until now!

I appreciate the enlightenment xD

mitigate: I want that as well, but haven't done anything about it thus far. One option to the "events may turn up in any order" problem would be to log the current session's events to a separate file in whatever order they turn up and then, either upon disconnection or else just periodically, sort the session file's contents and append them in the correct order to the permanent log.

Or append everything to the permanent log at the outset, but also store the timestamp for the last time that log file was sorted, and on disconnection re-sort the portion of the file with events post-dating the previous timestamp.

Or log to a sqlite database, and rebuild text files from that.

I suppose in principle the same ewoc-based approach used in room buffers could be used to edit log files within Emacs, but I don't imagine that scales well for multi-megabyte logs with years of chat history…

I'm sure there are better ideas, but that's my starter for ten.

In reply to @mitigate:matrix.org
re: the docstring for ement-disconnect, there are two sentences about ement-auto-sync which implies they are describing behaviour when t or nil, but they both indicate t behaviour ("enabled" "when enabled"). the last sentence that "existing room buffers are left alive" is false as ement-disconnect-hook which gets called calls ement-kill-buffers and gets rid of all ement buffers

In reply to @mitigate:matrix.org
has there been any thought of a logging framework for ement, so what gets shown also gets logged locally? i'm used to emacs chat client logging chat buffer contents by appending them to a text file (ala ERC) ? the present design seems to preclude any logging because of its "object model" ?

The subject has come up before. Phil's ideas are a good summary. We could just dump the incoming events to files, but the biggest problem with that is duplication of events in the log files. As, e.g. JSON objects, they could be deduplicated by message ID, but as plain-text, that would be more difficult.

The design of Matrix means that serious logging probably needs to be handled by dedicated programs. But something relatively useful could probably be hacked together based on Ement.