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<jiceher_AT_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
Received on Thu Sep 06 2012 - 13:24:39 CEST