Earlier quoted context omitted.
I love the idea of a Matrix emacs client, but it doesn't support E2EE and probably won't ever, so it's a non-starter for me.
Luckily, the good folks at Matrix have thought of the client support issue: https://github.com/matrix-org/pantalaimon
IRC and Emacs all the things
81–90 of 90 posts
Re: IRC and Emacs all the things
#82Earlier quoted context omitted.
> 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 complete…
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…
> 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.
Re: IRC and Emacs all the things
#83Earlier quoted context omitted.
> I still haven't found a way to make my custom keybindings just work everywhere; every so often I happen to end up with focus in a window where, for example, my normal window navigation bindings don't work and I'd have to go out of my way to fix it. The easiest way to do this is to use `bind-keys' (specifically, the one with an asterisk after it, which HN markup won't seem to let me use without creating italics inst…
My bindings need to be state-aware, because they are evil. So a simple global override is actually not quite enough..
Re: IRC and Emacs all the things
#84Earlier quoted context omitted.
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…
> 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 ver…
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)
...Re: IRC and Emacs all the things
#85Earlier quoted context omitted.
> 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 ver…
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 to…
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.
Re: IRC and Emacs all the things
#86Earlier quoted context omitted.
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 to…
> 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" tend…
...
> 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. :-)
Re: IRC and Emacs all the things
#87> 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., fee…
I've long struggled getting Emacs to interop with all things Mac, and so happily pulled down Spacehammer to give it a shot. It seems snappy and generally like a Good Idea, but whenever I try one of the configured Emacs-related commands, it briefly pops open a new Emacs GUI window and then immediately closes it. Nothing useful seems to come from Messages or Warnings.
I don't suppose you've run into & dealt with this or similar, or have any ideas? I'd love to use Spacehammer.
Re: IRC and Emacs all the things
#88> 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., fee…
Classic "support request via HN" move incoming! I've long struggled getting Emacs to interop with all things Mac, and so happily pulled down Spacehammer to give it a shot. It seems snappy and generally like a Good Idea, but whenever I try one of the configured Emacs-related commands, it briefly pops open a new Emacs GUI window and then immediately closes it. Nothing useful seems to come from Messages or Warnings . I…
Basically, both Hammerspoon and Emacs have to know about your activity of editing. Spacehammer handles Hammerspoon side, in order for that thing to work with Emacs, you have to import spacehammer.el package in Emacs.
Let me know if any additional questions arise.
Re: IRC and Emacs all the things
#89Every 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.
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.
Re: IRC and Emacs all the things
#90Earlier quoted context omitted.
Classic "support request via HN" move incoming! I've long struggled getting Emacs to interop with all things Mac, and so happily pulled down Spacehammer to give it a shot. It seems snappy and generally like a Good Idea, but whenever I try one of the configured Emacs-related commands, it briefly pops open a new Emacs GUI window and then immediately closes it. Nothing useful seems to come from Messages or Warnings . I…
I've been too busy with my work related duties. I need to update and improve the documentation. Sorry about that. Basically, both Hammerspoon and Emacs have to know about your activity of editing. Spacehammer handles Hammerspoon side, in order for that thing to work with Emacs, you have to import spacehammer.el package in Emacs. Let me know if any additional questions arise.