---------------------------------------------------------------------

Dear Maintainer,

    * What led up to the situation?

    tmux requires $TERM to be set correctly so I checked the value of
    $TERM and realized I had no idea what would BE a correct value

    * What exactly did you do (or not do) that was effective (or
      ineffective)?

    I read the documentation at https://wiki.gnome.org/Apps/Terminal

    * What was the outcome of this action?

    I learned nothing about gnome-terminal, there is almost nothing
    documented about it at all.

    * What outcome did you expect instead?

    To be honest, that outcome is pretty much as I expected. Nobody ever
    documents anything. But what I had HOPED to find was full reference
    documentation for gnome-terminal.

    gnome expects me to file bugs against my distro rather than use
    their issue tracker, so you're the ones getting it (and thank you
    for maintaining debian) but it probably needs to be forwarded to
    them directly.

---------------------------------------------------------------------

Hello,

gnome-terminal sets $TERM to xterm-256color by default. This is the
value the software's developers think is best suited. There should be
no reason for you to tamper with it.

_Inside_ tmux you'll need a different value for $TERM. But this has
hardly anything (if at all) to do with gnome-terminal. You need to
consult tmux's documentation for the details. (But I'm fairly certain
that tmux also sets the correct value by default, the best you can do
is probably again not to touch it. What is the _actual_ problem you're
having that does not work out of the box for you and you suspect
requires fiddling with $TERM?)

Rants like this, unfortunately, won't take you anywhere.

Like many software projects out there, gnome-terminal is also
developed by a few volunteers in their scarce free time. These
developers writing excessive documentation (including things like "hey
this is set up for you correctly by default, please don't touch it)
would take away a significant amount of time from actually making the
software function better, which a lot more people are interested in.
(Let alone the fact that writing good user-facing documentation
requires quite different skills than writing good quality software,
you can't just 1:1 trade one for the other.)

I'm not saying that it's good that there's no such documentation, nor
that your report is invalid. It is indeed a valid issue. I'm just
saying that given the scarce resources, and given the skills of the
volunteers this project has, it's probably the best compromise the
project could make, and therefore it's unlikely to be addressed in the
foreseeable future. That being said, high quality contributions (e.g.
a "full reference documentation" from a new volunteer technical
writer) would surely be highly welcome!


e.