Re: Subject üî

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thursday, September  6 at 08:59 PM, quoth [EMAIL PROTECTED]:
>Latin1 it is, until further bizarre things pop up.  Plus, xterm under 
>X11 does it right under Latin1, while it is screwy under UTF-8. 
>(uxterm and other things, like the -u8 option and friends, resulted 
>in messed-up colors, including no colors in vim -- a deal-breaker).

Hmm... For what it's worth, I use uxterm on my Mac all the time 
without problems. The messed-up colors sound like a $TERM problem. 
When you launch uxterm, what's it set to? Mine's xterm-16color.

~Kyle
- -- 
The average Ph.D thesis is nothing but the transference of bones from 
one graveyard to another.
-- J. Frank Dobie, "A Texan in England"
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iD8DBQFG4UuuBkIOoMqOI14RAniCAJwKRQ7Eo4uOZ1umI1qNU/GqrPuFuACgxY0i
tWto1hGGmN0bfHtAl/6JrwM=
=ZIsG
-END PGP SIGNATURE-

Terminfo settings et al. (was: Subject üî)

[Eyolf Østrem]

It seems to me that my own problems are related to this thread, so
I'll chime in here (with a "Was:..." change of the subject line). I've
found some really useful information, both in the reply to my intial
mail a few days back, and in this thread, but my attempts at changing
things here and there have been too random to be useful, so I've
decided to take a step back and review my options, hopefully with some
guidance from you knowledgeable people.



PROBLEM:

getting screen to work with 256 colors, without having any of the
following problems:

- function keys w/modifiers (shift, ctrl, alt) don't work, at least
  not as expected. In vim: c-f10 sends something that turns the five
  following characters uppercase. All the f-keys do something similar:
  move somewhere on the line, and make sth uppercase.
  If I enter the function keys directly, either after a command line prompt
  or in vim through ^v, the output is the same, first in an xterm with
  TERM=xterm-256color, then in an xterm with screen running and
  TERM=screen-256color-s. In both cases, the command line says 1;5~
  and in vim it says: ^[[21;5~ c-f10, then, apparently sends
  '1;5~', and vim behaves accordingly: moves five characters
  forwards and changes their case. 
  So am I right in guessing, then, that when it doesn't work in screen,
  it's because the preceding ^[[2 is not interpreted as I expect it to, and
  that this would be where I would search for an answer?

- colors: some (ncurses based?) apps like mutt, don't display backgrounds
  correctly in areas without text, as I described in my previous post.

- screen refreshing after leaving apps: should get back to the state it was
  before entering e.g. vim, but now just scrolls up the screen (as
  described in this thread by Kyle; does the solution apply to
  settings for xterm too?).

- I don't know if this is related: on the console, many commands make
  some color code being displayed on the screen. E.g.: in a clean
  shell, directly after logon:
  
  $echo $TERM
  $linux
  $vim
  in vim: pressing ':' gives ':2;blue' on the command line



==
Questions:
==

Where and how should I set the TERM variable?  I guess there are five
possible levels here: environment/shell, Xterm, Screen, ncurses, and
application.
My distro's wiki (Archlinux) says that it's a bad idea to set the TERM
variable in .bashrc, but that applications should be able to figure it
out for themselves.

So, which of these possible values of TERM do I put where?  
xterm
xterm-256color
screen-256color
screen-256color-s
screen-256color-bce
screen-256color-bce-s

Should it be the same everywhere I set it? 
Or does e.g. screen translate screen-256color to xterm-256color or vice
versa? Or override xterm's choice (xterm-256color) with its own?
What exactly does that setting do anyway? Tell applications what to load
from the terminfo database? about how to translate input (keypresses) to
output?

How do I make changes to the terminfo database?
Are they dangerous?
Can i corrupt anything?  Will experimenting cause damage?
How do I revert?
How much does this have to do with curses?

More concretely:
  - how do I get my function keys back?
  - which escape code is responsible for the missing colour refreshing in
mutt etc.?
  - dito for the refreshing of the screen after leaving a (ncurses-based?)
program.
  - and, RTFM oriented, which parts of  the system do I need to know
more about - terminfo? Screen? I wouldn't want to spend a week
reading up on terminfo if the solution is to change a single
variable somewhere

My system is Archlinux, XTerm(229), Screen version 4.00.03 (FAU)
23-Oct-06, both of which are compiled with 256 color support.

I realize that this ended up not having that much to do with the
original thread, but I did change the subject line...


Eyolf

-- 
Everything that can be invented has been invented.
-- Charles Duell, Director of U.S. Patent Office, 1899

Re: SEC:UOutlook 2003 splits URLs over multiple lines when viewed

[Kai Grossjohann]

On Fri, Sep 07, 2007 at 04:10:31PM +0800, Wilkinson, Alex wrote:

> Email sent from Outlook-2003
> -~-~-~-~-~-~-~-~-~-~-~-~-~-~
> 
> So this proves that outlook marks it up in HTML and does some seriosuly weird
> stuff to the email when it gets sent.

Actually, the HTML generated by OL looks sane.

>
> HREF=3D"http://www.mathworks.com/support/sysreq/current_release/?parentto=
>  pic=3DSystem%20Compatibility">  FACE=3D"Courier =
>  
> New">http://www.mathworks.com/support/sysreq/current_release/?parenttopic=
>  =3DSystem%20Compatibility

Each line here ends in "=".  The message is qp encoded.  The act of
qp-decoding the message should join a line ending in = with the
following line, removing the = character.  (The = character at the end
of a line in qp encoding works a lot like the \ character at the end of
a sh script line.)

So perhaps the best solution to view this stuff is to view the text/html
variant, rather than the text/plain variant.  Try v to see the
attachments, then hit Return on the text/html one.  If that invokes a
text-mode browser like w3m or links or lynx, then you should be able to
follow the link.

Kai

Re: Terminfo settings et al

[Eyolf Østrem]

On 07.09.2007 (16:45), Kai Grossjohann wrote:
> 
> But this depends on whether ~/.Xdefaults is read in your environment...

It is.

> To specify $TERM for screen, you can specify -t or -T on the command
> line (forget which), or "term foo" or so in ~/.screenrc.
> 
> I lost track of what you already tried.  For the interim, you can
> explicitly set $TERM with "TERM=foo; export TERM" from the shell.  Have
> you tried that in various situations and do you now know what the
> terminal needs to be?

For a screen-less xterm, TERM=xterm-256color is the right thing:
everything works as I expect it to do. The problem is when screen
enters the picture. I've tried both TERM=xterm-256color and
TERM=screen-256color (with additional -bce, -s, or -bce-s), but with
no luck - they all behave the same: as in the "problem" description in
my previous mail. 

Eyolf

-- 
Microsoft Zen - Become one with the blue screen. 

   -- From a Slashdot.org post

Re: Terminfo settings et al

[Kai Grossjohann]

On Fri, Sep 07, 2007 at 01:05:02PM +0200, Eyolf Østrem wrote:

> Where and how should I set the TERM variable?  I guess there are five
> possible levels here: environment/shell, Xterm, Screen, ncurses, and
> application.
> My distro's wiki (Archlinux) says that it's a bad idea to set the TERM
> variable in .bashrc, but that applications should be able to figure it
> out for themselves.
> 
> So, which of these possible values of TERM do I put where?  
> xterm
> xterm-256color
> screen-256color
> screen-256color-s
> screen-256color-bce
> screen-256color-bce-s
> 
> Should it be the same everywhere I set it? 

The TERM variable describes how the terminal behaves.  Obviously, this
depends on the terminal in use.  It might not be obvious that several
programs act to the system as if they were terminals.  Here is a list of
possible "terminals" you might encounter:

  - The Linux text console (accessible via Ctrl-Alt-F1 oder Ctrl-Alt-F2
while you are running X11 -- use Ctrl-Alt-F7 oder somesuch to get
back to X11).

  - Different X11 terminal programs may exhibit different behaviors,
requiring different values of TERM: xterm, rxvt, urxvt, konsole,
gnome-terminal, mlterm, eterm, aterm, ...  There are many, many,
many X11 terminal programs.

  - The program screen also behaves like a terminal.

You can specify the $TERM value for xterm using "-tn foo" on the command
line, or an X ressource setting.  For example, the following line in
~/.Xdefaults may be equivalent to "-tn foo":

XTerm*termName: foo

But this depends on whether ~/.Xdefaults is read in your environment...

To specify $TERM for screen, you can specify -t or -T on the command
line (forget which), or "term foo" or so in ~/.screenrc.

I lost track of what you already tried.  For the interim, you can
explicitly set $TERM with "TERM=foo; export TERM" from the shell.  Have
you tried that in various situations and do you now know what the
terminal needs to be?

Kai
 

Re: Terminfo settings et al

[Gary Johnson]

On 2007-09-07, Eyolf strem <[EMAIL PROTECTED]> wrote:

> Where and how should I set the TERM variable?

The terminal itself should set this. It puts this variable in the 
environment of any subprocesses it spawns so that the application 
and/or the curses library used by the application knows, by means 
of the terminfo database, what capabilities the terminal has and 
what character sequences to send to the terminal to invoke each 
capability. 

> I guess there are five possible levels here: environment/shell, 
> Xterm, Screen, ncurses, and application. My distro's wiki 
> (Archlinux) says that it's a bad idea to set the TERM variable 
> in .bashrc, but that applications should be able to figure it 
> out for themselves. 

Right.  By putting TERM in your .bashrc you are overriding the
terminal's setting and assuming that you are always using only one
terminal type.

> So, which of these possible values of TERM do I put where?  
> xterm
> xterm-256color
> screen-256color
> screen-256color-s
> screen-256color-bce
> screen-256color-bce-s
>
> Should it be the same everywhere I set it? 

It depends.  Ideally, you should use the value whose terminfo
database entry most accurately describes the capabilities of the
terminal you are actually using.  When using screen, however, the
application is communicating with your terminal through screen, so
while screen should sit transparently between your terminal and the
application, screen does have to know something about the character
sequences being used to control the terminal.

Also, there are some applications that are hard-coded to recognize
certain terminal names.  They may know what to do with "xterm" but
not "xterm-256color".

> Or does e.g. screen translate screen-256color to xterm-256color or vice
> versa? Or override xterm's choice (xterm-256color) with its own?

I believe that unless you tell it to do otherwise, screen sets 
TERM to "screen".  You can tell screen to behave differently.  Refer
to my earlier reply and the screen man page.

> What exactly does that setting do anyway? Tell applications what to load
> from the terminfo database? about how to translate input (keypresses) to
> output?

It depends on the application. It basically tells the curses 
library what terminfo database entry to use, so the application 
just calls curses/terminfo functions to control the terminal 
and the library takes care of the details, but applications may 
choose to make other decisions based on the value of TERM or to 
access some terminal capabilities directly. 

> How do I make changes to the terminfo database?

Using infocmp and tic.

> Are they dangerous?

Yes, tic can be, if you are running as root or otherwise have
permission to change the files in the terminfo database.

> Can i corrupt anything?  Will experimenting cause damage?

Yes.  Maybe.

> How do I revert?

By default, the curses/terminfo library uses the system terminfo
database, e.g., /usr/share/lib/terminfo.  Setting and exporting the
variable TERMINFO in your environment to another directory will
cause curses/terminfo to look there first for terminfo files.  This
can give you a safe place to experiment with changes to terminal
definitions without messing up the system database.  For example, I
have in my ~/.profile,

TERMINFO=$HOME/lib/terminfo

> How much does this have to do with curses?

Everything.  Applications often use a curses library to interface
with the terminal they're running in.  That library uses the
terminfo database to figure out what character sequences to send to
the terminal in order to execute a particular curses function.
Things that can go wrong include:

-  The TERM value is incorrect for the terminal being used.
-  The terminfo database entry for TERM is missing, incomplete or
   otherwise doesn't contain accurate information for the terminal
   being used.
-  The curses library used by the application is old, broken or
   otherwise doesn't allow the application access to all of the
   terminfo capabilities.  (The HP-UX 10.20 curses library, for
   example, didn't recognize colors.)
-  The application uses its own idea of a terminal's capabilities
   instead of or in addition to the terminfo database.

HTH,
Gary

Re: SEC:UOutlook 2003 splits URLs over multiple lines when viewed

[Rocco Rutte]

Hi,

* Wilkinson, Alex [07-09-07 16:10:31 +0800] wrote:


Email sent from Outlook-2003
-~-~-~-~-~-~-~-~-~-~-~-~-~-~



So this proves that outlook marks it up in HTML and does some seriosuly weird
stuff to the email when it gets sent. How the hell does an MTA such as mutt deal
with the below crap ?



This is a multi-part message in MIME format.



--_=_NextPart_001_01C7F124.1170E94F
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable




http://www.mathworks.com/support/sysreq/current_release/?parenttopic=3DSy=
s
tem%20Compatibility


This is technically perfectly valid. Note that the part in encoded in 
quoted-printable. These lines must not be longer than 76 and an equals 
sign as last character denotes a so called soft line break. As the first 
URL line ends in = it's a soft line break, so the next one is appended. 
As line 2 doesn't end in =, a real line break is added by mutt.


So, mutt does everything correct. You have to blame outlook for breaking 
the URL into two parts; and there's nothing mutt can do about it.


  bye, Rocco
--
:wq!

Re: SEC:UOutlook 2003 splits URLs over multiple lines when viewed in

[Wilkinson, Alex]

0n Fri, Sep 07, 2007 at 03:21:43PM +0800, Wilkinson, Alex wrote: 

>Hi all,
>
>Something that has bugged me for a long time is that when people send me 
URLs
>from Outlook-2003, mutt sees the URL split over 2 lines
>
>e.g.
>
>
http://www.mathworks.com/support/sysreq/current_release/?parenttopic=Sys
>tem%20Compatibility
>
>If I send the same URL from mutt to myself I get the URL on a single line 
as such:
>
>
http://www.mathworks.com/support/sysreq/current_release/?parenttopic=System%20Compatibility
>
>In the raw Maildir spool file the URL is split also e.g.
>
>
http://www.mathworks.com/support/sysreq/current_release/?parenttopic=3DSy=
>s
>tem%20Compatibility
>
>So it looks like the URL gets split over a series of lines in transit.
>
>Does anyone know why ? And how to make this stop happening ?

Ok, so I have investigated more. I have sent the URL from both mutt and
outlook-2003 and then I have proceeded to connect to the POP service on the
Exchange server to view the messaage _before_ fetchmail fetches it. The results:

Email sent from mutt
-~-~-~-~-~-~-~-~-~-~

A single pristine URL:

[http://www.mathworks.com/support/sysreq/current_release/?parenttopic=System%20Compatibility]

This is how it should be.

Email sent from Outlook-2003
-~-~-~-~-~-~-~-~-~-~-~-~-~-~

So this proves that outlook marks it up in HTML and does some seriosuly weird
stuff to the email when it gets sent. How the hell does an MTA such as mutt deal
with the below crap ?

 This is a multi-part message in MIME format.

 --_=_NextPart_001_01C7F124.1170E94F
 Content-Type: text/plain;
 charset="US-ASCII"
 Content-Transfer-Encoding: quoted-printable


 http://www.mathworks.com/support/sysreq/current_release/?parenttopic=3DSy=
 s
 tem%20Compatibility


 --_=_NextPart_001_01C7F124.1170E94F
 Content-Type: text/html;
 charset="US-ASCII"
 Content-Transfer-Encoding: quoted-printable

 
 
 
 
 
 URL from Outlook ...
 
 
 
 

 http://www.mathworks.com/support/sysreq/current_release/?parentto=
 pic=3DSystem%20Compatibility">http://www.mathworks.com/support/sysreq/current_release/?parenttopic=
 =3DSystem%20Compatibility
 

 
 
 --_=_NextPart_001_01C7F124.1170E94F--


 -aW


IMPORTANT: This email remains the property of the Australian Defence 
Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 
1914.  If you have received this email in error, you are requested to contact 
the sender and delete the email.

Outlook 2003 splits URLs over multiple lines when viewed in mutt ... why ?

[Wilkinson, Alex]

Hi all,

Something that has bugged me for a long time is that when people send me URLs
from Outlook-2003, mutt sees the URL split over 2 lines

e.g.

http://www.mathworks.com/support/sysreq/current_release/?parenttopic=Sys
tem%20Compatibility

If I send the same URL from mutt to myself I get the URL on a single line as 
such:


http://www.mathworks.com/support/sysreq/current_release/?parenttopic=System%20Compatibility

In the raw Maildir spool file the URL is split also e.g.

http://www.mathworks.com/support/sysreq/current_release/?parenttopic=3DSy=
s
tem%20Compatibility

So it looks like the URL gets split over a series of lines in transit.

Does anyone know why ? And how to make this stop happening ?

 -aW

IMPORTANT: This email remains the property of the Australian Defence 
Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 
1914.  If you have received this email in error, you are requested to contact 
the sender and delete the email.

Re: Terminfo settings et al

[Eyolf Østrem]

First of all: thanks for your reply - here, and to the previous post.
Much helpful. I will have to read up on terminfo, I can tell...
And test some settings. Phew...

On 07.09.2007 (10:10), Gary Johnson wrote:
 
> When using screen, however, the
> application is communicating with your terminal through screen, so
> while screen should sit transparently between your terminal and the
> application, screen does have to know something about the character
> sequences being used to control the terminal.

Does this mean that I could make a terminfo entry called, say,
'my-screen-in-xterm', based on that for xterm-256color, and set that
in .screenrc? That would tell screen exactly which capabilities the
terminal has, wouldn't it? But why then doesn't it work to set 'term
xterm-256color' directly?

> Also, there are some applications that are hard-coded to recognize
> certain terminal names.  They may know what to do with "xterm" but
> not "xterm-256color".

Is this the reason? That mutt and mocp (and vim?) know about xterm but
not xterm-256color?

 
> > How much does this have to do with curses?
> 
> Everything.  Applications often use a curses library to interface
> with the terminal they're running in.  That library uses the
> terminfo database to figure out what character sequences to send to
> the terminal in order to execute a particular curses function.

So terminfo is only relevant for applications that use ncurses? 

> Things that can go wrong include:
> 
> -  The TERM value is incorrect for the terminal being used.

And when I run screen, what is 'the terminal being used' - is it
screen(-256color) or the terminal which screen runs in? Or both? This
is one of the things I haven't fully grasped yet: does the information
pass serially through the full chain application > ncurses > screen >
xterm > system (so that e.g. mutt will have to know about screen's
capabilities, and screen about xterm's?), or are there shortcuts? 
Also: are the values simply transFERRED from one level to the next, or
are they also transLATED, so that, e.g. c-F10 is called 'apple' in
mutt and 'orange' in xterm, and ncurses knows how to translate between
them?

> -  The terminfo database entry for TERM is missing, incomplete or
>otherwise doesn't contain accurate information for the terminal
>being used.

It sounds as if this is the case, then? since ...

> -  The curses library used by the application is old, broken or
>otherwise doesn't allow the application access to all of the
>terminfo capabilities.  

... the curses version is 5.6.20061217, and ...

> -  The application uses its own idea of a terminal's capabilities
>instead of or in addition to the terminfo database.

... the problem occurs in many different applications, so unless they
all make the same assumptions, the problem should lie somewhere else,
no?

> HTH,

Very much so. Thanks again. 

Eyolf

-- 
linux: the choice of a GNU generation
([EMAIL PROTECTED] put this on Tshirts in '93)

Re: Terminfo settings et al

[Christian Ebert]

* Eyolf Østrem on Friday, September 07, 2007 at 19:58:29 +0200
> Does this mean that I could make a terminfo entry called, say,
> 'my-screen-in-xterm', based on that for xterm-256color, and set that
> in .screenrc? That would tell screen exactly which capabilities the
> terminal has, wouldn't it? But why then doesn't it work to set 'term
> xterm-256color' directly?

Here "term term-256color" in screenrc works if I do /not/ set
$TERM in eg. bashrc explicitly. So I do roughly the following in
bashrc:

[ -z "$STY" ] && export TERM="xterm-256color"

($STY is set in a Screen session)

and in screenrc:

term "screen-256color"

(I have screen built with 256 color support)

c
-- 
Python Mutt utilities 

Re: Terminfo settings et al

[Eyolf Østrem]

On 07.09.2007 (20:59), Christian Ebert wrote:
> Here "term term-256color" in screenrc works 

Just to make sure: do you mean "term screen-256color"? or ... 
 
> and in screenrc:
> 
> term "screen-256color"
 
...?

Eyolf


-- 
Parents often talk about the younger generation as if they didn't have
much of anything to do with it.

Re: Terminfo settings et al

[Gary Johnson]

On 2007-09-07, Eyolf strem <[EMAIL PROTECTED]> wrote:
> First of all: thanks for your reply - here, and to the previous post.
> Much helpful. I will have to read up on terminfo, I can tell...
> And test some settings. Phew...

You're welcome.  Sometimes these issues have easy answers and 
sometimes you just have to wade through the documentation and try 
some stuff.

I'm not an expert on any of this.  I've just encountered enough 
problems over the years and learned enough to solve most of them 
that I can give you a few answers and maybe point you in the right 
direction to find the rest yourself.

> On 07.09.2007 (10:10), Gary Johnson wrote:
>  
> > When using screen, however, the
> > application is communicating with your terminal through screen, so
> > while screen should sit transparently between your terminal and the
> > application, screen does have to know something about the character
> > sequences being used to control the terminal.
> 
> Does this mean that I could make a terminfo entry called, say,
> 'my-screen-in-xterm', based on that for xterm-256color, and set that
> in .screenrc? That would tell screen exactly which capabilities the
> terminal has, wouldn't it? But why then doesn't it work to set 'term
> xterm-256color' directly?

I don't know.  It's been a while since I read the screen man page.  
The last time I did, I learned a little (now forgotten) about the 
interactions among screen, terminals and applications and how to 
compile a terminfo entry that would fix the problem.  It didn't 
involve my .screenrc.

> > Also, there are some applications that are hard-coded to recognize
> > certain terminal names.  They may know what to do with "xterm" but
> > not "xterm-256color".
> 
> Is this the reason? That mutt and mocp (and vim?) know about xterm but
> not xterm-256color?

I don't know.  Probably not in the case of mutt, but the only way to 
know for sure is to look in the source.

> > > How much does this have to do with curses?
> > 
> > Everything.  Applications often use a curses library to interface
> > with the terminal they're running in.  That library uses the
> > terminfo database to figure out what character sequences to send to
> > the terminal in order to execute a particular curses function.
> 
> So terminfo is only relevant for applications that use ncurses? 

Not only ncurses, but any library the provides an interface to the 
terminfo library.  HP-UX and Solaris each have their own curses 
library, for example.  Slang is another.

> > Things that can go wrong include:
> > 
> > -  The TERM value is incorrect for the terminal being used.
> 
> And when I run screen, what is 'the terminal being used' - is it
> screen(-256color) or the terminal which screen runs in? Or both?

I meant the thing you look at and type into, e.g. xterm, but when 
using screen, which has some of the behaviors of a terminal and 
which sets TERM itself, it does get more complicated.

> This is one of the things I haven't fully grasped yet: 
> does the information pass serially through the full chain 
> application > ncurses > screen > xterm > system (so that e.g. 
> mutt will have to know about screen's capabilities, and screen 
> about xterm's?), or are there shortcuts? Also: are the values 
> simply transFERRED from one level to the next, or are they also 
> transLATED, so that, e.g. c-F10 is called 'apple' in mutt and 
> 'orange' in xterm, and ncurses knows how to translate between 
> them? 

As I wrote above, I don't remember exactly which character sequences 
screen passes transparently, which ones it acts upon and which, if 
any, it modifies.  All that is in the man page, as I recall.

> > -  The terminfo database entry for TERM is missing, incomplete or
> >otherwise doesn't contain accurate information for the terminal
> >being used.
> 
> It sounds as if this is the case, then? since ...
> 
> > -  The curses library used by the application is old, broken or
> >otherwise doesn't allow the application access to all of the
> >terminfo capabilities.  
> 
> ... the curses version is 5.6.20061217, and ...

If you're using ncurses on a relatively recent Linux distribution, 
it's not likely to be the problem.  That one in particular should be 
fine (based on my usage of 5.5).

> > -  The application uses its own idea of a terminal's capabilities
> >instead of or in addition to the terminfo database.
> 
> ... the problem occurs in many different applications, so unless they
> all make the same assumptions, the problem should lie somewhere else,
> no?

True.  

Regards,
Gary

X-Face viewing and creation

[Trey Sizemore]

Hi-

Can someone point me to a good reference on being able to view X-Face
headers in mutt as well as adding them to outgoing mails (preferably
color)?

-- 
Cheers,
Trey

 
Power, n:
The only narcotic regulated by the SEC instead of the FDA.
 
Linux valkyrie 2.6.16.53-0.8-bigsmp i686 GNU/Linux
  5:13pm  up  21:53,  3 users,  load average: 0.20, 0.20, 0.12


pgpx07exST9Kf.pgp
Description: PGP signature

Re: X-Face viewing and creation

[Kyle Wheeler]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Friday, September  7 at 05:14 PM, quoth Trey Sizemore:
>Hi-
>
>Can someone point me to a good reference on being able to view X-Face
>headers in mutt as well as adding them to outgoing mails

Adding an X-Face header is the same as adding any other header in 
mutt:

 my_hdr X-Face: 
-P+89ASh_wrs;AUGm`!l[}/o-lyK}5W.gq\fkJ{#d6Gu,hWrZNz::iMm5PJb}__A96]-LUrl)X=uF=V|\3-\9/sXvBs/H

*Viewing* them, on the other hand, is another matter entirely. There's 
a couple different ways to do it. Takahashi Tamotsu wrote a patch for 
displaying them using w3m's w3mimgdisplay (so it'll actually show the 
image through an xterm). Check out this webpage for that patch and for 
alternatives: http://www.df7cb.de/projects/mutt/x-face/

That said, why would you want to do that?

>(preferably color)?

Umm, I hate to break it to you, but X-Face headers are, by definition, 
black and white. "Face" headers are entirely different, and a bigger 
pain in the butt. I don't know what to tell you about those, except 
that maybe you can modify Tamo's patch to handle them.

~Kyle
- -- 
The search for the truth is the noblest occupation of man. Its 
publication is a duty.
   -- Anne Louise Germaine de Stael
-BEGIN PGP SIGNATURE-
Comment: Thank you for using encryption!

iD8DBQFG4cY4BkIOoMqOI14RAkonAJ0ST4G9tKGzjVUkSNs5MkLHzb7x/ACfb7jL
MwAm6VbXMK5eGabSwUk9ZBQ=
=9buT
-END PGP SIGNATURE-

Append signature on a case-by-case basis

[Kai Grossjohann]

I understand that I can set $signature to a file name with my signature.
Then all subsequent outgoing messages will have that signature appended.
Or I can set $signature to something else or remove the file.  Then all
subsequent messages will not have a signature appended.

But what I want is to be able to decide, for each outgoing message: I
want to append a signature to this message.

Is there a way to do this?

Perhaps I want a vim macro that will append the signature to the message
currently being composed?  Does anyone have a ready-made macro?

Kai

Re: Terminfo settings et al

[Christian Ebert]

* Eyolf Østrem on Friday, September 07, 2007 at 21:24:27 +0200
> On 07.09.2007 (20:59), Christian Ebert wrote:
>> Here "term term-256color" in screenrc works 
> 
> Just to make sure: do you mean "term screen-256color"? or ... 
> 
>> and in screenrc:
>> 
>> term "screen-256color"
> 
> ...?

or ... !

$ grep -F 256 ~/.screenrc
term "screen-256color"
> 
c

-- 
Wer auf sein Elend tritt, steht höher.
_HÖLDERLIN: H Y P E R I O N_ 

Re: X-Face viewing and creation

[Christoph Berg]

Re: Trey Sizemore 2007-09-07 <[EMAIL PROTECTED]>
> Can someone point me to a good reference on being able to view X-Face
> headers in mutt as well as adding them to outgoing mails (preferably
> color)?

http://www.df7cb.de/projects/mutt/x-face/

No idea about color, I think that's some other header. (X-Image?)

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: X-Face viewing and creation

[Trey Sizemore]

On Sat Sep 08, 2007 12:03AM, Christoph Berg wrote:
> Re: Trey Sizemore 2007-09-07 <[EMAIL PROTECTED]>
> > Can someone point me to a good reference on being able to view X-Face
> > headers in mutt as well as adding them to outgoing mails (preferably
> > color)?
> 
> http://www.df7cb.de/projects/mutt/x-face/
> 
> No idea about color, I think that's some other header. (X-Image?)
> 
> Christoph


Yes, as a previous responder mentioned, I should have said 'Face'
header vs. 'X-Face' header.

So any info about using and viewing 'Face' headers with mutt is
greatly appreciated.

-- 
Cheers,
Trey

 
We're deep into the holiday gift-giving season, as you can tell from
the fact that everywhere you look, you see jolly old St. Nick urging
you to purchase things, to the point where you want to slug him right
in his bowl full of jelly.
-- Dave Barry, "Simple, Homespun Gifts"
 
Linux valkyrie 2.6.16.53-0.8-bigsmp i686 GNU/Linux
  7:23pm  up 1 day  0:13,  3 users,  load average: 0.58, 0.41, 0.42


pgpHPIRl12F20.pgp
Description: PGP signature

Re: X-Face viewing and creation

[Christian Ebert]

* Trey Sizemore on Friday, September 07, 2007 at 19:25:49 -0400
> On Sat Sep 08, 2007 12:03AM, Christoph Berg wrote:
>> Re: Trey Sizemore 2007-09-07 <[EMAIL PROTECTED]>
>>> Can someone point me to a good reference on being able to view X-Face
>>> headers in mutt as well as adding them to outgoing mails (preferably
>>> color)?
>> 
>> http://www.df7cb.de/projects/mutt/x-face/
>> 
>> No idea about color, I think that's some other header. (X-Image?)
> 
> Yes, as a previous responder mentioned, I should have said 'Face'
> header vs. 'X-Face' header.
> 
> So any info about using and viewing 'Face' headers with mutt is
> greatly appreciated.

I tweaked Christoph's procmail filter from above link to display
both X-Face and Face headers (thanks Christoph!):


# filter procmailrc to display (X-)Face images with VIEWER
# (c) 2004 Christoph Berg, GNU GPL.
# tweaked by Christian Ebert

# customize X11 viewer (has to accept stdin)
VIEWER="/usr/local/bin/xli -fork stdin"

PRINTF="/usr/bin/printf"
UNCOMPFACE="/usr/local/bin/uncompface"
RECODE="/usr/local/bin/recode"
FORMAIL="/usr/local/bin/formail"
TR="/usr/bin/tr"

:0
* DISPLAY ?? .
{
:0
* ^X-Face: *\/.*
{
:0c
| $PRINTF '%s' $MATCH | $UNCOMPFACE -X | $VIEWER
:0fhw
| $FORMAIL -f -I 'X-Face:'
}

:0
* ^Face: *\/*
{
:0c
| $PRINTF '%s' $MATCH | $TR -d ' ' \
| $RECODE -f /base64 | $VIEWER
:0fhw
| $FORMAIL -f -I 'Face:'
}
}

:0
|

# EOF vim:ft=procmail


Note:
For some messages I have to recirect stderr to /dev/null:
set display_filter="procmail -pm x-face.procmailrc 2> /dev/null"

c
-- 
Python Mutt utilities 

Re: Append signature on a case-by-case basis

[Gary Johnson]

On 2007-09-08, Kai Grossjohann <[EMAIL PROTECTED]> wrote:
> I understand that I can set $signature to a file name with my signature.
> Then all subsequent outgoing messages will have that signature appended.
> Or I can set $signature to something else or remove the file.  Then all
> subsequent messages will not have a signature appended.
> 
> But what I want is to be able to decide, for each outgoing message: I
> want to append a signature to this message.
> 
> Is there a way to do this?
> 
> Perhaps I want a vim macro that will append the signature to the message
> currently being composed?  Does anyone have a ready-made macro?

How about this:

   :map  :exe "$put='\\\n-- '" \| $r ~/.mutt/signature

HTH,
Gary

Re: Append signature on a case-by-case basis

[Thor Andreassen]

On Sat, Sep 08, 2007 at 12:30:42AM +0200, Kai Grossjohann wrote:
> I understand that I can set $signature to a file name with my signature.
> Then all subsequent outgoing messages will have that signature appended.
> Or I can set $signature to something else or remove the file.  Then all
> subsequent messages will not have a signature appended.
> 
> But what I want is to be able to decide, for each outgoing message: I
> want to append a signature to this message.
> 
> Is there a way to do this?

You can accomplish this by setting signature in a send-hook, like so:

send-hook PATTERN set signature=SIGNATURE_FILE

-- 
with kind regards
Thor Andreassen