
IRC and Emacs all the things - preek
https://200ok.ch/posts/2019-11-01_irc_and_emacs_all_the_things.html
======
iLemming
> Not having a general text editor at your disposal for when you have to
> input/manage loads of text is like being a carpenter and only having a
> hammer in the toolbox.

Once I learned Emacs to the sufficient level, I felt that. Today, I can't even
imagine typing any text in anything else but Emacs. Having all the tools you
need at your disposal - spellchecking, thesaurus, dictionary, word lookup,
translation, etc., feels extremely empowering.

My work machine is a Mac. I have written this¹, mainly to integrate with
Emacs. Whenever I need to type anything longer than four words, in any
program, I use that. The idea is simple - to copy existing text, call
emacsclient, it invokes a function that opens a buffer and pastes the text
into it. Then you edit the text in Emacs, press dedicated key-sequence - it
grabs the text, switches back to the program, pastes the text back in there.
It works surprisingly well. I can for example, open Browser Dev Tools; invoke
Emacs; switch to js-mode, have all the bells and whistles: syntax-
highlighting, autocomplete, etc.; write some javascript; finish editing and it
would paste the code back into the Dev Tools console.

Sometimes I use Linux with EXWM. When I first discovered it, I got very
excited. Not because now I could manage all windows through Emacs, but mostly
because EXWM can "translate" and "simulate" the keys. So, for example, you can
use same key-sequences that you use on Mac, but they'd translate into Linux
native keys. There's no "context switching", you don't need to re-adapt to the
keys all the time. It took me a few hours to learn EXWM and configure it, next
day I wrote exwm-edit² Emacs package.

Being able to write any kind of text in your favorite editor is truly
liberating. I highly recommend trying. Be warned though - it's impossible to
live without that later. The only reason I don't much use Windows these days -
because I haven't yet figured out the way of doing this in Windows. Someday I
will.

\---

¹ [https://github.com/agzam/spacehammer](https://github.com/agzam/spacehammer)

² [https://github.com/agzam/exwm-edit](https://github.com/agzam/exwm-edit)

~~~
happyrock
I gave Emacs another good-faith effort recently, via Spacemacs. I really
bought into it, wanted to make it work, and forced myself to use it for all
text editing. But despite every intention of working through all of the quirks
and oddities and endless customization, and with the stated goal of reaching
Emacs enlightenment, I gave up after a month or so, deleted it from my machine
and resolved never to try again.

It feels silly saying this about a piece of time-tested software that many
people love, but as someone who believes in the _idea_ of Emacs, in my opinion
the reality of Emacs is that it just doesn't work very well. It's slow, it's
clunky, it gets in your way at every opportunity, it's documented in a very
puzzling style, the add-on packages often interfere with each other in
inscrutable ways, and the user experience is on the whole, terrible.

At least that's how I felt coming back to Emacs after using modern IDEs the
past few years.

~~~
giggles_giggles
I hate to tell you this, but it's not Emacs that's slow and clunky, it's
Spacemacs. I dumped Spacemacs and spent a couple days building a new config
with everything I used from Spacemacs and it is a good 10x faster.

It shouldn't be surprising, seeing as Spacemacs development ground to a
complete halt (no new releases) something like two years ago.

Spacemacs is a neat demo of what is possible with Emacs but it adds a TON of
complexity and bloat. I found it much harder to troubleshoot and it didn't
keep up with the rest of the ecosystem, and it's the rest of the ecosystem
(and Emacs Lisp) that make Emacs so special.

~~~
dilap
As a devoted emacs addict, I can attest that plan old emacs is also pretty
slow and clunky, though I could easily believe spacemacs is even worse!

My dream editor would combine the flexibility of emacs w/ the speed and
quality of sublime.

~~~
iLemming
Quality? I think Emacs (for what it does) is a product of superb quality. I
just checked - I pull over 400 packages (including built-ins). Can you imagine
Sublime, VSCode, or Atom with 400 plugins installed? I don't even know if you
can find that many useful plugins for them, but even if you do, I think at
best it would just hang them indefinitely.

And these are not 400 "dead-weight," useless packages. These are real programs
that very often tightly integrate with each other. Some of them like Magit and
Org-mode are quite serious products by themselves.

Sure, there are decades-old issues in Emacs, and they are slowly, steadily
being worked on. The problem with long lines is getting fixed. JSON
performance got improved with jansson. Elisp native - some people reported a
300% speed boost. Rendering improvements with Cairo - no longer experimental;
Native line numbers are in the stable version of Emacs; People today
discussing using Tree-sitter for parsing, which would significantly improve
syntax-highlighting. And many other things are slowly being improved.

Things move slowly in the Emacs world. We have many smart people, but we don't
have enough of them to contribute and move things fast.

~~~
dilap
No argument that emacs is getting better.

But I'm not sure it will ever be what I would consider high-quality!

I think it's just the nature of a huge system implemented (mostly) in a
dynamically typed, dynamically scoped (!) (though, happily, more and more less
and less) language to be partly broken all of the time.

And, to be fair, most of the bugginess is not emacs per-se, but in the various
packages and their interactions -- but what is emacs, really, other than a
platform to run the packages?

So here's some random problems I have (I have a long list, and occasionally I
try to fix one; the list is growing):

\- After I run a python shell for a while, bash shells stop asynchronously
showing command output; the shell just hangs until the command completes.

\- There's an awesome mode iedit that lets you edit all instances of a symbol.
Sometimes, for certain sequences of characters, instead of correctly
performing the edit, it inserts gibberish.

\- There's an awesome mode grep-ed that let's you edit grep(†) results inline;
very convenient. Except for when it very rarely, randomly decides to garbles
the files.

(† Or even better ripgrep -- random shout out to truly fantastic piece of
software!)

\- The afore-mentioned iedit mode doesn't work w/ the delete-horizontal-space
editing command. (All other commands, yes, just not that one, for some
reason.)

\- There is a mode dumb-jump that jumps to symbols. There is an emacs feature
to soft-wrap lines. Dump-jump doesn't work when jumping to a symbol that's on
a wrapped line.

\- To work around a rare but tricky race condition, emacs shell mode at some
point added a built-in 1-second startup delay. I lived w/ annoyingly slow
shell starts for _months_ before I finally tracked it down, only to find out
it was on-purpose terrible kludge!

\- The soft-line wrapping mode (visual-line-mode) goes crazy if the line gets
really long.

&c &c &c.

So while I spend most my time in emacs and have great affection for it, I
definitely don't feel like it's a high-quality experience. I'm constantly
running into little bugs.

To be fair, most of my arguments are with 3rd-party packages and their
interactions, not emacs per-se. But emacs w/o 3rd party packages would be like
a non-fat decaf latte: what's the point?

(P.S. Very excited about the possibility of fixed long lines & tree-sitting
parsers!)

~~~
useragent86
> I think it's just the nature of a huge system implemented (mostly) in a
> dynamically typed, dynamically scoped (!) (though, happily, more and more
> less and less) language to be partly broken all of the time.

To be clear, Elisp has had lexical-binding for about 8 years now.

> After I run a python shell for a while, bash shells stop asynchronously
> showing command output; the shell just hangs until the command completes.

That's very strange, indeed. See if you can reproduce with emacs -q.

> There's an awesome mode iedit that lets you edit all instances of a symbol.
> Sometimes, for certain sequences of characters, instead of correctly
> performing the edit, it inserts gibberish.

iedit is great. I've never seen it insert gibberish or misbehave in any way.

> There's an awesome mode grep-ed that let's you edit grep(†) results inline;
> very convenient. Except for when it very rarely, randomly decides to garbles
> the files.

Haven't heard of grep-ed. Maybe you're thinking of wgrep? See also occur,
which can also perform edits. In fact, there are probably at least 5-10
packages which implement such functionality, some of which are built-in.

> The afore-mentioned iedit mode doesn't work w/ the delete-horizontal-space
> editing command. (All other commands, yes, just not that one, for some
> reason.)

It would be helpful to report that issue so it could be fixed.

> There is a mode dumb-jump that jumps to symbols. There is an emacs feature
> to soft-wrap lines. Dump-jump doesn't work when jumping to a symbol that's
> on a wrapped line.

That's unlikely. If that ever were the case, it's probably fixed by now,
because dumb-jump is under active development, very popular, and widely
recommended, and that would be a very basic problem. Besides, I can't imagine
how being on a wrapped line would affect it, because Emacs commands that read
from the buffer aren't affected by visual-line-mode.

> To work around a rare but tricky race condition, emacs shell mode at some
> point added a built-in 1-second startup delay. I lived w/ annoyingly slow
> shell starts for months before I finally tracked it down, only to find out
> it was on-purpose terrible kludge!

Try ansi-term instead of shell.

> The soft-line wrapping mode (visual-line-mode) goes crazy if the line gets
> really long.

Extremely long lines have been a problem in Emacs for a long time, however
Emacs 27 includes so-long-mode, which mitigates it.

~~~
dilap
Thanks, I do appreciate the tips.

Like I mentioned, these are just a couple problems from a longer list.
Occasionally, I pick one and (try) to solve it. If I tried to solve them all,
I wouldn't have much time left for anything else. :-)

My more general point is Emacs is pretty janky.

I also don't think it's _inevitable_ \-- it's possible to make something that
offers the awesome flexibility of emacs, but w/o the quality issues. Who
knows, maybe Emacs itself will eventually evolve in this direction.

(Re a couple of your specific points:

\- I just checked, and 36% of the files in my site-lisp directory are using
lexical scoping.

\- Dynamic scoping can be handy! Here's (incredibly nasty) my fix for the
hard-coded 1-second delay in shell mode:

    
    
      (flet ((sleep-for (&rest args) ())) ;; redefine sleep-for since shell calls it on purpose, guaranteeing a 1s startup time...
    

The fact that such a fix is needed, on the one hand, and that such a fix is
possible, on the other, are emblematic of the both cultural and technical
reasons that emacs is not more robust.)

~~~
useragent86
> Like I mentioned, these are just a couple problems from a longer list.
> Occasionally, I pick one and (try) to solve it. If I tried to solve them
> all, I wouldn't have much time left for anything else. :-)

> My more general point is Emacs is pretty janky.

Well, for various definitions of "janky," perhaps. But I think your problems
are mainly from third-party packages and your init file, not from Emacs
itself. It's very common for Emacs to get blamed for badly written packages
and code copied from random places. Such problems usually disappear by running
`emacs -q`.

> I just checked, and 36% of the files in my site-lisp directory are using
> lexical scoping.

Maybe you meant the `lisp` directory? `site-lisp` is for site-local files,
e.g. ones provided by the distro packagers and sysadmins, not by Emacs itself.
I have a single file in my /usr/share/emacs/26.3/site-lisp directory,
`subdirs.el`, which contains, in its entirety:

    
    
        (if (fboundp 'normal-top-level-add-subdirs-to-load-path)
            (normal-top-level-add-subdirs-to-load-path))
    

In contrast, /usr/share/emacs/26.3/lisp contains 258 .el.gz files, from Emacs
itself.

About the same percentage as you mentioned use lexical-binding, yes. Patches
welcome, I'm sure, although I wouldn't expect a noticeable performance
improvement by changing them to do so.

> Dynamic scoping can be handy! Here's (incredibly nasty) my fix for the hard-
> coded 1-second delay in shell mode:

That is pretty nasty. ;) There are two better solutions:

1\. Use ansi-term instead of shell. ansi-term is the better shell package
included in Emacs. AFAIK there's no reason to use shell over ansi-term. Just
call `M-x ansi-term RET` instead.

2\. Generally, use advice rather than `flet`. But I can't recommend advising
`sleep-for`, as that would be likely to cause problems.

And FYI (you may already know, but in case not), with lexical-binding, you
would have to use either advice or `letf` with `symbol-function` to override
functions like that.

> The fact that such a fix is needed, on the one hand, and that such a fix is
> possible, on the other, are emblematic of the both cultural and technical
> reasons that emacs is not more robust.)

FWIW, there is no call to `sleep-for` in my Emacs 26.3's `shell.el` file. I
suspect you have a configuration problem, or perhaps you installed an Emacs
that was packaged poorly, with ill-advised patches applied.

~~~
dilap
On the one hand, you're absolutely correct that most of my problems are in 3rd
party packages, my own customizations (perhaps), and their interactions.

But on the other hand, emacs w/o 3rd party packages and personal
customizations isn't really Emacs!

So I think it's fair to critique the quality of the software you end up with
in practice, as a normal user of Emacs. Perhaps I should say the "Emacs
ecosystem" tends towards jankiness, rather than Emacs itself, per se.

> site-lisp vs lisp

I meant my personal collection of 3rd party packages I have installed, which
for some reason I call site-lisp, perhaps an abuse of the term!

My thinking was recent 3rd-party code wold be a better pulse-check of current
practice than emacs itself, which I'd expect to have a lot of older code
predating lexical scope. Interesting that they're about the same though.

> FWIW, there is no call to `sleep-for` in my Emacs 26.3's `shell.el` file

It turns out it's in comint.el, in (comint-exec). Here's the code:

    
    
      ;; Feed it the startfile.
      (cond (startfile
       ;;This is guaranteed to wait long enough
       ;;but has bad results if the comint does not prompt at all
       ;;       (while (= size (buffer-size))
       ;;         (sleep-for 1))
       ;;I hope 1 second is enough!
       (sleep-for 1)
     ...

~~~
useragent86
> But on the other hand, emacs w/o 3rd party packages and personal
> customizations isn't really Emacs!

Certainly it is! There are many users who have used Emacs for decades who have
only a handful of lines in their init files and no third-party packages.

> So I think it's fair to critique the quality of the software you end up with
> in practice, as a normal user of Emacs. Perhaps I should say the "Emacs
> ecosystem" tends towards jankiness, rather than Emacs itself, per se.

Yes, I think you should say that instead; that would be more fair and
accurate.

Elisp is a forgiving language, and Emacs is a forgiving environment, so low-
quality code is not always "punished" by failing to compile or run. So, as
with any software you would run on your computer, you should use discretion.

The good news is that the quality of software in the Emacs ecosystem is
steadily improving. MELPA is upholding higher standards for packages, and more
tools are being made to catch poor-quality code and encourage best practices.

> I meant my personal collection of 3rd party packages I have installed, which
> for some reason I call site-lisp, perhaps an abuse of the term!

Ah, I see. Not necessarily an abuse, if you are your own sysadmin, I guess. :)

> It turns out it's in comint.el, in (comint-exec).

Thanks, that's interesting. I guess there must be some interesting discussion
on emacs-devel about that from years past. I wonder if that could be improved.

~~~
dilap
> Certainly it is! There are many users who have used Emacs for decades who
> have only a handful of lines in their init files and no third-party
> packages.

...

> Yes, I think you should say that instead; that would be more fair and
> accurate.

Makes sense, & will do in the future!

> The good news is that the quality of software in the Emacs ecosystem is
> steadily improving. MELPA is upholding higher standards for packages, and
> more tools are being made to catch poor-quality code and encourage best
> practices.

Good to hear. :-)

------
mxuribe
This is brilliant! Not so much for use of emacs or libpurple or bitlebee
specifically for that matter (which are all fine)...Rather, what i find to be
the coolest is the whole... "I'm gonna use __my preferred __text editor to
interact with the world " approach! Some might say that this reduces outside
systems into nothing more than an API-sort of layer, but honestly, I really
like that; it helps with learning curves, general adoption, etc. Kudos!

~~~
preek
Op here. First, let me say: Thank you for the kind words

You're spot on!

I'm using Emacs for todos, project management, meeting minutes, quotes,
invoices, accounting, mails, chat, programming, configuration management,
slides, documentation and so much more. As long as the task is primarily based
around consuming or producing text, it's incredible how much more performance
a solid foundation yields.

In case anyone is curious, here's my config:
[https://github.com/munen/emacs.d/](https://github.com/munen/emacs.d/)

~~~
nemosaltat
I initially read this as the Spanish word “todos,” which translates as
“everything.” The rest of the comment goes on to support my initial
interpretation. I love it when things work out that way.

------
dfboyd
Slack is working hard to prevent this kind of interoperability; the incentive
for them is to push ahead on features, and being abstract-able behind bitlbee
or libpurple impairs that. They have deprecated the API token (called a
"Legacy Token" on their site) that bitlbee uses, and there's a sunset date of
May 5 2020.

~~~
tyrust
They used to run an IRC relay, too, but got rid of it years ago.

~~~
theelous3
Yeah, that was a frustrating day for me. I went from running all of my IM
through my IRC client, to being forced in to a combination of my IRC client
and the slack desktop native app, to eventually giving up on slack altogether
as it was heavy and finicky, providing nothing more (for me) than any simple
IM client.

I firmly believe we're just in a bad place on the whole in terms of IM/voip
systems for personal use and org use. Nothing is really good enough. The only
ones that live up to expectations are mumble and IRC - the absolute no-
nonsense of them leaves expectations low and exceeds them. Had slack taken a
more open route and stopped being so org focused it had the potential to do
really well (in the "good ecosystem" sense, not in the financial sense as
clearly they're doing fine.)

Nothing bridges the gap between personal social use, informal org use (gaming,
loose projects), and actual org use. How is it that mumble and teamspeak etc.
are still far superior voip clients to literally all other offerings,
including the well funded and supposedly mature discord which should be
excelling here. Only thing mumble/ts can't do is replace voip telco systems,
which in fairness nothing else does either.

Slack can't do voip for shit, discord can't even do notifications, irc can
only manage offline message history if you're highly tech savvy or pay for it,
whatsapp requires a phone with an active connecion and is clumbsy for
ephemeral groups (telegram is fairly similar), gitter doesn't even come in to
the picture, matrix has the shittiest public servers in the history of
technology, xmpp is esoteric gobbeldygook.

The whole space is a mess.

------
Naac
For a more feature-full emacs IRC experience, I would recommend Circe[0]. It
even supports showing images inline like slack.

If IRC in emacs is not your cup of tea, I would recommend the web client/web
server The Lounge[1], which as far as I'm concerned gives people everything
they want out of slack, in IRC, but doesn't lock you down to a proprietary
protocol.

[0]
[https://github.com/jorgenschaefer/circe](https://github.com/jorgenschaefer/circe)
[1]
[https://github.com/thelounge/thelounge](https://github.com/thelounge/thelounge)

~~~
preek
Op here.

Thanks for linking to Circe. I didn't know about that and will happily check
it out. thelounge also does look really nice!

Having said that, the IRC client ERC which I'm using works well with regards
to inline images. Here's my config for that:
[https://github.com/munen/emacs.d/#irc](https://github.com/munen/emacs.d/#irc)

------
Arathorn
could also Matrix and Emacs all the things, just sayin’
[https://github.com/alphapapa/matrix-
client.el](https://github.com/alphapapa/matrix-client.el) :)

~~~
mxuribe
My prediction is that at some point in the future, those folks who have
historically loved IRC (and there's nothing wrong with that!), will eventually
begin to prefer matrix as opposed to, say, slack, mattermost, etc. Not
necessarily for tech superiority, but for what I'll call the coziness factor;
they'll just feel cozy using some matrix client, as they felt comfy using an
ol' irc client. (Yes, yes, i know there are numerous existing irc-bridging
apps/services natively supported by matrix protocol. ;-)

Disclosure: I used to love irc in the 90s, then stopped using it in the 2000s
(aughts?), and now am a superfan of matrix.

~~~
rabidrat
I don't care what chat network I use, as long as I can use weechat.

------
defanor
I'm using a similar setup and for similar reasons, particularly for XMPP, but
finding it hard to recommend to others because of the awkward bits involved
(and because not everyone uses/prefers Emacs, of course). It's mostly okay for
basic textual messages over a stable connection, though even then an IRC
client is likely to split outgoing messages assuming an IRC message length
limit. But when it comes to anything more advanced (e.g., file transfer), less
visible (e.g., proper connection closing), or requiring a more advanced UI, it
leads to compromises at multiple stages: similarly to just bridging protocols
in general, but with addition of bitlbee/libpurple API restrictions.

Sometimes I wonder whether the situation would be better with specialized CLI
IM clients running inside Emacs's shell mode: it works well for telnet MUDs,
at least.

------
u801e
The contrast level they used for the text in the article makes it too
difficult to read.

~~~
kencausey
Surely everyone knows about Reader mode by now? More seriously, is something
like Firefox's Reader mode available as a plugin to Safari? I can confirm that
it is for Chrome.

~~~
hibbelig
Safari has it built in.

~~~
kencausey
OK, thanks. I am a bit of a broken record in regards to recommending the use
of Reader mode. This is more fuel to my madness.

------
zzo38computer
I might recommend that people who have set up Discord or Slack or Matrix or
whatever should set up their own IRC server to bridge with it, rather than the
end user setting up their own.

------
maurits
Every 6 months or so I do the vim<->sublime<->emacs dance. I really want to
like emacs and really believe in its central tenants.

Its not that it is hard, but I just can't get over the fact that it seems to
not work very well. Buggy, slow, bewildering documentation, fresh installs
that are broken, it all wears me down.

~~~
iLemming
It certainly may appear to be broken all the time. But that's the price you
pay for using the vast Emacs ecosystem. Emacs over the decades has accumulated
an incredible amount of things - built-in and third-party packages, different
ways to work on various platforms, protocols, screen-sizes, languages, etc.

There are tons of code written in Emacs-lisp on Github alone. None of them,
not a single developer contributed to Emacs ecosystem, has ever gotten paid,
except for a few, small, voluntary donations. Almost all of that work is done
by individual contributors. If you think about it, Emacs, to a certain degree,
defies any logic - the way how it's concocted shouldn't work at all. Yet, it
does, and some features of it done is a particular, astonishingly clever way,
that no other IDE or editor has ever successfully replicated them.

To become a serious Emacs user, one has to either choose to be austere and
handpick the packages to use or has to become really good in debugging the
problems when they arise. Learn Emacs lisp, learn how to use built-in
profiler, "toggle-debug-on" functions, learn how to investigate slow/failing
startup, how Emacs loads packages, and you can update things with no fear.

Yes, sometimes things break (show me a software product with no bugs), but for
me, it never takes longer than a few minutes to either find a fix or a
workaround. From my perspective - Emacs is very stable.

------
kleiba
Good ol' C-x M-c M-butterfly...

