My new favorite vim/tmux bug (2014)
daniellesucher.com
daniellesucher.com
> 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
Practically, I find that I'm way more efficient with the messy integration enabled.
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.
[1]: https://github.com/christoomey/vim-tmux-navigator
[2a]: https://github.com/jwhitley/dotfiles/blob/master/.tmux.conf#...
[2b]: https://github.com/jwhitley/tilde-local/blob/master/local/bi...
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.
I think the main cause for how we feel is the lack of focus on refactoring things and repaying tech debt within our orgs.
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.
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.
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.
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.
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.
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.
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.
Error code: MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT
View Certificate
---
Followed by: "Site not found"
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.
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.
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.
Yeah tmux and vim are not professional software. Let that sink in.
Unless this is /s in which case it has gone straight over my head!
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.
https://en.wikipedia.org/wiki/Teleprinter
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.
https://en.wikipedia.org/wiki/Canon_Cat
(Canon killed the Cat. Heh. Wah.)
Have you ever used the old Oberon OS? (Oberon emulator in browser: https://schierlm.github.io/OberonEmulator/emu.html?image=Ful... )
Oberon OS (plus the "Gadgets" widget system) represents a fundamentally better UI metaphor than the terminal.
Heck Smalltalk et. al. (E.g. Pharo) with their portable VMs and platform-agnostic pixel-identical GUIs are a better abstraction than UNIX+TTY, eh?
(Maybe that "Dark" thingy will be cool: https://darklang.com/ )
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.
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.)