[HN Gopher] Unix as a tool forge and how Emacs fits in Unix phil...
___________________________________________________________________
Unix as a tool forge and how Emacs fits in Unix philosophy
Author : ashton314
Score : 73 points
Date : 2022-11-08 18:53 UTC (4 hours ago)
(HTM) web link (lambdaland.org)
(TXT) w3m dump (lambdaland.org)
| namaria wrote:
| I don't think you need to shoehorn every piece of software you
| like into one worldview. It's OK to like two different things.
| Contradiction is a fact of nature when discourse is linear but
| reality is anything but. Unix philosophy was amazing in the 70s,
| modern linuxes are great work environments now, EMACS is super
| cool, vim is a great little piece of text editing beauty. One
| thing is clear tho, Windows users have a severe case of Stockholm
| syndrome.
| pjmlp wrote:
| Emacs is a survivor from the days of Lisp Machines, hardly a
| UNIX.
|
| "Evolution of Emacs Lisp"
|
| https://dl.acm.org/doi/abs/10.1145/3386324
|
| Also the UNIX "philosophy" besides its quote on a book, has been
| hardly a thing on commercial UNIXes.
| whartung wrote:
| The funny thing is that I put vi more in the "UNIX Philosophy"
| camp.
|
| Specifically, as a user of vi, especially with normal vi (vs
| vim), a routine workflow for me is !command some block of text,
| or the entire file to some utility or another.
|
| And the idea here is that with little effort, the entirety of
| the UNIX environment (at least the CLI tools environment) is at
| my beck and call. I've munged gobs of text through most any
| utility imaginable. I've use vi as an interactive pipeline.
| Running data through one sequence, then running it through
| another, or a 3rd. It's like an interactive pipeline debugger
| with undo.
|
| It's not that emacs can not do it, of course it can. You can
| run a region through a shell command as easily as anything.
|
| But, folks don't. Rather they rely on the extensive, emacs
| universe to solve those problems. There's lisp for that. Like
| the Java and JavaScript eco-systems, where "everything" gets
| rewritten into that world, the drive has been to port the
| essential utilities into the whole of emacs, rather than having
| it work with the system surrounding it. There's all sorts of
| good reasons for this, but at the same time, all of those
| routines and such are cut off from "unix". While its
| straightforward to leverage grep, sort, awk, et al from within
| emacs, it's less so the other way around. I'm sure it's
| possible, but it's not trivial.
|
| In a world of composite solution development, a monolith stands
| out because it acts more as an unscalable tower rather than a
| thing to touch for enlightenment.
| anthk wrote:
| nvi, entr, xargs, awk, sed, perl...
| gw98 wrote:
| Completely agree with this.
|
| Unix is centred around composing lots of individual tools
| that do one job well. Emacs is the antithesis of this. It's
| closer to Visual Studio.
|
| Honestly in the 30 years I've been using Unixes I have never
| needed anything but vi/vim with a few lines of configuration,
| mostly to satisfy some of the newer fussier language indent
| requirements (yaml, python). Most of the non trivial data
| processing is done with external tools (sed, grep, awk etc)
| where the knowledge and power is reusable for other tasks
| external to editing things!
|
| Only on Windows have I had to leverage anything more
| complicated.
| agumonkey wrote:
| I think there's strange rotation. Emacs being based on lisp
| is all about composing lots of individual bits. Unix too.
| gw98 wrote:
| Indeed. But it's a nested abstraction.
| jrumbut wrote:
| Exactly, because of bad habits developed elsewhere I
| sometimes find myself puzzling (as an example) "how do I
| remove HTML tags in vim?" rather than "how do I remove HTML
| tags? OK, now do that in vim."
| BlueTemplar wrote:
| Why vi vs vim ? (I have no experience with vi, only vim.)
| shagie wrote:
| vim is the improved version of vi, which is the visual
| interface to ex, which is the extended editor ed... the one
| true editor ( https://www.gnu.org/fun/jokes/ed-msg.txt )
|
| You will not infrequently find vim and vi links to the same
| executable. /usr/bin % ls -l ex vi vim
| lrwxr-xr-x 1 root wheel 3 Aug 24 03:59 ex -> vim
| lrwxr-xr-x 1 root wheel 3 Aug 24 03:59 vi -> vim
| -rwxr-xr-x 1 root wheel 5155568 Aug 24 03:59 vim
|
| The difference between which way you have argv[0] slightly
| changes the functionality... but it's the same thing.
|
| ed remains its own thing. /bin % ls -l ed
| -rwxr-xr-x 1 root wheel 235296 Aug 24 03:59 ed
|
| THE MIGHTY ED HAS SPOKEN!!!
|
| ?
| jrumbut wrote:
| In vim there are a lot of emacs-like plug-ins that
| reimplement functionality found elsewhere.
|
| You can still use the vi style workflow though.
| anthk wrote:
| I was about to say that. Emacs not just the LISP machines.
| Emacs' comes from ITS, an OS praised by RMS, basically the
| anithesis of Unix. Everything was hackable and shareable. No
| perms.
|
| The closest in philosophy may be Guix(SD), but, for that, the
| Unix utilities should be converted into optional tools and make
| Scheme both the command line prompt shell, the configuration
| tool and the API.
| thrown_22 wrote:
| I've ran chsh on top of a (virtual) Guix(SD) installation. It
| was rather nice but is still _not_ a lisp machine:
| https://www.youtube.com/watch?v=o4-YnLpLgtk
| AnimalMuppet wrote:
| > Emacs is a survivor from the days of Lisp Machines, hardly a
| UNIX.
|
| So? Did the author claim otherwise? Not that I could see. Does
| the OS of origin negate any of the author's claims about Emacs?
| No, it doesn't. Emacs on Unix gave the author a tool that fit
| their workflow and their mindset. Who cares what OS it
| originated on?
|
| > Also the UNIX "philosophy" besides its quote on a book, has
| been hardly a thing on commercial UNIXes.
|
| The UNIX philosophy, as quoted by the author, was supported by
| every commercial OS I have ever seen. (They added some other
| stuff, but they all provided the environment where the
| philosophy could play out well.)
| pjmlp wrote:
| Given the architecture of commercial UNIXes, and the plethora
| of options in every command, hardly.
| anthk wrote:
| No. Emacs' a huge REPL with zillions of ELISP modules for
| lots of cases.
|
| Emacs and its grandpa ITS (and Emacs for ITS) are very
| different beasts.
|
| Get SIMH and emulate ITS on it.
| https://gunkies.org/wiki/Installing_ITS_on_SIMH
| ok_dad wrote:
| I use VSCode right now, with lots of little extensions to do
| stuff like lint my code, format my code, color my code, highlight
| TODO and FIXME comments, 3-way merges, debugging with conditional
| breakpoints and watches and stuff, etc.
|
| How do I get started using Emacs, if I wanted to use this
| awesome-sounding tool, while still being friendly to the fact
| that I have to get stuff done and still need the tools I
| mentioned above? (Also, how to have my cake and eat it, too.) I
| am sure the Emacs community has built everything under the sun,
| but is it as easy to setup and easy to find as VSCode?
|
| I really want to know how I can transition from using VSCode to
| Emacs, because I'm starting to realize that VSCode is always
| going to be a "product" of a BigCo and will continue to add anti-
| features, tracking, and other stuff that I don't want. I'm also
| starting to realize that I want to be a bit more strict about my
| open source software usage, and try to support communities rather
| than coprorations.
| gropius wrote:
| Don't forget to check out the MELPA (melpa.org) repository,
| which has a staggering array of packages for Emacs. If people
| do something on computers, chances are someone does it in Emacs
| and there's a package on MELPA to support it.
|
| Also, the road to Emacs proficiency will be a journey, and
| you'll want to think about Emacs as something you'll gradually
| tinker with and tweak to get to a set up and understanding that
| is satisfying. It's not shiny nor whiz-bang by any means, but
| path through the learning curve can be extremely rewarding.
| ok_dad wrote:
| Thanks for that link, very useful for me to be able to find
| that stuff in one place. I want to treat my software
| development more like I do with physical hobbies and start to
| learn to use advanced-yet-powerful tools that are well-made.
| VSCode is perfectly fine, but I see it as something that
| won't last long in one form, constantly changing things for
| the flavor of the year tech.
| vinceguidry wrote:
| I found the ebook Mastering Emacs, and the accompanying blog to
| be extremely useful, even after going through both Spacemacs
| and Doom Emacs. I may go back to a modal workflow in the
| future, but for now I'm embracing Emacs' built-in ways of doing
| things, with a few exceptions.
|
| http://www.masteringemacs.org
|
| You may balk at the $50 pricing, but it gives the most complete
| picture of how Emacs works than anything else.
| vincent-manis wrote:
| To get started with Emacs: (1) install it, either from a
| package repository or from www.gnu.org/software/emacs; (2)
| start it up (3) type Control-H t to run the tutorial. Those new
| to Emacs might prefer to use a customized distribution such as
| Doom Emacs, but the official Emacs system is quite usable.
| Don't expect to become an Emacs Master quickly, but doing these
| 3 steps will get you to the point where you can use Emacs for
| basic text editing. Emacs comes with lots of documentation,
| both on the core system and on the many packages it includes,
| but you can defer reading it until you are comfortable with the
| basics.
|
| The two hurdles you'll need to overcome are: (1) the antique
| terminology, so "window" doesn't mean what you might expect it
| to, and (2) the key bindings, which don't match up with more
| modern systems. (1) is something you just have to get used to,
| while (2) is infinitely flexible. A vi user might prefer Doom
| Emacs or Spacemacs, which come with vi-compatible key-bindings;
| I'm not aware of something similar for the VSCode user. As you
| become more comfortable with Emacs, you will be able to make
| your own key bindings.
| ok_dad wrote:
| Thanks! That actually is what I found in the past, that (1)
| is hard to get through in order to setup an environment with
| the cool tools I want to use, and (2) is hard because I'm
| used to VSCode bindings. I think this time, though, I'm going
| to stage my use of Emacs because you gave me a good idea:
|
| > doing these 3 steps will get you to the point where you can
| use Emacs for _basic text editing_
|
| So, I'm going to replace my use of VSCode for text editing
| with Emacs for a while to start learning how to work with it,
| just not code stuff yet, and I'll replace my keybindings in
| VSCode with Emacs keybindings since VSCode is super easy to
| find extensions for and there happens to be a few "Emacs
| keybinding" extensions.
|
| Thanks for the tips, I also didn't know about `Ctrl+H t` and
| so I'll try that out, too!
|
| I'm actually pretty excited, I've had a ton of issues with
| VSCode updating the way they do things recently causing my
| workflows to get fucked up and have to change. I doubt I'll
| have that issue with Emacs!
| G3rn0ti wrote:
| Before you actually dive into coding in Emacs may I suggest
| to do the following:
|
| 1) Get yourself a copy of https://www.masteringemacs.org/
| and read it. That gives you a very good overview on the
| design philosophy of Emacs and many practical tips.
|
| 2) Explore vanilla Emacs a little bit. Run the built-in
| tutorial. Explore Emacs's customization UI. Play tetris.
|
| 3) Familiarize yourself with how you install Emacs packages
| from ELPA and MELPA. On your first steps you can use Emacs'
| built-in UI. But, ideally, you want to learn "use-
| package.el" as quickly as possible because that will
| simplify your configuration _a lot_.
|
| Coming from VScode you might feel a little bit overwhelmed
| at this point as you will be starting to use a Lisp macro
| routinely (!) to install editor extensions. Check out the
| "Emacs from scratch" series on YouTube for a helpful guide.
|
| 4) What programming languages are you using? For React
| projects you might need to use "webmode.el" which is not
| built-in. Similar situation with Clojure or Rust. If you
| want more convenience, you also might want to take a look
| on "lsp-mode.el" that adds more code introspection
| features. It is not crazily complicated to install and
| setup but definitely not beginner friendly.
|
| 5) Try to identify your most important extensions you are
| using right now in VScode. What are the features you cannot
| live without? Then embark on a google search what the most
| suitable replacements are in Emacs. For example, VSCode's
| "Restclient" extensions is paralleled by Emacs'
| "restclient.el" and it works quite well (if you use it
| together with "restclient-jq.el" that is).
|
| 6) For your dev work flow, checkout Emacs' built-in
| "compile-mode" (C-l) -- you can paste any shell command in
| there that will compile your code, run tests or synchronize
| with a remote dev server (everything that goes inside a
| bash script). Line errors will be clickable in the output
| window and help you jump in the offending code line. It's
| simple and effective. This will make you stop using the
| shell too often.
|
| 7) I recommend installing "which-key.el" which makes Emacs'
| display a cheat sheet of possible keyboard combos upon
| hitting control keys (after some delay). This way you'll
| learn keyboard commands more quickly.
|
| 8) However, don't let anyone tell you what the right way of
| using Emacs is. If you find the mouse menus convenient, by
| all means use them and don't listen to people who turn off
| the menu bar. (I even added a custom menu for Emacs modes I
| happen to use sometimes but not everyday.) Use CUA mode if
| you are used to "C-c C-v". Don't use the terminal version
| of Emacs. Ignore the extremists. However, definitely check
| out "magit.el" for version control.
| gumby wrote:
| The GP gave great advice that, in light of your response,
| I'll augment.
|
| 1 - Sometimes the worst helpers are the enthusiastic fans,
| not just with bands but with software. Most emacs advice
| starts by talking about customization. The GP was smart not
| to: just get comfortable with the model of emacs: a
| modeless editor. c-f goes forward a character, m-f a word.
| In code: c-f forward a character, m-f a symbol, c-m-f a
| structure (depends on the language).
|
| You can always type c-H (^H) at any time for help. It's
| context-sensitive so if you're typing a long command (m-x
| find file) it will show you the completions. If you can't
| remember a command c-H a (apropos) will show you matches.
| etc. All explained when you start with c-H t
|
| All of the stuff above has been true for more than 40
| years. A lot of rough edges have been knocked off over that
| time! Even back then people who claimed that they "couldn't
| do anything with a computer" were writing documents with
| Emacs, even writing macros and such.
|
| For more modern times: you'll find in most programming
| languages, markdown, etc syntax highlighting is automatic.
|
| Once you are comfortable editing text or code, you can see
| how to add, say, LSP support, or investigating how to
| compile your code and why that's easier in Emacs, and just
| incrementally make your environment more comfortable and
| powerful. I've been using Emacs since 1978 (when it was
| written in TECO, not a form of Lisp) and still I learn
| something new every week or so.
|
| Remember that "EMACS" stands for "Emacs Makes All Computing
| Simple"
| kagevf wrote:
| I second the suggestion to start off with org mode. You get a
| low stakes note taking utility to use while getting comfortable
| with emacs. From there spread out to learn other features at
| your own pace.
| dbtc wrote:
| Treat it like a game for a while. Don't even try to be
| productive, just play with it and see how the pieces fit
| together.
| namaria wrote:
| That's pretty much my whole approach to life
| ok_dad wrote:
| I totally get that, I've recently started on a toy
| programming project that has literally no purpose other
| than to play around, and it's great! It's such a breath of
| fresh air instead of working on actual _work_.
| namaria wrote:
| Beats stressing out about imaginary money on a race to
| kill the planet.
| allarm wrote:
| Not exactly what you're asking for, but check some articles and
| videos about org-mode. There's a chance you'll get hooked on it
| and the following learning will be much easier because damn,
| it's worth all the pain. Well, at least that was my case.
| Lownin wrote:
| The way I did it was by not using it for my entire workflow
| right away. The trojan horse for me was org-mode. Doom Emacs
| got me started in what felt to be a more modern UX, and I used
| org-mode not for coding outright, but for note taking and
| personal project management. After a while, I started to use
| org-mode's built in ability to run code via org-babel to
| experiment with ideas in code. Eventually I was comfortable
| enough that I just started using it to code some times instead
| of VS Code, because I was already there. I still dual-use VS
| Code and Emacs because VS Code is still better at some things
| (working with files on remote server is still kinda slow via
| TRAMP some times) but I'm about 85% in Emacs now, since I like
| it better for text traversal, org-mode has become more
| integrated into my workflow with things like tangle, and I like
| magit better than VS Code's built-in git interface.
| kuehle wrote:
| I moved from VSCode to Emacs with the help of Doom Emacs. You
| can check it out online. It's a distribution and configuration
| management solution.
|
| Generally people like to recommend writing your config from
| scratch but that didn't work for me.
|
| It comes with pretty much all you requested out of the box.
|
| One thing I liked more than with the default Emacs setup is
| that I could "activate" support for a Language just by un-
| commenting a line in the well organized config.
| Quekid5 wrote:
| Seconded, Doom Emacs is _such_ a huge QoL improvement over
| the DYI solution with a basic Emacs.
|
| (I did use the upstream vanilla Emacs, but the pain of LSP
| support, etc. etc. was just too much until I tried Doom
| Emacs... and suddenly Emacs is usable again!)
| ok_dad wrote:
| Ooh, thanks! That sounds like something that will help me. I
| tend to do better when I can get something running like
| someone else has done in the past, then slowly tweak things
| as I learn more about it. My current VSCode setup and all my
| dotfiles have been slowly cribbed and edited from various
| sources who knew more than me about those things.
| comfypotato wrote:
| Picking eMacs up as a replacement for VSCode while having to
| get stuff done is risky. I would venture to say that it's not
| realistic as far as your conceptualization. I say this because
| you venture to ask if the setup process is similar. The answer
| is a resounding no. VSCode is incredibly easy to "get
| productive" and eMacs is on the other end of the spectrum.
|
| That being said, if you can work some time into your schedule
| to learn eMacs, your goal can be realized. (Also, it's totally
| worth it.) I was a VSCode user and made some time to learn
| eMacs exclusively for org mode (possibly eMacs's coolest
| feature). Once I was comfortable, I just played around with a
| dev environment in eMacs (for fun) and loved it so much that I
| left VSCode.
| ok_dad wrote:
| Thanks for a realistic view! I'm trying out Doom Emacs, per
| another user's suggestion, and I'm going to try it out for
| non-code text editing for a while, since I do a lot of that
| still anyways.
| comfypotato wrote:
| That sounds like a great approach!
|
| I think some of the magic stems from ubiquitous conventions
| regarding bindings throughout eMacs. If you use evil mode,
| the conventions become a little murkier. I'd recommend
| sticking with the vanilla bindings (I haven't used Doom, so
| I'm not actually sure if evil mode is default). This is
| just my two cents. Doom will be a great introduction either
| way.
| jrm4 wrote:
| This is an incredibly underutilized idea. It still feels like
| there's ample room for interoperability in the realm of "I write
| a short piece of code for someone I'm working with, and then they
| take it and use it for something else" in a way that could be
| very specific to one project.
|
| I'd venture to say that essentially no one thinks like this, but
| there's no good reason they shouldn't?
| dale_glass wrote:
| That's great, but I think sometimes "Unix Philosophy" looks too
| much like a religion.
|
| Programs are tools, and if they do the work they need to do, who
| cares if they comply with some ancient ideal or not? Yes,
| certainly composability is a worthy feature to have if it fits,
| but sometimes it's not there and nobody cares because the tool
| still does the job.
|
| I'm also of the view of that the ideal might be almost obsolete
| in its original form. Yeah, "grep | awk | sort | uniq" style
| chains are neat and all, but in modern times they're actually
| quite inflexible. Modern data is likely to have a complex
| structure many of those tools are ill-equipped to deal with. Most
| any time I write anything of even slight complexity, I end up
| doing it in Perl or Python, and it works almost exactly the way
| the same code under Windows would.
|
| I've also got to admit that Microsoft got a leg up here with
| PowerShell, because rather than holding up to tradition from the
| 70s, they applied new modern thought to the problem and came up
| with something better. I think it's unfortunate that Linux has
| acquired a considerable amount of traditionalism, because that
| risks making it slow to adapt and improve.
| BeetleB wrote:
| The article doesn't really do justice to the composability - it
| provides little to no examples. So I'll try to provide some:
|
| Emacs has a lot of functionality on displaying email, handling
| attachments, etc. This made it almost trivial for notmuch[1] to
| make a frontend for their tool. If you think about it, notmuch is
| merely a stand alone _indexer_. But they quickly made a full
| blown email client in Emacs revolving around notmuch by borrowing
| most of the functionality from packages like Gnus, etc.
|
| magit has a neat menu based interface. Now many other packages
| make use of its interface even though they have nothing to do
| with git.
|
| There are multiple completion frameworks, and it's always
| gratifying to utilize one of them for your own needs. As an
| example, I wanted to keep a directory of contacts. I used org-
| roam to create a node for each contact, and freely put any
| information I wanted in there (notes about the person, etc).
| However, I sometimes keep meeting minutes at work (in org mode)
| and whenever I mention a person, I want a link to his/her contact
| page. So I hacked up some elisp functions to:
|
| 1. Insert a new person (and return a link to him/her)
|
| 2. Select an existing person (this is where using a completion
| framework comes in).
|
| Think of all the different pieces I used:
|
| 1. Org mode
|
| 2. Org-roam
|
| 3. A completion framework like vertico to show me _only_ nodes
| that are people, and not all my notes nodes.
|
| 4. Calendar functionality to specify times/dates (really I'm
| using the functionality in org mode, which builds on the Emacs
| calendar functionality).
|
| Basically I built a minutes taking tool + contacts management by
| using various components of packages. It was not a lot of code -
| perhaps 1-2 screenfuls.
|
| I once had a directory with a lot of video files. I wanted to
| share some with friends, but needed to go through each one to
| decide if it's relevant to them. I wrote some simple elisp that,
| within dired (Emac's file manager), when I hit Enter on an mp4
| file, would play the file using mplayer. If I wanted to share it,
| with another keybinding, it would put a link to the file in a
| particular org document.
|
| This is a typical example, of utilizing several different Emacs
| packages to achieve a custom task.
|
| [1] https://notmuchmail.org/
| DonHopkins wrote:
| This document describes UniPress Emacs 2.20, the Unix version
| written in C by James Gosling and distributed by UniPress (who
| RMS referrers to as "Evil Software Hoarders"), based on the
| MockLisp extension language. Version 2.20 included multi-window
| support for SunView, X-Windows, and the NeWS window system. The
| document goes on to describe the future plans for SoftWire (a
| networked PostScript interpreter like NeWS but for managing text
| file and streams and sub-processes instead of drawing graphics),
| which UniPress developed but by never released.
|
| UniPress Emacs Newsletter, February 1988: What is Emacs?
|
| https://www.donhopkins.com/home/ties/scans/WhatIsEmacs.pdf
| ashton314 wrote:
| Hi all, author here.
|
| Thanks for all the comments. I was not expecting to get on the
| front page with this little thought I had in the shower this
| weekend!
|
| Someone reached out to me with the following links, and I thought
| they'd be good to share:
|
| - https://amodernist.com/texts/emacs-unix.html
|
| - https://protesilaos.com/codelog/2021-09-22-live-stream-emacs...
|
| - https://tilde.town/~ramin_hal9001/articles/emacs-fulfills-th...
|
| I haven't watched the video by Prot yet, but I felt like these
| all belonged here to add to the conversation.
___________________________________________________________________
(page generated 2022-11-08 23:00 UTC)