Talk:Termite

From ArchWiki
Jump to: navigation, search

Colored ls output

I'm no shell/awk guru, but the following one-liner in my .bashrc enables colors for ls without having to create an entire dotfile only for that purpose:

eval $(dircolors <(awk '/^TERM/ && !x {print "TERM xterm-termite"; x=1} 1' <(dircolors -p)))

It can be improved for sure, but what if we use that command as the recommended fix in Termite#Colored ls output, then merge the dircolors stuff into Core utilities#ls as a generic way of customizing ls' colors?

Another advantage is that this method keeps dircolors' configuration in sync with any coreutils updates.

-- Kynikos (talk) 13:11, 13 January 2015 (UTC)

I'm no shell/awk guru either, so I might be the blind leading the blind here, but part of me feels that, although still a hack, a better solution is to simply export TERM=xterm. All of the dircolors hacks I've seen so far break as soon as you use termite to ssh into a server that hasn't been configured for it, for one thing (at which point I have to pull an export TERM=xterm anyway). As per my understanding, all the hack really does is says to the shell "xterm-termite is a terminal that is approved for displaying colored output the same way as all of the other terminals listed here, so don't do anything different, just don't get nervous when you see it." Moreover, Termite appears to be fully compatible with TERM=xterm output, as far as I can tell. Truthfully, I feel like they're all complete hacks (and not in the positive sense of the word), and the whole terminal-shell interdependence issue is nonsense. Alas, I can't think of any solution to fix it the Right Way™ (other than a POSIX standard for colored output that all shells and all terminals must comply with) so we're stuck choosing the lesser of the two (or three) evils.
PS: I've been meaning to ask for a while now: "Due to a recent update it is necessary to use a custom LS_COLORS environment variable..." -- Recent update of what? EscapedNull (talk) 17:58, 18 January 2015 (UTC)
I agree, I'm not even sure why TERM is set to xterm-termite in the code.[1][2] I'll invite User:thestinger to join this discussion to see what he thinks and how he solves the issue (assuming he does :) ).
I've removed the "recent update" thing, it indeed made no sense.
Kynikos (talk) 10:23, 19 January 2015 (UTC)
It's definitely not correct to set TERM=xterm. The terminfo for VTE and xterm is fairly different. For example, Termite supports italic text and it won't work if TERM is set to xterm. Even the backspace key won't work properly anymore for sane applications relying on terminfo rather than hardcoding dozens of escape sequences. The only broken thing here is dircolors: it should be asking terminfo if colors are supported rather than hardcoding a new non-extensible database. -- thestinger 15:54, 19 January 2015 (UTC)
Someone could just get xterm-termite added to their database, but the correct solution is for them to stop having their own database for no reason. -- thestinger 15:55, 19 January 2015 (UTC)
So it's dircolors that's maintaining an internal database of output-format-to-terminal-to-escape-sequence mappings, rather than using the terminfo API like it should be? Wouldn't that introduce a dependency on X (to use the terminfo API), even when running ls from the console? I sort of assumed that escape sequences were more-or-less standard among terminal emulators (and the console), and that they would be ignored if they were unrecognized. This is obviously a lot more complicated than I thought, and probably beyond the scope of this discussion, for that matter.
Since xterm and xterm-termite are incompatible, what's your preferred fix, User:thestinger? awk xterm-termite into the dircolors output? (Is this even correct? As far as I can tell, all we're doing is telling ls to do for xterm-termite the same it does for xterm.) Submit a patch to coreutils? Patch VTE to accept xterm compatible escape sequences? Hack an rc script together that replaces dircolors by querying the terminfo API and setting LS_COLORS itself? EscapedNull (talk) 22:51, 19 January 2015 (UTC)
Terminfo is a good thing and doesn't have any connection to X. The terminfo database and utilities are provided by the ncurses project. There are many differences in available features between terminals and terminfo is used to detect them along with providing the correct escape codes as those vary too. The reason it exists is not simply that escape codes vary between terminals. For example, the terminfo database can be used to query whether the terminal supports 8 colors, 16 colors or 256 colors. This is what dircolors should be doing rather than hardcoding a list of terminals with color support. The terminfo database is extensible and terminals like Termite and URxvt provide their own terminfo files. -- thestinger 22:58, 19 January 2015 (UTC)
The ideal solution is having dircolors read the information it needs from the terminfo database. To fix this specific problem, someone just needs to submit a patch to coreutils adding xterm-termite to their list but it's really not a sane way of doing this. -- thestinger 23:01, 19 January 2015 (UTC)
Well, I've chosen to be that "someone": http://lists.gnu.org/archive/html/coreutils/2015-01/msg00059.html . By the time I'm writing this it's already received a reply questioning termite's TERM type choice. — Kynikos (talk) 13:15, 20 January 2015 (UTC)
The reply there is wrong. The terminfo database is extensible (unlike the hard-wired dircolors database) and Termite ships a terminfo file. It needs to ship a custom terminfo file because VTE varies too much from xterm, yet many applications match against xterm* to check for stuff like mouse support. The ncurses terminfo database is also quite out-of-date for VTE terminals... but it's not going to call itself vte-256color anyway, because it breaks mouse support. Color support is listed in the terminfo database already, so the only thing that's incorrectly designed is dircolors. -- thestinger 14:20, 20 January 2015
URxvt also ships a terminfo file that's not provided in the ncurses database. It's better that way, because they can keep it correct / updated. The entries in the ncurses database tend to be very out-of-date and contain obvious errors. -- thestinger 14:22, 20 January 2015 (UTC)
I don't think I'm allowed to copy-paste your reply there and/or be your "spokesperson", and even if I did it wouldn't make much sense... I think this is the chance to give a quick fix to this problem in the same way as all the other terminals are doing; yes, replacing dircolors' database with a dynamic terminfo query would be a much better solution, but if I know well how these things work, such a feature could take 10 years to be added (I couldn't find any existing serious discussions about that, except for this one and [3], let alone any patches...), and honestly I'd start getting my dollar today rather than only aim for the million in the next geologic era ;) I think termite is a very interesting project, that's why I've posted the patch, but after all it's only up to you to decide up to what level it should integrate with other applications, including ls and dircolors at their current (i.e. not ideal) state, so, well, I can't do much more than that; certainly keeping discussing these things in this talk page won't lead anywhere :) — Kynikos (talk) 08:57, 21 January 2015 (UTC)
I'm glad to see you took the initiative to submit a patch, User:Kynikos. This Pádraig Brady didn't mention whether termite (more specifically, termite's terminfo) was installed on the system when he ran that command, but it works fine for me. I guess that's because tput queries the terminfo database as it should, instead of maintaining an internal database. In any case, he didn't consider the terminfo-vs-dircolors inconsistency. Perhaps someone should make said inconsistency clear on the ML thread (or post a link to this page)? I agree that patching dircolors to query terminfo is probably out of the question, but we might be able to get xterm-termite into the dircolors database if the maintainers are aware that termite is not directly compatible with xterm (assuming that he was suggesting termite preset itself as simply "xterm"). Yes, I know I should be posting this on the ML instead of here, but I'm learning all of this as I go (I just wanted the damned thing to work!), and I'm really not qualified to get into a discussion about it with the coreutils maintainers. EscapedNull (talk) 00:00, 22 January 2015 (UTC)
Thanks EscapedNull, but as I said it's pointless to add details here... please don't be afraid to reply to that ML! We have to keep that discussion alive, and every comment is important, it's not that the guys working on coreutils are untouchable gods that normal human beings can't talk with :) Also you'll understand that we can't ask them to register on the ArchWiki and come to discuss here, can we? That would really kill the discussion... In dircolors' database there are already entries for e.g. st and terminator, they wouldn't be able to object too much if we bring the right arguments and show them that it's not only thestinger who uses termite ;) — Kynikos (talk) 03:35, 22 January 2015 (UTC)
Probably I'm missing something here, but I have colored ls output using termiteAUR both with zsh and bash and no custom changes? -- Alad (talk) 16:07, 25 February 2015 (UTC)
Weird... My system is up to date and I confirm I still need the hack. Do you get xterm-termite from echo $TERM? Maybe you use an alias for ls that sets the TERM variable? Any chance you can try with a clean home directory? — Kynikos (talk) 10:17, 26 February 2015 (UTC)
I've created a new user (bash shell), and I didn't have colors in termite. With zsh (or bash launched from a zsh shell) it worked as intended; probably due to grml-zsh-config. -- Alad (talk) 21:29, 2 March 2015 (UTC)
You will have colored ls output either way, but using dircolors to set up LS_COLORS won't work. -- thestinger 10:19, 26 February 2015 (UTC)
The patch was committed. Too bad nobody mentioned the terminfo query solution, I think we should keep this discussion open for that reason, since apparently it's the only place of the internet where this is discussed... (actually I haven't searched again, this time) — Kynikos (talk) 01:14, 3 October 2015 (UTC)

Design goals

"Termite is a minimal terminal emulator designed for use with tiling window managers."

Despite the author claimed purpose, I'm not sure this wiki should follow the sales pitch to the letter. Termite has no daemon support and the author has made it clear he doesn't want to implement it. Arguably, this is not a tilling WM friendly terminal. At 10MB per invocation, on one of my normal i3 sessions, termite will take 70 MB for itself.

--Marfig (talk) 16:37, 7 August 2017 (UTC)

The reporter of the issue that is linked to above doesn't seem to understand how memory works on Linux, or how best to measure the memory usage of a process. Most of that 10MB will be shared among all termite processes. --Jbg (talk) 13:08, 6 September 2017 (UTC)
You can address me directly. I won't bite. You seem to be certain I know nothing of anything. But unfortunately to your claims, those measured 10 MB pertain already to physical non-shared memory, if at least you had gone to the trouble of measuring it yourself with that mysterious knowledge you claim I don't have and that you possess. --Marfig (talk) 19:20, 6 September 2017 (UTC)
Moderation: @Marfig, are you the same person as that behind the GitHub user "Chrysostomus" who reported the issue? Because User:Jbg was referring to him, and it would be hard to associate your wiki user name to that. In general, always assume good faith and please keep the conversation cordial and focused on the facts. -- Kynikos (talk) 12:21, 8 September 2017 (UTC)