On Tue, Sep 04, 2012 at 07:33:22AM +0200, Julien Richefeu wrote: > Le 03/09/2012 23:11, Christoph Lohmann a écrit : > >Greetings. > > > >On Mon, 03 Sep 2012 23:11:22 +0200 Julien Richefeu<jice...@free.fr> wrote: > >>4/ the st version installed on both computer is the last git relase > >>compiled on the computer (I do not try to copy binaries and execute it > >>on the other computer, I will try it). The version is from commit > >>beecb162e346c328db2a7ff1c0574352fe0ebebc. > >Please use the official repository for bug reports. There were some > >changes in the hg repository. > > > >When installing the st.info be sure to not have unwanted duplicated def‐ > >initions in your $HOME/.terminfo directory. > > > > > >Sincerely, > > > >Christoph > > > > > Hi all again, > > OK, I just found a little(!) differences between the two debian > installation on the two computer: the first one (the one with issue > between st and dvtm) has been installed with i686 architecture and > the second one with x86_64 architecture. > > So maybe the issue comes from the 32bits version of compiled or > libraries used as dependencies?
I am currently traveling and therefore I don't have permanent internet access. Yes there was a color related problem which caused 256color.pl to malfunction. I have since pushed a fix for this particular issue to the git repository. When I launch dvtm with that patch applied within a 256 color aware terminal and TERM set acordingly, for example: TERM=xterm-256color dvtm It seems to work. However the color mappings seem a bit strange afterwards which means after executing 256color.pl the colors don't look the way they should (noticed with mutt/vim in my case). Haven't yet had time to look into it though... Patches welcome ;-) A clearly reproducable testcase for your problem would be nice (now that 256color.pl seems to work). Marc -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
