This "integration" between vim and tmux seems like a misfeature. It is poorly thought out and I'm not surprised it could exhibit such a bug. I don't want tmux sending input to vi based on an unrelated action. Just as I wouldn't expect it to know what program was in the foreground and make lots of assumptions about how it works.
Wasn't it backwards? It's a vim plugin, so that vim knows it's running inside tmux. Honestly, I'm not sure which is worse, but I do agree that either integration would be misfeature.
> I don't want tmux sending input to vi based
> on an unrelated action. Just as I wouldn't
> expect it to know what program was in the
> foreground and make lots of assumptions about
> how it works
Architecturally, I agree. I don't want those things either. It's messy.
Practically, I find that I'm way more efficient with the messy integration enabled.
To be honest, I hit my tl;dr threshold on the article, and skimmed only the high level. But speaking personally, I've used vim-tmux-navigator[1] and some related setup on the tmux side[2a][2b] for years, and it's really, really nice. CTRL-{H,J,K,L} navigates seamlessly between vim splits and tmux panes. It works flawlessly, and I wouldn't be without it.
Put another way, there are a lot of tmux users who take advantage of it for its terminal pane management features on a local environment rather than the classic remote-session stability use case ala screen. In that light, some kinds of integration make a ton of sense.
These days, it vaguely annoys me that I can't just navigate between OS (macOS, here) windows by keyboard just as seamlessly. I haven't quite gotten around to solving the problem with Hammerspoon[3] yet.
I have to say, I can't understand the author's glee while investigating the bug. To me, bugs are a source of irritation. Like the author, I also like to get to the bottom of them instead of resorting to reinstalling and resetting a wide area of stuff to make it go away, but I do it because the existence of the bug is irritating. This person seems to do it because investigating seems to be a source of joy for them. For me, investigating is a frustrating necessity to fix the bug.
In the long long ago I used to enjoy chasing down bugs to their source and fixing them, but technology ground that out of me. I used to believe, deep down, that things generally worked and made sense so if I dug to the root of the problem and fixed it things would be better forever. Sadly, this is not the case. Instead complexity just keeps getting piled on top of complexity forever, bugs just get more frequent and harder to diagnose, and just about when you've finally ironed shit out some jackasses come along and decide to rewrite everything with a new layer of complexity or two in there.
Fuck that. I don't have time for this shit anymore. If it doesn't work and I can't fix it in a few minutes I just use something else or revert to a previous version. I don't even bother to file bug reports because it is my experience that no developer cares about bugs they don't personally encounter anyway, and regardless will make me waste even more of my time collecting logs and shit. There are major projects out there with paid developers working on them that have 10+ year open bug reports for fuck sake.
I'm more on the side of the author - I really enjoy hunting down and solving very difficult/odd/surprising bugs, at least every so often. It lets me exercise my generalist ('full stack') muscles, for instance going from a high-level application issue to reading/debugging kernel code.
I guess it's a matter of attitude or codebase. At least at the point where I find the cause, I don't often think, "wow, that was a difficult/odd/surprising bug", I think "Wow, that was a dumb mistake someone did (perhaps me, perhaps not)" or "Wow, such a mess of code. It's no wonder this mistake was so easy to make". That is, the end of the journey or the journey itself is often one of disappointment. That's what makes it frustrating for me.
It's also a matter of how refactorings are prioritized in one's organization. In the journey I end up feeling like the observed bug is just the tip of the iceberg of what needs to be fixed, but technical debt may have low prioritization, so you end up feeling disappointed of only chopping off that tip of the iceberg and leaving everything else that's submerged.
As time goes by, these tips pop up more and more often, and the ice below the surface also grows. I find that demoralizing.
I'll try to enjoy the journey more. I know it can be done even for our codebase because I have a coworker that seems to enjoy the bugs just like the author here.
Though, sometimes I think my attitude towards bugs is the healthy one.
It depends on the codebase and the person I suppose.
In my personal projects, I prefer greenfield programming, because I can write code embracing modern C++ features that ensure correctness by construction.
At work I'm saddled with C#'s shitty ecosystem that doesn't play well with its shitty async stack, and generations of old C++ paradigms that precludes things like constexpr, const correctness, static_assert, we use COM smart pointers instead of shared_ptr, (with no weak_ptr equivalent) shitty naming conventions where variable names are only a repeat of the type, etc. My greenfield work code at work is basically guaranteed to be buggy. I ain't that smart yo.
At work, I enjoy fixing bugs. I get to challenge the assumptions of Microsoft and the juggernauts of my corporation's OG Architects. And I get to win. I fight the man and I win. This afternoon I pointed out a bug in code written by a programmer who's been with the company for 20 years. He's the dev lead over a 70 person team. A weeks ago I fixed a bug in our software's core architecture which has been touched by many of the important people in our org.
At home I wear sweat pants. At work I wear a cape. Fixing bugs is awesome.
> Most programmers are complexity junkies getting paid to feed their habit.
Maybe more so today, but historically I've come to appreciate programmers as megalomaniacal control freaks - myself included, which programming allows them to exercise within the harmless confines of an imaginary world hosted by microprocessors and the attached storage.
It has been evolving though. Computers became networked, now software controls much of the real world, it's far less harmless than before. We also used to strive for minimizing complexity, I'm not sure how much of that was intentional or just a consequence of limited space while RAM was so expensive.
> We also used to strive for minimizing complexity, I'm not sure how much of that was intentional or just a consequence of limited space while RAM was so expensive.
Though I hate to admit it, I think it's the latter. We're now more able to shift complexity. We can add a big complexity layer (a framework, for example, with someone else being responsible for it) to avoid some complexity in another layer. The trouble comes when you need to understand the whole, including the layer you're not responsible for, to understand how that layer is affecting you.
It depends on the person. Most people would agree that murder is terrible but some people enjoy the process of investigating a murder. It’s so enjoyable, in fact, that a huge genre of novels, film, and television series have spawned from it. People spend large amounts of time creating murder stories for others to enjoy through all these media.
Stop and think about how weird this is for a moment. Imagine a video game or something where you had to find and fix bugs in fictional software. That’s how weird it is.
Diff'rent strokes, I guess. For some people the detective work itself is incredibly rewarding, sometimes even more than finding the solution. It's good that these people exist!
And people wonder why I think terminal is pretty horrible environment for anything but purely line driven applications. Just the other day my coworker was asking my why on earth do I run gvim instead of vim in terminal; I feel now vindicated. Sure, I haven't hit this issue but I am all the time cognizant of the eldritch horrors that are the terminal emulation layers, which makes me prefer to avoid them. And having tmux sit in the middle doing another emulation layer does definitely not help the feeling.
I just wish there were more almost ncurses like lightweight toolkits that would run natively in graphical environments, because to me they seem pretty rare.
It's not the smoothest, but at least it's fairly stable/consistent with good performance (vs. e.g. an electron GUI app). Once you get things dialed, you can keep your workflow going for years with minimal changes since nobody is trying to make money trying to sell you a new version of your workflow. I do a lot of work over SSH, too, so it's really nice to have my regular workflows largely port over to remote work.
Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for www.daniellesucher.com.
Because it's blindly following an inadequate heuristic, and not gracefully degrading if it fails - instead, you get comments like these blaming the author. Even though the author never wanted you to use HTTPS in the first place.
> What justification is there for serving HTTPS in a way users can't expect to consume?
Plenty of technical reasons (eg. what the sibling comments mentioned), but most importantly: there's no Internet/Web standard that I'm aware of which would prohibit me from doing so.
If you don't serve the same content on :80 and :443.
For example, you might be running a Tor relay node which would serve the node directory list on :443 to help people bypass firewalls, but also be using it as a useful and legitimate web server in order to prevent organizations from blocking it wholesale.
But the author was following convention: serving HTTP on traffic :80, and linking to that explicitly. It's you, the user, who for some reason decided to switch to a different protocol on a different port, and expected it to work even though there was no guarantee or indication that it would.
There isn't a HTTPS version of the site so you get dropped into the default vhost for their hosting provider, DreamHost.
DreamHost could automatically issue LE certs for their customers but that's not how they do things and don't enable it without customer approval.
It is impossible for DreamHost to not give you an error in this case. You connected directly to port 443 with a name that they don't have a certificate for. They could just close the connection but I don't think that would be an improvement on the situation.
Look, I use vim and tmux too. When they work, they work well, no doubt. It's
when they break, like in TFA, that the trouble starts.
Recall that the terminal is a glorified refried teleprinter with more
archeological layers than the Grand Canyon and more fossils than a
natural history museum.
My point was that other professions advance the state of the art of their
tools. We're still using vacuum tubes and steam. Those are cool but
it's not cool that nothing better is being adopted. Using terminals in
2020 is like LARPing steampunk (at work with a straight face.)
We get away with it because the newfangled crap (Eclipse, etc. Heck, I
use VScode but half of what I do is still in the embedded terminal
emulator!) is just not better.
This can't be the best we can do, can it? And yet, where are the
alternatives?
Well...
> what would you recommend instead?
I can't recommend them because nothing highly superior has reached mass
adoption. But they exist (in the sense that they exist or did exist or
could exist) like Jef Raskin's Cat.
I hear and understand your complaints about the tools we use now, but I don't think you can say they're unprofessional when the only alternatives you offer are tools that don't exist because people didn't use them.
> the only alternatives you offer are tools that don't exist because people didn't use them
They may not have wide adoption, but the tools he's describing very much exist. Wirth even published a book that describes how to implement an Oberon system from top to bottom, hardware (fpga) up to UI.
Systems like Symbolics, Smalltalk, Oberon, etc. all took lots of free time and funding to develop. Today's computing culture it dominated by next-quarter, short-term, profit seeking imperatives more than it was when these systems (along with the key systems we use today in production) were created. That leaves us in a bind: we have no choice but to merely iterate on what already exists and what's already available -- I'm talking about nix systems here mostly.
FOSS is a bit of a negative in this regard. Armies of interested programmers working in their free time are certainly not going to be able to invent things like Oberon or Smalltalk. You need to be properly funded and have the time to come up with things. The big companies aren't really interesting in doing this either -- they can just use existing FOSS, or even pay their own people to support a project, and build on top of that. It's not surprising, then, that no one has invented a wholly new personal computing system in decades.
Our current culture is, in my view, somewhat similar to medieval scholasticism. We are going to endlessly churn the the FOSS/nix soup until there is some kind of revolution in thought or action.
Well, FWIW, Pharo certainly exists and people use it (not me, but some people); and while IMO it's too soon to say anything concrete about Dark lang concerning its uptake/adoption, it does exist and some people are using it.
But what I'm saying is the very absence of better tools in common use (in 2020!) is telling.
IMO it's unprofessional that e.g. type inference is only coming to mainstream languages/frameworks in the last decade or so. ML is over forty years old!
Or check out the "new representation of conditional logic called schematic tables" in Jon Edwards' Subtext experimental language/IDE ( http://www.subtext-lang.org/https://vimeo.com/140738254 ) Something like that would be very useful if it was integrated into IDEs but it's barely known, eh?
Instead we concentrate on creating bold new flavors of C++, Python, Java, Javascript, or even Dart, Swift, Go, etc... or ReasonML, Typescript, ... I can't even keep going. You know what I mean.
We play with toys, for a living. It's unprofessional. ;-)
Much better UI metaphors exist but gain little or no traction. I think that's unprofessional. (This is my considered opinion after ~30 years as a programmer.)
