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

161–170 of 272 posts

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

#161

Post by spudlyo »

freetonik wrote: post #36

I hope you excuse me for a shameless plug, but it seems like a relevant enough thread to share my podcast about Emacs: https://emacscast.org/ While it might seem strange to discuss a text editor in the audio format, I've been getting positive feedback on this project as I try to talk more about underlying philosophy and mindset, not specific details or settings.

My feedback for you is you need to give listeners a reason to keep listening to your podcast right away, you simply can not go on a meandering personal discussion about yourself for the first 10 minutes of a podcast and expect to retain my attention.

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

#162

Post by selfishgene »

Could TeXmacs solve some of the problems mentioned in the slides?

http://www.texmacs.org

TeXmacs is based on Guile and there is apparently already a Guile-based implementation of Emacs that is near feature complete.

Perhaps a Guile-based Emacs could somehow be embedded as an elisp-compatible interpreter "back-end" inside TeXmacs, much like how Mathematica is separated into a kernel (for computation) and a front-end (for input and rendering) that communicate with each other over a protocol called MathLink.

There is also DomTerm from Per Bothner, who perhaps coincidentally has also worked hard to produce his own Scheme-based version of Emacs (by way of the JVM).

https://domterm.org

One of the downsides of TeXmacs is the significant keystroke input latency caused by the extensive amount of page redrawing that is often required when editing "rich text." It's one of the main reasons that many still prefer latex-preview mode inside Emacs instead. Maybe latency would be less of an issue inside a graphics-aware terminal emulator like DomTerm.

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

#163

Post by microcolonel »

klik99 wrote: post #68
mickeyp wrote: post #48

Emacs turns disjoint environments, languages, and activities into a (mostly) streamlined system of workflows and idioms. Explaining just how powerful that is to people who don't use Emacs is difficult. People need to sit with you for an hour or so and watch you work to truly appreciate just what that means.

There's a certain class of programmers tool that requires constant tweaking, like a road bike used in the city - and typically the users suffer from OCD or stockholm syndrome, because they won't stop evangelizing. I thought emacs was one of THOSE types of tools and the initial experience does nothing to disabuse that. On my 4th or 5th attempt to start using emacs I finally decided to get over the hump even if it took…

The more I use Clojure at work, the more I tolerate the elisp side of things. I've written a couple little major modes (though not to any great standard of quality) and elisp is indeed pretty crap, but usually adequate. I think the ideal Emacs lisp successor would be a Clojure derivative, with the buffer represented as a persistent trie datastructure like other things are in Clojure. Maybe the buffers could be disjointed from the presentation a bit, and we could have strictly AST-driven major modes, rather than the (admittedly quite usable) hack that is paredit.

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

#164

Post by pmoriarty »

jwr wrote: post #5

There are lines in my Emacs config files that are older than some of the programmers I work with, so I can relate. Contrary to what some people think, Emacs does not require constant tweaking and wasting time on configuration. I revisit my setup every couple of years or so, and I always find it is time well spent, as my productivity goes up as a result. I do not know of a better environment for multi-language program…

"Contrary to what some people think, Emacs does not require constant tweaking and wasting time on configuration."

This is true, to an extent. I have not touched my current Emacs configuration in about 6 months now, but it took years of tweaking and probably hundreds of hours to get it to a state where Emacs was mostly the way I wanted it... though it'll never really be complete, as there are still a lot of things I'd like it to do that it doesn't yet but could, and there are always new things I could do that would be interesting or new, more efficient ways to do what I'm already doing.

So, overall, it has the potential to be a great time suck, and certainly was for me when I first started.

How much time it'll take for you really depends on your needs, and how much you're willing to live with the defaults that Emacs and its various modes and packages provide, and how much tweaking and customization you want to do. I needed and wanted quite a lot myself.

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

#165

Post by spudlyo »

na85 wrote: post #85
rvz wrote: post #54

> Emacs support is on by default in MacOS. Given that the author is siding with the usability of macOS with something like Emacs over using it in a GNU/Linux distro is somewhat a surprising discovery and perhaps an insight into the falsehood of having a 'consistent' Linux Desktop; even for power-users like the author. If one has to go through a maze of settings and config files to configure Emacs shortcuts to work 'c…

I use the railwaycat port of emacs, which is frankly what any macos-based emacs user should use. I provides smooth scrolling, an interface with applescript, touch bar support, and lets you use os-native hotkeys including Command-as-Meta.

I agree that the Mitsuharu version of emacs is pretty great on the Mac, but the lack[0] of multi-tty[1] support is a deal breaker for me. I like emacs-plus[2], which while not quite as nice as the railwaycat/mitsuharu version, allows me to run text frames and GUI frames on the same server process.

[0]: https://bitbucket.org/mituharu/emacs-mac/pull-requests/2/add...

[1]: https://www.emacswiki.org/emacs/MultiTTYSupport

[2]: https://github.com/d12frosted/homebrew-emacs-plus

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

#166

Post by Myrmornis »

Oreb wrote: post #151
benreesman wrote: post #39

Earlier quoted context omitted.

I think the germane point about Emacs here is that some people like writing Lisp and some people hate it. If you hate it Emacs is likely not going to be your best environment, and that’s fine. I really like writing Lisp so Emacs has a simple way of doing anything I want, but it’s not for everyone.

I love writing Lisp and do it for a living, but I can’t even remember the last time I had to write a single line of elisp to use Emacs (unless you count things like adding or removing a layer in my .spacemacs file as writing Lisp).

Really? Emacs is the opposite for me, I've used it for 15 years and really only recommend it to those for whom writing a little bit of emacs lisp sounds like fun. You write lisp for a living, sounds like in Emacs, so I assume you use paredit-mode. Don't you have to do little things like ensure that paredit-mode is turned on in your mode hook for clojure or common lisp or whatever?

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

#167

Post by Myrmornis »

innagadadavida wrote: post #116

Fabric Bellard’s ema s port (QEmacs): https://bellard.org/qemacs/ It’s amazing how fast it is. Unfortunately it is not fully compatible and missing many features.

It doesn't have an emacs lisp interpreter right? It's funny, for me, emacs is emacs lisp. I sort of don't understand why one would emulate emacs without a lisp interpreter (given it's Bellard I'll probably find out I'm wrong and it does have a complete emacs lisp interpreter).

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

#168

Post by spudlyo »

alpaca128 wrote: post #76
eruci wrote: post #42

I've never seen the need to use anything other than vim.

Same here. I've tried getting into Emacs for a couple days but gave up. It would mean a lot of effort just to achieve a similar proficiency, for little gain(better syntax highlighting, a few small features). I think the deeper you're already in one of the ecosystems the harder it becomes to switch and the returns diminish further. In my case I'm very comfortable with Vim combined with a tiling window manager and term…

Emacs has recently been seeing a lot of growth from vim users who are migrating to emacs "distros" (like spacemacs and doom) that are pre-configured with emacs' vim-emulation.

I found this video[0] a pretty interesting perspective from a die-hard vim user who switched.

[0]: https://www.youtube.com/watch?v=JWD1Fpdd4Pc

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

#169

Post by Koshkin »

spudlyo wrote: post #161
freetonik wrote: post #36

I hope you excuse me for a shameless plug, but it seems like a relevant enough thread to share my podcast about Emacs: https://emacscast.org/ While it might seem strange to discuss a text editor in the audio format, I've been getting positive feedback on this project as I try to talk more about underlying philosophy and mindset, not specific details or settings.

My feedback for you is you need to give listeners a reason to keep listening to your podcast right away, you simply can not go on a meandering personal discussion about yourself for the first 10 minutes of a podcast and expect to retain my attention.

Well, that wouldn't be much different from the pervasive habit of many authors of YouTube videos to stick their own faces in the frame in one or the other ridiculous fashion. This is unsurprising, because it is self-advertisement that is the true goal of such podcasts and videos.

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

#170

Post by Myrmornis »

microcolonel wrote: post #163
klik99 wrote: post #68

Earlier quoted context omitted.

There's a certain class of programmers tool that requires constant tweaking, like a road bike used in the city - and typically the users suffer from OCD or stockholm syndrome, because they won't stop evangelizing. I thought emacs was one of THOSE types of tools and the initial experience does nothing to disabuse that. On my 4th or 5th attempt to start using emacs I finally decided to get over the hump even if it took…

The more I use Clojure at work, the more I tolerate the elisp side of things. I've written a couple little major modes (though not to any great standard of quality) and elisp is indeed pretty crap, but usually adequate. I think the ideal Emacs lisp successor would be a Clojure derivative, with the buffer represented as a persistent trie datastructure like other things are in Clojure. Maybe the buffers could be disjoi…

> Maybe the buffers could be disjointed from the presentation a bit, and we could have strictly AST-driven major modes

Yes, good point, agree that would be a very positive direction.

> elisp is indeed pretty crap

Ah, I've been enjoying it a lot recently :) But I don't have an excuse to write clojure and I certainly recognize that that's a much more sophisticated thing.

What are your biggest criticisms of elisp? Mine is basically that the naming of functions in the standard library is terrible.

Also: I'm still a bit confused about whether I should be using lexical binding (probably my fault for not thinking about it hard enough); the situation with threading is a little obscure; on the face of it threads in now exist in the elisp API, but are they not fully featured in some aspect?

Post reply on HN