I would learn a lot, but I really want a printed version! Maybe I can convince the local print shop do to it double sided and bind it?
Mastering Emacs
61–70 of 131 posts
Re: Mastering Emacs
#62I don't see why people are still using 1970s-era IDEs in 2023. Sure, it's a joke that emacs and vim users are at loggerheads, but name me one user of either who isn't a graybeard at this point. And specifically a graybeard who refuses to use more modern tools.
I'm not sure what you mean by graybeard, but I started developing software 5 years ago. Started using emacs 3 years ago (magit). Wrote my own 1000 line emacs config 1 year ago. I'm in my late 20s.
I'm sure you can config your beard to be gray in your 20s dude, you've managed with emacs for 3-years!
Re: Mastering Emacs
#63Earlier quoted context omitted.
Magit is probably the easiest one for casual devs to appreciate. "M-x magit" get a nice list of the status of the files in the current branch. After you mark which ones you want to keep by moving up and down pressing s(tage) u(nstage) you just press "c c" and write your commit message. Then you press P and your git repo is up to date. At a previous job the head engineer flagged the number of commits I was making as a…
> "M-x magit" get a nice list of the status of the files in the current branch. Except it will randomly split your frame and show up in a seemingly arbitrary location - often obscuring what you're working on. I find the whole layout system in Emacs completely chaotic. I guess it comes with the flexibility (VS a fixed system like most Ides) nor do I have any particular solution in mind I'm curious if anyone has tamed…
I have my Emacs setup to never split anything and just use the whole frame (window). That also goes for things like helm. Instead of splitting I prefer to open multiple frames and let my window manager, manage them. This really improved my workflow.
Re: Mastering Emacs
#64Earlier quoted context omitted.
Magit is probably the easiest one for casual devs to appreciate. "M-x magit" get a nice list of the status of the files in the current branch. After you mark which ones you want to keep by moving up and down pressing s(tage) u(nstage) you just press "c c" and write your commit message. Then you press P and your git repo is up to date. At a previous job the head engineer flagged the number of commits I was making as a…
> "M-x magit" get a nice list of the status of the files in the current branch. Except it will randomly split your frame and show up in a seemingly arbitrary location - often obscuring what you're working on. I find the whole layout system in Emacs completely chaotic. I guess it comes with the flexibility (VS a fixed system like most Ides) nor do I have any particular solution in mind I'm curious if anyone has tamed…
This thread is on the "Mastering Emacs" book and from its author, on the topic of mastering Emacs window managements you can read this:
https://www.masteringemacs.org/article/demystifying-emacs-wi...
To be honest I've never played with this part of Emacs. The way I use it I'm fine with the default. But if not it's possible to take control of Emacs internal windows management.
Re: Mastering Emacs
#65Earlier quoted context omitted.
Long after you've migrated from your current favorite IDE twice over, we'll still be using emacs. Long after whatever company sponsoring development of your current favorite IDE enshitifies them twice over, we'll still be using emacs. Long after you relearn your IDE workflows twice over, we'll still be using emacs. And emacs keeps evolving and can handle modern development just fine (except for the most garden-walled…
I started using JetBrains IDEA 12 years ago and I'm still using it today. My confidence of it being available 12 years later is high. Yes, if you're talking about a timeframe of ~50 years, use vim and emacs. I just don't care that level of future proof.
There is Jetbrains Fleet already, so we’ll see about that.
Re: Mastering Emacs
#66It's crazy that here in 2023, Emacs is still the absolute beast when it comes to developer productivity. I had a colleague review one of my workflows the other week and after a minute or so he said "Whoa, I would have been in 5 different tools by now". If you're not into Emacs, I suggest you give it a whirl. For most development, nothing else will get you close to the joy and productivity that a well configured Emacs…
^ with the caveat that a well-configured emacs requires a well-configured emacs, often leading to an infinite loop.
These days though you can offload that to a configuration distribution like Spacemacs, Prelude, or Doom Emacs.
Re: Mastering Emacs
#67Earlier quoted context omitted.
Magit is probably the easiest one for casual devs to appreciate. "M-x magit" get a nice list of the status of the files in the current branch. After you mark which ones you want to keep by moving up and down pressing s(tage) u(nstage) you just press "c c" and write your commit message. Then you press P and your git repo is up to date. At a previous job the head engineer flagged the number of commits I was making as a…
> "M-x magit" get a nice list of the status of the files in the current branch. Except it will randomly split your frame and show up in a seemingly arbitrary location - often obscuring what you're working on. I find the whole layout system in Emacs completely chaotic. I guess it comes with the flexibility (VS a fixed system like most Ides) nor do I have any particular solution in mind I'm curious if anyone has tamed…
For magit, I like having it display full screen (deleting other windows), and then on quitting restore to the windows/splits I had before:
(setq magit-display-buffer-function 'magit-display-buffer-fullframe-status-topleft-v1)
(setq magit-bury-buffer-function 'magit-restore-window-configuration)
Re: Mastering Emacs
#68It's crazy that here in 2023, Emacs is still the absolute beast when it comes to developer productivity. I had a colleague review one of my workflows the other week and after a minute or so he said "Whoa, I would have been in 5 different tools by now". If you're not into Emacs, I suggest you give it a whirl. For most development, nothing else will get you close to the joy and productivity that a well configured Emacs…
can you give an example of such workflow?
- Open a jira request backport in https://github.com/ahungry/org-jira
- Check to see that there isnt an MR outstanding bysomeone else ( using https://github.com/isamert/lab.el )
- (Optional) Cherry pick the commit from another stream where it may be fixed (magit-cherry-pick)
- Often massage the code (emacs cedet)
- Commit the code (magit)
- Submit a build (local built in code, elisp calling a local binary)
- Tag the build as the correct type (magit)
- Update the jira status (org-jira again)
- Wait for testing to complete, watch (eww)
- Email the requester on test results (wanderlust)
I also use:
- Some slack client for emacs (i dont remember the name)
- slime connected to nyxt brower so that I can automate some of the garbage that requires javascript.
Re: Mastering Emacs
#69Earlier quoted context omitted.
Literally changing the editor code, to do whatever you want. Emacs is a lisp (elisp) environment mostly with a small C based core for performance sensitive primitives. But the user code is at the same "level" as the Emacs core code. This is very different from most extensible editors, where extensions are sandboxed and have a limited, controlled API to the core editor, which is kept separate. This makes Emacs very "m…
> small C based core Count before you post; Emacs now boasts over 300,000 lines of C. "Encompassing Massive Amount of C Source"
Ok, I should have said relatively, or even better "subjectively", small C source base.
The C base supports many platforms and variants, so only a part of it is used in a running Emacs instance. And to the 1+M lines of elisp one typically had many more extension packages. That's the the "relative".
In practice, when I want to change things I don't hit the C layer. Anytime I had to introspect Emacs to change something I was firmly in the lisp world. I don't remember having been limited by something being at the C level, which are things that cannot be changed dynamically. This is really what I meant: in practice to change Emacs the C level (although big in the absolute, and definitely complex) doesn't show up much and hasn't been a limitation at least to me.
Re: Mastering Emacs
#70I don't much about gr[a|e]ybeards or being old, but emacs is legendary, still use it along side my main ide.
Tempted by the 29% discount on the book, Mastering Emacs is a well-polished emacs blog