And all that in widely-known to tons of people HTML/CSS. The huge advantage of VSC: plugins can use HTML to implement whatever UI they want, from a workflow tool, to a test tool, to a Git graph view to a debugger data structure visualizer.
Visual studio 2017 shortcut to add page preinit code#
For most people starting out, who just want to get hacking on some code as quickly as possible, it is perhaps not the best fit. If you like to have nearly absolute control of your editing experience, Emacs might be interesting to you. A trivial amount of Emacs Lisp gave me that with minimal effort. ) is that (a) it's often a little harder to get functionality that is provided out-of-the-box by another IDE, but (b) it's much easier (in some cases, infinitely easier) to implement workflows or functionality not already implemented by said IDE.Īs an example, I often run snippets of code and want to insert the result directly beneath the code in question (similar to Jupyter in Python, but for any language, in plain text, directly in my editor). The major difference between Emcs and other IDEs (VSCode, IntelliJ. To do this, we collectively probably use about 0.1% of the publicly available extension packages for Emacs on MELPA.īut the short summary is that most people use it for the various functions an IDE provides. Half my fifteen-person team at work (in a fast-growing mid-size fintech company in Chicago) uses Emacs, for editing/testing/running code in several languages, interacting with Web services, running various shells, calendar functions, document writing including UML diagrams and mathematics typesetting, and personal planning (Org Mode). I'm always keeping my eye on other editors and IDEs, and with varying levels of difficulty, I haven't really come across too many useful things that wouldn't be possible to do within the current Emacs/Elisp environment. the crash navigation stuff outside of an editor (perhaps as part of an error-handling dashboard).ī) likely already be possible to build in non-terminal versions of Emacs, without having to design your own terminal and editor from scratch.īy no means do I think Emacs is a perfect editor, but I'm also very cautious when pondering "do we rebuild from scratch"-type questions. I have no problem imagining use cases for e.g. It's already capable of displaying images either in separate buffers or inline.įrom Gary's talk there, my thoughts would be that a number of the features he's put in there would:Ī) be potentially better-served as CLI tools instead of baked directly into the IDE, with well-defined inputs and outputs. Pretty cool talk! I love some of the features he's added!Īn interesting thing that often gets forgotten or missed is that Emacs doesn't depend on a conventional TTY to run. Code talks, a bunch of people opining on a mailing list is pretty worthless in comparison. If someone thinks emacs will be more successful with these cosmetic changes they are welcome to fork it since this is one of the earliest open source programs. And changing the colors? The shortcuts that have worked for decades? Please. It’s not an insult to say something like emacs is not “modern.” Of course it’s not. But I think the bar is much higher than this. I’m not saying the editor can not be improved. When I see a highly successful 40+ year old piece of software, my first instinct isn’t to ask what the people behind it can learn from me but what I can learn from them. It is widely used for a staggering array of tasks.
And the author of the article would like the development process to be more “modern.”Įmacs is one of the most successful text editors of all time if not the most successful. I read the whole article and it seems the suggestions boil down to emacs needing to be more “modern” by defaulting to dark mode, making color theming easier, changing right click behavior, the menus, and changing the shortcuts.
0 kommentar(er)
