3 ms·

> 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 les

> 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 7y ago
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 7y ago
  > 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 7y ago
    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) ...

dilap 7y ago

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 7y ago
> 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 7y ago
  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) ...