Earlier quoted context omitted.
Emacs is a gui app. You can have if you like a tool bar. A menu-bar, tabs, split windows. If you want something slightly more like a traditional gui emacs application framework enables bidirectional communication with QT applications running in emacs frames. Personally I use it to render HTML mail inside emacs with what amounts to embedded chrome.
As far as I am aware it still isn't as GUI oriented as ZWEI used to be.
Making Emacs Popular Again
481–490 of 782 posts
Re: Making Emacs Popular Again
#482Earlier quoted context omitted.
Better yet, install vscode, then install either the vim or emacs plugin. The best of all worlds!
Eh. Sort of. Like the other person who replied about the Emacs plugin, I find myself running into issues with the Vim plugin -- usually not the keybindings as much as the ex-style commands. For instance, ":20,27m." will move a block of text in Vi/Vim to under the current location; that doesn't work in VSCode Vim. Worse for me personally, I've gotten really used to the ":find" command being the (rough) equivalent of a…
Re: Making Emacs Popular Again
#483Earlier quoted context omitted.
This view is obviously biased against Emacs, but I don't disagree completely with the premise. As an Emacs user, being "immediately productive" (whatever that means) is not your topmost priority. You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. As your job evolves and changes, you…
> You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. As your job evolves and changes, you maintain and grow your Emacs files over decades, and borrow from someone else's workflows. I've been writing software for ~24 years, and I can understand the need for this in the past. Now, I ju…
The difference is I can make Emacs do things just the way I want it vs can it do what I need it to do? And I find that for most part I don't miss it that much (even I'm shocked) but I still open Emacs for Magit from time to time, because there's just nothing else like it, and boy is Magit slow when I have to merge big changes (probably exacerbated by Emacs Mac port's slow vfork).
Re: Making Emacs Popular Again
#484The problem is, much of what today's twentysomething webdevs consider modern is mere fad. It is not objectively better (and is sometimes objectively worse) in terms of user affordance than what we had in the 90s. The current trends in UI design obscure distinctions which were bloody obvious in the days of bevelled gray buttons. Browser engines run like pigs, especially when compared with simple bit-mapped windows, and developing in the cloud hits a brick wall when your network connection goes down.
I want you to try something. Try to imagine Emacs not as an ancient editor in need of modernization, but as a programmers' tool from the future. It may be a grim future indeed, one in which programmers learned some harsh lessons -- that not all programming is webdev, and the dominance of webdev in the field today is likely to be short-lived; that CPU and RAM are cheap, but not free; that networks go down; that software the user can't examine and completely control is software that is potentially hostile to the user; that the job of a program's UI is to enable work and not to dazzle the user; and that programmers have a higher duty to expand their users' minds, making them capable of more than when they started, and not to simperingly cater to 1984's notions of what an absolute beginner should experience. (The implications of the fact that Stallman learned many of these in the 70s and 80s is left as an exercise.)
But a program from far enough in the future is just as incomprehensible to today's users (especially today's generation-Z webdevs) as a program from the distant past, the difference being that the future program is likely to be much, much more advanced -- and today's users can learn a lot by understanding it on its own terms as they try to unlock its secret power. So it is with Emacs -- an omni-tool designed to be shaped and sculpted by the user into just the thing for the task at hand as the user works with it. No kidding --hacking something together in Emacs Lisp is so easy, for many data munging tasks it compares favorably to regular Lisp. Such hacks may not be beautiful or elegant or even production-ready, but if they let you get a job done quickly, they're valid. When you combine Lisp's eldritch power with the ubiquitous buffer abstraction and all that enables, you have a juggernaut for information workflow optimization -- and by comparison, Visual Studio Code is explicitly designed not to be extensible in such an ad hoc fashion.
Try this in your editor: Emacs has a command M-. If you are working on some Emacs Lisp and you type M-. on a symbol with a function binding, Emacs will jump to the function definition, opening the file it's compiled in if necessary. If you keep drilling down like this, eventually you will hit bedrock: the primitive functions of Emacs implemented in C. If you compiled your Emacs from source, and you say M-. on one of these, Emacs will remember where its own source lives and take you straight to the C file and line where the primitive is defined. This, my friends, is the quintessence of open source.
Plus, Emacs can talk to text terminals and bitmapped displays, and almost everything works the same either way. When I finally get my VT330 working, I'm going to hook it up to my sweet-ass Ryzen box, fire up Emacs, and take advantage of all its modern -- nay, futuristic -- power from my 1980s terminal. Why? Because I can. More practically, this means Emacs can communicate with its user over very low bandwidth channels -- making it ideal for working with remotely, cloud or otherwise.
And all this in an editor, several instances of which can be supported by a cheapass SBC like the Raspberry Pi. It's a bloody miracle of design, even as its hackishness is made manifest.
Emacs doesn't need to be changed to suit the whim and caprice of today's developers. Emacs is eternal, an emanation of the Tao; if it were to somehow disappear, somehow some way we would re-make it from scratch. It's not without faults, it can be improved, but the ideas behind it are transcendent and unmoving, and should not be compromised in favor of webdev fads. Let it shine forth like a beacon unto the void, and let its luminousness enlighten all those who are drawn to it.
Re: Making Emacs Popular Again
#485Earlier quoted context omitted.
> The fact that I have a non trivial .emacs file ensures that when I switch machines, I only have to transfer a single file to enable an identical development environment. I just want to pull this particular sentence out for emphasis in case anyone is reading the "New employee 2 workflow at company X" comment and thinking that it's even the least bit true.
For me it is home-manager switch and I don't only have my full Emacs configuration, but a full development environment with Rust, Go, etc. Though you could probably also configure VS Code that way.
If somebody could make a VS code extension that seamlessly pulls down other extensions by altering the nix config, it'd be perfect.
Re: Making Emacs Popular Again
#486Earlier quoted context omitted.
As far as I am aware it still isn't as GUI oriented as ZWEI used to be.
What gui elements do you find lacking I'm not familiar with ZWEI
Back when I was still into Emacs (2004) this wasn't possible.
Re: Making Emacs Popular Again
#487Earlier quoted context omitted.
> You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. As your job evolves and changes, you maintain and grow your Emacs files over decades, and borrow from someone else's workflows. I've been writing software for ~24 years, and I can understand the need for this in the past. Now, I ju…
Emacs user here. I've been thinking about this lately since I switched to VSCode because Emacs doesn't have a good TypeScript React mode and to be honest, you're right. The difference is I can make Emacs do things just the way I want it vs can it do what I need it to do? And I find that for most part I don't miss it that much (even I'm shocked) but I still open Emacs for Magit from time to time, because there's just…
But to be honest I only use Emacs because 28 years of using it has made it feel like home, I don't usually recommend it to new people.
Re: Making Emacs Popular Again
#488Earlier quoted context omitted.
New employee 3 workflow at company X: 1. Install Emacs 2. Sync existing config via git 3. Work New employee 4 workflow at company X: 1. Install Emacs 2. Spend 2 hours learning default Emacs 3. Work New employee 5 workflow at company X: 1. Install Emacs 2. Spend 1 - 2 hours learning default Emacs 3. Spend 2 - 4 hours googling interesting Emacs packages, in each case going to their GitHub repo to read the directions, a…
Don't forget: New employee 6 workflow at company X: 1. Install Spacemacs, don't bother fiddling with the config 2. Spend a few hours working through the tutorial or reviewing the excellent docs [1] 3. Work. Become a better developer [2]. [1]: https://www.spacemacs.org/doc/DOCUMENTATION.html [2]: https://blog.osteele.com/2004/11/ides
It's the oh-my-zsh of vim/emacs.
After a year of SpaceVim, when I finally found time, I ended up switching back to my more lightweight and stripped down version of NeoVim but copied the keymapping approach and some of the individual configs. It was a great starting point.
If you're a) new to vim/emacs or b) tired of maintaining your own config for w/e reason, Space[x] is entirely usable in it's default state with good documentation. It also updates often and stays on the cutting edge of various plugins and progression in the community, but with the stability of a larger community.
It defeats a lot of the learning/config curve arguments again vim/emacs.
Re: Making Emacs Popular Again
#489New employee 1 workflow at company X: 1. Install VS Code 2. Click extensions and install language specific plugin 3. Work New employee 2 workflow at company X: 1. Install emacs 2. Try to install some source code indexing tool 3. Tool is missing 13 dependencies, so spend 4 hours finding, installing and configuring the dependencies. 4. Spend another couple hours reading non-existent to terrible documentation (documenta…
> In a few years, VS Code has achieved better out of the box functionality How many years will it take until stock vscode stops lagging randomly every 10 key strokes?
Remember that you can open the dev tools and profile VS Code itself. I've debugged a few weird issues that way.
Re: Making Emacs Popular Again
#490Maybe not the appropriate forum but does anyone have a sane setup for the insane javascript setup of modern times? I love emacs and am willing to put the time into tooling and configuration. But despite several hopeful attempts, I’ve been unable to manage anything comparable to vscode for this environment. That is, support for all versions of ecmascript, but also jsx, typescript, et al.
Sorry I don't use emacs, but Vim/Neovim is pretty easy to setup with coc and all it's subextensions for stuff like eslint, tailwind, vue and whatever. It's essentially just the VSCode language server running in Vim and it's awesome.