
My new favorite vim/tmux bug (2014) - zdw
http://www.daniellesucher.com/2014/04/24/my-new-favorite-vim-tmux-bug/
======
asveikau
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.

~~~
jolmg
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.

------
jolmg
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.

~~~
q3k
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.

~~~
jolmg
> very difficult/odd/surprising bugs

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.

~~~
hashhar
I agree 100% with you. Thanks for writing it out in a better way than I ever
would.

I think the main cause for how we feel is the lack of focus on refactoring
things and repaying tech debt within our orgs.

------
zokier
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.

~~~
stefco_
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.

------
joemi
Is this really actually a bug with either vim or tmux? It sounds like it's
just a bug with a vim _plugin_ involving tmux.

------
loeg
There are still issues using function keys like Home/End in neovim inside a
screen session, it drives me nuts.

------
0xff00ffee
My favorite HTTPS bug:

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"

~~~
q3k
Just because it serves HTTPS on port :443 doesn't mean you should be using it.
'HTTPS Everywhere' style plugins are a broken concept.

~~~
ivanbakel
In what way are they a broken concept? What justification is there for serving
HTTPS in a way users can't expect to consume?

~~~
q3k
> In what way are they a broken concept?

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.

------
carapace
On the one hand _I love this_ on the other hand _this is not the kind of crap
we should be using for professional work._

Yeah _tmux_ and _vim_ are not professional software. Let that sink in.

~~~
exdsq
As someone who almost exclusively uses tmux and vim (as I spend my life in
numerous terminals...), what would you recommend instead?

Unless this is /s in which case it has gone straight over my head!

~~~
carapace
Nah, "I'm seriously you guys."

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](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](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...](https://schierlm.github.io/OberonEmulator/emu.html?image=FullDiskImageWithSource&width=1024&height=576)
)

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?

[https://pharo.org/](https://pharo.org/)

(Maybe that "Dark" thingy will be cool:
[https://darklang.com/](https://darklang.com/) )

~~~
pavel_lishin
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.

~~~
scroot
> 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.

