4 ms·

> "In the workflow I described, all that code is already written, and you can invoke it with a single keystroke." The thing is, if that's the case, what you're

> "In the workflow I described, all that code is already written, and you can invoke it with a single keystroke." The thing is, if that's the case, what you're describing isn't a custom plugin, it's an existing plugin someone else has taken time to write that you're making use of. If that's the argument you're making then you could say Emacs has a better ecosystem of plugins, and that it's easier to tie them together, is that what you're trying to state?

throwanem 11y ago
It's a subset, and the Blub paradox applies. For one thing, Org isn't a plugin; it's part of the Emacs distribution, rather than something you have to explicitly install. All you need to do to use all the functionality I described is install Emacs and start it up. For another, Emacs doesn't actually have a plugin system, per se. Instead of the usual headache, where a program written in language A exposes a lossy subset of itself to plugins written in language B, Emacs just exposes all of the language in which it itself is written, and you can do what you like. The usual distinction between first-class application code and second-class plugin code doesn't exist. There's just Emacs Lisp code, any of which can freely interact with any other Emacs Lisp code running in the same process space, including effectively all of Emacs itself. You can add new code by installing packages from a repository, which you can do in a single command if you know the name of the plugin you want. (If you don't, there's a searchable list.) Or you can do it by opening an Emacs Lisp buffer, writing some code, and evaluating it - again, with a single keystroke. If you like it and want to keep it around, save it to a file: boom, it's a "plugin". Add a line to your init file to load it, and it's a "plugin" you're using. Or you can just drop your new code into your init file directly, because your init file is - you guessed it - just Emacs Lisp code, that happens to be in a file Emacs will load and execute when it starts up. As I said before, the Blub paradox applies: it's easy to recognize something less powerful than what you're familiar with as such, but something more powerful just looks weird. From the sound of it, Emacs looks very weird to you. It did to me, too, before I started using it. Now I won't willingly use anything else. Perhaps I'm just very weird, too.
- ZenoArrow 11y ago
  > "As I said before, the Blub paradox applies: it's easy to recognize something less powerful than what you're familiar with as such, but something more powerful just looks weird. From the sound of it, Emacs looks very weird to you. It did to me, too, before I started using it. Now I won't willingly use anything else. Perhaps I'm just very weird, too." Nah, it's nothing to do with the blub paradox. I've dabbled with Emacs before, I could see certain benefits to its flexibility, but was put off by other factors such as the clunky keyboard shortcuts (which is why I'm glad for both ergoemacs and spacemacs, as they have better defaults IMO), reliance on Lisp and a couple of other minor issues. Overall I think it's a great tool, and I can see why its popular. That said, using the blub paradox implies (whether you intended to or not) that you believe it's more powerful than the competition. The way I see it is that any program is only as good as its existing features. Org mode is a good example of a strong feature for Emacs, but I could point out a number of strong feature for VS too. IntelliTest is a good example: https://msdn.microsoft.com/en-us/library/dn823749.aspx https://msdn.microsoft.com/en-us/library/dn823749.aspx IntelliTrace is another: https://visualstudiomagazine.com/articles/2012/02/07/intellitrace-in-production.aspx?m=1 https://visualstudiomagazine.com/articles/2012/02/07/intelli... If someone has only ever debugged using print statements or breakpoints then they miss the power of such features, so I could just as easily invoke the blub paradox with reference to VS as well. The point is there is not one single ultimate tool, they all have strengths and weaknesses. Emacs is not a paradigm shift better than VS, and VS is not a paradigm shift better than Emacs, so the blub paradox does not apply.
  - throwanem 11y ago
    Visual Studio integrates well with the capabilities of C++ and of languages that run on the CLR. Outside that realm, it can do little or nothing for you. Emacs integrates well with the same capabilities in almost any language that provides them - even C#. See the difference?

throwanem 11y ago

It's a subset, and the Blub paradox applies. For one thing, Org isn't a plugin; it's part of the Emacs distribution, rather than something you have to explicitly install. All you need to do to use all the functionality I described is install Emacs and start it up. For another, Emacs doesn't actually have a plugin system, per se. Instead of the usual headache, where a program written in language A exposes a lossy subset of itself to plugins written in language B, Emacs just exposes all of the language in which it itself is written, and you can do what you like. The usual distinction between first-class application code and second-class plugin code doesn't exist. There's just Emacs Lisp code, any of which can freely interact with any other Emacs Lisp code running in the same process space, including effectively all of Emacs itself. You can add new code by installing packages from a repository, which you can do in a single command if you know the name of the plugin you want. (If you don't, there's a searchable list.) Or you can do it by opening an Emacs Lisp buffer, writing some code, and evaluating it - again, with a single keystroke. If you like it and want to keep it around, save it to a file: boom, it's a "plugin". Add a line to your init file to load it, and it's a "plugin" you're using. Or you can just drop your new code into your init file directly, because your init file is - you guessed it - just Emacs Lisp code, that happens to be in a file Emacs will load and execute when it starts up. As I said before, the Blub paradox applies: it's easy to recognize something less powerful than what you're familiar with as such, but something more powerful just looks weird. From the sound of it, Emacs looks very weird to you. It did to me, too, before I started using it. Now I won't willingly use anything else. Perhaps I'm just very weird, too.

ZenoArrow 11y ago
> "As I said before, the Blub paradox applies: it's easy to recognize something less powerful than what you're familiar with as such, but something more powerful just looks weird. From the sound of it, Emacs looks very weird to you. It did to me, too, before I started using it. Now I won't willingly use anything else. Perhaps I'm just very weird, too." Nah, it's nothing to do with the blub paradox. I've dabbled with Emacs before, I could see certain benefits to its flexibility, but was put off by other factors such as the clunky keyboard shortcuts (which is why I'm glad for both ergoemacs and spacemacs, as they have better defaults IMO), reliance on Lisp and a couple of other minor issues. Overall I think it's a great tool, and I can see why its popular. That said, using the blub paradox implies (whether you intended to or not) that you believe it's more powerful than the competition. The way I see it is that any program is only as good as its existing features. Org mode is a good example of a strong feature for Emacs, but I could point out a number of strong feature for VS too. IntelliTest is a good example: https://msdn.microsoft.com/en-us/library/dn823749.aspx https://msdn.microsoft.com/en-us/library/dn823749.aspx IntelliTrace is another: https://visualstudiomagazine.com/articles/2012/02/07/intellitrace-in-production.aspx?m=1 https://visualstudiomagazine.com/articles/2012/02/07/intelli... If someone has only ever debugged using print statements or breakpoints then they miss the power of such features, so I could just as easily invoke the blub paradox with reference to VS as well. The point is there is not one single ultimate tool, they all have strengths and weaknesses. Emacs is not a paradigm shift better than VS, and VS is not a paradigm shift better than Emacs, so the blub paradox does not apply.
- throwanem 11y ago
  Visual Studio integrates well with the capabilities of C++ and of languages that run on the CLR. Outside that realm, it can do little or nothing for you. Emacs integrates well with the same capabilities in almost any language that provides them - even C#. See the difference?