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

Emacs: The Editor for the Next Forty Years [video]

media.emacsconf.org

Post reply on HN
Print view View original

221–230 of 272 posts

Re: Emacs: The Editor for the Next Forty Years [video]

#221

Post by rusk »

pjmlp wrote: post #214
dragonsh wrote: post #203

Earlier quoted context omitted.

No it's not a poor replacement of Borland or SlickEdit used both and still went back to emacs. Personally I use emacs over vscode due to following reasons, 1. it does not waste CPU cycle in rendering html, we have browsers for it. 2. Provide a good irc insterface with ERC without distracting my work like slack and discord with unnecessary bells and whistles, 3. and last but not the least does one thing very well whic…

It doesn't do any kind of graphical tooling. IDEs also don't waste CPU cycles displaying HTML. C is rightfully crictised, plenty of systems programming languages offer the same hardware access, without exposing the world to memory corruption and UB exploits, some of them about 10 years older than C. Unfortunately UNIX had more success than the OSes they were available on.

Not having graphical tooling is a net positive in my experience. I’m a programmer, not a graphic designer.

Also the UI while visually clunky is neat and free of distractions.

The only IDE I use these days in IntelliJ for Java - because Java is one of those few languages that really benefits from integrated development. Great as it is, I do find myself having to relearn a few things every year or so, and often having to readjust to changes in look and feel, and for what?

Re: Emacs: The Editor for the Next Forty Years [video]

#222

Post by msla »

jhoechtl wrote: post #124
slightwinder wrote: post #70

Earlier quoted context omitted.

There may be much going on with emacs, but so far it fails to move ahead. The project is just improving the old strenghts, but not fixing the old fails. And as time moves, they start to hurt more and more and more until they break.

The most core inards of Emacs are subject to bitrot. It doesn't play well with any Windowing system. And as an editor it is quite slow/sluggish.

It's quite speedy, unlike IDEs, and it's very well-integrated with good windowing systems.

Re: Emacs: The Editor for the Next Forty Years [video]

#223

Post by dragonsh »

pjmlp wrote: post #214
dragonsh wrote: post #203

Earlier quoted context omitted.

No it's not a poor replacement of Borland or SlickEdit used both and still went back to emacs. Personally I use emacs over vscode due to following reasons, 1. it does not waste CPU cycle in rendering html, we have browsers for it. 2. Provide a good irc insterface with ERC without distracting my work like slack and discord with unnecessary bells and whistles, 3. and last but not the least does one thing very well whic…

It doesn't do any kind of graphical tooling. IDEs also don't waste CPU cycles displaying HTML. C is rightfully crictised, plenty of systems programming languages offer the same hardware access, without exposing the world to memory corruption and UB exploits, some of them about 10 years older than C. Unfortunately UNIX had more success than the OSes they were available on.

In spite of all your arguments even today most important software powering modern computing are written in C, this speaks volume about its simplicity.

I am sure there will still be critical software powered by C 40 years later. Rust will take another decade or two to reach that level of simplicity and ease of use still not sure if it will cross the threshold to replace C, when an average developer needs to spend years just understanding basic syntax, use of language and its traits.

C is like English, Hindi or simplified Chinese not very pure with flaws and ambiguity, still became lingua Franca of the majority world due to simplicity.

Re: Emacs: The Editor for the Next Forty Years [video]

#224

Post by dragonsh »

v-yadli wrote: post #216
dragonsh wrote: post #203

Earlier quoted context omitted.

No it's not a poor replacement of Borland or SlickEdit used both and still went back to emacs. Personally I use emacs over vscode due to following reasons, 1. it does not waste CPU cycle in rendering html, we have browsers for it. 2. Provide a good irc insterface with ERC without distracting my work like slack and discord with unnecessary bells and whistles, 3. and last but not the least does one thing very well whic…

What you list here basically means you prefer terminal to GUI, not specific to emacs. Swap emacs for vim and most still apply. :)

I use vim too besides emacs, still prefer to work with emacs due to org-mode and lisp. Also now I got more used to emacs key bindings compared to vim.

Re: Emacs: The Editor for the Next Forty Years [video]

#225

Post by rusk »

v-yadli wrote: post #216
dragonsh wrote: post #203

Earlier quoted context omitted.

No it's not a poor replacement of Borland or SlickEdit used both and still went back to emacs. Personally I use emacs over vscode due to following reasons, 1. it does not waste CPU cycle in rendering html, we have browsers for it. 2. Provide a good irc insterface with ERC without distracting my work like slack and discord with unnecessary bells and whistles, 3. and last but not the least does one thing very well whic…

What you list here basically means you prefer terminal to GUI, not specific to emacs. Swap emacs for vim and most still apply. :)

For all its merits, I would never use VIM as a development environment, and I would never fire up emacs just for the sake of quickly editing a file ...

Re: Emacs: The Editor for the Next Forty Years [video]

#226

Post by aurelien »

Emacs is an extensible editor ... It just need to be adaptive now to programming language evolution.

If Lisp have make the job from a while it should be nice to keep that solution, but, to had more flexibility for next generations.

A simple example, I works with it every days, IRC, mail, web, source code ... but on Ycombinator, I need to load an html browser to vote ... But yes I works out of Xorg ... and that is an important value that most of editor just don't understand.

Thanks for GNU Emacs, I really love it.

Re: Emacs: The Editor for the Next Forty Years [video]

#227

Post by sooheon »

ibrahima wrote: post #202
sooheon wrote: post #192

Earlier quoted context omitted.

One thing I notice: too many things cause unresponsiveness. 8 cores in my laptop and I can't install a package in the background, and semantic parsing interrupts typing. There doesn't seem to be any concurrency at all, things I do every day like eval'ing forms to REPL cause stutters. I love that it allows makers to explore new ui paradigms (magit, lispy), but performance is its biggest downside.

https://github.com/Malabarba/paradox lets you install packages async, by the way.

That looks like an interactive ui--I can't declare use-package forms in my init.el, and have the initial install and any updates be async and concurrent.

Re: Emacs: The Editor for the Next Forty Years [video]

#228

Post by gmueckl »

dmortin wrote: post #220
gmueckl wrote: post #211

Earlier quoted context omitted.

The sad part is that text based representations of programs are holding back programmer productivity by raising the bar for these refactoring tools unreasonably. If programs were represented and edited directly as syntax trees, 80 to 90 percent of the complexity of refactoring tools would go away.

On the other hand, when writing new code it is quite efficient to simply type, supported with proper completion. It would be much less efficient to create a program in a point and click gui, dragging visual elements onto the syntax tree. So both is necessary. Efficient text editing is required to work quickly with the code, edit things locally efficiently. And refactoring is also needed if you want to perform bigger…

You're jumping to conclusions when you're associating a syntax tree based program representation with the forced use of a mouse or cumbersome navigation for editing. Nothing could be further from the truth. A completely usable and fast keyboard based editing method for such a program representation is entirely possible. The only downside is that it's harder to create a minimal working version of such a tool compared to a text editor.

Re: Emacs: The Editor for the Next Forty Years [video]

#229

Post by dmortin »

gmueckl wrote: post #228
dmortin wrote: post #220

Earlier quoted context omitted.

On the other hand, when writing new code it is quite efficient to simply type, supported with proper completion. It would be much less efficient to create a program in a point and click gui, dragging visual elements onto the syntax tree. So both is necessary. Efficient text editing is required to work quickly with the code, edit things locally efficiently. And refactoring is also needed if you want to perform bigger…

You're jumping to conclusions when you're associating a syntax tree based program representation with the forced use of a mouse or cumbersome navigation for editing. Nothing could be further from the truth. A completely usable and fast keyboard based editing method for such a program representation is entirely possible. The only downside is that it's harder to create a minimal working version of such a tool compared…

It may be possible, but I haven't seen such a tool. I have seen tools where you edited the syntax tree via a GUI and it was terrible for writing code. It may work better for tree modifications.

Text programs are pretty efficent when writing, editing code, because you can access a large number of elements quickly with the syntax.

E.g. writing let a = 3 can be much quicker than starting some command palette from the keyboard, choosing the "declare variable" action and then fill some dialog with the name and value of the variable.

I have doubts it can be made as efficient as typing, otherwise we would have seen such prototypes already. Have you?

Re: Emacs: The Editor for the Next Forty Years [video]

#230

Post by swah »

dmortin wrote: post #109
swah wrote: post #98

I changed Emacs for Sublime and now VScode - my main reason to change IIRC was that my fingers/wrist hurt from using chords so much :(

You should have simply switched to sticky keys, so you don't have to press keys simultaneously: https://en.wikipedia.org/wiki/Sticky_keys Also, you can change the keybindings.

I tried a few times, but could not go from "pressing at the same time" to "presssing in a sequence". I just "chorded"...
Post reply on HN