IRC and Emacs all the things • Hacker News Board

Re: IRC and Emacs all the things

#61

Post by dilap » Sun, Mar 08, 2020, 1:18 PM UTC

Barrin92 wrote: post #46

dilap wrote: post #39

Earlier quoted context omitted.

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.

>As a devoted emacs addict, I can attest that plan old emacs is also pretty slow and clunky it's true in the sense that it's true for almost anything once you start to add a plugin or two or add personal customizations. The only thing for me that is actually consistently, superfast is terminal vim without any plugins. Which is too barebones for my daily use. In a realistic, daily working environment with all my stuff…

Even just basic text rendering in emacs is slow!

Three examples:

I use the windowed Mac version most of the time, and touchpad scrolling is so slow that it's basically not a reasonable way to get around a file. Compare to Sublime, where it's silky smooth, and you can get an almost physical feeling of where things are, which makes zipping around using scrolling very effective.

I run my shell inside emacs (which is super nice -- how do people survive not having easy immediate access to command output)? But if a command is going to generate a lot of output (e.g., if I have the misfortune to be running mvn), I'll need to either drop back to terminal or redirect the output to a file, or be content with my command slowing down 100x to wait for emacs to render the output.

Try opening a file that happens to contain a very long line (this happens sometimes w/ generated code, or json data, or ...). Emacs will basically freeze, due to some N^2 in line length algorithm somewhere.

It's no easy task, but I do think it's possible to make something w/ the near-infinite, excellent flexibility of emacs, while also hitting a much higher speed and quality bar.

Re: IRC and Emacs all the things

#62

Post by omaranto » Sun, Mar 08, 2020, 1:35 PM UTC

AlbertoGP wrote: post #54

catblast wrote: post #40

Earlier quoted context omitted.

> "opinionated" I feel this term might need to be officially dead and buried. If something as customizable as emacs is deemed opinionated what does this even mean? For chrissakes there are people that consider emacs to be a better vi implementation than vim.

Well, there are lots of customizations doable (I’m still rocking my .emacs from the 1990’s going through several platforms, Linux→MacOS→Linux, refined over the years with custom functions etc.) but to name a single example: my keyboard does have a Find key, and I tried mapping isearch-forward to it instead of the default CTRL+S. That’s trivial, but then, you know how you can press CTRL+S again to go to the next resul…

What HNer henry_flower neglected to state explicitly in his helpful comment is that it is false that pressing C-s to go to the next result is hardcoded in some Emacs Lisp function. I just wanted to say that in case non-Emacsers don't know it's implied by what Henry did say. (What he said is much better than just "that's not true!", he also tells you how to change the C-s key that goes to the next match.)

Re: IRC and Emacs all the things

#63

Post by dilap » Sun, Mar 08, 2020, 1:40 PM UTC

iLemming wrote: post #47

dilap wrote: post #39

Earlier quoted context omitted.

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.

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…

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!)

Re: IRC and Emacs all the things

#64

Post by omaranto » Sun, Mar 08, 2020, 1:42 PM UTC

dilap wrote: post #61

Barrin92 wrote: post #46

Earlier quoted context omitted.

>As a devoted emacs addict, I can attest that plan old emacs is also pretty slow and clunky it's true in the sense that it's true for almost anything once you start to add a plugin or two or add personal customizations. The only thing for me that is actually consistently, superfast is terminal vim without any plugins. Which is too barebones for my daily use. In a realistic, daily working environment with all my stuff…

Even just basic text rendering in emacs is slow! Three examples: I use the windowed Mac version most of the time, and touchpad scrolling is so slow that it's basically not a reasonable way to get around a file. Compare to Sublime, where it's silky smooth, and you can get an almost physical feeling of where things are, which makes zipping around using scrolling very effective. I run my shell inside emacs (which is sup…

Scrolling sounds like a terrible way to get around a file. I'd much rather be presented with a prompt to go to a named "section" with completion (an actual section in a prose document, or a function definition in a program), or to search for some text. Or, if I don't have a specific target in mind and I want an overview of the file, I prefer pagination to scrolling.

But... I wonder how much my preference is conditioned by years of Emacs and its subpar scrolling? My preference for pagination+search extends to other software; to browsers, for example (spacebar or ctrl+f over mouse-wheel), but is that just a habit I got from my constant Emacs usage (I typed this comment in Emacs)?

Re: IRC and Emacs all the things

#65

Post by AlbertoGP » Sun, Mar 08, 2020, 1:54 PM UTC

henry_flower wrote: post #58

AlbertoGP wrote: post #54

Earlier quoted context omitted.

Well, there are lots of customizations doable (I’m still rocking my .emacs from the 1990’s going through several platforms, Linux→MacOS→Linux, refined over the years with custom functions etc.) but to name a single example: my keyboard does have a Find key, and I tried mapping isearch-forward to it instead of the default CTRL+S. That’s trivial, but then, you know how you can press CTRL+S again to go to the next resul…

> that key combo is hardcoded in LISP isearch-forward turns on a minor mode that has it's own keymap a snippet from isearch.el: (defvar isearch-mode-map ... ;; Several non-printing chars change the searching behavior. (define-key map "\C-s" 'isearch-repeat-forward) (define-key map "\C-r" 'isearch-repeat-backward) hence to redefine C-s, to, say F12: (global-set-key [f12] 'isearch-forward) (define-key isearch-mode-map…

I see, thanks for the correction.

Re: IRC and Emacs all the things

#66

Post by AlbertoGP » Sun, Mar 08, 2020, 1:55 PM UTC

omaranto wrote: post #62

AlbertoGP wrote: post #54

Earlier quoted context omitted.

Well, there are lots of customizations doable (I’m still rocking my .emacs from the 1990’s going through several platforms, Linux→MacOS→Linux, refined over the years with custom functions etc.) but to name a single example: my keyboard does have a Find key, and I tried mapping isearch-forward to it instead of the default CTRL+S. That’s trivial, but then, you know how you can press CTRL+S again to go to the next resul…

What HNer henry_flower neglected to state explicitly in his helpful comment is that it is false that pressing C-s to go to the next result is hardcoded in some Emacs Lisp function. I just wanted to say that in case non-Emacsers don't know it's implied by what Henry did say. (What he said is much better than just "that's not true!", he also tells you how to change the C-s key that goes to the next match.)

I realize now that I misused the term “hardcoded”, thanks.

Re: IRC and Emacs all the things

#67

Post by thiht » Sun, Mar 08, 2020, 2:28 PM UTC

_hardwaregeek wrote: post #31

iLemming wrote: post #26

> 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 legitimately don't know how people can code without using some emacs or vim commands. Even the simplest stuff like M-f/M-b or C-a/C-e are so ingrained in how I use a computer. Do people genuinely not use them? Do they just navigate with the mouse and arrow keys? I suppose there's alternatives like Cmd- and Cmd- or Alt- and Alt- .

Not using emacs, I could answer, but I have no idea what "M-f/M-b or C-a/C-e" means

Re: IRC and Emacs all the things

#68

Post by dilap » Sun, Mar 08, 2020, 2:55 PM UTC

omaranto wrote: post #64

dilap wrote: post #61

Earlier quoted context omitted.

Even just basic text rendering in emacs is slow! Three examples: I use the windowed Mac version most of the time, and touchpad scrolling is so slow that it's basically not a reasonable way to get around a file. Compare to Sublime, where it's silky smooth, and you can get an almost physical feeling of where things are, which makes zipping around using scrolling very effective. I run my shell inside emacs (which is sup…

Scrolling sounds like a terrible way to get around a file. I'd much rather be presented with a prompt to go to a named "section" with completion (an actual section in a prose document, or a function definition in a program), or to search for some text. Or, if I don't have a specific target in mind and I want an overview of the file, I prefer pagination to scrolling. But... I wonder how much my preference is condition…

Exactly, it's hard to miss what you haven't had!

In emacs, I mostly navigate around by searching, or sometimes by outlining (hide all lines that aren't a definition, move to definition, unhide).

But I do remember before I became an emacs addict, and there was something very nice about having a physical sense of your file layout. If you have that sense, scrolling can an efficient way to navigate a file (well, up to a certain size, anyway).

And I think there's something valuable in the almost subconscious feeling for the layout of the file you get as you scroll thru it.

When I'm mostly in emacs, my sense of what a file "is" is much hazier, because I'm just warping from one place to another.

(On the other hand, maybe the entire concept of a file as a linear progression is antiquated for source code...)

Re: IRC and Emacs all the things

#69

Post by useragent86 » Sun, Mar 08, 2020, 5:34 PM UTC

clarry wrote: post #44

iLemming wrote: post #43

Earlier quoted context omitted.

The thing about Spacemacs many people don't get - it does not liberate you from learning Emacs internals. The good thing about Spacemacs that it simplifies one of the most challenging things about Emacs - discoverability. The hardest part of Emacs is to learn what Emacs can do, what it offers. And many gems are hidden under so many layers, that people may not even know about them after decades of using Emacs every si…

> The hardest part of Emacs is to learn what Emacs can do, what it offers. Nah, for me the hardest part is finding out about all the things it doesn't do. Unless you code it. Maybe you find some half-arsed packages, but they might just make you more frustrated. For example, I still haven't found a way to do vim-like completion. I still haven't got a good cscope interface that doesn't crap all over my windows (a commo…

> 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 instead), which creates a global map for your personal key bindings that override other bindings (so, use it thoughtfully, and remember that `describe-personal-keybindings' will list them). It's best used in the `use-package' macro, like:

    (use-package ace-jump-mode
      :bind* ("C-." . ace-jump-mode))

Re: IRC and Emacs all the things

#70

Post by useragent86 » Sun, Mar 08, 2020, 5:45 PM UTC

dilap wrote: post #63

iLemming wrote: post #47

Earlier quoted context omitted.

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…

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 inte…

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