Taking it to Th’emacs
gbracha.blogspot.com
gbracha.blogspot.com
Edit: ah, it looks like it's been done for Scheme: http://www.emacswiki.org/emacs/GuileEmacs
As a consequence, you can control everything emacs does programmatically. This makes emacs extensible in a way that is far deeper and more powerful than a plug-in architecture. A plug-in architecture must anticipate every desired extension to the system. Since it never can, it always disappoints in the end. Along the way it grows ever more complex and bloated in its futile attempt to foresee every possible need. With a language, you can code any extension you need.
Does anyone who has tried to modify both Emacs and an editor (or IDE) with a plug-in architecture agree or disagree with that?
As far as extensibility goes, the openness is the most important part, I think. No need for a scripting language necessarily - though it makes many things more convenient.
Emacs does have a steep learning curve.
E.g., what Emacs calls a frame, everyone else calls a window; what Emacs calls a window, everyone on Windows, Mac, etc, calls a pane (and the decorations around Emacs's panes, er, windows, look nothing like those around most of the panes on the OS on which the Emacs is running.)
E.g., Control-U in Emacs does not mean what it means in most Unix programs (delete to start of the line).
There's a lot of those kinds of differences, and it is understandable that a lot of people don't want to learn those differences.
But please don't just say "complex" (or "bloated") when you mean that it has a steep learning curve or that it has its own set of conventions that differ from most modern software.
I can compare writing extensions to Firefox and extensions to Emacs and it's pretty much the same experience, if that helps?
I'll give examples.
I love how easy it is to change or customize Emacs. E.g., if I want to change what happens when I right click on some text, I can do so (and have done so) by writing some Emacs Lisp code (and only 27 lines of Emacs Lisp code at that) -- leaving the parts of Emacs written in C completely untouched.
In other words, in Emacs (and IIUC Light Table), with very few exceptions, all of the editor’s functionality is exposed via "APIs" (and in Emacs, it would be accurate to replace "APIs" with "variables and functions" since Emacs does not have classes and such) written in a high-level scripting language (Emacs Lisp or ClojureScript).
The same cannot be said of Textmate, Sublime Text or Lime Text. What one can say of those three, though, is that they all have a plug-in architecture.
So, my question, again, is whether the OP is correct in his assertion that -- at least for people who are in the habit of frequently changing many different aspects of their editor -- having a plug-in architecture is no substitute for having virtually all of the editor's functionality exposed via "APIs" written in a high-level language.
Yes, that helps.
When I go to the Add-on Manager and select the tab labelled "Extensions", I see a list of things like Adblock Plus.
Are those things what you meant when you wrote "extensions to Firefox".
If not, then, well, an example would be great.
Lots of apps expose a C plugin API, many apps expose some scripting. I don't think the population of apps exposing a comprehensive scripting API that mirrors the internal C structure is that large. Chrome might be better.You can't do whatever you want with Chrome, it has to be published to the scripting interface first. Early versions of Chrome had trouble supporting a lot of common Firefox extensions for this reason.
The Emacs APIs for window management, buffers, and other various "chrome" so to speak are pretty good and easy enough to grasp, once you get over the Lisp hump. But the Emacs APIs for managing text in buffers is difficult to wrap one's brain around, because it takes a very different approach to text management than most Unix tools. Basically, you write out the editor commands necessary to do the manipulation you desire. That sounds straightforward enough, but it takes some getting used to.
What Emacs really excels at, though, and what makes it stand out from other customizable editors is the fact that you can literally change the beast from the inside. Since Emacs is basically a Lisp environment, with some large portion of the code written in Lisp, it's very easy to pop functionality in and out to test it out, or to make changes on the fly. In a Lisp buffer, you can just hit Ctrl-J to evaluate the expression immediately preceding the cursor and print the result into the buffer (or use Ctrl-X Ctrl-E to run it without printing the result). Or hit Meta-: from anywhere to run some Lisp interactively from the minibuffer, affecting your environment in real time. This ability to toy around with the running editor itself is a feature unmatched by pretty much any plugin editor. The built-in devtools with Javascript console in Chrome are a close analog in a web browser, but that is limited to the document you are viewing, and you can't control the entire browser experience from that console. With Emacs, you can.
So yes, I'd love to see Emacs add modes that move beyond text editing and allow rich buffers and embeddable videos, audio, and widgets of all sorts. There exists a very rudimentary capability for this sort of thing in Emacs now, but it is extremely limited.
You cannot use those devtools to customize the devtools themselves; can you?
I'm asking to make sure I understand -- I'm not trying to be argumentative.
You can actually just keep recursing and inspect the previous inspector ad nauseam...
My take would be that because Emacs lets you modify it deeply, you can do much more and also make a big mess.
The biggest problem I had with this was the lack of documentation and a sane development environment. Working in an embedded environment makes debugging (and exploratory programming) much harder: you can't just `print` your way through APIs and things. You can't use `pdb`, much less graphical debuggers. This makes developing such extensions painful: you need to learn a whole lot of APIs at once and memorize them before writing even one line of code.
Emacs is better on both accounts. The "self-documenting" part means that there are rich docstrings for every single function you'd want to invoke and that you have many supporting tools for discovering APIs (like apropos). There's a Messages buffer which functions as a stdout, where you can dump whatever you need to see at any point. You can also immediately see the source of any function, even if it's implemented in C. And you have a graphical debugger for Elisp if you need it.
Emacs is a really nice development platform for Elisp and accidentally for other languages. Things like Komodo are great for normal development, but much harder to develop for. That's my impression, anyway.
For me, such an environment is defined - in practical terms - by the lack of some features you expect from "general" programming environment. No stdout/stdin, no fork, no exec, no file and file system access, no threads, no sockets - and if you get some of this it's via an embedding app, not standard means. It's hard to work in such an environment because it's very rare for app developers to provide you with all the standard tools you have when developing standalone program. One of the most painful experiences I had with such env was with Google Refine - now Open Refine - which allowed scripting in Python (via Jython) and Clojure, but only really supported executing single statements in a tiny textbox, without any real error reporting and without access to anything external (like to files). It was a nightmare, and it's generally how this looks like: MS Office, Web browsers, Emacs are the exceptions here, definitely not the norm.
Indeed, the text editor portion is almost incidental. Emacs is a set of programs that all operate with the text editor as the common environment.
This works remarkably well with things that communicate through text. Which is, not unsurprisingly, a lot. Doesn't work as well for purely visual things. Especially not those that are lacking a text representation.
I'm now wondering about representing and manipulating bitmap images in a similar way to Emacs' vector handling. I think it could be fun and I don't see any practical impediments. Just represent the image as a PPM-style text while it's in Emacs then write it out as binary afterwards.
The problem, I think, is when people refuse to think of the textual representation as a reflection of the graphical one. Worse, we constantly dream of many textual representations of the same visual thing. Consider the constant wishing there was an AST based code editor, and then all of us that point out how paredit is that editor.
More to the point, the more complicated your AST or other language, the more difficult it can be to have meaningful semantics that are intuitive. What does it mean to type into a graphics image? Go down? Etc?
I love the ease of customization of Emacs and other text editors, but they're just plain dumb when it comes to knowing programming languages.
Specifically, language recognition is not just regexes in emacs.
I'd make it myself, but between work, thesis and procrastinating on HN, I'm not going to do this anytime soon.
I know there's Semantic [1], but do the typical major modes actually use it? The first line of Semantic's manual says: Ordinarily, Emacs uses regular expressions (and syntax tables) to analyze source code for purposes such as syntax highlighting.
[1] http://www.gnu.org/software/emacs/manual/html_mono/semantic....
But I think the OP's point was you are not limited by it, besides semantic (which I haven't never bothered to setup, there is js2-mode[0] as examples of modes that don't use regexps to operate on the language. There is even js2-refactor[1] built on top of it. You can read about js2-mode origin story here[2], and you would see that lack of threads in elisp hindered its development.
[0]: https://github.com/mooz/js2-mode [1]: https://github.com/magnars/js2-refactor.el [2]: http://steve-yegge.blogspot.com/2008/03/js2-mode-new-javascr...
I understand, on principle, why this is not ideal. In practice, I have trouble disagreeing with it. I do find autocomplete nice; though, I have also found that in the instances where I'm having to rely on autocomplete, I'd have been better off using the documentation of whatever I'm doing for a bit to actually have solid grounding before embarking on code.
My point was exactly as the sibling said, that this is by no means all emacs can do.