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

Making Emacs Popular Again

lwn.net

Post reply on HN
Print view View original

241–250 of 782 posts

Re: Making Emacs Popular Again

#241

Post by Koshkin »

agentultra wrote: post #29

Does it need to be popular or need more users to become maintainers? I use emacs because I can't imagine using anything else that has half the features and is harder to extend. I can't imagine why it needs to be popular. It's a programming environment that happens to have a text editor built in. That appeals to some folks but I can't imagine why someone interested in writing for publication would choose it over Scriv…

I find word processors with all their formatting, hyphenation etc. capabilities more of a distraction than help. IMHO they are better for publishing a text than for writing it. Even a simple text editor seems like a better choice.

Re: Making Emacs Popular Again

#242

Post by tsimionescu »

Koshkin wrote: post #192
state_less wrote: post #185

Earlier quoted context omitted.

Or, emacs in the browser. Popular editors like VS Code use monaco and now github has codespaces [1] which is running in the browser. People live as much or more in the browser as the terminal these days, so bring the emacs sauce to where the people live. Maybe you could get some of the c compiled to web assembly, and the lisp would follow? It'd be neat to open a buffer to the page emacs lives in and start editing, ca…

Agree, browser-based front-ends make so much sense today - conceivably including one for emacs (which can work in the client-server mode anyway).

Would you realistically be able to bind enough emacs keybinds in a web page so that it feels natural? Or would you need some extra extension to help with that?

I'm not very familiar with how easy it is to capture browser keybinds in a web page.

Re: Making Emacs Popular Again

#243

Post by matthewbauer »

dfabulich wrote: post #211
dan-robertson wrote: post #123

Earlier quoted context omitted.

Emacs itself starts fast. Most people who use emacs have a lot of packages that load on startup or autoload files that need to be read and this makes startup slow. Maybe if saving an image were easier then things would be faster but I think most serious users don’t care because they start emacs once a week

Out of the box, Emacs is slower than vim, and this is part of the reason why Emacs isn't installed by default on distros. Serious users don't care about startup performance, but that helps to explain why Emacs isn't gaining new users. Emacs isn't the quickest and easiest way to edit a file.

Is a second vs. a half second much of a difference? I think users start noticing at about 5 seconds.

Re: Making Emacs Popular Again

#244

Post by brainsmith »

When I started programming on ruby my laptop couldn’t handle IntelliSense and tests which required too much cpu and ram. So I’ve switched to vim on server through ssh. Later I’ve switched to emacs as it seemed to me more powerful than him back then.

After I got MacBook I’ve switched to TextMate utilizing powerful macOS keyboard shortcuts for text navigation. MacBook was pretty fast to handle ruby-related tasks.

Later I found myself in IntelliJ idea working on my Scala projects with emacs keybindings. I intuitively used emacs keybindings everywhere - from terminal to text fields in browser (without changing defaults!). Pretty comfortable until...

I started programming in Rust. It’s compiler and lsp servers use very much cpu, ram, compilation is really slow heating laptop like a frying pan. Here comes VSCode with vscode-remote which allows to write code on desktop gui while compiling, executing IntelliSense commands (lsp server to be exact), etc on a powerful cloud server. As I understand it executes everything remotely except GUI rendering and interaction. On network interruptions it restores connection seamlessly, I barely noticed. It was a salvation. VSCode has a bunch of predefined hotkeys which can be customized to fit my emacs-like navigation habits but there are always conflicts with some already existing bindings, also extension tend to add their own defaults. Too messy. Vim/emacs emulators are incomplete and buggy. This led me to weird trackpad&keybindings experience for navigating, building, debugging... Remembering how productive I was in vim/emacs I couldn’t handle this despite perfect state of the art vscode-remote.

So I decided to give vim/emacs a try, discover how ecosystem changed during 10+ years. After some investigation I’ve landed on neovim and tried to work on a rented server as I used to in my first programming years. Experience was far away from VSCode-remote. Due to network lags and ssh overhead I can’t be productive with all the benefits neovim offers. So I ended up buying a powerful home server, connecting to it from my MacBook and work in neovim over ssh. It’s ok but I really miss the “true” remote mode which offers local almost zero-latency editing with remote everything else. Renting powerful servers which has access to the whole dev infrastructure. Paying for them hourly. There are so many discussions about/plugins implementing VSCode and its extensions features in (neo)vim/emacs but in my opinion the really missing piece which don’t turn (neo)vim/emacs to VSCode but instead makes them as powerful as VSCode in cloud-powered code development. Am I the only one who miss this feature?

Re: Making Emacs Popular Again

#245

Post by melq »

throwaway_pdp09 wrote: post #140
dfabulich wrote: post #99

Emacs might never catch up to Visual Studio Code, which is actively funded by Microsoft, but intuitively, it seems like Emacs ought to be able to catch up to Vim. It's always been weird writing Emacs extensions in ELisp, but it's not like Vimscript is a top-tier language. Emacs is hard to learn, but so's Vim. I think it comes down to performance, especially startup time. Emacs developers have never cared much about i…

And no actual timings eh? My emacs starts up within 3 seconds. 2 seconds of that is it reopening all the files from my last session and arranging them on screen, saving me quite a few more seconds of doing it manually. > my #1 goal would be to beat Vim on startup time You have some weird priorities > Stallman is too far out of touch ... but even with active users of Emacs FUD! He monitors the emacs bugs list. Also I…

I agree on the start up time point. I don't know how slow most people's experience is, and I don't use emacs, but I really can't imagine people aren't using emacs because of a few extra seconds it takes to open your code.

To your second, rather obnoxious point: when they said 'out of touch', they didn't mean 'hasn't been in communication'. They meant he doesn't understand the attitudes/motivations/requirements of the community.

Re: Making Emacs Popular Again

#246

Post by matthewbauer »

dfabulich wrote: post #213
celeritascelery wrote: post #115

Earlier quoted context omitted.

Startup time can actually be really good if you configure it right. Stock Emacs is about 150ms for me. There is also a portable dumper that will save your Emacs boot Image to memory for faster loading. Also check this out. https://www.reddit.com/r/emacs/comments/f3ed3r/how_is_doom_e...

Sure, or you could use "emacs -Q," but all of those performance improvements are off by default, and it seems like they always will be. As long as that's true Vim will always be the quicker and easier way to modify a file.

-Q shouldn’t give you any better startup time than vanilla emacs.

Re: Making Emacs Popular Again

#247

Post by chongli »

simias wrote: post #229
chongli wrote: post #190

Earlier quoted context omitted.

Vim and Emacs have too many philosophical differences for this to work. For example, emacs doesn't have a fixed concept of what a paragraph should be. Instead, it leaves that up to the major mode. This is fundamentally incompatible with vim's paragraph motions which are determined by empty lines and remain the same regardless of file type. As a very long-time Vim user, I prefer that my editing commands be predictable…

Interesting viewpoint, but aren't there enough differences between programing languages to warrant mapping these concepts slightly? Clearly my Emacs origins show here, because not having simple built-in motions to select "a function" or "a class" feels like a big limitation to me. I actually have a bunch of ad-hoc bindings for that. I also seldom use paragraph motion while coding simply because it doesn't really make…

Clearly my Emacs origins show here

I think so. The Emacs philosophy is essentially to treat the editor like a highly-customizable IDE. I use Vim only because I want a Vi that has a few quality-of-life tweaks here and there (the undo tree works fine for me without any plugins, I just use g- and g+). I don't use the vast majority of what was added. The core of what I want was created by Bill Joy back in the 70s.

I want a text editor that works the same whether I'm editing a C source code file or a text file that happens to have some C pasted into it or a configuration file or a file that looks superficially like C but happens to be a different language. I'm not interested in an IDE. I would prefer that most of those language-specific tools be separate programs that I can invoke by shelling out.

Performance issues in Vim are usually caused by various autocompletion engines, none of which I use. I like Vim's built-in completion which is very simple and predictable (fitting the theme), invoked using C-x in insert mode.

Re: Making Emacs Popular Again

#248

Post by Koshkin »

serf wrote: post #200
downerending wrote: post #137

Earlier quoted context omitted.

Re copyright, what would you prefer? Alternatively, what would you even do with the copyright to your fixes and additions to GNU emacs?

a lot of contributors/developers are bothered by the fact that they have to play ball with copyright laws, at all. it's a fact of life for developers with projects anywhere near the GNU-scape that if you don't GNU it, you'll catch a lot of hatred, even worse if you choose to avoid licensing all together -- and gods help you if you choose a tongue-in-cheek licensing agreement like WTFPL. at the end of the day a lot of…

> love and admiration

I don't know about that, I hate agendas. A hammer does not have one, and that does not make it a less useful tool.

Re: Making Emacs Popular Again

#249

Post by kgwgk »

kick wrote: post #221
pvg wrote: post #205

Earlier quoted context omitted.

Vi has text input modality, unlike essentially, well, anything. It's an entirely different model of operation which it shares with no current software and hasn't for a quarter century. It's strange to be talking about the UI details of vi/emacs (both, by current standards, about equally super-weird) when the article itself is a kind of perfect vignette of the organizational dysfunction of the group that maintains ema…

'press i and then basically everything works as you'd expect' is pretty simple; it's got a significantly-smaller barrier to entry than Emacs, and breaks fewer core-assumptions. Is that agreeable to you? The thread on the mailing list was basically guesses as to why Emacs has lost popularity & methods of regaining it, and the lwn article is primarily focused on just relaying it. The thread itself doesn't point to all…

> 'press i and then basically everything works as you'd expect' is pretty simple

If that means that you can press letters in they keyboard and see them appear in the screen that’s also true in Emacs... and you don’t even have to press ‘i’ for things to start working as expected.

Re: Making Emacs Popular Again

#250

Post by tgbugs »

brainsmith wrote: post #244

When I started programming on ruby my laptop couldn’t handle IntelliSense and tests which required too much cpu and ram. So I’ve switched to vim on server through ssh. Later I’ve switched to emacs as it seemed to me more powerful than him back then. After I got MacBook I’ve switched to TextMate utilizing powerful macOS keyboard shortcuts for text navigation. MacBook was pretty fast to handle ruby-related tasks. Later…

I think what you're looking for is TRAMP [0,1]. After resisting it and continuing to ssh into remote hosts in a shell, I finally started to switch my workflows over, and the improvement is substantial. Async remote compiling might work out of the box in some cases, or it might require some additional configuration.

0. https://www.gnu.org/software/tramp/ 1. https://www.emacswiki.org/emacs/TrampMode

Post reply on HN