1. 8

    I’m not sure I understand forcing things into classes when literally all the methods are staticmethod. If the point is purity and always passing in all needed input data without needing to carry internal state (and the classes have no members aside from their methods anyway), why not just replace the class with a set of functions in a module?

    1. 9

      It’s a readability thing:

      Please note that examples will use the classes+static method form in order to make this article readable. In a production code, the modules+functions form is the way to go.

      1. 4

        I was thinking the same thing. It’s probably just for pseudo namespacing within a single file instead of 3 separate modules. Total guess though.

        Edit: Also hey @ubernostrum! I’ve followed your for years via Django (maybe since 0.96 days), but hadn’t seen you in a few years. Just noticed that was you. Thanks for all your work.

        1. 4

          Indeed, in Python, having a module with a set of functions would be more appropriate.

          I guess that the reason the author of the article used Python classes is related to the fact that in the book, I have illustrated the separation between code and data using JavaScript classes instead of JavaScript modules.

          My idea was to illustrate how separation between code and data could be applied even in languages where everything has to be a class (e.g. Java). But in languages that support module (or namespace) like Python, JavaScript and Clojure, I think it’s better to avoid classes for aggregating functions.

          1. 2

            Besides readability (classes can act as a namespacing construct within a module), you can use classes to define environmental data (ie. secrets, urls, host/ports, etc), in a pattern like so:

            class MyAPI:
               def __init__(self, environment):
                  self.environment = environment
            
               def perform_action( self, arg ):
                  ....      
            

            and then

            api = MyAPI(...)
            api.perform_action(...)
            

            The key problem with DOP is that if you’re doing concurrent state updates, you end up with two distinct state branches that need to be merged. This is a slow operation unless the transforms are incremental (consume the previous state, a data atom, and produce a delta on the previous state). If Python gets immutable data structures and differential dataflow primivitives, then this will be much easier and performant!

            1. 2

              Indeed managing concurrent mutations with mutable data structures is not efficient. In the book, I am devoting Chapters 4 and 5 to illustrate how immutability make it more efficient using Lodash FP.

              I would love to see a similar implementation in Python. Maybe pyrsistent can help?

              1. 1

                What do you mean by efficient? I suspect that the kernel and the JVM runtime would be massively slower if they couldn’t use atomics and compare-and-exchange primitives.

                1. 1

                  Could you elaborate a bit?

            2. 1

              it tends to get a lot of pushback, but i personally like the use of classes as namespaces for a bunch of related functions.

              1. 2

                I agree. It can be nice if you want to write something in a single file and still have some namespacing.

            1. 1

              If you want to forward jist one applic5 you can do so by adding a line to your docker run command. I have a example here: https://raymii.org/s/tutorials/Running_gnash_on_Ubuntu_20.04.html

              1. 7

                Wait, is applic5 a typo? Or is it shorthand like i18n? If shorthand, did you just make it up? It seems like such an arbitrary spot to split it. Also why not just use “app”.

                Sorry for the 21 questions, but I just woke up and it seemed so funny and out of place to me.

                1. 2

                  That was a typo indeed. On mobile, so probably didn’t notice the autocorrect failure. I do understand your confusion with i18n yes.

                  1. 1

                    I have never ever seen anyone use that word, so probably something @raymii made up :).

                1. 4

                  Cool read. Serenity is such an interesting and inspiring project to follow.

                  1. 9

                    Call be a curmudgeon, but I only stream music long enough to know if I should purchase it for DRM from a site like Bandcamp. Spotify never appealed to me. I don’t like the idea of not having offline access, or paying for subscriptions, or listening to ads, or giving bands peanuts for streams. I’ll stick to mpd.

                    1. 13

                      I’m kind of a curmudgeon too, but some of these are incorrect.

                      or paying for subscriptions

                      Agree, but $120 a year for virtually unlimited music seems like a reasonable compromise to me.

                      I don’t like the idea of not having offline access

                      It has offline access with that subscription.

                      or listening to ads

                      There are no ads with that subscription.

                      or giving bands peanuts for streams.

                      I can’t comment on this. I don’t know how all that works.

                      1. 12

                        off-topic but indeed bands are given peanuts. Spotify’s goal was never the compensation of artists but the stop of piracy : https://www.businessinsider.fr/us/taylor-swift-doesnt-need-streaming-royalties-former-spotify-boss-said-2021-7

                        1. 1

                          However, the next stop is obviously subscriptions on individual artists or perhaps groups of artists. Substack for music.

                          1. 3

                            Since Bandcamp was already mentioned in this thread, just wanted to point out that they do indeed have this. As far as I’m aware, it functions kinda like Patreon, but built into the core download/streaming service.

                        2. 4

                          I know some of these concept conflict when free versus paid subscriber but I don’t see the value personally. That said, what does offline mean here? Is it DRM-free and yours to keep and and share, or is locked behind a single device, account, logevity of you being a subscriber?

                          1. 6

                            “Offline” in the sense that you can “cache” selected songs indefinitely for the Spotify client on your device.

                            I don’t know how it’s actually physically stored on disk, but I imagine it’s just a binary blob that could also have some rudimentary encryption on it. At any rate it’s definitely not designed to make songs available outside Spotify.

                            However, compared to “offline mode” in other subscription products (e.g. Netflix) I don’t think Spotify enforces any limitations on the duration or size of your offline library. Not sure what happens to your “offline” songs if your subscription expires though.

                          2. 1

                            I have Spotify Premium, and I was very annoyed to encounter ads recently on a podcast on Spotify. This may not be Spotify’s fault, but clearly Premium does not pay enough for this podcaster to abandon ads, and it is not accurate to say that there are no ads.

                            If you say “no ads on music”, then that is accurate AFAIK.

                          3. 4

                            But if you buy an album and stream it, you’re giving the artists extra money. I only buy albums that I really love (which hasn’t really changed since pre-streaming/downloading days in high school), so when I stream music it’s either a bonus to a band or a few pennies extra to a band I normally wouldn’t listen to at all (or certainly wouldn’t buy their albums).

                            Payouts depend on a number of factors, though. Even with my meager numbers, I’ve made about $20 on streams this past year.

                            1. 2

                              The client is what I’m paying for.

                              Doing it all myself for many years was fine, recommendations are easy enough to come by … Cleaning metadata, getting album covers correct, organizing, that started to be a lot of work.

                              At a certain point, Spotify was cheap enough (for me) that having a client with any music I wanted instant-on for any device (laptop, client, kid’s tablet), and an actual, real-life, working version of what uPNP always promised but never delivered… Worth it.

                              Compensating artists is and always will be a separate topic (let’s talk about radio play baskets) and the equation still favors publishers pretty heavily (Bandcamp doesn’t get press for donating their profits some of the time because it’s no money.)

                              1. 4

                                And I choose to contribute to MusicBrainz and use Picard because I’d rather help open source

                              1. 4

                                The goal is definitely GNU-free, but yea, it still depends on gmake to build some packages. It’s the only GNU dependency, too. A gmake replacement would finish the job.

                                1. 4

                                  Seems that you would have to replace freetype as well.

                                  Curious to read a little bit more about the rationale though. What’s so wrong about GNU software?

                                  1. 20

                                    I think one advantage is that GNU has had something of a “monopoly” in a few areas, which hasn’t really improved the general state of things. The classic example of this is gcc; everyone had been complaining about its cryptic error messages for years and nothing was done. Clang enters the scene and lo an behold, suddenly it all could be improved.

                                    Some more diversity isn’t a bad thing; generally speaking I don’t think most GNU projects are of especially high quality, just “good enough” to replace Unix anno 1984 for their “free operating system”. There is very little innovation or new stuff.

                                    Personally I wouldn’t go so far so make a “GNU free Linux”, but in almost every case where a mature alternative to a GNU project exists, the alternative almost always is clearly the better choice. Sometimes these better alternatives have existed for years or decades, yet for some reason there’s a lot of inertia to get some of these GNU things replaced, and some effort to show “hey, X is actually a lot better than GNU X” isn’t a bad thing.

                                    1. 8

                                      A LOT of people have soured on GNU/FSF as a result of the politics around RMS and the positions he holds.

                                      1. 3

                                        A lot of people were soured on them long before that; the whole GPL3 debacle set a lot of bad blood, the entire Open Source movement was pretty much because people had soured on Stallman and the FSF, the relentless pedantry on al sorts of issues, etc. Of course, even more people soured on them after this, but it was just the last in a long line of souring incidents.

                                        Was (re)watching some old episodes of The Thick of It yesterday; this classic Tucker quote pretty much sums up my feelings: “You are a fucking omnishambles, that’s what you are. You’re like that coffee machine, from bean to cup, you fuck up.”

                                        1. 1

                                          For sure. Never seen The Thick Of It but I love Britcoms and it’s on my list :)

                                          I’ve always leaned towards more permissive licenses. We techies love to act as if money isn’t a thing and that striving to make a living off our software is a filthy dirty thing that only uncool people do.

                                          And, I mean, I get it! I would love NOTHING more than to reach a point in my life where I can forget about the almighty $ once and for all and hack on whatever I want whenever I want for as long as I want! :)

                                      2. 4

                                        Yeah, when I hear “GNU” I think cruft. And this is from someone who uses emacs! (I guess you could argue it’s the exception that proves the rule, since the best thing about emacs is the third-party ecosystem).

                                        And this is only about GNU as an organization, to be clear. I have no particular opinions on the GPL as a license.

                                        1. 2

                                          Even Emacs is, unfortunately, being hampered by GNU and Stallman, like how Stallman flat-out refused to make gcc print more detailed AST info for use in Emacs “because it might be abused by evil capitalists”, and the repeated drama over the years surrounding MELPA over various very small issues (or sometimes: non-issues).

                                          1. 2

                                            Yeah, it’s really unfortunate :/

                                      3. 12

                                        From the site:

                                        Why
                                        • Improve portability of open source software
                                        • Reduce requirements on GNU packages
                                        • Prove the “It’s not Linux it’s GNU/Linux …” copypasta wrong
                                        1. 2

                                          Why not? (I’m not affiliated with the project, you’d have to ask the people maintaining it)

                                          1. 6

                                            Yeah, “why not?” is a valid reason imvho. I would like to know which one it theirs in actuality. I often find that the rationale behind a project is a good way to learn things.

                                            And fair enough, I assumed you were affiliated. FWIW, Freetype is not a GNU project, but it is indeed fetched from savannah in their repos, which I found slightly funny.

                                            ETA: it also seems to be a big endeavor so the rationale becomes even more interesting to me.

                                            1. 1

                                              My rationale was partially to learn things, partially for the memez and partially as an opportunity to do things the way I want (all these people arguing about init systems, iglunix barely has one and I don’t really need anything more). I wanted to do Linux from scratch to learn more about Linux but failed at that and somehow this ended up being easier for me. I think I definitely learnt more trying to work out what was needed for myself rather than blindly following LFS.

                                          2. 1

                                            There is nothing inherently wrong with gnu software; I just like to have choice.

                                            1. 1

                                              Freetype is available under its own permissive license.

                                              1. 1

                                                That’s correct! I downloaded https://download-mirror.savannah.gnu.org/releases/freetype/freetype-2.11.0.tar.xz just to double check, and here is the license:

                                                FREETYPE LICENSES
                                                -----------------
                                                
                                                The FreeType  2 font  engine is  copyrighted work  and cannot  be used
                                                legally without  a software  license.  In order  to make  this project
                                                usable to  a vast majority of  developers, we distribute it  under two
                                                mutually exclusive open-source licenses.
                                                
                                                This means that *you* must choose  *one* of the two licenses described
                                                below, then obey all its terms and conditions when using FreeType 2 in
                                                any of your projects or products.
                                                
                                                  - The FreeType License,  found in the file  `docs/FTL.TXT`, which is
                                                    similar to the  original BSD license *with*  an advertising clause
                                                    that forces  you to explicitly  cite the FreeType project  in your
                                                    product's  documentation.  All  details are  in the  license file.
                                                    This license is suited to products which don't use the GNU General
                                                    Public License.
                                                
                                                    Note that  this license  is compatible to  the GNU  General Public
                                                    License version 3, but not version 2.
                                                
                                                  - The   GNU   General   Public   License   version   2,   found   in
                                                    `docs/GPLv2.TXT`  (any  later  version  can  be  used  also),  for
                                                    programs  which  already  use  the  GPL.  Note  that  the  FTL  is
                                                    incompatible with GPLv2 due to its advertisement clause.
                                                
                                                The contributed  BDF and PCF  drivers come  with a license  similar to
                                                that  of the  X Window  System.   It is  compatible to  the above  two
                                                licenses (see files `src/bdf/README`  and `src/pcf/README`).  The same
                                                holds   for   the   source    code   files   `src/base/fthash.c`   and
                                                `include/freetype/internal/fthash.h`; they wer part  of the BDF driver
                                                in earlier FreeType versions.
                                                
                                                The gzip  module uses the  zlib license (see  `src/gzip/zlib.h`) which
                                                too is compatible to the above two licenses.
                                                
                                                The  MD5 checksum  support  (only used  for  debugging in  development
                                                builds) is in the public domain.
                                                
                                                --- end of LICENSE.TXT ---
                                                
                                            2. 4

                                              Why would anyone want to write a GNU make replacement when GNU make exists?

                                              1. 3

                                                Having it under a more permissive license is a very valid reason though. Guess why FreeBSD is writing their own git implementation…

                                                If the only tool for a task is closed-source then there is a project trying to make an open-source one. If the only open-source tool for a task is under a copyleft license then there is a project trying to make a non-copyleft one. Once a project is BSD, MIT or public domain we can finally stop rewriting it.

                                                1. 2

                                                  If avoiding copyleft is the goal then the Linux kernel is a weird choice. And important parts of the FreeBSD kernel (zfs) are under a copyleft license too (CDDL).

                                                  1. 1

                                                    I find OpenBSD to be one of the best choices as far as license goes. I’ve been slowly moving all my Debian machines to OpenBSD in the past year (not only because of the license, but because it’s an awesome OS).

                                                    1. 1

                                                      I haven’t tried using OpenBSD in earnest since are around 1998. I prefer a copyleft to a BSD style license personally but maybe I’ll take another look. And I hear that tar xzf blah.tar.gz might even work these days.

                                                      1. 1

                                                        It gets improved with every new major release, I’ve used it consistently for the past 3 or 4 releases and there’s always noticeable improvement in performance, user-land tools, drivers, arch support, etc. I’d definitely give it a try again!

                                                  2. 1

                                                    This is fine reasoning but relativized. After all, I could just as easily say that if the only tool for a task is under a non-copyleft license, then there is a project trying to make a GNU/FSF version; once GNU has a version of a utility, we can stop rewriting it.

                                                  3. 2

                                                    They don’t want to do that. They want a non-GNU replacement for GNU make

                                                    1. 1

                                                      They could just fork GNU make. That would work right?

                                                      1. 4

                                                        Or use bsdmake.

                                                        1. 2

                                                          bsdmake is in fact included, but it can’t build all gmake makefiles unfortunately.

                                                          1. 3

                                                            I used to do a fair bit of packaging on FreeBSD, and avoiding things like GNU make, autotools, libtool, bash, etc. will be hard and a lot of effort. You’ll essentially have to rewrite a lot of project’s build systems.

                                                            Also GTK is GNU, and that’ll just outright exclude whole swaths of software, although it’s really just “GNU in name only” as far as I know.

                                                          2. 1

                                                            No bmake isn’t enough to build the Linux kernel

                                                          3. 1

                                                            Depends on their goals. Some people don’t like GNU or GPL projects. If that’s the case then probably not.

                                                            1. 4

                                                              If they don’t like GPL projects then using the Linux kernel is a weird choice.

                                                            2. 1

                                                              The entire point here is to not contain any GNU code, so no.

                                                              1. 5

                                                                zlib is derived from GNU code (gzip) so anything that includes zlib or libpng etc will “contain GNU code”. This includes for example the Linux kernel.

                                                                1. 6

                                                                  He didn’t say they’ve achieved their goal. It’s still a goal.

                                                                  Why does it seem like you’re trying to “gotcha” on any detail you can refute?

                                                                  It’s just someone’s project.

                                                                  1. 3

                                                                    I’m trying to understand the goal. If the goal is avoiding software that originated from the GNU project that is probably futile. The GNU project has been a huge, positive influence on software in general.

                                                                    1. 5

                                                                      You know the goal. They stated it. The parent comment to you stated it again.

                                                                      It might be futile, but luckily we don’t control other peoples free time and hobbies, so they get to try if they want. You seem to be taking personal offense at the goal.

                                                          4. 1

                                                            For fun

                                                        2. 3

                                                          From the site:

                                                          Iglunix is a Linux distribution but, unlike almost all other Linux distributions, it has no GNU software¹

                                                          ¹With the exception of GNU make for now

                                                          1. 1

                                                            Yes I still haven’t been able to replace a couple projets. For self hosting gnu make is all that’s left, for chromium bison (and by extension gnu m4) and gperf are all that’s left.

                                                          1. 4

                                                            I love the write ups. Thanks jcs.

                                                            Bring back garbage.fm!

                                                            1. 2

                                                              Nice. This is basically the same advice as Ben Johnson’ article on package layout [1]. We use this daily, although not as table driven tests.

                                                              I spent many years in the Django world and liked their organization (splitting on features instead of functionality), so it took me a while to really have Ben Johnson’s advice take hold in some of my projects. But the more go I write, the more I believe he is right.

                                                              This weekend I re-watched Peter Bourgon’s “Best Practices for Industrial Programming” [2] and he even mentions it around the 5m40s mark.

                                                              [1] https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1

                                                              [2] https://www.youtube.com/watch?v=PTE4VJIdHPg

                                                              1. 1

                                                                But only for code, not for commit messages I assume? Or is there a good argument for limiting commit messages to 80 columns too? It’s enforced at my job but I can’t think of any good reason for it.

                                                                1. 3

                                                                  Absolutely:

                                                                  From Linus:

                                                                  https://github.com/torvalds/subsurface-for-dirk/blob/a48494d2fbed58c751e9b7e8fbff88582f9b2d02/README#L88

                                                                  Another good explanation:

                                                                  https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

                                                                  TLDR: If you use git in a terminal, viewing logs of properly formatted messages is much nicer.

                                                                  1. 3

                                                                    I do see that both offer advice to manually wrap the text within less than 80 characters, but in both cases the only reason given is “it looks nice with git log”.

                                                                    When I git log in the terminal (macOS), commit message bodies that are not manually wrapped are auto-wrapped within the window bounds, albeit per character and not per word, which I consider a limitation of the terminal and not of the rule of thumb.

                                                                    GUI tools such as Tower properly wrap commit message bodies per word, like any other prose.

                                                                    1. 2
                                                                      1. 2

                                                                        Thanks for that link!

                                                                        And the tool you use to visualize things cannot know.

                                                                        I would argue that tools know how to wrap common prose very well. Text editors have done this for at least 30 years.

                                                                        However:

                                                                        Some things should not be word-wrapped.

                                                                        What if a (part of a) message is not common prose? For code, you’ll manually wrap it to never go outside the screen width, so auto-wrapping should never affect code. Indeed, Linus refers to:

                                                                        They may be some kind of quoted text - long compiler error messages, oops reports, whatever.

                                                                        If I understand correctly he says that having automatic word wrap is not nice when a quote is better left in a single long line and you want it to go off-screen, typically a log message. I can see how in this exceptional case you don’t want to your tool to auto-wrap.

                                                                        However this is an argument to not uniformly enforce an 80 character limit.

                                                                        With any kind of enforcing, you’d need to make exceptions for these log lines. Perhaps by allowing markdown and making an exception for code blocks? But if you want to go that far, I would argue it would be equally involved to look for a message viewer/editor that knows how to exempt certain annotated lines from auto-wrapping instead.

                                                                        Taking Linus’ points into account, so far I would conclude that enforcing an 80 character limit on commit messages is never a good idea:

                                                                        • If a message is common prose, any tool can properly auto-wrap it.
                                                                        • If a message is not common prose, it is either:
                                                                          • Code, which we want to manually format to never reach the screen limit so auto-wrapping should never affect it,
                                                                          • A special case where a line needs to extend beyond the screen limit. If we want to account for this, we need to invest in more advanced tooling anyway because a fixed 80 character limit won’t work. In this case we get a higher benefits by configuring a message viewer that knows how to make an exception for these long lines and auto-wrap the rest.
                                                                        1. 1

                                                                          So yeah, as Linus says:

                                                                          Sure, the alternative would be to have commit messages be some non-pure-textual format (html or similar). But no, that’s not how git does things.

                                                                          You are basically arguing for markdown or “non-pure-textual format”, which is reasonable. The point is, hard wrapping and a 72 column limit is still the best option given that git is pure text, and that this is unlikely to change.

                                                                          With any kind of enforcing, you’d need to make exceptions for these log lines.

                                                                          Yes, this is annoying. It’s a wart of the pure text solution. But the alternative (throwing out line length standards for commit messages) is worse imo.

                                                                          Also, note that offloading soft-wrapping to editors or terminals is not as well supported as you’d think. While every editor/terminal can soft-wrap at the window’s right margin, most cannot soft-wrap at a specific column width. For example, in a full-screen window in nvim or Terminal, I can’t (afaik) make it soft-wrap at 80 columns. So if I don’t want to read long horizontal lines, I am forced to resize the window itself to make the not-hard-broken lines readable. This sucks.

                                                                          1. 1

                                                                            Wouldn’t you agree that given pure text, the following holds for any (part of a) message:

                                                                            • If it is common prose, any tool can properly auto-wrap it. EDIT: except for cases like suspending vim after working in a multi-column layout or maybe working in a fullscreen terminal window but still wanting an 80-character limit.
                                                                            • If it is not common prose, it is either:
                                                                              • Code, which we want to manually format to never reach the screen limit so auto-wrapping should never affect it, or
                                                                              • A special case where a line needs to extend beyond the screen limit. With pure text there no solution to accommodate this and auto-enforce an 80-character line limit.

                                                                            So I would conclude that the only reasons to enforce a manual / hard-wrapped 80-character width for commit message bodies, the subject line is different, are rather exceptional scenarios where the tool setup does not (always) support auto-wrapping prose to a desired line length.

                                                                            The latter may well be an argument to keep this rule, but I think it might be worth doing a poll of how many people within the organization actually use tooling that have this limitation.

                                                                            1. 1

                                                                              If it is common prose, any tool can properly auto-wrap it. EDIT: except for cases like suspending vim after working in a multi-column layout or maybe working in a fullscreen terminal window but still wanting an 80-character limit.

                                                                              This is the incorrect assumption imo. The problem is that soft-wrapping, as a feature, is typically coupled to window width.

                                                                              As I noted in my last response, vim cannot soft wrap at a specified column length – only at the the window’s edge. Thus I can only “properly auto-wrap” by controlling window (or buffer) size, which is an unacceptable proposition. The bad case is not limited to suspending a split-window vim and dropping back into terminal (though that’s a good example). It includes closing one of my vertically split-window buffers so that the remaining buffer now fills the screen, or resizing my window for other reasons, changing my columns-per-character when I change font size, and on and on.

                                                                              Mac Terminal itself (afaik) similarly lacks a configuration for soft-wrapping at a column width (regardless of window width). I don’t know about iTerm, but I suspect the lack of this feature is the norm rather than the exception in most tools and editors.

                                                                              A special case where a line needs to extend beyond the screen limit. With pure text there no solution to accommodate this and auto-enforce an 80-character line limit.

                                                                              Agreed. And it’s a problem because if you want the 80-char rule, it’s a lot better to enforce it at the CI level. I would be in favor of a simple GH action, say, that does enforce it and allows some simple escape hatch like surrounding the exceptional lines by --- or a # linecheck-disable comment or some such. It wouldn’t be hard to write one. Of course we’ve now broken “pure text” and introduced our own (albeit tiny) markup language. But “lesser of evils” is the best we’re going to get here, I think.

                                                                              The latter may well be an argument to keep this rule, but I think it might be worth doing a poll of how many people within the organization actually use tooling that have this limitation.

                                                                              I think this affects almost everyone who prefers reading prose at reasonable widths and also uses full-width windows sometimes.

                                                                              As a side note (not saying this is an issue for you), the hard-wrapping requirement is hardly an inconvenience if you have a hotkey for doing it in your editor. It would be quite annoying otherwise.

                                                                              1. 3

                                                                                This is the incorrect assumption imo. The problem is that soft-wrapping, as a feature, is typically coupled to window width.

                                                                                As I noted in my last response, vim cannot soft wrap at a specified column length – only at the the window’s edge.

                                                                                Maybe this is getting a bit off-topic, but this has annoyed me for years. There is no good modal editor for prose (that I know of) and this is one of the problems of using Vim/Neovim for normal writing. People try to hack around it with plugins like goyo that create a lot of empty buffers around your document, but that has limitations.

                                                                                Not that I have time to work on it, but every now and then I get the urge start writing a new editor from scratch for this purpose.

                                                                  2. 2

                                                                    I believe I’ve heard the argument that if you need more space to describe what you changed, you should break it into smaller commits.

                                                                    1. 1

                                                                      typical style for commit messages (in git) is a subject line of up to 50 characters, then a blank line, then a multi-line description no more than 72 columns wide.

                                                                      1. 2

                                                                        Do you have any argumentation for why you wouldn’t want commit messages to be word-wrapped automatically by the tool you are using to view or edit them?

                                                                        1. 3

                                                                          A short subject line (50ish) allows viewing and skimming commits, one per line to see what has been done.

                                                                          1. 1

                                                                            That’s a good point for subject lines. I’m not sure if there would be an easy way to enforce a size on the first line only…

                                                                          2. 2

                                                                            nearly every UI that displays a list of commits will have a layout that is optimized for subject lines of 50 chars or less. Beyond that, whether the first line will be trimmed or wrapped (and at what position it will be trimmed/wrapped) will vary substantially from client to client. The web views in github and bitbucket work very consistently when this rule is followed, but not as consistently when it isn’t. git log --pretty=oneline also benefits tremendously from this rule of thumb since every line also includes the full commit hash, which is 40 chars wide.

                                                                            1. 1

                                                                              Thanks for these pointers. Indeed for the subject line a limited line length seems very useful.

                                                                              This does not answer the question why the body of the commit message should be hard-wrapped at 80 lines as well though.

                                                                              Again, I can imagine that it is hard develop a git hook to consistently enforce that only the subject line has a limited length. But although I may be missing edge cases, it doesn’t sound impossible either.

                                                                              1. 2

                                                                                git log will indent all lines with 4 spaces. when it softwraps because the terminal isn’t wide enough, the wrapped lines wind up unindented. If you have any line breaks at all, you’ll wind up with mixed indentation levels.

                                                                                a pre-commit hook is still opt-in and client side, so it’s not really enforceable if you’re using some sort of star topology like github/gitlab/bitbucket/etc, which is how the majority of projects and teams use git. Most providers of git servers don’t permit custom pre-receive hooks, since you’d have to allow the execution of arbitrary code. For github, it’s an enterprise feature. Rejecting PR’s in CI is pretty common but generally toolsets expect that rejected PR’s get updated and eventually merged, not deleted entirely. You can rewrite history in PR’s in most toolsets but the experience is often lackluster.

                                                                                1. 1

                                                                                  That is a good point, if your commit message relies on indentation, auto-wrapping will not work for it. However as far as I can see, typical prose will not depend on indentation, right?

                                                                                  A pre-commit hook backed by a blocking CI rule is what we use now to enforce the 80 character limit, this seems to work pretty well so far. Indeed rewriting history is the common approach here. As far as I have experienced, github PRs deal with that pretty well.

                                                                            2. 1

                                                                              Pretty much for the reason Daniel gave in the post: humans typically struggle with long lines. If I run git show on a commit and my terminal happens to be quite wide, git won’t reflow the text for me (and nor should it). Hard breaks in the commit message mean that everyone reads the commit message the same way.

                                                                              1. 1

                                                                                That’s interesting, so there are scenarios where you have a wide terminal window but you don’t want wide lines? Wouldn’t it be more convenient to size the terminal window to the width of your personal preference and have the lines adapt?

                                                                                1. 1

                                                                                  so there are scenarios where you have a wide terminal window but you don’t want wide lines?

                                                                                  Yes. I typically have the terminal wide so that, for e.g. in vim I can have a vertical split with two files open side by side.

                                                                                  Wouldn’t it be more convenient to size the terminal window to the width of your personal preference and have the lines adapt?

                                                                                  For some cases, yes: e.g. when scanning through log files I’d prefer it to wrap (journalctl’s default of chopping rather than wrapping is maybe the most annoying thing), but for my use-case above I really do want a wide terminal with two (or more) files open with narrower text; but when I suspend vim to commit changes or review commits, I don’t want the commit messages filling the entire width of the terminal. I just can’t read long lines easily like that.

                                                                                  1. 1

                                                                                    in vim I can have a vertical split with two files open side by side.

                                                                                    But wouldn’t vim be able to wrap lines for every individual column in this case?

                                                                                    1. 2

                                                                                      Yes, but:

                                                                                      I suspend vim to commit changes or review commits, I don’t want the commit messages filling the entire width of the terminal.

                                                                                      And sticking to a relatively fixed line length means as I add or remove splits, the code isn’t reflowed, so I remain looking at the same things and don’t lose context or focus by having to figure out where things moved in a reflow.

                                                                                      1. 1

                                                                                        I see, so we can conclude that there are certain scenarios in which (a specific use case of) the tooling is not able to auto-wrap prose reliably.

                                                                                        1. 1

                                                                                          I think it’s fairer to say there are cases I’d prefer not to need tooling to auto-wrap. Not just prose; prose and code.

                                                                                          1. 2

                                                                                            That’s indeed a better way to put it, thanks for refining.

                                                                        1. 16

                                                                          vipe is pretty useful. Can do things like:

                                                                          ls | vipe | wc -l
                                                                          

                                                                          To manipulate intermediate results with your $EDITOR. I’ve re-implemented this tool in Haskell:

                                                                          https://hackage.haskell.org/package/editpipe

                                                                          1. 1

                                                                            That’s funny, i thought it was based upon the moreutils author. I guess vipe predates Joey’s desire to write everything in Haskell?

                                                                          1. 2

                                                                            I’ve recently been looking at this.

                                                                            My setup for close to 5 years now has been using a remote VPS with everything on it and running emacs/tmux over mosh. I just connect from my Mac Air (or Thinkpad) and everything is just running and all setup. I did it at first as an experiment but I don’t think I could return.

                                                                            Switch machines with easy, reboot, restart X, upgrade system, battery dies, lose laptop, etc. Its all just running somewhere else so it doesn’t matter.

                                                                            I love it. I do work via terminal only which might be an issue for some people though.

                                                                            1. 1

                                                                              Working this way definitely has a lot of advantages :D

                                                                            1. 28

                                                                              There’s a huge funnel problem for computer science at the moment. Go and Rust have some pretty serious evangelical marketing teams, but they are a drop in the ocean compared to the emergent ultramarketing behemoth that feeds JavaScript to the new developer.

                                                                              Part of this is that JS is constantly “new and modern” – with the implication that it’s a bandwagon that you’ll be safe on, unlike some of the old cobwebbed bandwagons. Constant change and “improvement” is itself a safety generator.

                                                                              Another part is that it’s so easy to get to hello, webpage. The sweet spot on the racket is enormous. Every computer including your phone comes with at least 1 and usually several JS interpreters. Frictionlessness drives adoption.

                                                                              The problem is that JS is, violently, garbage for most purposes. It’s a local maxima that has essentially everyone trapped, including the next generation. It’s not clear how we escape from this one.

                                                                              1. 17

                                                                                I feel about JS similarly to the way I felt about the x86 ISA taking over the world. “A local maxima that has everyone trapped”, that caused billions of dollars of R&D to be diverted into clever hardware, code generation, psychological treatment for programmers, etc. (I think the last thing is a joke, but I’m not sure.) One could even draw a parallel between the modern “micro-op” architectural approach to bypassing literal x86 in hardware and the WASM approach to bypassing literal JS in the browser.

                                                                                1. 12

                                                                                  The longer it goes, the more this talk gets correctly.

                                                                                  1. 1

                                                                                    I’m not sure any other ISA would have been better than x86 at the time x86 began to take off. Lots of companies were trying lots of things in the RISC world, and plenty of money was being spent on RISC hardware and compilers, and the x86 still began to take off. Intel had a lot of money? IBM had a lot of money, and IBM was working on RISC. HP had a lot of money, and HP was working on RISC. And so on.

                                                                                    1. 2

                                                                                      Of the obvious choices available at the time x86 began to take off (1984ish), I would say the 680x0 was a better choice, demonstrated by watching the parallel evolution of the two. At least the extensions to 32-bit and virtual memory seemed a lot more straightforward on the 68k. They both would have run out of steam and gotten weird by now, but I feel like it would have been less weird.

                                                                                  2. 2

                                                                                    It’s not clear how we escape from this one.

                                                                                    Simply wait. There are some better tools out there (for some value of the objective function “better.”)

                                                                                    We’ve moved on from C, C++ and Java, all of which have had a similar level of death grip. JS is not invincible. The more users it attains, the more it suffers problems of perception due to the wide variance of quality. This gives rise to new opportunities.

                                                                                    Really, I get a bit disappointed that everyone is content to rewrite everything every seven years, but, hey, it’s their life.

                                                                                    1. 0

                                                                                      I take strong offense at this proclamation of JavaScript as garbage. What kind of an opinion is that? If you don’t know JavaScript, don’t call out garbage. If you do know if well, you’ll see that it isn’t any more garbage then any other modern language for most purposes for which it is used - at least on backend.

                                                                                      The entire ecosystem has some issues, but every ecosystem does. And considering that node was created only a decade ago and has vastly more users then some “serious” things that exist for ages, it’s obvious that there’s something that it’s going correctly.

                                                                                      1. 29

                                                                                        I take strong offense at this proclamation of JavaScript as garbage.

                                                                                        You are offended on behalf of Javascript? People can dislike things that you like. It doesn’t do anything.

                                                                                        1. 4

                                                                                          Okay, inprecise choice of words on my part. I’ve wanted to state that I strongly disagree with his statement, english isn’t my first language and so I didn’t think every word completely through. I think you can still get the message. Be flexible a bit and you’ll understand it.

                                                                                          1. 8

                                                                                            I’m not sure what other languages you know, but compared to most popular languages:

                                                                                            • Javascript has a weird type-system that doesn’t really pay off. Sure, they added inheritance recently (welcome to the 80s), but there are all kinds of inconvenient relics like having to do Object.keys(x) when in Python you can just do x.keys() (as in most popular languages)

                                                                                            • Javascript makes it much harder to catch errors. Its implicit typecasting (undefined+“1”==“undefined1”, really??) and misuse of exceptions in the API means that when something goes wrong, you’ll often find out a few functions later, and then struggle to zero-in on the actual problem.

                                                                                            • The ecosystem is too fractured. The lack of a curated “standard library” sends novices into all sorts hacky solutions, and makes other people’s code less familiar.

                                                                                            I could really go on for a long while, and there are tons of example that I could give. I can say positive things too, like it has a good JIT, lots of interesting libraries, and some nifty syntax features (while lacking others), but overall think it’s a really bad language, that just happened to be in the right place and in the right time.

                                                                                            1. 1

                                                                                              For the record, JavaScript has always had inheritance, it just hasn’t had a class syntactical sugar that made it trivial to use until ES6.

                                                                                              1. 1

                                                                                                I wouldn’t call it bad. It just has bad parts. The == operator you mentioned is a trap for many beginners. On the other hand, there’s no inheritance problem because the inheritance was always there - you just have to know how prototypes work. The type system without extra tools and some practice is a pain. Yet the closure or say prototypical inheritance and composability you get is great.

                                                                                                JavaScript got really lousy reputation because unlike, say, C++ or Java, everybody wrote it, not just people who studied software engineering for five years and know how to use tools, have structure and not break the rules.

                                                                                                And it’s keeping the lousy reputation because it is still being done - randos adding jquery plugins for perfectly css-able animations even today.

                                                                                                Plus it’s got 25 years of backwards compatibility to maintain, so those bad parts never leave. Yes, it has been at the right place at the right time - but many others have tried and are still trying.

                                                                                                But despite all the bad parts and lack of standards, it’s still immensely flexible and productive and for a lot of use cases actually provides the best concepts to do them. Could you put something like elixir in a browser engine? Or java? Or Rust? Probably. Would it be better? Maybe, but I suspect not by much.

                                                                                                I don’t know, I’m probably not seeing it. I’m not claiming that it’s a great language or that it’s even good for everything and everyone. But people only see the ads and single page apps where they don’t belong or where they simply don’t like it, and ignore a lot of directness that the language provides, look down on flexibility, and don’t allow the little language that could its deserved praise (where it does deserve it).

                                                                                                Once again, as I’ve said in another comment - I don’t claim it’s the best language ever. I’m just saying it is not garbage. These days the tooling and the entire ecosystem is mature and there are no more language issues in writing a typical NodeJS application then in most other similar languages.

                                                                                                1. 1

                                                                                                  Javascript has a weird type-system that doesn’t really pay off. Sure, they added inheritance recently (welcome to the 80s)

                                                                                                  It added inheritance as a sop to people who didn’t know composition and refused to learn. Are you not satisfied with that? Does it have to become a pure Smalltalk clone for you? Composition is more powerful but it’s less familiar. Now JS has easy ways to do both.

                                                                                            2. 24

                                                                                              I have a deep understanding of JavaScript; I promise that my opinion is rooted in experience.

                                                                                              1. 6

                                                                                                Even though you personally find Node impressive, there might be people who don’t get impressed by languages (or any software really).

                                                                                                Being impressed or having respect (for a software) makes no sense. It is just a tool that should be used or discarded at will. Not a cultural icon.

                                                                                                If you do know if well, you’ll see that it isn’t any more garbage then any other modern language for most purposes for which it is used - at least on backend.

                                                                                                You have stated no arguments that support your conclusion. I believe that the jury is still out on the matter of language effect on productivity. All the studies I know of were totally botched.

                                                                                                Anecdotally, I have seen more poor Node backends than Python ones. I have also seen less high quality Haskell backends, which confuses me greatly. Still, I wouldn’t go as far as to conclude that everything is the same crap.

                                                                                                1. 6

                                                                                                  Denying the role of aesthetic judgement in programming is madness.

                                                                                                  1. 1

                                                                                                    I didn’t state I find Node impressive. I do love it for the productivity it brings to me. And that is just the point of my reply. The guy claimed JavaScript is garbage, also without arguments. I’ve just pointed out that. No more garbage then any other language, in my opinion. If anybody brings arguments into this whole discussion, including the original post of the thread that claims people are pushing node, we can talk about with arguments. Otherwise we’re all just giving opinions and estimations.

                                                                                                    Anecdotally I’m seeing much more crappy Java Enterprise and Spring backend code lately then node. Likely because I work at a java shop now. But I don’t claim that people are pushing Java exclusively for backend (even though they do at my company, we literally have 100% Java in my 800 people department), nor do I claim Java is garbage.

                                                                                                    I hope that clarifies my objection to the claim of garbageness.

                                                                                                    1. 4

                                                                                                      I think you are right that JavaScript brings great initial productivity. Especially in the single developer case. For many simple tasks, it is easy to use node, easy to use npm, and easy to deploy code. Where I have seen problems that I know are avoidable in other languages is in its long term sustenance and operation, which are vitally important parts of software engineering.

                                                                                                      Other languages have, for example, highly vetted and deep standard libraries of functions which are included in the system and move very slowly, which eliminates large classes of dependency management issues. Or, they have good type systems, which helps prevent common problems, especially in dynamic languages. Or they have exceptional tooling that enforces good practices. Or they are especially operable in production, with good intrinsic performance or observability characteristics.

                                                                                                      But the most important thing, to me, is that most other languages have a culture of remembering, but this is distinctly lacking in JavaScript. I attribute this to many JavaScript programmers starting from scratch in their software career inside JavaScript, and not having broader exposure to the vast surface of other kinds of software. And I attribute it also to the “stack overflow” method of programming, in which rather than engineer your software, you assemble it from the guesses of others, losing fidelity and getting more blurry with each iteration.

                                                                                                      It could sound like I’m being a pretentious jerk. I’ll confess to that. But having been a professional software engineer for now 32 years, and having seen probably a hundred languages and environments, the current JavaScript one is my least favorite. I appreciate that it’s one that you have significant personal investment in, but I would also encourage you to step out and up, and look around.

                                                                                                      1. 1

                                                                                                        Thanks, this also raises some quite relevant concerns. And I agree with these things. And now I have to fall back to the fact that despite these problems, it’s not garbage. I did step out and I try other languages and their frameworks, but I’m simply personally the most productive with it. And when I worked in teams where Node was used on the backend, the teams were professionals and mostly didn’t have problems with the language itself - maybe more or less then if it was done in, say, Spring or Rails, but I would say the typical problems are always stupid things like commas in the database where they break serialization somehow.

                                                                                                        And that is the point of my original comment. Which was that I object to the claim that JavaScript is garbage. Maybe a lot of garbage is written in JavaScript today, but it in itself is not that, and can provide perfectly productive envrionment for doing our jobs.

                                                                                                  2. 6

                                                                                                    I wouldn’t call JavaScript “garbage” myself, but it sure has some problems that few other languages have. [1] + [2] resulting in "12" being a simple example. JavaScript definitely took the 90s/00s vogue of “all things should be dynamic!” more than a few steps too far.

                                                                                                    considering that node was created only a decade ago and has vastly more users then some “serious” things that exist for ages, it’s obvious that there’s something that it’s going correctly.

                                                                                                    Well, just because it’s popular doesn’t mean it’s good ;-)

                                                                                                    I notice myself that I often use tools that I know, even when it’s not necessarily the best fit, simply because it’s so much easier. Yesterday I wrote some Ruby code for a Jekyll plugin and had to look up a lot of basic stuff and made a few simple mistakes along the way; there was quite a lot of overhead here. And I programmed Ruby for a living for 2 years (but that was 5 years ago, and looks like I have forgotten much).

                                                                                                    JavaScript is rather unique in the sense that almost everyone has to deal with it because it’s the only language supported by browsers[1], so there are a lot of people familiar with JS who would rather like to use it in other scenarios as well: not necessarily because it’s the “best”, but because it’s just easier as they won’t have to re-learn a whole bunch of stuff.

                                                                                                    That’s not necessarily a bad thing, by the way; I’m all for giving people the tools to Get Shit Done. My point is merely that much of NodeJS’s popularity probably stems from factors other than intrinsic qualities of the language, runtime, and/or ecosystem.

                                                                                                    [1]: Ignoring wasm, which isn’t quite ready for production-use, and “X-to-JS” compilers, which typically still require knowledge of JS.

                                                                                                    1. 1

                                                                                                      Oh, I wasn’t claiming that the popularity of NodeJS comes from it’s quality. I’m just saying JavaScript is not garbage, which the commenter claimed without argumenting it.

                                                                                                      I mean, I know that [1] + [2] is “12” in JavaScript. But if you ask me how many times I’ve had a problem because of that in the last year, I would possibly be mistaken, but I would say 0 times.

                                                                                                      Again, it’s not the best language and it has its problems. But it’s not garbage.

                                                                                                      1. 2

                                                                                                        I mean, I know that [1] + [2] is “12” in JavaScript. But if you ask me how many times I’ve had a problem because of that in the last year, I would possibly be mistaken, but I would say 0 times.

                                                                                                        I find this interesting, because a few comments upwards, you state this:

                                                                                                        The typical problems are always stupid things like commas in the database where they break serialization somehow.

                                                                                                        It might just be me, but in no other language have I ever heard of specifically this problem. If you dig a little deeper, you’ll notice that there are a few fundamental issues in the language. But definitely the most prominent root issue is that types are treated extremely loosely, which causes all sorts of offshoot problems, like the two above.

                                                                                                        I always try to think a bit more holistically about this, and when you do, you start to see this pop up everywhere. Just yesterday I was debugging an issue with a colleague where he accidentally was throwing a JSON-encoded string at a program where in fact he should have been taking the JSON document, extract a specific key’s string value and send that to the program. Basically the same thing: it’s too easy to mix up types.

                                                                                                        I occasionally see this in Python as well: when you accidentally have a string instead of a list of strings; because of the “everything is a sequence” abstraction it’s too easy to mix things up, and you end up chasing down the rabbit hole before you figure out where it’s going wrong. It’s better if things error out early when you try to do something that makes no sense.

                                                                                                        Having type-specific operators makes it easier to get your bearings when reading unfamiliar code, too, in my experience.

                                                                                                    2. 3

                                                                                                      And considering that node was created only a decade ago and has vastly more users then some “serious” things that exist for ages, it’s obvious that there’s something that it’s going correctly.

                                                                                                      No, it means JS has a powerful monopoly (the web) and thus commands a huge mindshare. Some subset of those people want to take their painstakingly earned experience to the server.

                                                                                                      1. 0

                                                                                                        So, ‘heads I win, tails you lose’, eh? Good argument. /s

                                                                                                    1. 26

                                                                                                      I looked at the source and thought I’d share some neat things that you can do.

                                                                                                      Instead of

                                                                                                      var bin_name = args.nextPosix();
                                                                                                      

                                                                                                      you can do

                                                                                                      _ = args.nextPosix();
                                                                                                      

                                                                                                      to ignore the value, and get rid of the unused variable.

                                                                                                      Instead of

                                                                                                      var fname = args.nextPosix();
                                                                                                      if (fname == null) {
                                                                                                          std.debug.warn("expected at least one file name as an argument\n", .{});
                                                                                                          std.os.exit(1);
                                                                                                      }
                                                                                                      
                                                                                                      if (readFile(fname.?))
                                                                                                      

                                                                                                      you can do

                                                                                                      var fname = args.nextPosix() orelse {
                                                                                                          std.debug.warn("expected at least one file name as an argument\n", .{});
                                                                                                          std.os.exit(1);
                                                                                                      }
                                                                                                      // `orelse` has already "unwrapped" the optional, so no need for `.?`
                                                                                                      if (readFile(fname))
                                                                                                      

                                                                                                      Instead of

                                                                                                      if (readFile(name)) |_| {} else |err| {
                                                                                                          std.debug.warn("error reading file: {}\n", .{err});
                                                                                                      }
                                                                                                      

                                                                                                      you can do

                                                                                                      readFile(name) catch |err| {
                                                                                                          std.debug.warn("error reading file: {}\n", .{err});
                                                                                                      }
                                                                                                      

                                                                                                      which is a bit nicer, IMO.

                                                                                                      And of course, if you want, you can make main return !void, and use try directly in it.

                                                                                                      1. 3

                                                                                                        This is really helpful! I appreciate the feedback. I will need to read more about the orelse keyword.

                                                                                                        1. 3

                                                                                                          I’m not that familiar with Zig yet, but I prefer your adjustments here. Thanks and thanks to gsquire for putting it together.

                                                                                                        1. 7

                                                                                                          Love it. You should definitely checkout magit for some UI ideas. It’s superior to everything I’ve used in that sense, and I think anyone that has used it feel the same.

                                                                                                          1. 5

                                                                                                            Link for convenience: Magit, a Git porcelain inside Emacs

                                                                                                            1. 3

                                                                                                              Yup, I don’t really use Emacs these days for editing, but I have an mg alias in my shell which launches magit for many cases where just git is inconvenient (like, dozens of times per day).

                                                                                                              1. 2

                                                                                                                What use cases are that so that I can see what to implement next in gitui?

                                                                                                                1. 3
                                                                                                                  • interactive rebasing
                                                                                                                  • instant fixup (fixup commit and rebase folded into a single operation)
                                                                                                                  • by hunk or by line staging
                                                                                                                  • composing longer commit messages
                                                                                                                  1. 2

                                                                                                                    Thanks!

                                                                                                                    • interactive rebase was on my list
                                                                                                                    • instant fixup I need to research what that is
                                                                                                                    • by hunk is supported, but by line not, need to figure out how to do that intuivly
                                                                                                                    • better support for longer commit messages I added: https://github.com/extrawurst/gitui/issues/46
                                                                                                                    1. 2

                                                                                                                      Oh, I’ve recalled one more thing which was hugely important when I was learning magit. It displays the actual git flags which are activated by each shortcut. You can see it on screenshot (shamelessly plugs his own tui rant) here.

                                                                                                                      1. 2

                                                                                                                        Really interesting but gitui is not using the git shell under the hood so I think that is not really a matching purpose I am afraid

                                                                                                              2. 1

                                                                                                                (Athor here) Looks definitely interesting, but I think I gotta try it because the documentation looks complicated on first glance. My focus is simplicity and something that does feel like a GUI even though it’s in the terminal.

                                                                                                                1. 5

                                                                                                                  Definitely give it a shot. Specifically I recommend you try the interactive rebase which you mentioned. It makes it trivial. Everything is one key press away.

                                                                                                                  I can say it’s probably my favorite piece of software I get to use.

                                                                                                                  Either way nice work!

                                                                                                              1. 21

                                                                                                                Emacs.

                                                                                                                I initially picked it as a text editor, and then found that each new task I brought into Emacs got more efficient, benefiting from a) my familiarity with the editor accelerators, b) integration with the rest of my Emacs based toolchain, c) blindingly fast performance on even ancient hardware, d) programmability via Emacs Lisp.

                                                                                                                Some key packages:

                                                                                                                Orgmode (http://orgmode.org). Organise your life - or at the very least your work - all inside Emacs. org-present lets you use Orgmode files as slides, and org-present-remote (which I wrote) presents a mobile friendly Web interface to control Orgmode slides from your phone.

                                                                                                                Mu4e (https://www.djcbsoftware.nl/code/mu/mu4e.html). Manage all your email in Emacs. Includes a handy HTML to text rendering feature.

                                                                                                                SLIME (https://github.com/slime/slime). Having programmed commercially for two decades in C, Perl, C#, Ruby, Java, JavaScript (and CoffeeScript), Clojure, and VBA in a wide range of editors and IDEs, I’m happy saying SLIME is my favourite. Now I’m “post-technical” (contracting as an engineering manager and technical product manager, entirely off the tools) I only program recreationally, and SLIME and Common Lisp on Emacs are my go-to tools.

                                                                                                                Multi-term (https://github.com/manateelazycat/Multi-term). Almost (I’m looking at you, dpkg) all CLI tools run happily inside terminals inside Emacs, all managed with multi-term. This also allows easy scripting of terminal sessions in, of course, Emacs Lisp.

                                                                                                                Elfeed (https://github.com/skeeto/elfeed). A fully featured RSS/Atom feed reader inside Emacs.

                                                                                                                ERC (https://www.gnu.org/software/emacs/manual/html_mono/erc.html). An IRC client for Emacs. Now built in.

                                                                                                                The joy of doing everything in Emacs is how seamless and easy it is. For example, if you have an email open and want to create an Orgmode TODO linking to it, that’s just one keyboard shortcut away.

                                                                                                                Next up, I’m planning to move my Slack (yech, ptooey) workflows into Emacs with slack.el (https://github.com/yuya373/emacs-slack).

                                                                                                                edit: Oh, nearly forgot Magit (https://magit.vc/). I’ve used a bunch of Git UIs and this is the only one I rate as better than the CLI. It departs from Emacs’ usual approach of abstracting SCM details, but in so doing exposes all the power of Git.

                                                                                                                edit: Oh, and Emacs runs anywhere. I have the same Emacs config running on my client-issued Mac, my personal ThinkPad W540, an ancient ThinkPad R51 which I love for writing because of the 4:3 screen, several Raspberry Pis, a few EC2 instances, my phone (a PinePhone), and in the past MS Windows boxen too. Running locally or over SSH in console, It Just Works.

                                                                                                                1. 5

                                                                                                                  Multi-term

                                                                                                                  Sorry to plug my own thing, but I wrote sane-term[0] in response to multi-term clobbering keybindings years back. Its about 1/10 the code size and it cycles terminal windows, which is all I wanted out of multi-term.

                                                                                                                  Otherwise our setups are similar.

                                                                                                                  [0] https://github.com/adamrt/sane-term/

                                                                                                                  1. 4

                                                                                                                    Plug away, that’s how people learn about new tools :) I’ll take a look, thanks.

                                                                                                                  2. 3

                                                                                                                    Looking at the tools you are using now makes me wanna try them out :) I haven’t really tried emacs but now I might

                                                                                                                    1. 1

                                                                                                                      Enjoy it :). And if you’re after help, check out the Emacs IRC channel on Freenode and the Emacs Stack Exchange.

                                                                                                                  1. 3

                                                                                                                    I’ve use my Macbook Air 2018 (previously 2011) as a browser and a dumb terminal to my Linux workstation at Digital Ocean, via mosh/tmux. Its just an Emacs instance running and everything happens inside that.

                                                                                                                    I use a Mac instead of OpenBSD on the desktop for Photos (and iPhone/iCloud sync of them), TablePlus, Messages, Spotify, Netflix, Teams and other minor hiccups. I dream of getting to use OpenBSD full time some day though.

                                                                                                                    Mostly Python, Go and terraform development.

                                                                                                                    1. 3

                                                                                                                      I love my MacBook Air 2018 too. 2 CPU cores and 16 GB is enough for me. It’s a perfect laptop with only one issue: the keyboard. I will try their replacement program someday.

                                                                                                                      If I had to buy a new computer now I’d get the 2020 version with the new keyboard and maybe a quad core CPU.

                                                                                                                      1. 2

                                                                                                                        I heard they replaced it with there new magic keyboard or maybe I could be wrong

                                                                                                                        1. 1

                                                                                                                          You’re right! The MacBook Pro 13 is the only laptop they are still selling with a butterfly keyboard. Other models are fixed.

                                                                                                                        2. 1

                                                                                                                          I had to get my keyboard replaced already. Still sucks. I have a HHKB I’ve used for many years that I love. But recently got a Ergodox-EZ. Haven’t used it much yet, as my productivity drops to zero when I use it.

                                                                                                                        3. 1

                                                                                                                          Oh nice I mostly write python so getting the macbook won’t be problem. I currently have dell xps13 with linux running on it

                                                                                                                        1. 2

                                                                                                                          I’ve found that I split my time between the command-line and magit in emacs.

                                                                                                                          1. 1

                                                                                                                            Can I ask what things you use the command line for? Just curious, not doubting you or anything. I’ve used magit for 10+ years and I don’t think Ive used the git command line in 8+ years. Magit definitely introduced me to alot of git features that are so trivial to use and would be a nightmare to do via the command line (IMHO).

                                                                                                                            I think I can say magit is my all time favorite piece of software. It kind of acts as the hub for all of my development. I should probably go donate again right now.

                                                                                                                            1. 2

                                                                                                                              Absolutely.

                                                                                                                              I think that the driver is that I’ve reached my limit (buffer’s full, loosing neurons, etc..) in the number of magic short keystrokes that I can remember. I learned git on the command line before I discovered magit.

                                                                                                                              I’ve never been big on aliases and shortcuts and etc, it’s easier for me to remember N+M things and how to combine them than it is to remember N*M aliases and etc…. I hang onto nouns and verbs easily (although git commands are, well, irregular…).

                                                                                                                              I also like to be able to do these things on minimally-configured machines, on remote systems, and/or in other people’s accounts so leaning hard on any gui is a personal anti-pattern. I can even use vi in a pinch… ;)

                                                                                                                              By way of a list:

                                                                                                                              • I almost always stage and commit from a magit buffer (partial staging is a godsend).

                                                                                                                              • If I interactive rebase, I do it in magit.

                                                                                                                              • I probably create/switch branches about 40% of the time in magit.

                                                                                                                              • I generally git init from the command line.

                                                                                                                              • I have an alias, ‘git hist’ that I use to get an overview of the branching structure from the command line. I’ll sometimes poke around and do the equiv. in magit but not often enough that it sticks. From my ~/.gitconfig:

                                                                                                                                [alias]
                                                                                                                                # From Ricardo Signes
                                                                                                                                hist = log --all --graph --color=always --pretty='[%C(cyan)%h%Creset]%C(bold cyan)%d%Creset %s'
                                                                                                                                shist = log --graph --color=always --pretty='[%C(cyan)%h%Creset]%C(bold cyan)%d%Creset %s'
                                                                                                                                
                                                                                                                              • I git rm from the command line.

                                                                                                                              • I nearly always git fetch and git merge from the command line.

                                                                                                                              • git push seems to be split about 50/50, depending on what window is focused.

                                                                                                                              1. 1

                                                                                                                                Cool thanks for the explanation. That makes sense. My workstation is a remote machine at digital ocean that I use ssh(mosh) and tmux with emacs always running. So my computers just act as a browser and gateway to that workstation, where all the work actually happens. I don’t use other peoples computers ever so I think its easier for me to work the way I do.

                                                                                                                                Have a good weekend!

                                                                                                                                1. 1

                                                                                                                                  Interestingly, I am also split between magit and the command line, and where the splits occur for me are almost identical to this list! The only major thing I would add is that I tend to do all my remote adding/editing/removing from the command line as well.

                                                                                                                                  1. 1

                                                                                                                                    Oops, remotes…. Yep, command line (though my usage is pretty simple…)

                                                                                                                                    Great minds think alike!

                                                                                                                                2. 1

                                                                                                                                  One other thought on rereading your question….

                                                                                                                                  alot of git features that are so trivial to use and would be a nightmare to do via the command line (IMHO).

                                                                                                                                  I strive to organize my work so that I rarely have to do anything nightmare-ish. Basic nvie style git flow and it’s derivatives.

                                                                                                                                  My only common dirty trick is when I forget to create a branch and drop a bunch of commits on my base branch. It happens often enough that I can do the recovery dance from memory and it’s not really nightmarish.

                                                                                                                                  I’m curious, what git features you use that are trivial in magit and really difficult on the command line. The only ones that come to mind for me are interactive rebase and staging/committing an unfortunate conglomerate of work in bits, which are both way easier in a “tui/gui” environment.

                                                                                                                                  1. 2

                                                                                                                                    I’m curious, what git features you use that are trivial in magit and really difficult on the command line.

                                                                                                                                    Not the parent, but for myself:

                                                                                                                                    Increasing/decreasing hunk sizes and selectively choosing what hunks to stage/unstage is the biggest one for me. I still use git a lot on the command line but its interface for doing this stuff is… not good. magit is stupid easy +/- (s)tage (u)nstage etc… also ediff and conflict resolution via magit is rather nice as well.

                                                                                                                                    1. 1

                                                                                                                                      Absolutely, that’s what I’d shorthanded as “partial staging….”

                                                                                                                                      1. 1

                                                                                                                                        Gotcha, wasn’t clear what you meant there. But another bit thats nice is undoing/redoing things from prior commits as well. Its all really well done in magit. As well as getting stuff out of stashes/etc….

                                                                                                                                        1. 1

                                                                                                                                          Face it, it’s all nice :)

                                                                                                                                          It’s been great to read what bits other folks use.

                                                                                                                                          1. 1

                                                                                                                                            Heh, sure, I use more than this to be clear but the overall hunk handling in magit is…. I think divine is the best word I can think of. I still use the command line though, I’ve a ton of old aliases for drilling through histories that magit really doesn’t help with. As well as just being able to deal with using git plain on systems where my local emacs setup isn’t available is also nice. I’ve never been big on getting so used to other tools that I’m incapacitated when I don’t have my preferred thing.

                                                                                                                                    2. 1

                                                                                                                                      I’m curious, what git features you use that are trivial in magit and really difficult on the command line.

                                                                                                                                      You mentioned staging/committing, but even for me, just seeing what is changed and staged is a big help. It’s better than “git status” because everything is nicely presented – you can collapse and expand sections as you want. You can even hit enter on a diff hunk to go to that hunk and edit it! As you mentioned, you can stage/commit, but I like it even when I want to commit everything, not just when I’m dealing with “an unfortunate conglomerate of work”. I like to review my changes before staging them, even when it’s not an especially complicated set of changes.

                                                                                                                                      1. 1

                                                                                                                                        Don’t want to leave the impression that ‘unfortunate conglomerates” is my general modus operandi, it’s definitely the oops.

                                                                                                                                        In the usual, neat, case I find myself splitting between exploring them in magit and just scrolling the output of git diff in a terminal window.

                                                                                                                                        1. 1

                                                                                                                                          Oh, definitely. It didn’t come across that way. I just wanted to point out that I find magit a better experience not just for unusual, disaster-recovery situations.

                                                                                                                                      2. 1

                                                                                                                                        I said “nightmare” above but that’s definitely an exaggeration. Most of these have been mentioned. But I think for me it comes down to not context switching. I can just do what I want with a couple keystrokes without dropping to the command line and remembering git syntax. Maybe that syntax is so ingrained for you guys, like the magit keystrokes are for me so, in the end it comes down to being comfortable.

                                                                                                                                        Interactive rebase (and the tons of features this provides), stashes, rebase and merge conflict resolution, cherry picking, hunk staging, visual representation of the entire project state.

                                                                                                                                        But we all just work different. I’m not trying to convince anyone to change their workflow. I was just curious. I’ve seen people here say they use diff or log in the command line for example. Which I find odd since instead of switching to a terminal and typing a command you can just press tab on a file and see the diff and press enter to go to that place in the file or s to stage it. Using the command line here just feels like extra work, especially if there are 5+ files you are diffing. There just seems to be way more value in using magit for this (IMHumbleO). Same with l l for log. But with using magit’s log you can scroll up and down, press enter on a commit, etc. Where as on the command line you have to look for SHA hashes to get the code in that commit, or count how many commits to use HEAD~x.

                                                                                                                                        They just feel like and extension of where I am. And none of the magit features seem, to me at least, to have any shortcomings or trade offs. It just feel likes a complete win.

                                                                                                                                        Sometimes I get ingrained in my workflow it seems like the only logical one, which is obviously not true and a dumb mindset for me to have. Thanks for sharing.

                                                                                                                                  1. 3

                                                                                                                                    Interesting find! So the service in question was not only running as root, but the webserver/app wasn’t even chrooted. Reminds me a bit of the Apache phf exploit from 1996. People, always wear your seatbelt!

                                                                                                                                    Just as an aside, and I know this article isn’t about any particular language, but Go makes it trivially easy to get a webserver running - but it’s not chrooted and runs as root. Would be nice if it were trivially easy to get a webserver running with basic defenses.

                                                                                                                                    1. 2

                                                                                                                                      You can listen on high ports as an unprivileged user and redirect traffic at the firewall (I do this for my Go servers in production).

                                                                                                                                      1. 2

                                                                                                                                        but Go makes it trivially easy to get a webserver running - but it’s not chrooted and runs as root.

                                                                                                                                        If it was dev you’d be at a port above 1024, so a regular user would run it. And if it was prod, wouldn’t you drop privileges after start via your service manager?

                                                                                                                                        Or were you just saying how easy it is to just sudo ./web-server

                                                                                                                                        1. 1

                                                                                                                                          …or use authbind and not worry about privileges at all.

                                                                                                                                        2. 1

                                                                                                                                          One of the downsides of chroot is that it’s not implemented on Windows, so it’ll make your webserver not cross-platform. I’m not sure what alternatives there are for Windows?

                                                                                                                                          1. 1

                                                                                                                                            Docker containers usually run their local system as root, and most compiler services I know of run in Docker containers or something similar. Eventually we’ll get to a capability-based reality where you have to explicitly grant permissions rather than explicitly taking them away, but we’re not quite there yet.

                                                                                                                                          1. 3

                                                                                                                                            Downloads bin img lib sites src tmp torrents who www

                                                                                                                                            1. 1

                                                                                                                                              Very similar to mine, except I use tmp as downloads. What’s in the who folder?

                                                                                                                                              1. 5

                                                                                                                                                it’s my white/yellow pages. nested directories starting with last names or handles. i run a variant of research unix http://man.cat-v.org/unix_8th/7/tel to search an index generated by a cron job.

                                                                                                                                                1. 2

                                                                                                                                                  Can you share this (and perhaps others) script?

                                                                                                                                                  1. 2

                                                                                                                                                    each final directory under who/ contains files like addr, email, tn, etc. cron runs http://plan9.stanleylieber.com/rc/nutel >$home/lib/tel to update the index. search using https://code.9front.org/hg/plan9front/file/754916eeedf1/rc/bin/tel

                                                                                                                                            1. 9

                                                                                                                                              Fun stuff! I’ve been meaning to do a write-up on this but haven’t gotten around to it yet. I may not be a master, but I maintain a number of themes (base16, monokai-pro, and grayscale being my favorites).

                                                                                                                                              My config has gone through a number of revisions both in and out of org-mode, with evil-mode, with normal bindings, etc. This is where I’ve settled for the time being.

                                                                                                                                              https://github.com/belak/dotfiles/tree/master/emacs.d

                                                                                                                                              Advantages to a config in org-mode: everything is in one file, org is amazing, and it’s easy to leave comments in a format that allows for more than just text.

                                                                                                                                              Disadvantages: everything is in one file, completion and linting of code blocks has never worked quite right in org files for me, and it can be slower

                                                                                                                                              Here are a number of things I can recommend for every config:

                                                                                                                                              • use-package - this makes config much easier and is the reason separate files works for me. It makes it easy to separate packages into different blocks (the main advantage you get from org-mode blocks) and removes a lot of boilerplate often used to speed up config loading.
                                                                                                                                              • straight - this is an alternative to package.el. It’s at least worth looking into. I’m using it because it makes it a lot easier for me to maintain my own packages without having a manual cloning process.
                                                                                                                                              • ido, helm, or ivy/swiper - pick one of these. ido is built-in but there are lots of good packages that expand it. helm is a huge package that does a ton of awesome things and ivy is a lighter weight package that’s still fully featured. I prefer ido because it’s fairly minimal.
                                                                                                                                              • If you want code completion, company-mode is amazing. I’ve been moving away from this for performance reasons, but I may revisit it later.
                                                                                                                                              • flycheck does an amazing job with linting.
                                                                                                                                              • magit is the best git wrapper I’ve used… ever
                                                                                                                                              • projectile made project navigation super easy. I would strongly recommend this for anyone who sometimes works in multiple projects at a time.

                                                                                                                                              If you’re looking for a good config framework, there are a few really solid ones I’ve used in the past, but I’m picky so I don’t tend to use them:

                                                                                                                                              • doom-emacs is a well-maintained project built on a really solid base that gets tons of updates. This is evil-mode focused but recently had better emacs bindings submitted as well.
                                                                                                                                              • spacemacs is evil-mode focused, but also has emacs bindings. It’s tried and true.
                                                                                                                                              1. 4

                                                                                                                                                I’ve tried spacemacs, although i like it, I think its too much magic. I would like to get my hands in and learn how to configure things myself.

                                                                                                                                                Thanks for sharing your config. If you ever write a blogpost, please share it in the community!

                                                                                                                                                1. 2

                                                                                                                                                  Thanks for grayscale. I’ve been using it exclusively for a long time.

                                                                                                                                                  1. 1

                                                                                                                                                    grayscale looks very zenburn’ish to me…

                                                                                                                                                    1. 1

                                                                                                                                                      Yep! I ended up using the zenburn colors as highlights. The general idea was taken from the original duo themes for atom where brighter colors are supposed to be “more important”, but even after that, there were still things like warnings, errors, diff colors, etc… so I went with the zenburn colors because I found they worked well with grayscale.

                                                                                                                                                1. 3

                                                                                                                                                  I use git all day every day and appreciate it. The only thing that really stood out to me in these notes was the --end-of-options option. That seems like a really inelegant solution to this problem. I hope it doesn’t catch on. Obviously they have backwards compatibility to worry about. Seems like restricting branch names on future branches would be a better solution, but I’m no expert.

                                                                                                                                                  1. 1

                                                                                                                                                    The only thing that really stood out to me in these notes was the –end-of-options option.

                                                                                                                                                    The UNIX Way[tm] is to use --, but git already used that to separate branches from filenames.