Stack Exchange for Emacs(github.com)
github.com
Stack Exchange for Emacs
https://github.com/vermiculus/sx.el/
52 comments
That's certainly what the title implies, perhaps "Stack Overflow on Emacs" would have been a better title.
This is Yet Another Example of the amazing utility of being able to easily and stably extend one's environment. emacs is just a text editor, but this project is changing it into a Stack Exchange client. That's useful!
Emacs certainly is not just a text editor. Emacs is just a big REPL, a REPL with a powerful text editor instead of minimal command line interface. Right on the homepage: http://www.gnu.org/software/emacs/, it is written that:
"GNU Emacs is an extensible, customizable text editor—and more. At its core is an interpreter for Emacs Lisp, a dialect of the Lisp programming language with extensions to support text editing."
Text editing is a subset of Emacs and Emacs Lisp, not the other way around.
"GNU Emacs is an extensible, customizable text editor—and more. At its core is an interpreter for Emacs Lisp, a dialect of the Lisp programming language with extensions to support text editing."
Text editing is a subset of Emacs and Emacs Lisp, not the other way around.
> Emacs certainly is not just a text editor.
I know. But it was written as just a text editor—but an extensible one, and so it has grown to be a lot more. Which is really pretty awesome.
I know. But it was written as just a text editor—but an extensible one, and so it has grown to be a lot more. Which is really pretty awesome.
> But it was written as just a text editor
No it's not. It is really a big REPL optimized for text processing. You compare Emacs to the like of Python, not just some random editor. Unlike other editors that have an optional extension language, if you remove Emacs Lisp, effective you remove Emacs. Even file opening is written in Emacs Lisp.
No it's not. It is really a big REPL optimized for text processing. You compare Emacs to the like of Python, not just some random editor. Unlike other editors that have an optional extension language, if you remove Emacs Lisp, effective you remove Emacs. Even file opening is written in Emacs Lisp.
Dude, I get what you're saying, but you're like a guy who comments on a Facebook picture of a newborn with 'The reason you think he's cute is purely evolutionary.'
Yes, of course emacs is a big REPL optimised text processing. But it's optimised for text processing because…it started out as a text editor.
The whole point of what I wrote is that emacs started out as a simple text editor (yes, I'm aware that its origin was as text editing macros for TECO) and due to its extensibility it can and has become so much more.
Really, I think you got way too hung up on the word 'just.'
We both love emacs. We both love having a fully-extensible text editing environment.
Yes, of course emacs is a big REPL optimised text processing. But it's optimised for text processing because…it started out as a text editor.
The whole point of what I wrote is that emacs started out as a simple text editor (yes, I'm aware that its origin was as text editing macros for TECO) and due to its extensibility it can and has become so much more.
Really, I think you got way too hung up on the word 'just.'
We both love emacs. We both love having a fully-extensible text editing environment.
Fair enough :)
I just wanted to clarify in case someone read your comments and have a wrong impression that Emacs is a text editor like Vim. Nothing more, nothing less.
I just wanted to clarify in case someone read your comments and have a wrong impression that Emacs is a text editor like Vim. Nothing more, nothing less.
So you can ask question about emacs on emacs.stackexchange while using stackexchange for emacs in emacs.
I build something similar for Atom a few months ago[1] and while some people liked the idea a lot of comments were negative and turned around that fact that programming is not about copy/pasting and plagiarism. Now a similar project is built but for emacs and comments about the concept of having a client inside an editor is interesting and powerful.
[1] https://news.ycombinator.com/item?id=7931667
[1] https://news.ycombinator.com/item?id=7931667
Emacs makes complex things possible and simple things hard: http://www.tjradcliffe.com/?p=74
That post is the fifth most popular thing on my blog, all from search-hits looking for how to count words in Emacs.
That post is the fifth most popular thing on my blog, all from search-hits looking for how to count words in Emacs.
What's your definition of simple, in this case? A million different users want a million different simple things. An editor that gives all of these functions equal weight is not an editor anyone would want to use.
if you're only using StackOverflow, I created a small mode called sos-mode: https://github.com/omouse/emacs-sos
The difference is that sos-mode is made for getting answers quickly and being able to copy/paste any code snippets. The output buffer of answers uses org-mode so it's easy to tag the list.
A full-blown stackexchange mode may be good if you're answering questions or looking for a lot of answers but I don't see that happening a lot. Most users are anonymous (sos-mode doesn't require login) and just want to get some answer.
The difference is that sos-mode is made for getting answers quickly and being able to copy/paste any code snippets. The output buffer of answers uses org-mode so it's easy to tag the list.
A full-blown stackexchange mode may be good if you're answering questions or looking for a lot of answers but I don't see that happening a lot. Most users are anonymous (sos-mode doesn't require login) and just want to get some answer.
This is a killer idea! Looking forward to seeing where it goes... will be as helpful, if not more, than ERC has been for me while searching for answers.
I never fully "got" emacs even though it was the popular editor during university times and I occasionally use it for quick server admin stuff.
Today I feel it has missed its boat with good looking and user friendly stuff available like Sublime Text, Atom, Eclipse and even cloud IDEs.
I cant help but to laugh quietly to addons like this.
Today I feel it has missed its boat with good looking and user friendly stuff available like Sublime Text, Atom, Eclipse and even cloud IDEs.
I cant help but to laugh quietly to addons like this.
There's nothing to "get" really. If you feel that Sublime Text, Atom, Eclipse, etc. are sufficient for your workflow, and wholly capture your needs, then you don't need emacs (or any other editor for that matter).
It just happens that there are people out there, like me, that want more out of their software and really enjoy tweaking and improving our editor. For us, there's emacs :).
It just happens that there are people out there, like me, that want more out of their software and really enjoy tweaking and improving our editor. For us, there's emacs :).
Can Sublime Text/Atom do all of this here: https://news.ycombinator.com/item?id=8639804 ?
I want to jump to any file at any time regardless of where I am in the project instantly, can Sublime do it? And even if a project has 30-40k files, it must be fast and make me jump instantly. See the demos in this guide for details: http://tuhdo.github.io/helm-projectile.html
Atom has a limit of 2MB text file which is worse than Vim in the 90s.
I want to jump to any file at any time regardless of where I am in the project instantly, can Sublime do it? And even if a project has 30-40k files, it must be fast and make me jump instantly. See the demos in this guide for details: http://tuhdo.github.io/helm-projectile.html
Atom has a limit of 2MB text file which is worse than Vim in the 90s.
Those videos on the Idris mode are also very impressive:
https://www.youtube.com/channel/UCsON_8vogp4nCQFTnfu43kA
(Other languages also have nice modes for context-aware completion (and more), like Haskell's ghc-mod and Rust's racer, which is incomplete but is already very nice)
https://www.youtube.com/channel/UCsON_8vogp4nCQFTnfu43kA
(Other languages also have nice modes for context-aware completion (and more), like Haskell's ghc-mod and Rust's racer, which is incomplete but is already very nice)
Or take a look at the videos at Emacs Rocks.[1]
[1] - http://emacsrocks.com/
[1] - http://emacsrocks.com/
> I want to jump to any file at any time regardless of where I am in the project instantly, can Sublime do it? And even if a project has 30-40k files, it must be fast and make me jump instantly
Yes, Sublime handles that smoothly. Do a linux tree clone, enter the directory, run "subl .", then ctrl+p (or cmd+p) and start typing whatever. It fuzzy-completes your typing and immediately displays your selection as a preview in the background as well.
Video here: https://www.dropbox.com/s/wjc9k8ocwiukq5t/sublime-linux.mov?...
(note the percentage in the footer, it was indexing in background the files for code completion and other stuff, since I had just cloned it, but the file jumping still works smoothly).
I skimmed through your other videos, and I didn't instantly see anything that I couldn't do with a recent editor as well.
Yes, Sublime handles that smoothly. Do a linux tree clone, enter the directory, run "subl .", then ctrl+p (or cmd+p) and start typing whatever. It fuzzy-completes your typing and immediately displays your selection as a preview in the background as well.
Video here: https://www.dropbox.com/s/wjc9k8ocwiukq5t/sublime-linux.mov?...
(note the percentage in the footer, it was indexing in background the files for code completion and other stuff, since I had just cloned it, but the file jumping still works smoothly).
I skimmed through your other videos, and I didn't instantly see anything that I couldn't do with a recent editor as well.
Emacs also has that preview feature when you move the highlighter to a selection. However, I feel it annoying because screen keeps changing while I narrow to a file or a set of files, and luckily it is off by default.
How about other thing? Like switch between source and header files without configuring anything? Or Jump to any file I see instantly, even without full filepath and you only have just a name and without typing the filename? http://tuhdo.github.io/static/helm-projectile/helm-projectil...
Can it do powerful automatic indentation: https://github.com/Bruce-Connor/aggressive-indent-mode. It does not only indent the current line, but the whole Semantic context around your cursor. Demos inside the homepage.
Beautiful compile output: http://tuhdo.github.io/static/c-ide/compilation-compile.gif
Open man page for symbol at cursor: http://tuhdo.github.io/static/part3/helm-man-woman.gif
Emacs can save any arbitrary window layout and restore it later. You can even have workspace in Emacs, each can store a set of window layouts (i.e. one for debugging, one for reading doc, one for just source code...), can be saved as a bookmark and later restore in future session. In Emacs, you can bookmark everything, even a git commit.
How about other thing? Like switch between source and header files without configuring anything? Or Jump to any file I see instantly, even without full filepath and you only have just a name and without typing the filename? http://tuhdo.github.io/static/helm-projectile/helm-projectil...
Can it do powerful automatic indentation: https://github.com/Bruce-Connor/aggressive-indent-mode. It does not only indent the current line, but the whole Semantic context around your cursor. Demos inside the homepage.
Beautiful compile output: http://tuhdo.github.io/static/c-ide/compilation-compile.gif
Open man page for symbol at cursor: http://tuhdo.github.io/static/part3/helm-man-woman.gif
Emacs can save any arbitrary window layout and restore it later. You can even have workspace in Emacs, each can store a set of window layouts (i.e. one for debugging, one for reading doc, one for just source code...), can be saved as a bookmark and later restore in future session. In Emacs, you can bookmark everything, even a git commit.
> How about other thing? Like switch between source and header files without configuring anything?
Yes (ctrl+alt+up).
> Or Jump to any file I see instantly, even without full file path > and you only have just a name and without typing the filename?
I'm not sure I understand. I mentioned fuzzy completion before, the way it works is that it matches even subparts of the paths and/or filename, with the only requisite of preserving left to right. For instance if I type "bmx25" I can find boot-related imx25 files, because it will match the "b" from the boot path, and then "mx25" from the filename (even a few directories down the path).
> Can it do powerful automatic indentation:
I never saw such a plugin; generically speaking, plugins can do stuff on keypresses (in a separate thread of course to avoid blocking), for instance you can configure the linters to run at each keypress, at each save, every Nth seconds, after N idle millesconds, etc.
So it depends whether you want to compare the richness of the ecosystem or the core capabilities of the editor.
> Beautiful compile output:
I honestly don't know; it doesn't that by default, though there might be some plugin to that effect; when I use compiled languages, I prefer a linter-like approach to showing compilation errors, so I don't use this kind of plugins in my own environment.
> Open man page for symbol at cursor
yes, this is supported, though I personally switched to Dash (http://kapeli.com/dash) recently, which is similar but much more powerful than just man, as it allows to cache and index documentation from dozens of programming environment and frameworks, taking care of the different formats, etc. So for instance with the same shortcut I can get the help for a POSIX function from its man page, or a Boost class method from their official documentation, and everything is blazingly fast because of local cache and index, so my computer doesn't need to go to boost.org to show that page.
> Emacs can save any arbitrary window layout and restore it later.
You can do that in Sublime, but you need to define a project (which, in its most basic form, is just a "save project" command after having opened a directory); at that point, you have a shortcut to switch between projects with fuzzy completion, and each project keeps the full workspace, ALSO including unsaved modifications to files (which sounds crazy but I love it) as it means that you can do it without even thinking once.
---
Generally speaking, I don't think there's a world of difference. I find vim harder to replicate in its more advanced features, with its approach to command combinations which is totally different from anything else; but emacs introduced to the world the concept an extendible editor based on complicated, targeted commands (which is the one in widespread usage today), so I think that any sufficiently advanced editor can get very close to emacs in most features.
Obviously emacs has many years of history and contributors that created a vast ecosystem, but there might also be some ecosystem bias given its legacy (e.g.: I think it's safe to assert that most web programmers don't use emacs, so I think it's normal to expect Sublime or Atom support for web programming to be generically more advanced).
In fact, I don't think Emacs have a specific paradigm that is hard to replicate, as it's the contrary (what used to be special in Emacs 20 years ago as become the default for all editors nowadays). We can battle on the last advanced feature in one specific workflow, but I think the discussion then becomes anecdoctal or at least very niche-related.
If look at Atom for instance, they introduced a concept where the editor window is not simply line-based, but they can open graphical windows within it, which is a paradigm shift which might introduce unique features, very hard to replicate. See for instance their nested CSS editing feature, which is very nice because it helps my brain limit the context switching a lot.
Yes (ctrl+alt+up).
> Or Jump to any file I see instantly, even without full file path > and you only have just a name and without typing the filename?
I'm not sure I understand. I mentioned fuzzy completion before, the way it works is that it matches even subparts of the paths and/or filename, with the only requisite of preserving left to right. For instance if I type "bmx25" I can find boot-related imx25 files, because it will match the "b" from the boot path, and then "mx25" from the filename (even a few directories down the path).
> Can it do powerful automatic indentation:
I never saw such a plugin; generically speaking, plugins can do stuff on keypresses (in a separate thread of course to avoid blocking), for instance you can configure the linters to run at each keypress, at each save, every Nth seconds, after N idle millesconds, etc.
So it depends whether you want to compare the richness of the ecosystem or the core capabilities of the editor.
> Beautiful compile output:
I honestly don't know; it doesn't that by default, though there might be some plugin to that effect; when I use compiled languages, I prefer a linter-like approach to showing compilation errors, so I don't use this kind of plugins in my own environment.
> Open man page for symbol at cursor
yes, this is supported, though I personally switched to Dash (http://kapeli.com/dash) recently, which is similar but much more powerful than just man, as it allows to cache and index documentation from dozens of programming environment and frameworks, taking care of the different formats, etc. So for instance with the same shortcut I can get the help for a POSIX function from its man page, or a Boost class method from their official documentation, and everything is blazingly fast because of local cache and index, so my computer doesn't need to go to boost.org to show that page.
> Emacs can save any arbitrary window layout and restore it later.
You can do that in Sublime, but you need to define a project (which, in its most basic form, is just a "save project" command after having opened a directory); at that point, you have a shortcut to switch between projects with fuzzy completion, and each project keeps the full workspace, ALSO including unsaved modifications to files (which sounds crazy but I love it) as it means that you can do it without even thinking once.
---
Generally speaking, I don't think there's a world of difference. I find vim harder to replicate in its more advanced features, with its approach to command combinations which is totally different from anything else; but emacs introduced to the world the concept an extendible editor based on complicated, targeted commands (which is the one in widespread usage today), so I think that any sufficiently advanced editor can get very close to emacs in most features.
Obviously emacs has many years of history and contributors that created a vast ecosystem, but there might also be some ecosystem bias given its legacy (e.g.: I think it's safe to assert that most web programmers don't use emacs, so I think it's normal to expect Sublime or Atom support for web programming to be generically more advanced).
In fact, I don't think Emacs have a specific paradigm that is hard to replicate, as it's the contrary (what used to be special in Emacs 20 years ago as become the default for all editors nowadays). We can battle on the last advanced feature in one specific workflow, but I think the discussion then becomes anecdoctal or at least very niche-related.
If look at Atom for instance, they introduced a concept where the editor window is not simply line-based, but they can open graphical windows within it, which is a paradigm shift which might introduce unique features, very hard to replicate. See for instance their nested CSS editing feature, which is very nice because it helps my brain limit the context switching a lot.
If you want image display, there Emacs has it eons ago, and people write plug-ins for it, like this one: https://github.com/josteink/wsd-mode
Emacs is also a fine PDF reader. I can search text in the PDF file with highlighting and a table of content side by side. All can be controlled with the keyboard: https://tuhdo.github.io/static/emacs-read-pdf.gif. I never use Evince again.
Emacs is also a fine PDF reader. I can search text in the PDF file with highlighting and a table of content side by side. All can be controlled with the keyboard: https://tuhdo.github.io/static/emacs-read-pdf.gif. I never use Evince again.
No, I don't want image display. I want to replicate Atom's inlining editing features. Did you look into that? This is one example:
https://discuss.atom.io/t/expand-css-rules-inline-html/12437
i think skewer-mode is close enough: https://github.com/skeeto/skewer-mode for live editing.
I don't think that inlining feature really help much. Generally, if you want to access a css element in Emacs, you jump in, edit and jump back in an instant to see your result.
See also web-mode: http://web-mode.org
I don't think that inlining feature really help much. Generally, if you want to access a css element in Emacs, you jump in, edit and jump back in an instant to see your result.
See also web-mode: http://web-mode.org
> is a paradigm shift [...] very hard to replicate
Well, that's true, and Atom deserves recognition for replicating it...
http://www.emacswiki.org/emacs/EmacsXWidgets
Well, that's true, and Atom deserves recognition for replicating it...
http://www.emacswiki.org/emacs/EmacsXWidgets
Well, that's the basic technological point, then you need the commands to make it useful for writing code at production speed, and not just a gimmick.
Yes, I was being obviously unfair here, sorry for this.
> Yes (ctrl+alt+up).
Does it work in the source as large as the linux kernel that shows you every possible files? i.e I have a file named `fpu.c`, I want all `fpu.h` in Linux. And Emacs does not work with only C/C++, but work for any languages that users define two lists of pairs of file extensions to switch to. i.e. you can switch between Gemfile <-> Gemfile.lock, .h <-> .js...
> I'm not sure I understand. I mentioned fuzzy completion before, the way it works is that it matches even subparts of the paths and/or filename, with the only requisite of preserving left to right. For instance if I type "bmx25" I can find boot-related imx25 files, because it will match the "b" from the boot path, and then "mx25" from the filename (even a few directories down the path).
No. I mean that in an ASCII text file, with only the filename (no path information), you press a key binding, it automatically jumps to that fine. For example, I have a file "Document/test.txt". In "src/feature1/test.c", it only mentions "test.txt". I want that when cursor is on "test.txt", and if that file is the only file in my project, I jump to it instantly; otherwise, it gives me a list of potential candidates. And this must work in any file, even plain ASCII text file.
If the text at point is a directory path, I expect with a single key stroke, my editor returns all files that contain that path.
> So it depends whether you want to compare the richness of the ecosystem or the core capabilities of the editor.
Both. After all, Emacs is a Lisp interpreter at its core. It's a computing environment more than a text editor; text editing is just a subset of it. That's why it is so easy to write tools for Emacs, despite a much lesser user base than other editors. Emacs has many hidden things that I can never find in other editors. For example, it has an advanced calculator and mathematical tool roughly based on the HP-28/48 : http://www.gnu.org/software/emacs/manual/html_mono/calc.html
> I honestly don't know; it doesn't that by default, though there might be some plugin to that effect; when I use compiled languages, I prefer a linter-like approach to showing compilation errors, so I don't use this kind of plugins in my own environment
Emacs supports coloring compile output by default, built-in. Emacs also has a syntax check plugin for wide array of languages, called flycheck: https://github.com/flycheck/flycheck (see the homepage for a simple demo).
And here is GDB inside Emacs: tuhdo.github.io/static/c-ide/gdb-many-windows.gif
Every change you make to a value, all other panes update as well, when relevant. You can also have an integrated memory debugger inside Emacs. You can even do remote debugging with Emacs.
> yes, this is supported, though I personally switched to Dash (http://kapeli.com/dash) recently, which is similar but much more powerful than just man, as it allows to cache and index documentation from dozens of programming environment and frameworks, taking care of the different formats, etc. So for instance with the same shortcut I can get the help for a POSIX function from its man page, or a Boost class method from their official documentation, and everything is blazingly fast because of local cache and index, so my computer doesn't need to go to boost.org to show that page.
Emacs has support for Dash as well, and you can view it inside Emacs: https://github.com/areina/helm-dash
> You can do that in Sublime, but you need to define a project (which, in its most basic form, is just a "save project" command after having opened a directory); at that point, you have a shortcut to switch between projects with fuzzy completion, and each project keeps the full workspace, ALSO including unsaved modifications to files (which sounds crazy but I love it) as it means that you can do it without even thinking once.
Emacs can do that as well. You can switch between projects, and Emacs remembers window layout of each project you are working on with Projectile: https://github.com/bbatsov/projectile. You can see more Projectile demos in my guide (demos at top): http://tuhdo.github.io/helm-projectile.html
What I said is very different. You think each Emacs window is like a perspective in Eclipse. Each window layout can have different purposes: it can be a layout of 4 smaller code buffers, or it can be a debug view, or it can hold many documentation panes... You can arrange arbitrary window layouts, save and restore in future sessions. You can group many window layouts (or "perspectives") inside a workspace, and you can also have many workspaces like that. Each workspace can be a project, each has many different layouts for different purposes.
> Generally speaking, I don't think there's a world of difference. I find vim harder to replicate in its more advanced features, with its approach to command combinations which is totally different from anything else; but emacs introduced to the world the concept an extendible editor based on complicated, targeted commands (which is the one in widespread usage today), so I think that any sufficiently advanced editor can get very close to emacs in most features.
Vim is now a proper subset of Emacs. Evil is the best Vim emulator out there, said Vimmers who switched to Emacs. See Spacemacs: https://github.com/syl20bnr/spacemacs
> If look at Atom for instance, they introduced a concept where the editor window is not simply line-based, but they can open graphical windows within it, which is a paradigm shift which might introduce unique features, very hard to replicate. See for instance their nested CSS editing feature, which is very nice because it helps my brain limit the context switching a lot.
Yet Atom cannot work in terminal, which is essential for working remotely. Emacs can live to this day because it has 30 years of accumulating vast amount of different uses cases. Someday someone will add such capacities to Emacs, when it is really needed. For now, graphic is cute but it mostly satisfies web development. If I have 10 or 20 local VMs (with only terminal), it would be crazy without Emacs to manage all of them effortlessly.
Does it work in the source as large as the linux kernel that shows you every possible files? i.e I have a file named `fpu.c`, I want all `fpu.h` in Linux. And Emacs does not work with only C/C++, but work for any languages that users define two lists of pairs of file extensions to switch to. i.e. you can switch between Gemfile <-> Gemfile.lock, .h <-> .js...
> I'm not sure I understand. I mentioned fuzzy completion before, the way it works is that it matches even subparts of the paths and/or filename, with the only requisite of preserving left to right. For instance if I type "bmx25" I can find boot-related imx25 files, because it will match the "b" from the boot path, and then "mx25" from the filename (even a few directories down the path).
No. I mean that in an ASCII text file, with only the filename (no path information), you press a key binding, it automatically jumps to that fine. For example, I have a file "Document/test.txt". In "src/feature1/test.c", it only mentions "test.txt". I want that when cursor is on "test.txt", and if that file is the only file in my project, I jump to it instantly; otherwise, it gives me a list of potential candidates. And this must work in any file, even plain ASCII text file.
If the text at point is a directory path, I expect with a single key stroke, my editor returns all files that contain that path.
> So it depends whether you want to compare the richness of the ecosystem or the core capabilities of the editor.
Both. After all, Emacs is a Lisp interpreter at its core. It's a computing environment more than a text editor; text editing is just a subset of it. That's why it is so easy to write tools for Emacs, despite a much lesser user base than other editors. Emacs has many hidden things that I can never find in other editors. For example, it has an advanced calculator and mathematical tool roughly based on the HP-28/48 : http://www.gnu.org/software/emacs/manual/html_mono/calc.html
> I honestly don't know; it doesn't that by default, though there might be some plugin to that effect; when I use compiled languages, I prefer a linter-like approach to showing compilation errors, so I don't use this kind of plugins in my own environment
Emacs supports coloring compile output by default, built-in. Emacs also has a syntax check plugin for wide array of languages, called flycheck: https://github.com/flycheck/flycheck (see the homepage for a simple demo).
And here is GDB inside Emacs: tuhdo.github.io/static/c-ide/gdb-many-windows.gif
Every change you make to a value, all other panes update as well, when relevant. You can also have an integrated memory debugger inside Emacs. You can even do remote debugging with Emacs.
> yes, this is supported, though I personally switched to Dash (http://kapeli.com/dash) recently, which is similar but much more powerful than just man, as it allows to cache and index documentation from dozens of programming environment and frameworks, taking care of the different formats, etc. So for instance with the same shortcut I can get the help for a POSIX function from its man page, or a Boost class method from their official documentation, and everything is blazingly fast because of local cache and index, so my computer doesn't need to go to boost.org to show that page.
Emacs has support for Dash as well, and you can view it inside Emacs: https://github.com/areina/helm-dash
> You can do that in Sublime, but you need to define a project (which, in its most basic form, is just a "save project" command after having opened a directory); at that point, you have a shortcut to switch between projects with fuzzy completion, and each project keeps the full workspace, ALSO including unsaved modifications to files (which sounds crazy but I love it) as it means that you can do it without even thinking once.
Emacs can do that as well. You can switch between projects, and Emacs remembers window layout of each project you are working on with Projectile: https://github.com/bbatsov/projectile. You can see more Projectile demos in my guide (demos at top): http://tuhdo.github.io/helm-projectile.html
What I said is very different. You think each Emacs window is like a perspective in Eclipse. Each window layout can have different purposes: it can be a layout of 4 smaller code buffers, or it can be a debug view, or it can hold many documentation panes... You can arrange arbitrary window layouts, save and restore in future sessions. You can group many window layouts (or "perspectives") inside a workspace, and you can also have many workspaces like that. Each workspace can be a project, each has many different layouts for different purposes.
> Generally speaking, I don't think there's a world of difference. I find vim harder to replicate in its more advanced features, with its approach to command combinations which is totally different from anything else; but emacs introduced to the world the concept an extendible editor based on complicated, targeted commands (which is the one in widespread usage today), so I think that any sufficiently advanced editor can get very close to emacs in most features.
Vim is now a proper subset of Emacs. Evil is the best Vim emulator out there, said Vimmers who switched to Emacs. See Spacemacs: https://github.com/syl20bnr/spacemacs
> If look at Atom for instance, they introduced a concept where the editor window is not simply line-based, but they can open graphical windows within it, which is a paradigm shift which might introduce unique features, very hard to replicate. See for instance their nested CSS editing feature, which is very nice because it helps my brain limit the context switching a lot.
Yet Atom cannot work in terminal, which is essential for working remotely. Emacs can live to this day because it has 30 years of accumulating vast amount of different uses cases. Someday someone will add such capacities to Emacs, when it is really needed. For now, graphic is cute but it mostly satisfies web development. If I have 10 or 20 local VMs (with only terminal), it would be crazy without Emacs to manage all of them effortlessly.
I agree that Emacs has many nice features that come with 30 years of development, but I also thing that those features have a bias towards older paradigms/languages of programming, and thus the advantages reduce a lot and/or there are deficiencies if you move into newer technology stacks.
Morevoer, even if Emacs is a LISP machine, it doesn't give it any super-power that can't be replicated in other editors; I mean, it of course gives it flexibility to use it as a mail reader, that's true, but within the editor itself, there's nothing game-changing. I showed features that are either very close, or a bit worse, or a bit better, made with an editor which is not a LISP machine. I think we can agree that anything that you mentioned can be implemented in Sublime as a plugin; if it's not there out of the box, point taken that the ecosystem is more mature, but it doesn't show an inherent gap that can't be filled, it only shows where development effort is being focused on. For Sublime, surely it's not C/C++.
Morevoer, even if Emacs is a LISP machine, it doesn't give it any super-power that can't be replicated in other editors; I mean, it of course gives it flexibility to use it as a mail reader, that's true, but within the editor itself, there's nothing game-changing. I showed features that are either very close, or a bit worse, or a bit better, made with an editor which is not a LISP machine. I think we can agree that anything that you mentioned can be implemented in Sublime as a plugin; if it's not there out of the box, point taken that the ecosystem is more mature, but it doesn't show an inherent gap that can't be filled, it only shows where development effort is being focused on. For Sublime, surely it's not C/C++.
[deleted]
Emacs can be made prettier, but that's not its forte - power and extensibility are. It's a better text editor, IMO, than any of the three you mention.
However, it's not particularly suited to quick server admin stuff. If you're using emacs as its intended, you'll have a lot of packages to load on startup, making it sluggish for ad-hoc editing with sudo (precluduing use of emacsclient). Emacs -q or mg would be faster. Personally, I'm fond of joe for this purpose - more functionality than mg while far smaller an install than emacs.
However, it's not particularly suited to quick server admin stuff. If you're using emacs as its intended, you'll have a lot of packages to load on startup, making it sluggish for ad-hoc editing with sudo (precluduing use of emacsclient). Emacs -q or mg would be faster. Personally, I'm fond of joe for this purpose - more functionality than mg while far smaller an install than emacs.
>ad-hoc editing with sudo (precluding use of emacsclient)
It looks to me like you're probably unaware that an Emacs not running as root can edit files owned by root. The way it goes about it (in a word, TRAMP) is a little complicated under the hood, but (at least for files residing on the same machine as the Emacs process) reliable.
Specifically, both C-x C-f /sudo::/etc/hosts and `emacsclient /sudo::/etc/hosts` work.
It looks to me like you're probably unaware that an Emacs not running as root can edit files owned by root. The way it goes about it (in a word, TRAMP) is a little complicated under the hood, but (at least for files residing on the same machine as the Emacs process) reliable.
Specifically, both C-x C-f /sudo::/etc/hosts and `emacsclient /sudo::/etc/hosts` work.
And you can have something fun like the following in your bashrc to allow attaching to your running emacs daemon any time you need in the terminal:
function semacs() {
emacsclient -t -a "" "/sudo::$(realpath $@)"
}Even more fun is using tramp to edit files as root on a machine via ssh. The whole installed editor canard is somewhat a nonissue from the emacs side.
Probably you have never seen a good emacs setup, that turns it into powerful customized IDE with great usability. Emacs is like minecraft for editors, you never stop building on it.
Good. You seem to favor form over functionality, nothing wrong with that. Emacs is the complete opposite of that.
It's hard to explain when there are all these reasonably featureful programming editors and IDEs going around. The key realisation to have is that even today I spend a huge amount of time just editing text. Commenting on HN? Editing text. Emails? Editing text. Coding? Editing text.
Once you have that "everything is text" realisation, there are two ways to make the most of it. One is to have an editor that's easily called from other places (e.g., vim) and the other is to have an editor that can be integrated into everything (e.g., emacs).
I started using emacs over a decade ago, and it keeps growing and changing to best suit my workflow. And yes, that includes reading mail.
Once you have that "everything is text" realisation, there are two ways to make the most of it. One is to have an editor that's easily called from other places (e.g., vim) and the other is to have an editor that can be integrated into everything (e.g., emacs).
I started using emacs over a decade ago, and it keeps growing and changing to best suit my workflow. And yes, that includes reading mail.
>One is to have an editor that's easily called from other places
Emacs is even better than vim at this, ironically. emacs --daemon makes it easy to call emacsclient anywhere I want without worrying about the file already being open - a common pain in vim, at least for me before I switched.
Yeah I use emacsclient as well, but I wanted to keep the description simple.
What's the point in being so condescending?
You are a fool.
You shouldn't blame him. The truth is that Emacs does a great job at hiding its potential from users. Editors like Atom are ultimately much less powerful but they make it easy to discover and use the features that they provide. When I started using Emacs (after a decade of Vim), it took me two years to make myself fully feel at home in Emacs. Part of the reason was that you can't really use Emacs to its fullest without learning a good deal of Elisp. This is the part were other editors do much better.
Emacs is an outstanding image-based IDE for Elisp, with extensive support for text editing. It's a dynamic environment where you can script your way out of any situation as you go, without restarting and recompilation and so on, which is probably its most powerful feature. No wonder you need to know how to script it to appreciate this power - but I don't think Emacs hides this feature from users. On the contrary, the second thing you see when running vanilla Emacs (after its logo and greeting) is a scratch buffer, so a feature directed at users who want to customize or extend Emacs.
The potential of Emacs comes from the huge number of excellent third-party extensions not from the ability to evaluate lisp code in the scratch buffer. Many of these extensions are not very visible. Did you know that there is a really powerful PDF viewer for Emacs that has extensive support for annotations? It took me a long time to find out about it although reading and annotating PDFs is an important part of my work, which is why I did a fair amount of research into the topic. For some reason, this PDF viewer doesn't have a proper web page or documentation. I had to read the code in order to find out what its capabilities are. I leave it as an exercise to you to find out which extension I'm talking about. Perhaps that makes clearer what I meant when I wrote that Emacs is hiding its potential.
> The potential of Emacs comes from the huge number of excellent third-party extensions
Yes, but you wouldn't have that many excellent extensions without Emacs being a great Elisp IDE. I recently compared PyCharm (I had to purchase it for work) with Emacs and the number of plugins for the former is negligible in comparison. I think that this is because writing extensions/plugins for PyCharm is so much harder than for Emacs: no scratch, no built-in API docs, no full blown book on scripting (like Elisp info), no macro->defun ability, no defadvice, no find-function/find-library and so on and on and on...
Of course, the other reason may be the fact that Emacs has 30 years worth of code written for it :) but I think without matching Emacs extensibility features no editor will ever come close to it in terms of extensions. LightTable looks promising in this regard, so does Atom, but other than these all editors/IDEs look like they don't treat extensibility seriously. Which is why I'm still using Emacs as my primary workspace.
> Did you know that there is a really powerful PDF
You mean with DocView mode? Yes, I knew it (and it's built-in, not 3rd party). I also knew about Calc (http://nullprogram.com/blog/2009/06/23/), about Calendar, about proced, about dired and wdired, about VC, about ediff and emerge, about ctags/etags, about artist-mode, about rmail and gnus, about TRAMP and eshell and ansi-term...
Do you know how I learned about all of them? I just opened this page: https://www.gnu.org/software/emacs/manual/html_mono/emacs.ht... and started reading. You know, cover to cover, as I'd do with any good book. Of course, along the way I switched to reading it inside Emacs, and I skipped some parts I decided I'm very unlikely to ever use, but I can assure you that it's all there. Perhaps a need for such a book is an Emacs failure in itself (because the interface is not discoverable by itself?), but at least it is there. I know of no other editor (Vim comes close in terms of docs coverage, but it's less neatly structured and harder to read cover-to-cover) which is that well documented.
Yes, but you wouldn't have that many excellent extensions without Emacs being a great Elisp IDE. I recently compared PyCharm (I had to purchase it for work) with Emacs and the number of plugins for the former is negligible in comparison. I think that this is because writing extensions/plugins for PyCharm is so much harder than for Emacs: no scratch, no built-in API docs, no full blown book on scripting (like Elisp info), no macro->defun ability, no defadvice, no find-function/find-library and so on and on and on...
Of course, the other reason may be the fact that Emacs has 30 years worth of code written for it :) but I think without matching Emacs extensibility features no editor will ever come close to it in terms of extensions. LightTable looks promising in this regard, so does Atom, but other than these all editors/IDEs look like they don't treat extensibility seriously. Which is why I'm still using Emacs as my primary workspace.
> Did you know that there is a really powerful PDF
You mean with DocView mode? Yes, I knew it (and it's built-in, not 3rd party). I also knew about Calc (http://nullprogram.com/blog/2009/06/23/), about Calendar, about proced, about dired and wdired, about VC, about ediff and emerge, about ctags/etags, about artist-mode, about rmail and gnus, about TRAMP and eshell and ansi-term...
Do you know how I learned about all of them? I just opened this page: https://www.gnu.org/software/emacs/manual/html_mono/emacs.ht... and started reading. You know, cover to cover, as I'd do with any good book. Of course, along the way I switched to reading it inside Emacs, and I skipped some parts I decided I'm very unlikely to ever use, but I can assure you that it's all there. Perhaps a need for such a book is an Emacs failure in itself (because the interface is not discoverable by itself?), but at least it is there. I know of no other editor (Vim comes close in terms of docs coverage, but it's less neatly structured and harder to read cover-to-cover) which is that well documented.
Docview is great, but not enough. He mentioned pdf-tools: https://github.com/politza/pdf-tools, that enhances doc-view with outline for table of contents and annotations.
Wow, very nice! Thanks, I don't deal with pdfs very much so I never felt the need for something more than DocView, but this looks nice :)
You can view the demo here: https://tuhdo.github.io/static/emacs-read-pdf.gif
I love Emacs. I would have never been tricked into learning Elisp without it. :P (Emacs is also an integrated learning environment for Emacs Lisp!)
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
(just kidding. I don't like SE but I'm sure this is a great tool for people who do like SE.)
(just kidding. I don't like SE but I'm sure this is a great tool for people who do like SE.)
Please don't have an opinion when posting on StackExchange. Democracy and committees are what make America great and why we chose XML over S-Expressions.
http://emacs.stackexchange.com/
(After first seeing the title, I assumed that's what this post was about!)