Live data from Hacker News

Emacs Lisp's Future

lists.gnu.org

51–60 of 160 posts

Re: Emacs Lisp's Future

#51

Earlier quoted context omitted.

Literally dozens more. Look, neither Common Lisp nor any Scheme implementation are exactly topping the charts in popularity these days. This should be about the technical merits of the choice, because I'm pretty sure Emacs Lisp both has more code and more programmers (both represented in the forms of small scripts we've shoved into scratch and evaluated) than both.

The decision to go either Common Lisp or Scheme was made based on RMS very personal reasons and conflicts with close-source Lisp machine companies during the first half of the 80s. GNU has had two common Lisp implementations under their umbrella at least since mid 90s (CLISP (of Viaweb fame) and GCL (of Maxima fame)), but due to RMS' hate of Symbolics and Common Lisp, all of the effort was invested into making Guile…

Can you explain more what FFI support would give? I understand that Emacs is a C+Lisp system. Is it about calling other languages from Elisp easier? Or possible at all?

Re: Emacs Lisp's Future

#52
post #48

Dream: "Common Lisp/Guile, and a Chromium based rendering engine".

Maybe I'm in the minority, but I for one really appreciate how Emacs can run in a terminal, over SSH, with almost no feature-degradation at all.

Besides Emacs being a very nice programming (and programmable editor), this is one the key features which keeps me from even considering other more "modern" options.

Re: Emacs Lisp's Future

#53

If emacs supported new languages other than elisp, a lot of new blood will join the community. Once we get the new hackers, they will try and find ways to modify the old codebase. Emacs is a wonderful editor, but to a newcomer it can be a lot daunting. For example, I have completed the emacs tutorial, I've even read the infos info tutorial and several info pages regarding emacs and still don't know much about ELisp.…

You don't need to read the manual, or even any tutorials, IMO, as long as you know that function application in Lisp looks like (f arg1 ...), know how to program, know that Lisp has macros, almost everything else follows.

It took me a few hours to learn enough Elisp to customize .emacs, add custom macros, and start using defadvice to wrap existing commands with extra behaviour, like preserving the selection for text replacement in a selected block. I even went as far as writing a macro that could use defadvice to generically preserve the selection for any other command on the second day of using emacs.

A bigger hurdle was learning the Lisp jargon, so that I could find the correct function to call when searching for it, whether in emacs itself, or online. But once I knew about the point, that the selection is called the region and is the text between mark and point, that files are called buffers, that open is called find, etc., it was pretty smooth sailing.

It's fairly trivial to find the source for an arbitrary elisp function - just C-h f , and follow the source link. Plugins like helm (dynamically filtered list searches) make it very easy to find relevant functions too.

Elisp has a couple of features that make it work well as an application extension language: dynamic variable scope and function advice are two that are fairly unique to Lisp (technically, Javascript has dynamic scope via the eval function, but it's not usually a good idea to use it). These things make it easy to tweak behaviour from the outside.

However, contra other people's opinions, Elisp is not fast. It is slow, very very slow, compared to efficient languages. My startup time is just about tolerable on a modern machine, but not tolerable enough to stop me starting emacs --daemon every time I reboot. Scrolling through large files with line numbers enabled is slow, and the UI has a few milliseconds of lag for almost every non-trivial action. Dynamic searches need very noticeable debounce delays for list refreshes or otherwise things get unresponsive.

Re: Emacs Lisp's Future

#54
post #50

Earlier quoted context omitted.

If I was them, I'd gradually introduce the minimum set of breaking changes to ELisp that converge it on Common Lisp. Even if those changes were unhelpful or removed features. Then eventually, when it maps 1:1 onto a subset of CL, just swap the implementation for a supported CL.

Some years ago the a clisp maintainer actually made a minimal demo of Emacs hosted on clisp with just a compatibility layer for Elisp via macros/functions, which seemed to work pretty well. But it didn't progress any further because Stallman vetoed basing Emacs on Common Lisp (he considers CL to be too big a language, and to some extent just doesn't like it). In retrospect I'm not sure this was a good call: Guile as…

Too often it seems RMS is why GNU can't have nice things.

Re: Emacs Lisp's Future

#55
post #48

Dream: "Common Lisp/Guile, and a Chromium based rendering engine".

Maybe I'm in the minority, but I for one really appreciate how Emacs can run in a terminal, over SSH, with almost no feature-degradation at all. Besides Emacs being a very nice programming (and programmable editor), this is one the key features which keeps me from even considering other more "modern" options.

You may be in the minority in terms of the total number of users, but most of the Emacs developers will have the same mindset. Terminal-friendliness is a part of Emacs tradition. The developers would surely keep the ability to run Emacs in a terminal.

Re: Emacs Lisp's Future

#56
post #48

Dream: "Common Lisp/Guile, and a Chromium based rendering engine".

Maybe I'm in the minority, but I for one really appreciate how Emacs can run in a terminal, over SSH, with almost no feature-degradation at all. Besides Emacs being a very nice programming (and programmable editor), this is one the key features which keeps me from even considering other more "modern" options.

Yep, I agree. Modernization efforts (a modern emacs) should be attempted on products under a new name.

Re: Emacs Lisp's Future

#57
post #48

Dream: "Common Lisp/Guile, and a Chromium based rendering engine".

Maybe I'm in the minority, but I for one really appreciate how Emacs can run in a terminal, over SSH, with almost no feature-degradation at all. Besides Emacs being a very nice programming (and programmable editor), this is one the key features which keeps me from even considering other more "modern" options.

With adequate separation of concerns the backend could either be V as full Dom or as a terminal friendly minimal DOM (no css fonts attributes, pixel positioning, box shading etc).

Re: Emacs Lisp's Future

#58

Earlier quoted context omitted.

The decision to go either Common Lisp or Scheme was made based on RMS very personal reasons and conflicts with close-source Lisp machine companies during the first half of the 80s. GNU has had two common Lisp implementations under their umbrella at least since mid 90s (CLISP (of Viaweb fame) and GCL (of Maxima fame)), but due to RMS' hate of Symbolics and Common Lisp, all of the effort was invested into making Guile…

I've been programming with ELisp, CL and Scheme for a long time. Somehow Guile feels like an odd choice. Why not Chicken scheme, or Racket, or Bigloo; which are the top scheme environments you can choose from? AFAIK, Guile is not used much beyond a few random projects. Maybe I just don't know Guile, really. Maybe it has a decent implementation afterall. However, I would have gone CL. There are several "emacs-like" ed…

[deleted]

Re: Emacs Lisp's Future

#59
post #50

Earlier quoted context omitted.

Some years ago the a clisp maintainer actually made a minimal demo of Emacs hosted on clisp with just a compatibility layer for Elisp via macros/functions, which seemed to work pretty well. But it didn't progress any further because Stallman vetoed basing Emacs on Common Lisp (he considers CL to be too big a language, and to some extent just doesn't like it). In retrospect I'm not sure this was a good call: Guile as…

Too often it seems RMS is why GNU can't have nice things.

RMS would never let practicality get in the way of ideology.

The GNU/RMS is best because you're free! (As long as your computing needs are a text editor, compiler, and some unix system utils)

Re: Emacs Lisp's Future

#60
post #50

Earlier quoted context omitted.

Some years ago the a clisp maintainer actually made a minimal demo of Emacs hosted on clisp with just a compatibility layer for Elisp via macros/functions, which seemed to work pretty well. But it didn't progress any further because Stallman vetoed basing Emacs on Common Lisp (he considers CL to be too big a language, and to some extent just doesn't like it). In retrospect I'm not sure this was a good call: Guile as…

Too often it seems RMS is why GNU can't have nice things.

If he made the opposite call, and adopted CLisp, you'd be complaining about him anyway, in a thread about some unexpected compatibility problem or whatever.

It gets tiresome even to watch.

Post reply on HN