1. 8

    I use Fastmail, which doesn’t support wrapping. I don’t think it’s a particularly good idea to wrap at 72 chars (it is a display preference so it should be a receiver-side matter), but on lists where that’s the norm I just compose the email in my text editor and use the reflow feature.

    1. 5

      When you’re in the webmail editor in Fastmail and you’re in plain text mode, you can hit C-m to hard-wrap the email. When I get some time I’ll send a patch to the website to add this info.

      As for format=flowed they said it wasn’t worth implementing 2 years ago, but things could change.

      1. 5

        And thanks to hard wraps, the e-mail will be harder to read on non-standard resolutions like in mobile phones.

        1. 1

          I think the vast majority of the email clients mentioned on the website do hard wraps, no? The only alternative to hard wraps is format=flowed AFAIK (tell me if I’m wrong) and, based on Fastmail’s 2 years-old blog post, it sounds like very few clients implement it?

          1. 1

            Yes, lots of software does hard wraps, but that doesn’t make it a good thing. I’m often using NeoMutt with Vim, but I specifically disable hard wraps, I’m enabling only soft wraps.

            1. 1

              “soft wraps” is when the receiving client does text wrapping, just like any text editor, right? (i.e. the sender didn’t include any line returns in their paragraphs?). I’m confused as to why this isn’t the recommended default? (i.e. make people send email without line returns, and configure their client to do soft wrapping).

              For example, the author of the plaintext.email website asks people to hard-wrap their emails when sending to sourcehut mailing lists, when it seems to me it would be vastly superior to let receiving clients do soft wrapping on the fly so that it works with any type of display width? Am I missing something?

              1. 1

                If you’re missing anything, then I’m missing the same thing as well. I see no reason why the client shouldn’t be able to perform soft wrapping by its own.

                Using 80x25 terminal? No problem, I’ll wrap the text for you to fit your current terminal. Using variable font width and a mobile phone? No problem, I’ll just wrap the text for you accordingly.

                I mean, Lobste.rs comment box does soft wraps and there are no problems with that. I.e. I can’t imagine why anyone would want to enable hard wraps in Lobste.rs comment box? Similar to this, I don’t see why anyone would want to enable hard wraps in e-mails as well. If some software doesn’t support soft wrapping, it seems it’s a broken software, because vast majority of e-mail applications DO support soft-wraps.

                One weak argument could be used that it’s more convenient to read text when it’s placed inside a column instead of spanned across large wide-screen monitor. But then you can just instruct your software to wrap the email to 80 characters and you’re done, no need to include CR/LF inside the e-mail. And if one’s software doesn’t support it, just resize the window and you’re done!

                As for plaintext.email website, the author has lots of opinions that are directly opposite to mine, so I can’t really explain the rationale for most of the arguments :)

                1. 1

                  I can’t imagine why anyone would want to enable hard wraps in Lobste.rs comment box?

                  If you read a suitably nested comment thread on mobile, you end up with a word a line, then a few letters on a line. This would be a good reason to not infinitely soft wrap.

        2. 1

          I just tried this and it works great, thank you for the information!

      1. 0

        I tried out mutt a few weeks ago. It was blazing fast and I was excited to be able to use powerful macros. However, there are many emails I get that I want to be in HTML - my company newsletter and film newsletters to be exact. The escape latch from text is not easy to use in mutt. It requires setting up a trigger to save the email to a file and open it in a browser. We have to acknowledge the reality and see that people do want to receive some emails in HTML.

        1. 4

          I use mutt and here’s what I do: I have a .mailcap file with the following entries:

          text/html;/usr/bin/lynx -force-html %s
          text/*	copiousoutput
          

          Then within mutt, if I’m reading an email I know is in HTML, I hit ‘v’, then select the HTML section and it launches lynx with the HTML portion. All other text types are handled by mutt directly.

          1. 1

            This does help with HTML-formatted mostly-text emails. But my point is that many emails I want to read have images in them and I want the full fidelity of a browser to read them.

            I had previously tried: text/html; /usr/bin/google-chrome ‘%s’; test=test -n “$DISPLAY”;

            1. 1

              I have the same problem as you: I subscribe to a bunch of newsletters about movies and comics and it’s kind of the point to receive an HTML email that can show you the pictures. I also tried mutt and was almost happy with it until I ran against the arcane knowledge of mailcap files and my inability to make a config that (1) works and (2) is cross-platform (since I’m using an obligatory dotfiles repository across my machines). I’d looooove for someone to write a tutorial for that kind of stuff.

            2. 1

              Instead of viewing the HTML in a browser you can dump it into the pager:

              muttrc: auto_view text/html alternative_order text/plain text/html

              mailcap: text/html; links -assume-codepage utf8 -dump %s; copiousoutput

          1. 8

            293,000 lines of code and 50 third-party dependencies for a closed-source proprietary fork of a GPL-licensed project?

            1. 0

              The fork of XBMC is far behind. If we are to trust what Elan said here and there on the forums (we don’t have to but he doesn’t have any reason to lie either), they have rewritten enough of the server and client code that there’s not much left from the original codebase. Plus, AFAIK, the mobile/TV/misc clients were written from scratch. Plex and Kodi are now two completely different things who cater to completely different audiences anyway.

              1. 1

                Does XBMC/Kodi have a server component? I thought it was basically client-only.

                1. 1

                  It is indeed client only. But Plex basically started by splitting that codebase in 2, separating the database part from the client side, so you could have multiple clients connect to it. Plex was OS X only at that time. Then they branched out to all kinds of other clients Kodi didn’t run on, added a whole bunch of stuff to the server (automatic offline sync is what sold me on it… always get new episodes of TV shows on your tablet to watch during your morning commute!), etc.

            1. 8

              I’ve had to work a bit with mercurial over the last few months, and I really don’t get it’s appeal. It seems like git-lite, but it’s written in Python – somewhat contradictory, imo? Does anyone here have better experiences, or could give real-life examples where you used, e.g. Git and thought to yourself “I wish I was using mercurial”?

              For example, compared to Fossil, I get the benefits: everything is stored in one sqlite file, allowing atomic transactions. Repositories may have integrated wikis, forums, etc. and there’s a built-in web interface by default too. It’s different, what makes it interesting. Hg just seems too similar…

              Edit: To clarify, I’m not saying hg shouldn’t be used, or that it’s bad. I was just wondering about it’s major differences to git.

              1. 26

                Here’s a list of Mercurial features that I think are really cool:

                • Revsets – a domain-specific language for querying your commits
                • Templates – a domain-specific language for altering the output of almost every command. Putting together these two you can do things like this.
                • Evolution – a distributed and safe way to share rewrites (think automatically recovering from upstream rebase without any git reset --hard and no git push --force).
                • Absorb – automatically amends an entire stack of WIP commits at once by picking the right diffs from your working directory based on which commits’ contexts they fit best.
                • Curses interface for hunk-picking – a unified interface for splitting diffs for any purpose: whether to revert working-directory changes, write a new commit, uncommit parts of a commit, or amend a commit with more diffs. Just add --interactive to any of those commands and start picking hunks!
                • A fairly rich built-in web interfacehg serve and point your browser to http://localhost:8000 and you’re good to go.
                • Lots of support for monorepos – indeed, this is the main reason that Google, Facebook, and Mozilla are all pouring work into hg and are using it.
                • A consistent UI – this one is more subjective but often-touted feature of Mercurial. If a command accepts a revision/hash/tag/bookmark; it always uses the -r/--rev flag for it (and you can also always use a revset for any command that accepts a revision). If a command allows hunk selection, it always uses the -i/--interactive flag for it. The help for every command fits in about a screenful.

                Give it a try! Mercurial is neat!

                1. 4

                  Nice Summary!

                  From my perspective two things are really important:

                  • Easy to write and rich plugins, distributed configurability, and generally much better windows support is a major consideration when introducing a DVCS into a larger organization.
                  • Evolve. This is a really fresh approach to the end-user workflow. When you get out of Git mindset and switch to evolve things get really exciting.

                  It’s also great that Mercurial was added into sr.ht. Lack of tools and solutions if hitting Mercurial for years now. Having something new makes me happy.

                  1. 2

                    Give it a try! Mercurial is neat!

                    I did, but it was weird (to me, I’m not saying it’s generally bad!), since I’m not used to it. The documentation seems to be all over the place. Could you recommend a starting point for someone coming from git?

                    1. 5

                      Not that I’ve ever made enough progress against my own git bias, but @sjl has some blog posts (http://stevelosh.com/blog/) worth checking out or Gregory Szorc’s posts (who has lots of experience with git and hg).

                  2. 14

                    (disclaimer: I’m the one who worked on this hg.sr.ht with @SirCmpwn)

                    There are many things that have alternatives, and having alternatives is generally a good thing. I appreciate Mercurial for its more friendly CLI (I have to lookup Git man pages a lot more), better cross-platform support (although Git has gotten better lately), revsets language (as @ngoldbaum pointed), extension ecosystem (I myself wrote a couple of extensions that make my life easier), template language (to make output pretty the way I like), and phases/changeset evolution. Of course it also has downsides compared to Git so really YMMV as they say.

                    But yes, if you use Mercurial the same way you use Git, it will definitely feel inferior (and vice versa). And if you stick to the basic minimum (clone/commit/push/pull/resolve, maybe a bit of rebase and branching here and there) then they both look so similar that you might wonder why both exist at all.

                    1. 5

                      As I mentioned in my edit above, I’m not saying adding this was wrong in any way. It was more of a curious enquiry as to why people here like hg.

                      Considering that 95% of everything I do with Git nowadays is mediated by Magit, most of these features seem less important to me. Revsets seem interesting, but it doesn’t seem to be something that’s only possible due to an intrinsic architectural decision behind mercurial, or am I wrong. Any git porcelain could implement such a thing, as far as I understand what it’s about.

                      But you’re probably right, since I was only using “the bare minimum”, and then had to do something more than that (accidentally pushed a commit I didn’t want to), I was frustrated, since I was thinking in git-mode, and couldn’t find the documentation to quickly fix the issue. But the same would have happened if I was a regular-hg user that had to switch to git temporarily, so it’s quite meaningless.

                      1. 4

                        Oh yeah, nothing prevents Git from implementing revsets fairly easily – and people on the #mercurial IRC channel were just saying it would be great if Git could steal that idea from Mercurial, among others. I mean that’s the whole point of having alternatives, each one can steal the other ones’ ideas.

                        I also find the Mercurial documentation hard to navigate (although thankfully I don’t need it too much since the CLI docs make enough sense to me). The online Git documentation is much better IMHO.

                    2. 7

                      It seems like git-lite

                      Mercurial is not meant to be a Git-lite, nor was it even ever meant to replace Git. Instead, Mercurial and Git were both designed to replace Bitkeeper. They differ a month in age, and are based on the same commit DAG model; you could say they grew up together.

                      Does anyone here have better experiences, or could give real-life examples where you used, e.g. Git and thought to yourself “I wish I was using mercurial”?

                      The most recent time I used Git and thought ‘I wish I could use Mercurial’ was last Tuesday, when I had to explain to a merging colleague how to get a copy of a file (not modify the existing one) as it was in an older commit. I know the answer, I thought, I already know the git show command! So I ran, from the same directory as the file,

                      git show abc123:myfile.ipynb > myfile-abc123.ipynb
                      

                      and got

                      fatal: Path 'src/myfile.ipynb' exists, but not 'myfile.ipynb'.
                      Did you mean '232279:src/myfile.ipynb' aka '232279:./myfile.ipynb'?
                      

                      . So instead I had to run

                      git show abc123:./myfile.ipynb > myfile-abc123.ipynb
                      

                      . Most Git commands assume paths are relative to your current working directory — but git show instead assumes paths are relative to the repository root, unless they start with an explicit ./. Because of the syntax inconsistency, knowing the command was not enough to use it correctly. That made me think ‘I wish I could use Mercurial’.

                      PS: my colleague didn’t ask why git checkout and git show are different in how you specify the revision. I wouldn’t have known the answer.

                      git checkout myrevision -- myfile  # revert file to old version
                      git show myrevision:./myfile       # print old version to stdout
                      

                      In Mercurial, for comparison:

                      hg revert myfile -r myrevision  # revert file to old version
                      hg cat myfile -r myrevision     # print old version to stdout
                      
                      1. 3

                        For years I used Mercurial, mostly for personal projects, or small scale ad-hoc collaborations.

                        My points:

                        • Python means good, portable unicode support for commit messages and comitter names.
                          In an international team and in the 21st century this is a must for me. With git I still see broken characters even for latin characters in comitter name. The american cultural imperialism prevalent in IT/CS in the sentence “just use ASCII” is unacceptable to me, and I still encounter this especially in UNIX circles.
                        • Web interface presented by hg serve is the same as the one used for remote push/pull operations.
                          with small collaborations sometimes with limited internet connections having both a web interface and remote push/pull working with zero effort is a killer imo. Also it is a nicer implementation to have a repo as http://my/repo , but with git for clone you usually have http://my/repo.git and web interface of your choosing at http://my/repo.
                        • the UI s far more convenient than git’s. The index in git, stateful commit preparation simply does not make sense to me. I can do that in a GUI where I see diffs inline. It could have been done with a different helper tool for git, but having it in the git command does not seem logical/convenient to me.
                          the git command arguments are totally convoluted, they are not organized in a single universal way, or at least I cannot comprehend that. hg commands have nice CVS like short aliases, and this makes working with hg convenient for me. I have git aliases on my machine but when trying to help someone else I always find them missing.

                        I’m a bit sad that git became the defacto standard, as I personally found hg more convenient and suitable to the workflows I use. I think the main points cited as git’s benefits are al bad practices, though I can accept that someone has a workflow where those are handy. In the PR based workflow with squash merges which I prefer hg and git are equivalently suitable.

                        1. 3

                          Whenever I have to dig out something from history in git I wish I had revsets: https://www.mercurial-scm.org/repo/hg/help/revsets

                          Git has about a million options to log to do the ~same thing, but almost every mercurial command accepts revsets, so you can use them all over the place. Say I want to rebase the commits on this branch that had this author but not this author onto this other branch. With hg it’s easy, with git I think I might need a shell script.

                          1. 1

                            but almost every mercurial command accepts revsets, so you can use them all over the place

                            Ok, that sounds neet, I have to say. But I don’t see why git couldn’t do the same?

                            1. 2

                              It totally could. They just haven’t yet.

                          2. 1

                            I think it’s entirely personal preference. There are tons of arguments online about why each is slightly better than the other, but in practice they’re virtually equivalent.

                            It seems like git-lite, but it’s written in Python – somewhat contradictory, imo?

                            Not sure I understand what you mean there.

                            1. 3

                              Not sure I understand what you mean there.

                              Maybe it’s just be, but when something has to be lightweight, it shouldn’t be running in an process-based interpreter, but should be compiled. But that’s just my view.

                              1. 3

                                There is some work to move parts/most of mercurial to rust see: https://www.mercurial-scm.org/wiki/OxidationPlan

                                Also, Mercurial existed before git did. Linus decided against mercurial mostly because it wasn’t “fast enough” for his use case, the linux kernel tree. So he wrote git, instead of just speeding up mercurial.

                                1. 8

                                  Also, Mercurial existed before git did. Linus decided against mercurial mostly because it wasn’t “fast enough” for his use case, the linux kernel tree. So he wrote git, instead of just speeding up mercurial.

                                  It depends what you mean by “exist”. The git prototype came before hg, but hg was self-hosting before git. The details can probably be excavated from the LKML, but I remember there is like a one-month gap between the first mention of git followed by the first mention of hg.

                                  Matt Mackall, original author of hg, chose Python because it let him build an interface quickly. Linus was never particularly bothered about an interface, so he just built the data structures out of C and shell. For a long time, the only way to build a git commit was to run a bunch of ad-hoc shell scripts in turn for creating blobs and trees.

                                  1. 7

                                    For a long time, the only way to build a git commit was to run a bunch of ad-hoc shell scripts in turn for creating blobs and trees.

                                    For a git n00b like me, it feels like not much has changed in that regard ;)

                          1. 2

                            I use old hardware because it’s “good enough” for everything I work on.

                            I have a ~10 year old workstation that I recently upgraded with an SSD and a couple GPUs from the e-recycling bin at my last job, but upgrading much more would just be a waste of time and money.

                            And, as the article points out, as a developer, I like using old hardware because it sets realistic performance expectations. If it’s fast enough on this machine, it should be fast enough for anybody.

                            1. 3

                              I ended up using old hardware without really realizing it because it was “good enough” indeed. Until very recently I still had a mid-2008 Macbook (the first unibody ones). I was mostly working on small CLI/web projects, but it did kinda force me to optimize my code a bit more than if I had a more powerful machine – getting that script to run under 5 seconds takes a little extra work on a 10 year old machine.

                              I just recently upgraded to a used 2015 Macbook (the last good Macbook model before the new keyboards and touchbars) mostly because the old one’s hinges and motherboard were failing.

                            1. 3

                              Thanks for this, however I still can’t understand how and why GNU Stow (or other similar dotfile managers or Ansible playbooks, etc) are better than a simple shell script. Precisely because I’m sharing my dotfiles across multiple devices, platforms, and operating systems I want them to be as platform agnostic and minimal as possible, and without any external dependencies. My script simply installs/symlinks everything and later I use git pull to sync changes across machines.

                              1. 2

                                Yep I also use an install script (although mine is in Python), the reasons being:

                                • I need to support 3 platforms (Ubuntu/Mint, macOS, Windows), with different things to install in different ways (or not at all) depending on the platform.
                                • In some cases, I find it easier to procedurally generate a dotfile that will point to a resource located in your dotfiles repo, instead of symlinking everything into a fixed/hard-coded location.
                                • A script can also manage your sub-repos (pulling/cloning), so that everything is done in one command.
                                • A script can optionally do a subset of something, so that if you want to just update, say, your tmux config, you can just run that and it will just pull your tmux plugins’ repos, redo the symlinks, etc., and nothing else.
                                1. 1

                                  It’s certainly not for everyone. I use it because its default behaviour matches my workflow perfectly, and there’s no need for a shell script. The only thing simpler than a simple shell script is no shell script at all!

                                  1. 1

                                    Unless I’m missing something you are creating an extra dependency before you can install (and manage) your dotfiles: Stow. I.e., you have to download, compile, and install from source or via a package manager. What if you have to use systems you’re not the admin for and have no sudo rights? Or Perl is too old (Stow’s requirement.) Or, or, or…

                                1. 1

                                  This is pretty nice. I appreciate the simplicity mixed with the innate usefulness.

                                  1. 1

                                    Thanks! :)

                                  1. 4

                                    If something doesn’t work the way you need, pick something else (or stick with what you have, no reason to always upgrade when new stuff comes out).

                                    1. 4

                                      exactly. But good thing is there are people trying these things and writing about so you can decide if a new toy tool could be something you could use or not

                                      1. 1

                                        Yep, especially since Apple is marketing this more and more as a laptop replacement, it’s good that people are reviewing those claims seriously… although I absolutely love my 1st gen 12.9” iPad Pro for things like drawing and reading PDFs/comics, it’s really a clumsy laptop alternative. Multi-tasking is annoying to use, you’re limited by the iOS sandbox, etc… it’s nice that some people find ways to port their workflows over and, hopefully, get a net benefit as a result (especially for people who are always on the go), but I will always reach for the laptop until there’s serious changes in iOS.

                                    1. 1

                                      After using a whole bunch of TODO systems (various online stuff, dating all the way back to when Remember The Milk started to more recently with ClickUp, and various local stuff like Todotxt), the one thing that I always come back to is indeed the good ol’ paper TODO list. Also because I have a couple of fancy expensive pens that I need to justify having bought :)

                                      The key for me however is to have a separate, thin notebook for TODO (like Field Notes… or something better if you use fountain pens), because otherwise I would mix up TODO items with general notes and then I lose/forget what I needed to do.

                                      1. 3

                                        $WORK: Optimize gameplay camera blending code on Xbox1 for the upcoming Anthem game

                                        $PERSONAL: Polish and properly ship support for incoming WebMentions in my PieCrust static website generator. Add support for outgoing WebMentions in SiloRider.

                                        1. 1

                                          Just makes me wonder how many people use mercurial at there company?

                                          Edit: from company I mean at work.

                                          1. 2

                                            Which company? Octobus? As per their website, there are only 2 people, and Pierre-Yves David (“marmoute”) is a well know core Mercurial contributor. The company itself is about providing commercial support for Mercurial, along with other stuff like Python contracting.

                                            1. 1

                                              I think mercurial definitely has a niche in a corporate space. It’s easier to train new people on than git, scales better for monorepo setups, is more easily extensivle via python, and allows richer customization.

                                              1. 2

                                                It’s easier to train new people on than git

                                                I am curious about this – while mercurial definitely has less initial surface area and a far more consistent way of interacting. It also tends to have lots of customizations that add a lot of complexity right back in – and mix and match them in ways that are often unique per mercurial setup.

                                                Git while far uglier, also has more training resources both professional and free. Additionally, while git is far less consistent in terms of interaction, to a far large degree once you know it – you know it. You are unlikely to go to a site where git has lots of customizations making it behave different than the “git” you used at your last organization.

                                                1. 2

                                                  Well you pretty much summed it up :) Mercurial is nicer/easier to use, but Git has more resources out there. I think at that point one being better than the other for a particular person or team will then depend less on the pros/cons of each tool, and more on the person/team’s mindset/culture/available support/etc.

                                                  I’d add that Git having more resources, while helpful, is as much a proof of its success as a symptom of one of its main problems. Having to look up help pages and other tutorial pages on a regular basis becomes tedious quickly, and they still need to fix the core problem (they can’t quite fix the broken CLI at this point, but I did note several helpful messages being added to the output in the last few versions, so there’s progress).

                                                  Finally, yeah Mercurial has a problem with the amount of customization they force on user because of their very strict backwards compatibility guarantees (resulting in a good portion of new features being turned off by default). This tends to be mitigated by the fact that teams will generally provide a central .hgrc that sets up good defaults for their codebase. Also, Mercurial extensions almost never change Mercurial’s behaviour (evolve is an outlier there but is still considered “experimental”) – they just add to it, so I’ve never come across (so far) any Mercurial resource that was potentially invalidated by an extension (feel free to point to counter-examples!).

                                                  1. 1

                                                    I suspect my issue might be more in my head (and my unique experience) than in reality. I have contracted with lots of git shops – and a fair number of mercurial ones. Most of the git shops worked very similarly, they differed in master dev versus feature branch dev, mono-repo or multi-repo – but they all felt similar and I could use very minor changes to my workflow to integrate with them, which is great for contracting.

                                                    Each mercurial shop has been a wild adventure in unique workflow, and brand new extensions I have never seen or used. One used TWO different sub-repo extensions, another one used THREE configuration extensions! On top of that, most of them had annoying/wonky authentication mechanisms (some hand-rolled). The reason I use those examples (which is only a fraction of what I have seen) is that are all basically non-optional. I needed to use them to be able to work on the project… and of course mq versus non-mq. Never used evolve (yet).

                                                    During the “will mercurial or git win?” – I was firmly on the mercurial side because I did work on Windows and git early on was non-function on it. But now when I hear a client is a mercurial shop, I dread it. But, I realize that is probably just my unique experience.

                                                    1. 2

                                                      Huh, well it’s very probable I’m just not aware of all the wild things people do out there with Mercurial. I frankly had no idea there were sub-repo extensions (outside of the core subrepo feature), and I don’t know why anybody would do custom authentication when SSH works everywhere (although I understand people might want to setup ActiveDirectory for Windows-only environments instead, but that’s it). What do you mean by “configuration extensions”? As for MQ, I don’t think it matters for the central repo, no? It should only matter for local workflows?

                                                      1. 2

                                                        According to https://www.mercurial-scm.org/wiki/UsingExtensions – there are at least 6 sub-repo extensions. And, yes, ActiveDirectory logins, other SSO variations and then on top of those multiple ACL layers.

                                                        As for MQ – absolutely you can avoid it with others tools that can produce the same sort of history… rebase, graft, strip, etc. The issue being if all the “how we work” docs are written in MQ style – it is a bit of mental gymnastics to convert over.

                                                        1. 1

                                                          Ah I see. And yeah I never really scrolled down past the non-core extensions :) (The only non-core extensions I have are a couple I wrote myself…)

                                                          1. 1

                                                            are a couple I wrote myself…

                                                            you… you are part of the problem! runs scared hehe

                                                            1. 1

                                                              Haha but that’s fine, I don’t think anybody besides myself are using them :)

                                                  2. 2

                                                    Might it instead be the other way around: that customization-seeking companies are more likely to choose Mercurial? This could be either because adventurousness promotes both non-Git and customization, or because Mercurial has the better architecture when you need to customize. IIRC the latter is true for both Mozilla and Facebook. Anyway, at my second job we used vanilla Mercurial, and we did fine. It was basically the same as any Git workflow, for that matter.

                                                    1. 2

                                                      Absolutely. Additionally, Mercurial is just more accessible in terms of customization. On top of that more than a handful of these shops had heavy Python contingents internally.

                                                      1. 1

                                                        Haha, yes, knowing the language certainly makes it easier to stray off the common path and into the woods of in-shop customization :-D

                                              2. 1

                                                I use Mercurial at work. My company uses Git, but I use Mercurial and clone, push, and pull transparently thanks to hg-git. I’ve noticed I am generally more aware than my Git-using colleagues of recent changes to the repo, because I’ve got a pre-pull hook set up to run hg incoming (with a tweak to avoid double network talk).

                                              1. 1

                                                Interesting that he’s concerned people will attack or some how create trouble for Mastadon. Without giving up enough info to enable this of be curious as to what kind of trouble he’s worried about.

                                                1. 1

                                                  I would assume he’s talking about the kind of abuse you see often on Twitter (anything from randos to sockpuppets to bots to whatever). The original idea was that we’re limited to whatever moderation (or lack thereof) the Twitter HQ decides to do on their network, and on the other hand, various admins of Fediverse instances can do various amounts of moderation, so finding a “good” instance would in theory protect you better from harassment than Twitter. But the reality is that blocking/muting people might be harder on the Fediverse, where it’s harder to track the people behind the accounts, and given that instance admins have little credentials to show for, you could potentially get your data (PMs, etc.) stolen more easily than on Twitter.

                                                1. 1

                                                  Sounds like a good time to finally set up my bouncer. If only there were one that had good Emacs compatibility.

                                                  1. 4

                                                    I just run weechat on a server and connect to the weechat relay with weechat.el. There’s a few bugs in weechat.el (e.g. nicks go out of sync) and some things missing (e.g. nick list), but that’s a small price to pay for replacing another standalone app with emacs :)

                                                    1. 1

                                                      I did this at the beginning but quickly switched over to ZNC because of bugs like that, the inability to have per-client history rollback, and other little details… I still use Weechat half the time on the client side though :) (I also use Textual on macOS, and Palaver on iOS).

                                                    2. 1

                                                      Znc is what I use with erc

                                                      1. 1

                                                        I’ve been trying to set this configuration up for half a year now, but I never get anything I’m satisfied with. The ZNC documentation is quite bad and confused, imo. And when I manage to set it up, even using ZNC.el it won’t work with IRCnet. Switching between multiple servers is another annoyance.

                                                        But maybe I’ve just messed up somewhere.

                                                      2. 1

                                                        I used to use znc, seemed to work just fine with ERC.

                                                        Now I use weechat (a bit more features, nice Android app), again with ERC. There is weechat.el, but I prefer ERC (connecting to what weechat calls an “irc relay”, instead of using the weechat protocol). I use https://gist.github.com/unhammer/dc7d31a51dc1782fd1f5f93da12484fb as helpers to connect to multiple servers.

                                                        1. 1

                                                          Ive used znc with Circe, works great

                                                          1. 1

                                                            What did you find in Circe that made it better than ERC or Rcirc?

                                                            1. 2

                                                              In case it’s useful - I used to use ERC, and I switched to Circe long enough ago that I can’t exactly remember, but I think the issue was that I wanted to connect to both freenode and an internal IRC server at the same time, and ERC made that awkward or impossible to do. It may well have improved in the last 5 years though.

                                                              1. 2

                                                                It was easy for me to setup and use so I stick with it. Never tried those other two

                                                          1. 4

                                                            IRC is great. It’s easy to implement a client for, simple enough to understand, and used pretty widely. It’s still the main protocol I use to keep in touch with people.

                                                            The only thing I wish that it would get is server side history, so I could scroll back in a channel without idling or setting up a bouncer.

                                                            1. 2

                                                              Early this year I finally broke down and subscribed to IRCCloud. They handle all the details of staying connected so you have access to channel history. Admittedly it works out to about 14 cents per day. Well worth it, in my opinion.

                                                              1. 1

                                                                I’ve been keeping an eye on IRCCloud – I currently keep a ZNC server running… playing with it has been quite fun and instructive so far, but I would be OK paying 5$/month for someone taking care of it all. I’m waiting for them to open up a bouncer service so we can connect with other clients than their official IRCCloud client… apparently it’s on their roadmap (see bottom).

                                                              2. 2

                                                                There are people working on a revised spec called ircv3, that aims to address those issues. I haven’t been in touch with that group, so I can’t speak to their progress or success.

                                                                1. 2

                                                                  I’m aware of ircv3, but I’m not aware of any proposal to add server side history to it – at least not one that’s gone anywhere. I’m sure someone cares about the other features, but they don’t really make a difference for me.

                                                                  Edit: And I found one: https://github.com/ircv3/ircv3-specifications/pull/292

                                                                  1. 1

                                                                    Uh, that is interesting. Thanks for sharing! I wonder if there are already any clients and servers out there.

                                                                    Also see this story: https://lobste.rs/s/zdkuil

                                                                    1. 2

                                                                      the rust irc crate aims for ircv3 support ;) (I’m trying to contribute to it (but outside of the v3 things))

                                                                      1. 1

                                                                        You mean this crate? https://crates.io/crates/irc

                                                                        1. 1

                                                                          Yup.

                                                                1. 3

                                                                  These days I post about IndieWeb tech, game development, static websites and other hobby web projects, and random miscellaneous stuff (since my blog also includes my microblogging). It’s here: https://ludovic.chabant.com/devblog/

                                                                    1. 3

                                                                      Ah nice way to apply the UNIX philosophy :) But yeah, I needed something more complicated to do stuff like uploading images, change title formatting, support filtering/tags/whatever.

                                                                    1. 3

                                                                      Wonder what he thinks of fossil and mercurial. The fossil author deliberately disallowed rewriting history; he makes a good case for it. At one time, Mercurial history was immutable too, but I believe this has changed.

                                                                      I guess my point is that there are DVCS out there that satisfy his criteria; they’re just not git.

                                                                      1. 5

                                                                        History can never be truly immutable so long as the data is stored on mutable media like a hard disk. Refusing to package tools that do it just makes people who need the feature find/build 3rd party tools

                                                                        1. 5

                                                                          Do you see people doing that? I mostly see people just accepting the limitations and dealing with it.

                                                                        2. 1

                                                                          The site seems down now :(

                                                                          About Mercurial, I believe it has always allowed rewriting history, but not by default — you have to change your configuration files to opt-in to all the “dangerous/advanced” features.

                                                                        1. 2

                                                                          You can think of the phases as totally ordered (secret → draft → public) and a commit’s phase can only move in that direction. That is, a secret commit can become either a draft or a public commit, a draft commit can become a public commit, and a public commit is “stuck” being public. (Obviously, Mercurial allows you to force a commit to any phase as well.)

                                                                          I hate when people say “obvious” or “obviously”. From that description it is not at all obvious to me why Mercurial allows you to force a commit to any phase. My first impression from that is, well then, that’s not much a feature if I can disregard it at any time.

                                                                          “Obvious” is so insulting. At best, you get some people nodding along and then a bunch of people also going “well, not sure what is obvious about that”.

                                                                          1. 4

                                                                            I personally read that more in the customer-service tone of “of course if you really want to do [X] we’re not going to stop you, so you can always force to override this” rather than in the mathematical “of course, [corollary] follows” tone, but I can see how it can be read differently.

                                                                            1. 1

                                                                              And it looks like the author changed “obviously” to “of course” now :)

                                                                              1. 1

                                                                                Having any statement like that is useless. “Of course” would make as much sense if Mercurial forbade forcing.

                                                                                It’s hard to stick just to the facts because interesting documentation often feels prosaic, though simply stating the way of things leads to less misunderstanding and head-scratching like “why is this of course?”

                                                                            2. 1

                                                                              That seems like a deep read with a strong reaction into one word, I think it probably says more about you than the author.

                                                                              1. 1

                                                                                I think you are being very dismissive.

                                                                                “Obvious”, “obviously”, and “clearly” are all problematic when writing or speaking.

                                                                                Best case scenario:

                                                                                Someone shares the same background as you do and it is obvious to them. In which case, you’ve gained nothing from the use of the word.

                                                                                Likely scenario:

                                                                                Someone doesn’t share the same background as you and it isn’t clear. For example, in this article, it is not all clear to me why you would design a system that would allow you to violate a state machine. At best here, the author did a poor job of explaining. “Obviously” here is standing in for a poor job of explaining a feature and its tradeoffs.

                                                                                Worst case scenario:

                                                                                Someone who is new to whatever the particular area is ends up feeling frustrated and gives up because they think it really should be obvious. If your goal as a writer is to teach people, you want to avoid this.


                                                                                Anytime I find myself reaching for “obvious” as a term I stop and think, “why do I think that is obvious” and then explain it, because, invariably it is never obvious to all the members of the audience I am trying to reach.

                                                                                1. 1

                                                                                  I think your critique of the word as a poor way to explain something is good and I think I agree with and I would have upvoted you if you just tried to offer a gentle suggestion on how to communicate better. I think it’s too far to say it’s “insulting” though. Someone is just trying to explain something and they used one word you have a problem with and now it’s insulting. Just because it triggered doesn’t don’t mean the author was anything other than just not realizing they used a word that didn’t help their explanation.

                                                                                  1. 3

                                                                                    I read what I wrote previously and it was overly short, poorly written and assumed too much about the audience. I was committing the same sin that I was complaining about in a different fashion.

                                                                                    1. 2

                                                                                      Thank you for being humble and thoughtful, I wish more internet discussions could be like this.

                                                                            1. 2

                                                                              Wait until I add a signature that shows my uptime.

                                                                              Also, it frankly took me a minute before realizing Lobsters didn’t have a PhpBB forum. I guess I’m really old.

                                                                              1. 2

                                                                                I started with a MediaWiki instance years ago but I had 2 problems: the fact that I started wanting simpler, text-file based storage (it doesn’t scale, but it’s nicer and good enough for personal content), and the fact that I wanted support for “metadata”… stuff like “tag my ‘project’ pages and then write a query that lists those pages in an index page”, which led me to SemanticMediaWiki and a bunch of other plugins.

                                                                                Eventually, I started writing my own wiki engine (don’t we all?), based on text files (Markdown + some templating/front-matter/etc.), Mercurial or Git storage for revision control, some basic user permission support, etc. Similar to a bunch of other similar things, basically, but with just a few different or additional things that make it work for me. The nice thing with SCM-backed wikis is you can edit locally in your favourite editor and push to the remote repo instead of using the Web UI. Mobile editing isn’t solved though – the Web UI is responsive but it would probably be better with a dedicated app (there’s a REST API for that if I ever want to go there). Anyway, it’s called “Wikked”, see here: https://bolt80.com/wikked/

                                                                                One nice thing is that it’s using an SQLite cache to not work things out of the file-system all the time, which makes it scale better than I expected. See some performance tests here: https://ludovic.chabant.com/devblog/2014/04/13/wikked-performance/

                                                                                I don’t work on it very often because it works fine on my server, but it may require a bit of bug fixing for anybody else. For instance, I use it with a Mercurial repository, so the Git backend is probably not totally functional out of the box… ping me in this case, I’ll be glad to help!

                                                                                1. 1

                                                                                  Checking back on TiddlyWiki it looks like they added a bunch of stuff like search and semantic queries, which was one of a big reasons I started writing my own engine. That’s pretty awesome!