githubalphapapa

At first I thought that sounded great, but then I realized that that would exclude files that I want to be backed up, like `dir-locals-2.el`, which should be excluded from git, but should also be backed up. There doesn't seem to be a great solution to that in general.

The official spec is a combination of hundreds of tiny specs and extensions, akin to XMPP.

You could say the same thing about any specification that involved multiple features.

There may be one single reference, but it's constantly evolving.

So is HTML. But one of my Matrix clients from 7 years ago still works. How well would a 7-year-old Web browser work on today's Web? Could you use a 7-year-old version of a third-party Discord client?

In a best case scenario, sure. The Discord version of your example would just be "Hello, world" without any of the other JSON.

So Discord encodes the message type in the URL instead of the body. So what? It has to go somewhere, and I'd generally rather have URLs include less, not more.

I actually messed up earlier: The `type` field is included in the event as seen after sending. The sent event could just be, e.g.

    {
        "content": {
            "body": "Hello, world.",
            "msgtype": "m.text"
        }
    }

In practice, you need to deal with a whole range of message types with various references and slight variations.

Is the same not true for Discord? It supports a variety of message types as well, and Discord also constantly evolves the system and adds new features (every time I log on to it I'm bombarded with news of updates, yet I still can't find a way to view a simple list of "servers" I'm in by names instead of by unintelligible icons).

In practice, you need to deal with a whole range of message types with various references and slight variations. Inner Matrix message bodies are essentially freeform, which makes Matrix quite powerful but also difficult to deal with compared to the "different HTTP endpoint per request type" approach Discord takes.

That seems to conflate two issues. And I don't see how it's more difficult to deal with than any key-value store in any program. You collect the values from the keys you care about. That's it. Every Matrix event has certain basic fields in common. A few are specific for message type (e.g. a filename field for a file or image upload event). Where's the problem? Destructuring incoming data is probably the easiest part of writing a messaging client.

Sure, if you accept having your users install two different apps, one for encrypted chat and one for group chats.

I use unencrypted 1:1 chats as well (in which case it's no worse than IRC or Discord, where the server operator could read your messages).

I think that's pretty cool, frankly: that a modern system with well-audited end-to-end encryption still allows it to be used optionally. You're not required to deal with the complexity of key management and session verification if you don't need or want it. Matrix lets me choose.

And I can choose my homeserver or run my own. Can you run your own Discord server (actual server)?

The only significant appeal I see for Discord is the existing user base. Well, that didn't save AOL. I guess we'll see how it turns out.

Matrix has a billion different standards

There is one specification, available on the official site. It isn't, and never will be, required to implement all of it.

a complex message format

It is a very simple format. Here's an example message (as sent by a client; additional fields are added by the server, such as server-side timestamp):

    {
        "content": {
            "body": "Hello, world.",
            "msgtype": "m.text"
        },
        "type": "m.room.message",
    }

This is also optional. If you want to talk in unencrypted public rooms, for example, you needn't bother with it.

The spec is so simple that you can send a Matrix message from a shell with curl. It's just JSON over HTTP.

Wow, Brian, funny running into you here after all these years! You may remember me as a guy who ran the site for you for a year or two when you needed a break. You also helped me get started with Web development on the server-side. You were always kind, encouraging, and trusting--sometimes I still marvel at how well everything worked out considering how little any of us really knew each other. You seemed to have a knack for finding good-natured people to join in. I have a lot of fond memories from playing JK and working on the site with the great community.

Do you still have the same email address at the .net domain? I'd like to contact you again. :)

Here's a library for writing such classification systems in Emacs Lisp: https://github.com/alphapapa/taxy.el

Especially, see this example: https://github.com/alphapapa/taxy.el#sporty-understanding-co...

Thanks for the kind words. I'm glad they're useful to you.

org-ql is a search tool. It provides an alternative to some parts of org-agenda and integrates with it to some extent. Its searching is much faster and more powerful than the built-in Org search tools; see its documentation for details.

org-super-agenda performs a different function, to group results in agenda buffers (which can be from org-agenda or org-ql). See https://github.com/alphapapa/org-super-agenda#faq

I'm not sure what you mean, but maybe this is what you're looking for: https://github.com/alhassy/org-special-block-extras

I collect some Org resources here: https://alphapapa.github.io/org-almanac/

See https://github.com/alphapapa/org-ql, which can be used to select entries with a SQL-like language, and then you can do whatever you like with the results.

org-agenda is not fast enough, and is practically unusable with more than a few tens of files.

Please see https://github.com/alphapapa/org-ql, which implements agenda-like views with a much faster search backend.

See also https://github.com/alphapapa/org-ql which supports org-super-agenda grouping.

But I get the vibe that we won't be seeing a client I like anytime soon; or it'll be a very minimalistic client with no support for all the fancy modern features, in which case I'd likely get the same or better experience with IRC anyway.

I don't know if you're the Emacs type, but you might be interested in https://github.com/alphapapa/ement.el. It feels kind of like an upgraded IRC, with support for features like images and rich text, and it tries to be privacy-respecting (e.g. read receipts and typing notifications are enabled by default, to imitate Element, but optional).

It doesn't support E2EE natively, but E2EE works through the Pantalaimon proxy, so it can be used with E2EE rooms that way. (Or if you don't care about E2EE rooms, like me (I mostly don't), you can use it in unencrypted rooms without using Pantalaimon.)

As for the first point, fine grained control for what goes into a commit, that's definitely a power user feature, but an important one of course.

It's not a power-user feature, and it shouldn't be considered one. It should be taught as a standard part of any workflow: before committing, look at the changes you're about to add, and use hunk-staging features (e.g. trivial using Magit) to stage and commit unrelated changes separately.

For example, did you clean up some comments and docstrings while you were adding a new feature? Commit those improvements separately, so that if you need to revert the feature commit later, the improvements won't also be reverted. It also makes reviewing much easier, as each commit or patch, having its own purpose, can easily be reviewed separately, and attention can be focused on parts that need changing.

Again there are ways to achieve this without introducing new state (the index), for example by allowing to amend the last commit.

Amending a commit does not serve the same purpose as staging files and hunks separately into the index.

It's my impression that few git users understand the value of the index, because few of them use porcelains that expose its power in simple ways. If I had only "git add -p" to use, I might not, either. But Magit is, well, like its name implies, like magic.

As active as you are in the Emacs community, you ought to know that there is a steady stream of commits to "core." Anyway, if that's not enough for you, maybe you could allocate some of your own manpower to fixing those bugs.

as well as red-squiggle-style linting tools like flymake, flycheck, and LSP-related tools.

In fact, I would have to look up how to even "reopen" an Emacs bug, it is not very clear to users, and this makes it especially frustrating if issues are closed without solution.

At the top of your bug report, it says:

    To add a comment to this bug, you must first unarchive it, by sending
    a message to control AT debbugs.gnu.org, with unarchive 21526 in the body.
    You can then email your comments to 21526 AT debbugs.gnu.org in the normal way.

Web tech gives you a greater degree of control: e.g., Emacs Lisp cannot put red sqiggles under text like VSCode does, but rather limits the user interface essentially to one large "textarea" (though in contrast to TTY interfaces, Emacs has good support for the mouse), but it is very rare for me to want web tech's greater degree of control.

Emacs can certainly apply red squiggles and many other rich text formatting, through the use of faces (which is how all syntax highlighting is implemented). Emacs also has a rich text-properties API through which any part of a buffer's text may be propertized with metadata. And it also provides overlays, which "overlay" text, also optionally with additional properties, without modifying the buffer text itself.

Together, these features are used to implement GUIs such as the Customization system with widgets, buttons, clickable links, collapsible sections, etc., as well as red-squiggle-style linting tools like flymake, flycheck, and LSP-related tools.

The question is almost like asking a fish to describe water. It's the sudden lack of it that produces a really clear example. :)

Anyway, here's a random example that comes to mind: I have some sexps in a Lisp file and I want to sort them alphabetically. Each sexp (usually a top-level form, but not necessarily) usually spans multiple lines, so line-sorting won't do it. Since they may be top-level forms, there may be comments between them that would lose their context if their position relative to sexps were lost, so comments need to "stick to" sexps they're above.

How would you solve this in a random text editor?

In Emacs, I would develop a command that does what I need. At each stage of the development process, I evaluate the command's definition, and it's instantly available to be used and tested. I could even test the function on its own definition, if I wanted to be silly (undoing the sorting after testing, of course).

When I'm done, I save the command definition to my configuration, and it's now a permanent tool in my toolbox. I didn't have to recompile the editor and start a new process, nor did I have to submit a patch to an upstream and ask for it to be merged. Similarly to a carpenter (forgive me if it sounds silly), my editor is my workbench, and as wood is malleable, so is my editor.

So, here's the command I came up with (maybe not the prettiest implementation, but maybe not the worst): https://github.com/alphapapa/unpackaged.el#sort-sexps And using Emacs and Org mode, I publish it into this "unpackaged" package, which I then install into my configuration as a package, and other users can then easily install it into theirs, too.

I don't know of any other editor that can do all of this, certainly not so easily.

Pandoc can read from and export to Org format. As well, there are a number of Org parsing libraries in other languages; see https://alphapapa.github.io/org-almanac/#Parsing

FYI, there are a variety of Org parsing libraries outside of Emacs. Some of them even appear to be robust and well-developed. I collected a list here: https://alphapapa.github.io/org-almanac/#Parsing

trying to search myriad org agenda files for an ID or text search (e.g. org rifle) will basically lock up emacs.

Please try `org-ql` and `helm-org-ql`; these newer search tools perform better than `org-rifle` and generally supersede it.

If you're on Linux, libeatmydata might help reduce the number of writes hitting the SSD.

Also:

    $ cat ~/bin/dired
    #!/bin/bash

    # Launch Dired in a plain Emacs configuration.

    # Arguments are passed to Emacs, e.g. "-nw" works as expected.

    emacs -q "$@" \
          --eval "(dired default-directory)" \
          --eval "(defun kill-window-or-emacs () (interactive) (if (one-window-p) (kill-emacs) (delete-window)))" \
          --eval "(setq dired-dwim-target t delete-by-moving-to-trash t)" \
          --eval "(define-key dired-mode-map (kbd \"q\") #'kill-window-or-emacs)"

Buffers and strings with range-indexed metadata is also how Emacs's text properties work. For example, this shows the print syntax for strings with properties:

    (concat (propertize "foo"
                        'face '(:weight bold))
            " "
            (propertize "bar"
                        'link "http://bar"))
    ;;=> #("foo bar" 0 3 (face (:weight bold)) 4 7 (link "http://bar"))

Please see also org-ql, which mostly obsoletes org-rifle and is much faster as well.

You posted that code that seems to show calculating some CSS values dynamically.

That's cool, but why are you calculating CSS attributes dynamically at export time instead of just writing a stylesheet and putting that in an export theme? Separating presentation from content, etc.

Thanks, that's a great example of how Org documents can integrate code that provides interactivity. I shared it on Reddit: https://www.reddit.com/r/emacs/comments/jj2ok0/skxorgworklog...

is there a word for a note-taking tool where every bullet is a nested note, and they can link to each other?

Org mode works that way, as well as supporting the one-note-per-file paradigm. It's a very flexible tool.

Do you mean that you have a tag-cloud in Org? Is there a package for that?