Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Toward a “modern” Emacs

lwn.net

Post reply on HN
Print view View original

481–490 of 539 posts

Re: Toward a “modern” Emacs

#481

Post by TeMPOraL »

neltnerb wrote: post #479
TeMPOraL wrote: post #475

Earlier quoted context omitted.

By making your own tools I don't mean making your own knitting needles or torch head - though some do that too. I meant making custom workbenches, custom harnesses for the parts you're working on, modding the tools to be more ergonomic or to serve a different purpose than intended, etc. This is all "making your own tools" too. I have a woodworker in my family and from what I observed watching him at work, he mods his…

I wouldn't call anyone who doesn't feel it's worth the investment to customize something an "assembly line worker", it implies that they aren't doing creative work with the tool because they happen to be more focused on the project than the tool. It's just insulting and I don't get why you'd bother to go that far. I also don't know why you'd draw any kind of line at "modified own tool". Building your own 3d printer d…

I admit the comment was phrased in an unnecessarily inflammatory way, and I apologize.

The point wasn't to draw a line between "programmers - craftsmen" and "programmers - assembly line workers", but to highlight that programming is very much craftsmanship, and because of that, I disagree with the thought "I am a craftsman, not a tool maker" in the comment I replied to. A craft is almost by definition something that isn't streamlined to the point you can reasonably only focus on using tools you're provided. There's always a benefit in doing meta-work - work to make your work easier. This applies to programming much more than other crafts, because the skill set you need to build tools is literally the same as the one you use for working with those tools.

Also note that the comment didn't say the assembly line workers aren't creative (though on a perfect assembly line they can't be creative at work, by definition) - but that the type of work doesn't leave much space for bottom-up improvement.

> Building your own 3d printer doesn't make you creative if you're using a kit, it's the parts you make that are creative or not.

If building your own 3D printer lets you shorten your iterations compared to your old process of sending CAD drawings to some company and waiting a couple of days, thus saving you effort and money, then building that printer from a kit is very much worthwhile and it's what I'd expect a craftsman would do. Too much focus on the work immediately in front of you is bad too (see also: greedy algorithms). This whole topic isn't an issue of creativity, but pragmatism.

Re: Toward a “modern” Emacs

#482

Post by tonyarkles »

Dangeranger wrote: post #446
tonyarkles wrote: post #437

Earlier quoted context omitted.

> There will be major new areas of innovation I’m really curious what you mean by that, and how you see the world evolving such that Emacs, as is, won’t be able to come along with it.

Imagine a world where your terminal isn’t emulating a TTY from fifty years ago. Gary Bernhardt gave a talk about this in 2012[0]. [0] https://www.destroyallsoftware.com/talks/a-whole-new-world

Pretty cool talk! I love some of the features he's added!

https://imgur.com/Gtytll1

An interesting thing that often gets forgotten or missed is that Emacs doesn't depend on a conventional TTY to run. It's already capable of displaying images either in separate buffers or inline.

From Gary's talk there, my thoughts would be that a number of the features he's put in there would:

a) be potentially better-served as CLI tools instead of baked directly into the IDE, with well-defined inputs and outputs. I have no problem imagining use cases for e.g. the crash navigation stuff outside of an editor (perhaps as part of an error-handling dashboard).

b) likely already be possible to build in non-terminal versions of Emacs, without having to design your own terminal and editor from scratch.

By no means do I think Emacs is a perfect editor, but I'm also very cautious when pondering "do we rebuild from scratch"-type questions. I'm always keeping my eye on other editors and IDEs, and with varying levels of difficulty, I haven't really come across too many useful things that wouldn't be possible to do within the current Emacs/Elisp environment. Awkward, maybe.

Re: Toward a “modern” Emacs

#483

Post by nobody9999 »

Qwertious wrote: post #325
nobody9999 wrote: post #196

Earlier quoted context omitted.

>The keybindings need to be fixed. CUA has been the norm for what, 35 years at this point. M-x cua-mode Oh, and you're welcome.

Thatcs not the norm. That's an off-by-default feature that doesn't display its existence to people who would use it.

>Thatcs not the norm

So what? Is your argument that if not many people/products/software packages do a certain thing a certain way, they should be rejected out of hand?

Back when I was a teen, I rode my skateboard goofy-footed[0]. That wasn't (and still isn't) the norm. Should I have been chastised or prevented from doing so?

I'm also left-handed. While I do keep the mouse on the left side of my keyboard, I do not swap the mouse buttons. As such, a right-click is done with my index finger and a left-click with my middle finger. That's not the norm either. Should I be criticized for that?

Chrome is, by far, the "norm" for web browsers. I use Firefox, and occasionally Vivaldi. Should FF or Vivaldi just make themselves clones of Chrome because they're not "the norm"?

I run sendmail and not postfix, even though that's much more "the norm." Does that make my MTA bad or less useful?

I could probably rattle off a dozen other similar things that aren't "the norm." Does that mean no one should do things that way or use them?

If you want/need an editor that uses CUA by default, there are dozens of editors that do so. Why should Emacs (or any other product that you don't contribute to or use) do things the way you want them to do so?

[0] https://www.liveabout.com/goofy-meaning-3002686

Re: Toward a “modern” Emacs

#484

Post by da39a3ee »

bananaface wrote: post #361
da39a3ee wrote: post #37

Earlier quoted context omitted.

I found that it didn't work out of the box for me (Rust and Python) but that eglot did work out of the box. Eglot, not lsp-mode, will be the LSP implementation that makes it into the GNU Emacs distribution (because it is being developed with FSF assignments, and because the maintainer is active in the GNU Emacs development community, maintaining eldoc and flymake, and maybe others).

It would be bad if it did, IMO. Eglot is a pretty dodgy piece of software and the code is much worse than lsp-mode.

Could you give some justification for that criticism and assertion please? (On its own, your comment falls short of HN standards.)

Re: Toward a “modern” Emacs

#485

Post by konjin »

JoshTriplett wrote: post #469
konjin wrote: post #353

Earlier quoted context omitted.

It helps to have a lot of very visible brackets when people sign up, it scares away the majority who won't cut it. Emacs is in that unfortunate position that you can learn the shortcuts and 'use' it for months before you even see your first bracket and end up thinking the brackets are the problem, not you. The number of times I've heard people demand the scripting language change to python...

And that exact attitude also drives away people who could handle and enjoy Lisp just fine, just not unwelcoming elitism.

Yes, it's a feature, one we should use a lot more of.

Someone that thin skinned would demand that the project accommodate them, try to take it over and then run it to the ground.

After all it's not like Stallman didn't become homeless because of people like that.

Re: Toward a “modern” Emacs

#486

Post by baby »

olejorgenb wrote: post #354
baby wrote: post #259

Earlier quoted context omitted.

> then you trigger whatever command you need how do you do see? How do you get to the list of commands? How do you search for a command? How do you remember a shortcut if you run a command manually? I've been using emacs for quite some time and I still get stuck there.

To run/search-for a command: M-x If you have installed and configured helm (I assume the same for ivy) you'll get a list and the search will be fuzzy) In helm: shortcuts are shown in the result list: M-x replac| replace-string replace-regexp query-replace (M-%) ... In helm you can navigate the list with the arrow keys and TAB (not sure if it's the default key) will pop up an help buffer for the command

I don't use helm, tried for a while but got really confused by a lot of things. So when I do M-x I actually can't fuzzy search OR see what the shortcut version of a command is.

Re: Toward a “modern” Emacs

#487

Post by baby »

olejorgenb wrote: post #350
baby wrote: post #157

All of these are missing the point imo. The biggest advantage of modern IDE is the ease in trying new plugins and functionalities. Everything is a menu away, and fuzzy searching makes it easy to find out commands and learn their shortcuts. This whole process just doesn’t exist in emacs. To get a plugin, it’s a huge step (setting up custom elisp to get melpa) and then it’s a huge learning curve just to try a plugin.

> The biggest advantage of modern IDE is the ease in trying new plugins I don't think think pasting a few lines[1] into a file can be counted as a huge step? There's built-in UI [2] for installing and configuring packages. To me the overwhelming advantage of an IDE is good semantic language support out-of-the box. Even having invested quite some time in language-support configuration in emacs I usually use an IDE ins…

For example, I'm trying to setup rust-analyzer with emacs right now, and the instructions here makes 0 sense at all: https://rust-analyzer.github.io/manual.html#emacs

I'm completely stuck at step 2 and 3, how can anyone parse this without being an emacs pro is beyond me

Re: Toward a “modern” Emacs

#488

Post by Fishysoup »

daedalus_f wrote: post #424
Fishysoup wrote: post #312

Earlier quoted context omitted.

I would like it to be multithreaded and for Org mode to have some more UI features (and I think a lot of people would - at least the former). From what I understand it's really hard to do that by building on the existing C base ELisp base. Unpopular opinion: we should write the "new" Emacs in Julia (and maybe Rust).

As for Julia, I mean I like the matlab like syntax for data science use, and I’m sure its great for prototyping computation heavy algorithms where run time dwarfs the JIT lag, but its surely not suitable for a text editor, at least at present. I’ve tried Julia several times as new versions of have been released and for simple scripting tasks that required a few external libraries I’ve always ended up rewriting the sc…

My experience has been the opposite: things have been much easier and faster to set up in Julia. Yes, "time to first plot" is annoying after you update the plot package, but that's the only annoying thing for me.

Julia is a thinly disguised Lisp, offering all the wizardry associated with that language family - so it's very expressive.

Re: Toward a “modern” Emacs

#489

Post by vfclists »

TrisMcC wrote: post #410
trenchgun wrote: post #408

Earlier quoted context omitted.

Doom emacs is probably the state of the art emacs starter pack now. A lot faster than spacemacs, more stable etc. A rock solid default config made out of Doom emacs might work.

I don't think a starter pack that completely disables the "Customize" interface would be a good candidate for default. https://github.com/hlissner/doom-emacs/blob/a2a5038b970df20e... "Doom doesn't support `customize' and it never will. It's a clumsy interface" I find the Customize interface very useful.

When you use the customize interface you sacrifice proper version control.

Bad idea.

Re: Toward a “modern” Emacs

#490

Post by grzm »

vfclists wrote: post #489
TrisMcC wrote: post #410

Earlier quoted context omitted.

I don't think a starter pack that completely disables the "Customize" interface would be a good candidate for default. https://github.com/hlissner/doom-emacs/blob/a2a5038b970df20e... "Doom doesn't support `customize' and it never will. It's a clumsy interface" I find the Customize interface very useful.

When you use the customize interface you sacrifice proper version control. Bad idea.

You can include custom-file in version control easily enough.
Post reply on HN