[HN Gopher] The benefits of everything being a buffer in Emacs
___________________________________________________________________
The benefits of everything being a buffer in Emacs
Author : mbork_pl
Score : 257 points
Date : 2023-01-30 15:31 UTC (7 hours ago)
(HTM) web link (mbork.pl)
(TXT) w3m dump (mbork.pl)
| Lapsa wrote:
| hoped to be impressed. better luck next time
| billforsternz wrote:
| Jef Raskin, one of the people who conceived the Macintosh at
| Apple, spent decades advocating user interface ideas that didn't
| (yet?) reach a wide audience. I recall he wanted the user to be
| able to manipulate and interact with the filesystem in the same
| way as everything else, including spell check and correction.
| This Emacs user manages to do that with filenames within Emacs
| although it seems a little clunky.
| luispauloml wrote:
| Reminds me of "Episode 16: dired" of Emacs Rocks:
| https://emacsrocks.com/e16.html
| mjw1007 wrote:
| Yes, this sort of consistency is very valuable.
|
| It's far too common that the interface an IDE gives you for
| something like adding a watchpoint is "type an expression into
| this small area in a dialog box, using a restricted subset of my
| text-editing features".
|
| I sometimes think the main attraction of print-style debugging is
| that it doesn't do that to you.
| xenodium wrote:
| The emacs rocks episode on multiple cursors does a great job
| showing the power of everything in the buffer. It's well worth
| watching until the end, it's got a wonderful finale
| https://emacsrocks.com/e13.html
|
| ps. I write the ocasional emacs post at https://xenodium.com
| AiAi wrote:
| I remember this video being a great motivation for learning
| Emacs, the `multiple-cursors` package is awesome.
|
| Thanks for sharing your content too!
| xenodium wrote:
| Nice to hear. For me also! it's my all-time favourite from
| emacsrocks.
| DonHopkins wrote:
| Meanwhile, in an alternate universe:
|
| https://www.donhopkins.com/home/ties/scans/WhatIsEmacs.pdf
| fithisux wrote:
| I wish I could learn using Emacs. With Vi I make already baby
| steps.
| hprotagonist wrote:
| i absolutely love wdired. it's magic.
|
| for extra fun, it combines well with multiple-cursors or visual-
| regexp-steroids, at which point bulk renaming is basically a
| game.
| marco_craveiro wrote:
| I also love wgrep. [1]
|
| [1] https://melpa.org/#/wgrep
| hprotagonist wrote:
| and rg.el, which is that UX for ripgrep.
| stevenhuang wrote:
| dam, where's vim's equivalent for this??
|
| whenever I get into netrw I always have to lookup its special
| bindings to create/rename. I'm jealous :P
| amadeuspagel wrote:
| Yes I know of another OS allowing this: The browser. If I rename
| a file in google drive it's just an input field, and spellcheck
| works there like in any other input field.
| kleiba wrote:
| Does it suggest the correct spelling, or just mark a misspelled
| word?
| textread wrote:
| "It is better to have 100 functions that operate on one data
| structure than to have 10 functions that operate on 10 data
| structures" - SICP <3
| xyzwave wrote:
| I'm guessing SICP took that from Alan J. Perlis, considering he
| wrote the foreword.
|
| http://www.cs.yale.edu/homes/perlis-alan/quotes.html
| meonmyphone wrote:
| I remember when I discovered this feature, I found it so cool!
| Emacs always surprises me with something like that.
| butterisgood wrote:
| Plan 9 makes it easy to search your terminal buffer history (it's
| in /dev/text) (Ok I shouldn't call it a terminal... it's a rio
| window with a shell in it... it's not a terminal)
|
| Acme does similar things letting you manipulate the tag line, or
| body of a given window.
|
| "Everything is a file" can be a nice interface even at the
| widget/application level.
|
| "Everything is a buffer" in Emacs likely enjoys the same benefits
| (and predates Plan 9 and Acme)
| TacticalCoder wrote:
| Speaking of spellchecking... As devs we tend to use lots of weird
| words and acronyms and they're not, by default, in the
| spellchecker that Emacs (or other editors) do use ( _aspell_ in
| my case). You can add them but then I take it many of us keep
| "adding to the wordlist" the same words (for example, yes, "abs",
| "stdin" and "stdout" are correctly spelled, etc.).
|
| Does anyone know of a good source of "programming vocabulary"
| made to add to spellcheckers?
| teddyh wrote:
| Maybe https://en.wikipedia.org/wiki/Free_On-
| line_Dictionary_of_Com...
| TacticalCoder wrote:
| Thanks, I just checked Foldoc: there's definitely quite some
| stuff in there but then I tried terms like "Clojure" and
| "iptables" (which aren't recent by any means) and they're
| apparently not in that dictionary but it's a start, I'll dig
| a bit more.
| abudabi123 wrote:
| The Unicode has a Unihan_Readings.txt file that can be
| transformed into a readings-table for Emacs to help you
| accelerate your learning the character definition and key
| sequence for input method. To help your eyesight you can
| configure Emacs to enlarge the East Asia fonts. What I don't know
| how is to append to the "chinese-ctlaub" input method missing key
| sequence for input method.
|
| For example, Huan , code point #x96c8, the chinese-ctlaub input
| sequence is missing. I'd like to update chinese-ctlaub with the
| reading "woon4".
|
| See https://humanum.arts.cuhk.edu.hk/Lexis/lexi-
| mf/search.php?wo...
|
| Here is the emacs lisp configuration. 1
| 2 3 4 ;; --- create readings table 5
| 6 ;; #!/bin/sh 7 ;;
| M='path_to/unidata/Unihan_Readings.awk' 8 ;;
| X='path_to/unidata/Unihan_Readings.txt' 9 ;; Y='./uni-
| unihan-readings.el' 10 ;; awk -f "$M" "$X" > "$Y"
| 11 12 13 ;; --- readings table to load
| 14 15 ;; (defvar readings-table 16 ;; (make-
| char-table 'readings-table nil) 17 ;; "Char table of
| definitions for East Asian characters.") 18 ;; (aset
| readings-table #x340C "a tribe of savages in South China")
| 19 ;; (aset readings-table #x3416 "Du , an old name for India")
| 20 21 ;; --- keybindings to locate definition or key
| sequence 22 23 (load
| "~/lib/emacs/x/Unihan_Readings.el") 24 25 (defun
| x/define-char ()
| 26 (interactive)
| 27 (message "%s" (aref readings-table (following-char))))
| 28 29 (defun xb/quail-show-key ()
| 30 "Always apply quail-show-key to chinese-ctlaub input
| method." 31 (interactive)
| 32 (if (string= current-input-method "chinese-ctlaub")
| 33 (quail-show-key)
| 34 (progn
| 35 (set-input-method "chinese-ctlaub")
| 36 (quail-show-key)
| 37 (toggle-input-method)))) 38 39 (defun
| xxb/quail-show-key ()
| 40 "Always apply quail-show-key to chinese-py-b5 input method."
| 41 (interactive)
| 42 (if (string= current-input-method "chinese-py-b5")
| 43 (quail-show-key)
| 44 (progn
| 45 (set-input-method "chinese-py-b5")
| 46 (quail-show-key)
| 47 (toggle-input-method)))) 48 49 (add-
| hook 'text-mode-hook 50 (lambda () 51
| (define-key text-mode-map (kbd "<f1> <up>") 'x/define-char)
| 52 (define-key text-mode-map (kbd "<f1> <right>") 'xb/quail-
| show-key) 53 (define-key text-
| mode-map (kbd "<f1> <left>") 'xxb/quail-show-key))) 54
| 55 ;; (setq view-mode-hook nil) 56 (add-hook 'view-mode-
| hook 57 (lambda () 58 (define-key view-
| mode-map "w" 'x/define-char) 59
| (define-key view-mode-map "a" 'xxb/quail-show-key) 60
| (define-key view-mode-map "d" 'xb/quail-show-key))) 61
| 62 (dolist (charset '(kana han symbol cjk-misc bopomofo))
| 63 (set-fontset-font
| 64 "fontset-default"
| 65 charset (font-spec :family "BabelStone Han" :size 28)))
| anschwa wrote:
| Yes! wdired and wgrep are really fun.
|
| It's amazing how Emacs utilizes buffers to offer a very powerful
| and consistent user interface.
|
| I think some other compelling examples are compilation-mode and
| magit.
| a_e_k wrote:
| And `e` in occur to go into the very similar occur-edit-mode
| (which also works in multi-occur to make changes across
| multiple buffers).
| anschwa wrote:
| Wow! Occur is the gift that keeps on giving. That's great!
| seanw444 wrote:
| For me it's not the "unusual synergy" between its applications
| that's handy. I rarely have a situation that is significantly
| faster than it would be in any other editing environment. What
| makes it amazing to me is the uniformity of it. Everything
| operates the same, and the keybinds apply everywhere that they're
| supposed to. There are many programs that are not that way, and
| it's kind of jarring.
|
| Also, every buffer is a blender of modes. Want a new feature or
| some handy functionality? Activate a mode.
|
| My only argument against Emacs used to be its sluggishness, but
| that's no longer a thing with native compilation. So now I'm
| pretty sure Emacs has spoiled me, and I'll never be able to enjoy
| another text editor again.
| theonething wrote:
| > I'm pretty sure Emacs has spoiled me
|
| Comments like this make a long time Vim lover like me very
| curious, but I guess not curious enough to try it. Maybe one
| day.
|
| What both Emacs and Vim have in common is an intimidating
| learning curve. You can't just dip your toe in. You gotta jump
| in head first, sink for awhile and then hopefully learn to
| swim. Only then will you know if you like it.
| weaksauce wrote:
| you should install doom emacs. it has some vim stuff baked
| into it and you also get the absolutely awesome git ui that I
| can't stress enough is the best piece of software written in
| a long time. sounds like hyperbole but it's seriously so well
| made.
|
| doom emacs. press spacebar to get a menu of things you can do
| and you also get a bunch of vim stuff for free. I don't use
| emacs as a daily driver but I still use it exclusively for
| the magit mode for git.
|
| a caveat that you should be aware of is that you do need to
| learn a bit about emacs. what's a frame/buffer and how to
| kill them but that's not _too_ bad.
| spamizbad wrote:
| FWIW vim was my first "serious" editor and I switched to Doom
| Emacs (which defaults vi keybindings) and couldn't be
| happier. Although tbh if I didn't have vim muscle memory I
| probably would've landed on VSCode.
| bo-tato wrote:
| same, and I surprisingly found it quicker to get used to
| doom emacs coming from vim, than it took me to get used to
| a modern neovim setup which I also tried briefly
| fpoling wrote:
| VSCode has vim extensions emulating keybindings similarly
| to Emacs Evil mode.
|
| Although I am not a fun of vim I ended up using one of
| those when I needed to switch between VScode on Mac and
| Windows on a daily basis due to uniformity of keybindings.
| My only wish is for Vim not to use Ctrl key at all. Then
| difference between Mac and PC keyboards will not affect
| muscle memory at all.
| weaksauce wrote:
| vscode has a neovim extension you can use that shells out
| to an actual vim for normal mode. it's better than the
| emulation one and it's quite fast.
| nequo wrote:
| > What both Emacs and Vim have in common is an intimidating
| learning curve. You can't just dip your toe in.
|
| Another thing that Emacs and Vim have in common is Vim
| keybindings.[1] You can pick Emacs keybindings up at your own
| pace. From one vimmer to another, if you want to try out
| Emacs, I highly recommend doing it with Evil.
|
| [1] https://github.com/emacs-evil/evil
| nocman wrote:
| I second that recommendation.
|
| If you have many years of experience with vim, evil-mode
| allows you to keep a lot of that and add good stuff from
| emacs.
| kneebonian wrote:
| I was a long time vim only user, that lived and breathed in
| the terminal. Then I found Doom Emacs, and it gave me
| everything I never knew I wanted or needed. I'd highly
| recommend giving doom emacs a try. There is also a great
| series of videos on how to use Doom Emacs on youtube.
| theonething wrote:
| Thanks! Do you or any other emacs users contend with "emacs
| pinky"? I'm prone to typing related wrist pain and have to
| be proactive about avoiding it.
| tmtvl wrote:
| I have used Emacs for around 5 years now (about as long
| as I used Vim) and I find the Emacs keybindings more
| ergonomical. Though that might just be because I have
| long and agile fingers.
| ntonauta wrote:
| Yup. Have been using emacs for a couple of years.
|
| Started with a vanilla config and remapped caps to ctrl.
| After a while I got emacs pinky, so I decided to switch
| to spacemacs and vim key bindings. I tried doom-emacs and
| a couple of other "emacs-distros", but I kept coming back
| to spacemacs.
|
| The combination of 'evil' together and chords, like
| pressing 'fd' or 'jk' in short succession working as an
| escape key made me rely a whole lot less on the pinky.
|
| A while ago I went all in on rolling my own config, now
| that I know how I want my environment. Next step for me
| will be learning to type on a keyboard with a thumb
| cluster to rely even less on the pinky.
|
| Sometimes I have doubts. I wonder if I am doing this all
| wrong? Maybe a step backwards would be better - just use
| gedit or acme and a mouse? Unfortunately, I think I am
| too far down the rabbit hole to look back up now.
| kneebonian wrote:
| I don't know for sure what the emacs pinky is but one of
| the things doom does is maps the ctrl key to space bar, I
| find myself rarely having to leave home row now.
| kfajdsl wrote:
| The solution to that is to use evil mode, which is a very
| good Vim emulation layer for Emacs. Doom Emacs comes with
| it enabled by default.
| drums8787 wrote:
| 100% agree re: Doom Emacs. Evil mode user and no issues
| with emacs pinky ;-). It's a perfect match. No concerns
| about performance either, start my emacs in the morning
| and close it at the end of the day.
|
| For quick command line things or remote tasks I still use
| Vim. I know, I know, emacs does all that also.
| michaelhoffman wrote:
| I use a Kinesis Advantage2 keyboard that has Ctrl, Alt
| (Meta for Emacs), and Win at the space bar. Some
| ergonomic setup like this is going to work much better
| than the usual suggestion of remapping CapsLock to Ctrl.
| celrod wrote:
| I second the suggestion of getting ergonomic keyboards
| with thumb clusters.
|
| I also have the Kinesis advantage 2, and am also a fan of
| the convex keys. I also ordered a Kinesis 360 several
| months ago, but have not received it yet.
| outworlder wrote:
| > What both Emacs and Vim have in common is an intimidating
| learning curve. You can't just dip your toe in.
|
| You kinda can, these days.
|
| One of the main issues is that Emacs is, out of the box, the
| most complete toolbox you'll ever see, while at the same time
| being very incomplete. You have an email client, spreadsheet,
| unit converter, ASCII drawing, debugger, file explorer and so
| on and so forth. Meanwhile, you open a Python file and you
| are lacking a bunch of stuff that the likes of VSCode have
| out of the box.
|
| So the solution is to customize, and that takes an inordinate
| amount of time.
|
| Thankfully, some other people have solved this for us:
|
| https://www.spacemacs.org/
|
| Spacemacs has VI commands by default - and I don't mean just
| the simplest keybindings like some VI emulators do, it's
| using evil-mode and it's pretty good. It can also be used in
| 'holy' mode (Emacs keybindings).
|
| There's also(the one I use):
|
| https://github.com/doomemacs/doomemacs
|
| Either of these will get you a much more modern Emacs
| experience out of the box. You may need to add packages (it
| wouldn't be feasible to add all packages that everyone could
| possibly want), but they make it easy. Even though Emacs now
| comes with a package manager, it doesn't have any opinion on
| how you configure things. Both Spacemacs and Doom Emacs are
| opinionated, and that's a good thing.
|
| Sure, you still need to learn concepts and keybindings.
| Thankfully, there's no shortage of tutorials, and Emacs own
| built-in documentation is very good. It also has a built-in
| tutorial, which is how I learned.
| pdimitar wrote:
| Spacemacs is slow as molasses on macOS and yes I have the
| latest Emacs.
|
| It became so bad I switched to a Doom derivative
| (CentaurEmacs) and while it did improve the speed, it
| merely reduced it from "almost impossible to work with" to
| "noticeably and annoyingly laggy fairly often".
|
| I gave up on Emacs after trying to make it work for a
| loooong time. Carefully and slowly making my way through
| NeoVim in the last 6 or so months now, and it's much easier
| to work with and configure, not to mention 99.9% of
| everything is _instant_ (the only time it lagged was
| opening a source file of 1.7M size and I suspect the
| slowness came from the LSP server and not NeoVim itself).
|
| Emacs seems to be carried by nostalgia from folks that love
| to tinker with their tools more than they like to actually
| get any job done. A bit of a toxic statement, surely, but
| I'm pretty salty still and I haven't seen any objective
| evidence to make me look at Emacs and its fans more
| charitably. For anything and everything the answer always
| is "hack it for the 6328th time to make it even more your
| own!"
|
| No thanks. I actually have a job to do.
| lycopodiopsida wrote:
| While I have big respect for neovim, it's performance on
| big files is actually worse than emacs. I've submitted a
| bug on that upstream - it gets stuck with disabled TS,
| LSP, highlighting where vim and emacs chew through
| without any issues. Emacs has its problems but is
| actually OK performance-wise, if you avoid the obvious
| (long lines) and less obvious (custom modelines, fancy
| pseudo-tabs, etc) pitfalls. Thing is, emacs is constantly
| improving - 28 is faster than 27, 29 will be again faster
| and solve the problem with long lines.
|
| > Carefully and slowly making my way through NeoVim in
| the last 6 or so months now
|
| Emacs has also a ton of stuff included, so that you could
| carefully and slowly make your way through emacs instead
| of jumping through distros and complaining. In the end, I
| am pretty sure that you will not be able to freely
| configure and alter and neovim distribution, such as
| LazyVim or AstroVim - they have a rather complex
| structure.
|
| > and it's much easier to work with and configure
|
| No, it is not - it has poor discoverability, you have to
| reload it on changing the config file. Configuring emacs
| is a breeze - you can eval blocks of code, check, eval
| again - until it sticks. Every function is can be called
| and inspected. Oh, and have you tried to debug your
| config code in lua? Tell me how it went.
|
| > Emacs seems to be carried by nostalgia
|
| Emacs is carried by the fact that it is the only editor
| alive almost completely written and documented in it's
| extension language.
|
| > No thanks. I actually have a job to do.
|
| Of course you do - why else would you jump between emacs
| and neovim :)
| pdimitar wrote:
| Your snark doesn't make my Emacs run faster but if it
| makes you feel better, do continue. -\\_(tsu)_/-
|
| I switched editors because my job was suffering because
| of impossibly slow Emacs, not because I don't value my
| free time -- of which Emacs wasted plenty. Chose the
| lesser evil. Not a hard concept to grasp, I hope.
|
| Shame that you felt attacked and figured you have to be
| nasty but you helped with exactly zero of my concerns, in
| practical terms.
|
| NeoVim + LunarVim worked for me out of the box. The
| tweaks I did were entirely cosmetic. That's valuable. So
| far I spent exactly 5 minutes on functionality in it --
| namely TS and LSP installs.
|
| Oh and if I have to debug my editor then the battle is
| lost anyway. Not sure why you put any value on that at
| all; if anything, it's a negative value.
| shadowofneptune wrote:
| This was not my experience with Emacs, oddly enough. I
| started using it because it was the only editor that both
| supported a terminal and had a top bar. Like a windows
| program, pressing F10 gets you a File, Options, etc. menu
| that helped me get through that first session. Emacs (and
| other Vi's, I should note) has made a nod towards
| accessibility that Vim has not.
| u801e wrote:
| gvim has a menu bar by default. I believe it's possible to
| enable it in the terminal assuming vim has been compiled
| with the necessary options.
| w0m wrote:
| As a long-time Vim'er who has had a dalliance with emacs a
| few times before fleeing - I always saw the bar and had no
| idea how to use it. f10. Nice. What always got me was how
| it still* felt sluggish on my intel 32gb rMBP.
| jacobsenscott wrote:
| Performance has improved _a lot_. I 'm on version 28 with
| native compilation enabled and I just opened a 12599 line
| yaml file and there is no lag. In the prior version the
| file was pretty much uneditable in emacs. There are
| probably still cases where vim outperforms emacs, but for
| any reasonably sized file it should be good.
| pdimitar wrote:
| Every single time I press M-x my Emacs lags.
|
| I use Emacs 29 RC with JIT compilation. Seldom any
| difference at all.
|
| Granted I use a Doom derivative that shows a popup where
| you see command auto-completion but in 2023 this is
| absolutely inexcusable, if not laughable.
| jacobsenscott wrote:
| It is likely the fault of an extension or
| misconfiguration. It is instant for me, with ivy
| typeahead/fuzzy match magic. You would need to start
| uninstalling packages until you find the offender. I
| don't know if that is easy with something like doom since
| a ton is stuff is pre-installed.
| pdimitar wrote:
| Exactly the problem. I lost all will to tinker with it
| (and I've done that a lot in the past).
|
| If it can't work reasonably well out of the box then it
| is a failure.
|
| I'm already eating down votes in another comment which
| ironically only cements my decision to move away from
| Emacs.
| nequo wrote:
| >> Granted I use a Doom derivative that shows a popup
|
| > If it can't work reasonably well out of the box then it
| is a failure.
|
| It is not out of the box though, is it? It sounds like
| the code that shows you the popup might not ship with
| stock Emacs.
|
| Do you get the lag if you start Emacs with `emacs -Q`? Do
| you get it with Doom proper?
| pdimitar wrote:
| Switching Emacs distro sounds like doing a favor to a
| friend that kept stealing my money but I'll grant you
| that yes, I'm not using stock Doom and that might be the
| problem.
|
| Can't promise I'll try again ever. I tinkered a good
| amount and lost faith. Nothing should need that much time
| and effort spent to have basic stuff working acceptably.
| nequo wrote:
| That's fair. The most important thing is that you get
| your work done.
| agumonkey wrote:
| There's probably some room for improvements. People say
| lispmachines were still more interesting down and up compared
| to emacs.
|
| A few things I'd like to have is keymap collisions handling,
| but as anything in emacs, i can always code it with enough time
| :)
| Torwald wrote:
| > What makes it amazing to me is the uniformity of it.
| Everything operates the same, and the keybinds apply everywhere
| that they're supposed to.
|
| This is the best summary of what the original Macintosh was all
| about and why Macintsoh enthusiasts back then loved System 6
| and upwards.
|
| (They didn't call them keybindings though. Keyboard shortcuts.
| (Ironicly a longer word. (yes)))
| ramin_hal9001 wrote:
| Yes, and this really showed with applications like Hypercard
| where you could build apps making use of the operating
| system's widget toolkit. The old Mac OS was based on the
| Xerox Star, which was in turn a commercial implementation of
| Douglas Engelbart's original GUI computer NLS. The Xerox Star
| supported both Lisp and Smalltalk development environments.
|
| Unfortunately, Steve Jobs didn't care about Lisp or
| Smalltalk, and he hated Hypercard, and he took the company's
| product lines in a consumerist direction, which is why Apple
| has "app stores" nowadays instead of a thriving ecosystem of
| tiny Lisp programs that compose well with each other.
| Synaesthesia wrote:
| I think what we ought to blame rather than Jobs is the
| logic of capitalism, maximum profits all the time, even at
| the cost of other things.
| hindenburg wrote:
| Please, elucidate. I'd love to hear about all the
| superior programming environments developed in non-
| capitalist economies.
| seanw444 wrote:
| To be fair, FOSS is pretty much the definition of
| socialism. Donations are pretty much the only way money
| is made directly off the software itself. Running an
| _instance_ of the software, if it 's a server for
| example, is a slightly different story. Everyone
| contributes of their own volition and interest.
|
| I'm not a fan of government-enforced socialism or
| communism. But if you can get enough people together to
| willingly participate independently, I'm chill with it.
| And FOSS software is an example of it working out
| alright.
| pasc1878 wrote:
| If Jobs did not care a ot Smalltalk the why was Next based
| on Objective C which is basically Smalltalk grafted onto C.
|
| I suspect the reason that the Lisa was not Lisp or
| Smalltalk based is due to speed and cost of memory.
| lispm wrote:
| > The Xerox Star supported both Lisp and Smalltalk
| development environments.
|
| There was a common hardware. It ran Star, Lisp or Smalltalk
| - but not at the same time. Each were whole operating
| systems.
| yamtaddle wrote:
| Connecting the two, having emacs-like text navigation
| shortcuts work in any halfway-native text input or field, on
| Mac, now feels so right to me that any platform without that
| feature seems flat-out _wrong_.
| spudlyo wrote:
| It's pretty cool. It's eve cooler in applications with
| working[0] Cocoa text widgets, where you can do things like
| M-u and M-l for upcase/downcase word, transpose, and even
| an Emacs-like kill-ring[1].
|
| [0]: Unfortunately in most third party web browsers and
| Electron apps (Chrome, Firefox, Slack, etc) most of these
| shortcuts don't work for some reason.
|
| [1]: https://developer.apple.com/library/archive/documentat
| ion/Co...
| celrod wrote:
| Regarding the uniformity...
|
| I started using tiling window managers a few years ago. These
| took a little configuring. I always had one monitor with an
| emacs session, and then another with an internet browser, and a
| terminal running tmux, which again needed a bit of configuring.
|
| It took me wayyy too long to finally try EXWM[0]. Suddenly, I
| have that uniformity and consistent experience everywhere, and
| only a single configuration language to learn and use to get
| things how I like them.
|
| If you like both emacs and tiling window managers, I strongly
| recommend it. My only major gripe is that the single
| threadedness can be bothersome on occasion, when certain
| commands can render it unresponsive. But it is still well worth
| it for me.
|
| [0] https://github.com/ch11ng/exwm
| barbariangrunge wrote:
| What does eMacs have to offer a rider or other jetbrains ide
| coder? Somebody who is used to some really handy refactoring,
| autocomplete, and auto formatting tools for very large code
| bases, Eg, like an unreal engine game project (which even
| visual studio can't really keep up with)
| patrec wrote:
| Practically speaking, probably nothing that would make up
| for the loss in functionality. The main practical reasons
| might be slightly better git support (magit) and the
| ability to run in a remote terminal -- as well as being
| generally more lightweight. But for that alone, vim might
| be a better choice.
|
| Conceptually speaking, it remains (despite various flaws
| and warts) one of very, very few well thought out pieces of
| non-trivial software. For decades, emacs was pretty much
| the only program with a search function that didn't suck.
| Emacs is still the only program I know pf with a decent,
| branching, undo system and proper, non-alzheimered copy-
| and-paste. Vim has branching undo system, and a clipboard
| that can hold more than one item, but both work poorly
| (e.g. in emacs it's ergonomic to cycle through clipboard
| history or pull a clipboard item by textual content, in vim
| it really isn't). Emacs is also remains far more deeply
| extensible and self documenting than anything else I can
| think of.
| Kamq wrote:
| I'm more of a vim user that occasionally dabbles in emacs
| (mostly for lisp).
|
| But... everything.
|
| > Somebody who is used to some really handy refactoring,
| autocomplete, and auto formatting tools
|
| Those aren't really differentiators anymore. They're
| available everywhere (even vim/emacs). LSPs have made the
| choice of thing for editing pretty irrelevant.
|
| There's also the debugger adapter protocol, which has
| worked surprisingly well. Though I do still miss intellij's
| conditional breakpoints occasionally, it's rare that that's
| necessary, but they're surprisingly useful when you need
| them.
|
| So, with emacs, you'd have everything you listed, and
| everything else you hear people talk about with emacs.
| Emacs will pretty much do anything. At the cost of higher
| initial set up effort, and config maintenance.
| ticviking wrote:
| The single threadedness is the thing keeping me from trying
| it. Emacs with per-buffer threading would be pretty much
| golden, but I understand the work to get from here to there
| may actually be nearly impossible.
| volforix wrote:
| After using Emacs for years (huge fan!) I finally realized that
| Emacs hinders my productivity instead of improving it. Thus I
| moved to other tools, sadly, and never looked back.
|
| In this case I would use Text Extractor (part of M$ PowerToys)
| and Google Translate.
| nonrandomstring wrote:
| For me the consistency of Emacs lies not only in its user
| interface but in stable longevity. Productivity is important,
| yes, but is only one dimension in complex decision space of
| software. What will you use next year when Microsoft throws its
| powertoys out of the pram and Google makes translate obsolete?
| Emacs is almost 50 years old, and I hope to be using it in
| another 50.
| volforix wrote:
| Good point. I'll switch back to Emacs as soon as it's best
| tool for my task again.
| mbork_pl wrote:
| This is a cool anecdote about something that happened to me last
| week. I'd love to hear similar anecdotes where people who use
| Emacs (or Vim, or other software sophisticated enough) were able
| to combine its features in unexpected ways.
| a_e_k wrote:
| Changing buffers works just fine in keyboard macros.
|
| So sometimes I'll prepare one buffer with a list of lines that
| are basically meant to provide input to a macro for editing
| another buffer and have the macro constantly jump back and
| forth between them. (E.g., move to a spot in the "edit" buffer,
| jump over to the "input" buffer, kill the next line, jump back
| to the "edit", yank that line, etc.)
| wging wrote:
| One lovely little thing: since everything is a buffer,
| autocomplete has more to work with. Specifically I'm thinking
| of hippie-expand's `try-expand-dabbrev-all-buffers`, which just
| uses all buffers as sources for 'expansions' for what's
| currently written. So you type "thi" -> M-/, and because
| another buffer has "thing-you-want", it is able to complete
| what you wrote out to "thing-you-want".
|
| This is straightforward when you just think of buffers as being
| source files in your IDE, but it's not limited to that - you
| can also complete from a dired buffer, or your compiler output
| buffer, or your REPL. So you can get a filename to expand, even
| though no source code file actually contains that filename. If
| instead of dired and compile-mode you were using a separate
| file manager, and a separate terminal window to compile, you'd
| have text in three separate programs and no expectation that
| the text editor in your IDE would be able to see the other two.
| convolvatron wrote:
| C-x r k C-x b *scr C-I C-x r y M-< (+ M-> ) C-j
| mxmdkdop wrote:
| [flagged]
| kriyative wrote:
| I don't think they were trying to be. Broadly, those are
| the key bindings to copy a column of characters (presumably
| numbers) paste them into the ` _scratch_ ` buffer and sum
| them, give or take some assumptions
| garethrees wrote:
| Another way to sum a column of numbers uses calc:
| M-x calc-grab-rectangle RET V R +
| jgrahamc wrote:
| "Kill" text in a "rectangle" and save its contents
| C-x r k
|
| Switch to the scratch buffer (think there's a missing RET at
| the end) C-x b *scr C-I
|
| "Yank" the "rectangle" saved in the first command
| C-x r y
|
| Moves to the start of the buffer and sets a "mark"
| M-<
|
| Literals that are entered at the start of the buffer
| (+
|
| Move to the end of the buffer M->
|
| Another literal )
|
| Executes the buffer (or at least the LISP expression at the
| cursor). Note the _scratch_ buffer allows you to type
| arbitrary LISP stuff and execute it with C-j.
| C-j
|
| So, suppose the initial buffer contained 1
| 1 2 3
|
| Then the scratch buffer would get turned into
| (+1 1 2 3 )
|
| And when executed this would add the list of numbers and look
| like this: (+ 1 1 2
| 3) 7
| wging wrote:
| > Switch to the scratch buffer (think there's a missing RET
| at the end)
|
| In vanilla emacs you need a RET, but I bet that like many
| people, OP's using a mechanism that will just select the
| matching item if there's a unique match, rather than the
| built-in buffer selection mechanism.
|
| I use ido (with flx-ido for fuzzy completions), and it
| works for me as stated: C-i in the minibuffer runs `ido-
| complete`, which selects the unique completion if there's
| only one. (By default, that is, this is emacs and so _of
| course_ there 's a variable `ido-confirm-unique-completion`
| that you can set to customize this behavior.)
| why-el wrote:
| Oh yeah, it gets even more interesting in large refactors, say an
| involved rename that requires you check the context before you do
| so (like not just global search and replace). I do a search, this
| opens a buffer with all results, with file name, position, all
| that, and Emacs can allow you to "peek" into the file without
| even leaving the search buffer focus (i.e use a split screen).
| Then, use https://github.com/mhayashi1120/Emacs-wgrep to do the
| magic of in-place editing.
| shadowofneptune wrote:
| With the Emacs shell, this goes a step further. Emacs functions
| and /bin/ commands are put in the same namespace. '+' is now a
| command that can be run at the command line, while 'grep' can
| have its output redirected to a buffer instead of a file (Sadly
| no input redirection). This, all while itself being a buffer.
|
| It doesn't work well with full-screen programs, or ones that use
| escape sequences. Sadly there's no away around that besides
| keeping a list of those programs. Unix programs have never needed
| to say to the OS "I am a fullscreen program" due to how little a
| traditional shell actually interacts with a programs.
|
| Emacs is my login shell now. I feel however that other, more pure
| attempts at this like the Canon Cat and Plan 9's text editor were
| smothered by the Mac/Windows interface of GUI programs which
| rarely interact. A more evolved shell never had the chance to
| arise.
| jrockway wrote:
| > It doesn't work well with full-screen programs
|
| eshell, at least in the past, is quick to involve ansi-term
| (M-x ansi-term) when launching a program that requires it. I
| recall being able to run Emacs inside of Emacs circa 2008, not
| sure if things have changed since then.
| _emacsomancer_ wrote:
| There's also eshell-vterm[1], which allows eshell to use
| vterm for visual commands.
|
| [1]: https://github.com/iostapyshyn/eshell-vterm
| celrod wrote:
| I haven't tried eat (Emulate A Terminal) yet, but I've been
| meaning to: https://codeberg.org/akib/emacs-eat
|
| Eat is an terminal emulator supporting eshell, written in
| elisp. It also supports full screen programs. It claims
| vterm is 1.5x faster, though, but that eat doesn't flicker
| while vterm does.
|
| I haven't noticed vterm flickering, or maybe I just don't
| notice?
| _emacsomancer_ wrote:
| I've tried out eat a bit, it does also have something
| similar to eshell-vterm (for visual commands), but,
| obviously, in eat. My limited experience is that: (a)
| vterm doesn't feel like it flickers to me; (b) vterm
| still also feels faster than eat.
| celrod wrote:
| Thanks, I'll give eshell-vterm a try.
| shadowofneptune wrote:
| That's what I meant by keeping a list, didn't expand on that
| much. It's something that needs to be configured per-program,
| which is an issue.
| akira2501 wrote:
| I've mostly ditched tmux for emacs shells. I wrote a quick
| script that gives me tmux like shortcuts for tagging and
| switching to different buffers. This allows me to start several
| shells and move between them with simple "Alt-Fn" shortcuts.
| The split screen modes and copy paste are so powerful I find
| myself opening emacs just to use the shells even when I don't
| have any need for a file editing buffer.
| soamv wrote:
| wow, I've used emacs for a gazillion years and never thought
| to replace screen/tmux with it. I think I'll start now,
| thanks to your comment!
| ramin_hal9001 wrote:
| I still use Screen/TMux to run servers, or any process that
| I need to keep running for a long time and still maintain
| control over it's STDIN/STDOUT.
|
| But now that I use Emacs "shell-mode" I hardly ever use
| Screen/TMux anymore. I don't even use Bash anymore, I
| switch my default shell to Dash, because I don't need
| Bash's tab-complation in Shell-mode. I use Emacs's tab
| completion instead.
| jacobsenscott wrote:
| I run tmux in vterm in emacs rather than multiple vterm
| buffers because as awesome as emacs is it still crashes or
| just becomes unusable with enough uptime. This way I can
| bounce emacs without losing my terminals.
| lelanthran wrote:
| That's quite funny. I've ditched the terminal for vim with
| split screen, for pretty much the same reason that you are
| using emacs - quicker to shift between shells and copy/paste
| become so much more (also, searching command history is not
| intuitive).
|
| Here's my shell script for vimterm.sh: vim
| -c 'call Tmux()'
|
| And here's the relevant function from my .vimrc:
| function! Tmux() vsplit terminal
| set nonumber wincmd j q
| wincmd l terminal set nonumber
| wincmd j q endfun
| u801e wrote:
| I never really set up a function for it, but what I usually
| do is in a new vim instance, I'll run the :term command,
| press ctrl-w o to make it the only window and then run a
| nested vim instance in that term window (typically one
| instance per vim tab). I'll open new terminals by running
| :tab :term.
|
| Basically, I'm using one instance of vim as a session
| manager to run other programs in, including vim itself. You
| can pass ctrl-w to a nested vim instance by pressing
| ctrl-w .
| shadowgovt wrote:
| This was the first tricky bit to wrap my head around when using
| emacs: "Why do they call files 'buffers?' Every other text editor
| just calls them files."
|
| Wrapping one's head around the difference is IMHO the first step
| into grasping why emacs sticks around after all these decades.
| hollerith wrote:
| I do not catch your meaning.
|
| Every text editor I know of makes its edits to an in-memory
| copy of the file. If interactive edit commands operated
| directly on the file, the Save command would make no sense.
|
| Emacs calls the in-memory copy a buffer. (VSCode calls it an
| editor.)
| shadowgovt wrote:
| Most text editors call it "file" or "document," even if it's
| not yet backed by disk.
|
| It's a subtle difference, but I think emacs's decision to
| call them "buffers" (though it makes the editor a space-alien
| by modern standards, that much harder to learn) makes more
| clear that the user should have no expectation that any of
| the buffers _ever_ get backed to long-term storage. Once one
| wraps one 's head around that, a lot of things get much
| easier (including and especially writing document editing
| functions; where most systems would have you store blobs of
| text in string variables, emacs really wants you to pop up
| temporary buffers and manipulate them like any other buffer,
| with the added benefit that if a function fails mid-
| execution, the regular buffer editing tools make it easy to
| inspect the failed state).
| anyfoo wrote:
| The distinction is that buffers are by no means necessarily
| in-memory copies of files. When you start up emacs, you will
| have more buffers active that are not backed by files than
| buffers that are.
| cmrdporcupine wrote:
| The distinction becomes clearer once you start using emacs
| buffers for things other than text editing; like, say, an IRC
| client or a command shell, or elisp eval.
|
| It is a direct manipulation interface based around
| interacting with text. The buffer is where it happens.
| "Files" or "documents" can be in those buffers. But so can
| textual sessions of many other kinds.
| spudlyo wrote:
| Windows and frames, killing and yanking, point and mark,
| slurping and barfing -- there's a lot of Emacs nomenclature
| that confuses people initially.
| jordigh wrote:
| This is poetry. I almost could fit it to the tune of
| Favourite Things, which coincidentally these thing are. My
| favourite things, I mean.
| vidarh wrote:
| I use my own custom text editor, but came from emacs, and one
| of the best choices I made was to copy that bit.
___________________________________________________________________
(page generated 2023-01-30 23:00 UTC)