Live data from Hacker News

Frontmacs

github.com

71–80 of 100 posts

Re: Frontmacs

#71
post #55

Earlier quoted context omitted.

I've been using emacs for over a decade now and I have yet to reach this state of nirvana. I do want to understand every line of elisp and I've been doing a lot of elisp recently. But then again, I also have work to do, and I realize all I've been trying to achieve with my emacs config in the past 10 years is to make it work like a modern IDE. Which is perfect, because the reason I switched to Emacs in the first plac…

Been there, done that, switched to JetBrains IDEs, and haven't looked back. My gut feeling is that people who haven't looked up from emacs or vi for a decade or two have no idea what modern IDEs are capable of out of the box.

> My gut feeling is that people who haven't looked up from emacs or vi for a decade or two have no idea what modern IDEs are capable of out of the box.

I use visual studio in my day-to-day job for .net and C# work. I know what it’s capable and it’s a very impressive piece of technology.

What it doesn’t do is allow me to shape it to fit my workflow. I always have to adapt to fit the tool as opposed to the other way around, and any level of customization and extensibility feels extremely shallow compared to Emacs.

With Emacs I get everything my way. And I don’t think that can be said about any other tool I know of.

Needless to say I use both editors side by side and use whatever tool is best for the job at the time.

Edit: IMO standardized technologies like LSP is now bridging the gap for many (but obviously not all) IDE features. I suspect the imminent death of the “plain editor” is vastly exxagerated :)

Re: Frontmacs

#72
post #55

Earlier quoted context omitted.

I've been using emacs for over a decade now and I have yet to reach this state of nirvana. I do want to understand every line of elisp and I've been doing a lot of elisp recently. But then again, I also have work to do, and I realize all I've been trying to achieve with my emacs config in the past 10 years is to make it work like a modern IDE. Which is perfect, because the reason I switched to Emacs in the first plac…

Been there, done that, switched to JetBrains IDEs, and haven't looked back. My gut feeling is that people who haven't looked up from emacs or vi for a decade or two have no idea what modern IDEs are capable of out of the box.

Well, I think I should make it clear that I'm very well aware of what modern IDEs can do, and I think most Emacsens do too. In fact, their killer features haven't really changed much since the late 90s / early 00s.

What I never liked in IDEs is their features come with a huge cost. Their integrated features are great, but their implementations are so complex and opaque, when they inevitably go wrong, I can't just dive into a plugin and fix it myself. Emacs packages still goes wrong, but at least fixing them is a much easier affair. It is this reason, and that Emacs generally just come out with functioning packages for new concepts and ideas way faster than any other IDEs, I've vowed to avoid IDEs written in compiled languages like the plaque.

What I really mean is, I'd love to replicate IDE features on a text editor, but without the pain. Elisp is just a horribly outdated language and runtime environment to be honest. Everything is global, OOTB most of the modern FP constructs is non-existent in this FPL, dependency management is a mess, it's single threaded, it's a terminal app pretending to be a GUI etc, and oh god, don't even get me started with the default window management mechanism. I don't understand why so many people keep romantizing it.

Re: Frontmacs

#73

Earlier quoted context omitted.

Emacs is a programming language with it's own text editor built in. Like every other programming language on the planet, it benefits from dependency management and source code management. Getting all of our tools into similar management forms ultimately makes all of coding more accessible.

elisp ist the programming language. Emacs is an environment with text-oriented interface. Pretty much like modern browsers, just more mature. One could even say, Emacs is the spiritual ancestor of the electron-framework.

I disagree. I've tried to use Electron editors (VS Code, Atom) and the thing that frustrated me the most is that it is missing the "essence" of Emacs. To me, these things are:

* Self-documenting

* Easy to dynamically inspect and change the editor internals and all packages, from the editor itself

* Emphasis on the editor as an interface into your system (the editor as a way to process and "glue" together text from subprocesses)

Atom in particular seems promising, but from the time that I spent with it, I quickly concluded that it was missing the spirit of Emacs entirely, because it was not straightforward or well-documented how I would go about exploring and changing the internals of the editor and its packages. E.g. a package was throwing an exception...it was quite a process to find the source, set a breakpoint on that error, and fix/work around the bug. That's trivial stuff in Emacs, and IMO is at the spiritual core of Emacs.

I would love to be wrong here, so please correct me if I'm mistaken!

Re: Frontmacs

#74
post #68

Earlier quoted context omitted.

I can relate to this. The problem is I already know how to get my work done (efficiently) in Emacs and find any change of my everyday tools to be daunting. Any advices on how to experience "what modern IDEs are capable of out of the box" without major pain?

I've found one of the best ways to experiment with other text editors is to use them for one specific type of task or type of file. So when I started using vim I only used it edit config files. Makes it easier to lock into the mental mode of using a particular editor.

This is a very good piece of advice! I do have to configure my emacs every time I take on a new type of task albeit not very often. I'll give it try next time. Thanks!

Re: Frontmacs

#75
post #16

Earlier quoted context omitted.

I think what they mean is it's fully set up, so that if you've never used Emacs and you start using it, you won't encounter the situation where something stinks and your friend who's an experienced Emacs user says "oh, you need to customize such and such." So, "awesome by default" rather than "awesome after many hours of learning about and applying configuration changes." (I have no idea whether what they've done wou…

I think (and I say this with love) that any sane person who starts using emacs will find it infuriating- its part of the appeal.

So true. I recently started using it while learning common lisp and it is really fun and really frustrating

Re: Frontmacs

#76

Earlier quoted context omitted.

Been there, done that, switched to JetBrains IDEs, and haven't looked back. My gut feeling is that people who haven't looked up from emacs or vi for a decade or two have no idea what modern IDEs are capable of out of the box.

> My gut feeling is that people who haven't looked up from emacs or vi for a decade or two have no idea what modern IDEs are capable of out of the box. I use visual studio in my day-to-day job for .net and C# work. I know what it’s capable and it’s a very impressive piece of technology. What it doesn’t do is allow me to shape it to fit my workflow. I always have to adapt to fit the tool as opposed to the other way ar…

The problem is often you have to build "Your way" from the ground up. Some people just want "A way" that's working as soon as they open up the editor.

Re: Frontmacs

#77
post #73

Earlier quoted context omitted.

elisp ist the programming language. Emacs is an environment with text-oriented interface. Pretty much like modern browsers, just more mature. One could even say, Emacs is the spiritual ancestor of the electron-framework.

I disagree. I've tried to use Electron editors (VS Code, Atom) and the thing that frustrated me the most is that it is missing the "essence" of Emacs. To me, these things are: * Self-documenting * Easy to dynamically inspect and change the editor internals and all packages, from the editor itself * Emphasis on the editor as an interface into your system (the editor as a way to process and "glue" together text from su…

I assume that is a difference in cultur not ability. But lack of introspection and prototyping is a surprise. After all at the end it's just a browser, which have good tools for such things. Maybe it's just not mature enough for this at the moment.

Re: Frontmacs

#79
post #55

Earlier quoted context omitted.

I've been using emacs for over a decade now and I have yet to reach this state of nirvana. I do want to understand every line of elisp and I've been doing a lot of elisp recently. But then again, I also have work to do, and I realize all I've been trying to achieve with my emacs config in the past 10 years is to make it work like a modern IDE. Which is perfect, because the reason I switched to Emacs in the first plac…

Been there, done that, switched to JetBrains IDEs, and haven't looked back. My gut feeling is that people who haven't looked up from emacs or vi for a decade or two have no idea what modern IDEs are capable of out of the box.

My problem is I consider vim to be the best text editor ever created. That is, when it comes to manipulating text, there is no equal. But it's a lousy (even terrible) "IDE". Between editing text and other dev related tasks (searching, diffing, autocomplete, etc), text editing is slightly more important to me, so I use vim. Using another editor/IDE with a vim emulator doesn't cut it. I've never found one that matches real vim. Neovim could eventually allow me to have my cake and eat it too though.

Re: Frontmacs

#80

Earlier quoted context omitted.

> My gut feeling is that people who haven't looked up from emacs or vi for a decade or two have no idea what modern IDEs are capable of out of the box. I use visual studio in my day-to-day job for .net and C# work. I know what it’s capable and it’s a very impressive piece of technology. What it doesn’t do is allow me to shape it to fit my workflow. I always have to adapt to fit the tool as opposed to the other way ar…

The problem is often you have to build "Your way" from the ground up. Some people just want "A way" that's working as soon as they open up the editor.

Sure. But that applies to almost any problem I face on a daily basis as a programmer.

I don’t see why optimizing my flow and tools should be less important than optimizing what I deliver. The former practically enables the latter.

This mindset is pretty much what has given us the high quality FOSS projects we use everywhere. I wouldn't really call this is a “problem”.

Post reply on HN