There are WebKit integrations in Emacs available [0]. The beauty of emacs is that it's actually programming language kernel that has a text editor built in. You can extend Emacs far beyond text.
Emacs has built-in scripting language. . . . All of the editor’s functionality is exposed via APIs written in the scripting language.
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?
I use emacs several hours each day and have written quite a few customizations myself in elisp. Enough that I think I have a handle on the question.
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.
>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.
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.
Actually, you can use DevTools to inspect DevTools. Hit option-command-J to bring up devtools, make sure it's in "window mode," i.e., in a separate window from the browser itself, and then hit option-command-J again to DevTools that DevTools.
You can actually just keep recursing and inspect the previous inspector ad nauseam...
>depends on what is meant by a plug-in architecture.
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.
Interestingly, once you enable the developer tools, Komodo is very similar to what you're describing. Pretty much everything is exposed as an API to the JavaScript environment, you can change stuff on the fly and the like. It also has a Python API for certain features. I think that's a consequence of being based on XUL, a web browser is similar to emacs in terms of runtime extensibility, though not 100% of the way there.
That's a flawed comparison. Firefox takes the Emacs approach. All of Firefox is built of XUL, Javascript, and the gang.
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.
Yes, it is. But I think Staltek may be right in that Firefox essentially takes the same approach as emacs and lets extensions access the main application runtime directly (Although with some security constraints).
I tried to extend Komodo IDE back when I used it heavily. I had no knowledge of Firefox internals then.
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.
I mean "embedded" as in a "scripting environment hosted by a bigger app" (nothing to do with embedded systems in hardware sense, obviously). I thought the term is widely used for this, for example there's a guide to "embedding python"[1] and they use the same term in Lua[2].
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.
Emacs should be compared to Eclipse, which seems flexible enough that it is frequently used when big company X writes an new IDE targetting a new platform or language.
My take would be that because Emacs lets you modify it deeply, you can do much more and also make a big mess.
Complex and bloated, eh. Thank God emacs has managed to avoid that fate...
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 is not complex and bloated by the standards of recent decades. To address the "complex" point, yes, there are a lot of lines of source code in the Emacs tarball -- not nearly as many as in Firefox's source-code tarball or Chrome/Chromium's, but certainly at least an order of magnitude more than, e.g., Bash's tarball -- but the vast majority of those lines of code will never run on your machine unless you make a conscious decision to do so. E.g., the tarball contains at least 9000 lines of Emacs Lisp specific to the Ada programming language (code that indents code written in Ada, code that applies Ada-specific syntax coloring / highlighting, etc), but unless you explicitly load the files containing the 9000 lines or you open a file with the extension ".ada", those 9000 lines will (unless I'm really missing something) never run.
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.
Having picked up Emacs recently, it feels sort of the opposite of bloated, though there is definitely complexity. I think its reputation for being large dates to a different era of minimalist Unix tools, when Emacs using MEGABYTES of memory ("eight megs and constantly swapping") looked big compared to vi. But if you're comparing emacs to Eclipse, it's a resource-stingy speed demon.
Really seems that you can take emacs back to the core by just looking at the origin of the name. Editor MACroS. Says it all right there, it isn't just a text editor.
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.
Emacs can display and edit vector graphics. I wrote a dedicated vector image editor a while back ("Minara") in which the application, tools, and images were all just Scheme code (using Guile).
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.
Oh, certainly. And you'll never get a lack of my preaching the gospel that is org-mode. The inline latex/ditaa/graphviz/whatever manipulation is truly first rate and borderline mind blowing.
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?
Check out Light Table. It has a really interesting architecture specifically designed to support that kind of interactive scriptability / extensibility, and the fact that it's written in a decent Lisp (Clojure) is the icing on the cake. It's a joy to work with, because even when the internal code has problems you can just patch it on the fly.
Emacs is my preferred text editor. I don’t use old-fashioned text editors as much as I used to, because I often need more specialized tools. I use IDEs for various programming languages and other things when producing high quality documents. And yet, I often wish I could subsume these with a tool that had the basic goodness of emacs.
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.
Me thinks you haven't used emacs as much as "other text editors." There are very few features that people "wish" emacs had, that it doesn't actually have.
Specifically, language recognition is not just regexes in emacs.
Perhaps this is not the right forum but does anyone know of a good emacs mode for jump-to-definition in Python? I've used ctags and jedi but haven't been able to configure anything as awesome as the Python plugin for IntelliJ (same as PyCharm). To implement it, it would require a combination of static analysis and on-the-fly interpretation, given Python's duck typing. If emacs had this, I would use emacs all the time.
I use jedi.el along with virtualenv-wrapper which does jump to definition perfectly fine ime. But keep an eye for open sourcegraph's mode[0], they are going incorporate python soon AFAIU.
One of the authors of srclib here. Python has been incorporated (and should be installed if you update srclib and run the toolchain install script). The website hasn't been updated to reflect this, however. Let us know if you run into any issues!
That looks like it should be ridiculously easy to do. Feels like it would be annoying pretty quickly, though. (I typically have my computer completely muted...)
> Specifically, language recognition is not just regexes in emacs.
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.
Yes, tit the default mode is through regexs, and most of the modes use it.
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.
Apologies for not responding earlier. As indicated in a sibling post; yes, I believe most language recognition is done with the old style. Mainly because it is fast and works for the majority of use cases, though, and not because it is required to be that way.
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.
The problem with emacs is that while emacs is indeed long lived, plugins often have a short life-span. I've tried on a couple of occasions to find a good C++11 compatible plug-in but failed. I found one which used libclang, but didn't work with the latest version of clang.
[0] http://www.emacswiki.org/emacs/WebKit