Re: Autoview images in the pager - w3m
On Wed, 16 Oct 2002, PeterKorman wrote: This is *really* nice. I saw the page at http://w3m.org a few months ago. I wrongly concluded that there was no on-going development since the date on w3m.org is: Tuesday August 01, 2000 02:43 P Your reference to http://w3m.sf.net cleared my confusion. Thanks. http://prdownloads.sourceforge.net/w3m/w3m-0.3.1.tar.gz?use_mirror=unc The July 2002 release leaves links and lynx looking dusty and beaten. not really. The inline images are actually windows that overlay the xterm, and are not event-coordinated. So what you're seeing is in effect multiple external viewer windows that are positioned to match the text. Nice - but doesn't exactly make things obsolete. It can be annoying to use w3m in an xterm which is running 'screen'. As is usual, I find that between lynx/w3m/opera/netscape, some sites do not work well on one or more of those. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: Mutt, SSH and Urlview
On Thu, 3 Oct 2002, Andre Berger wrote: Alternatively you could you use links version 2; both w3m and links support ssl and pictures!, but none of them JavaScript (at least to lynx supports ssl as well. my best knowledge). Netrik is said to support JavaScript but thinks as a matter of fact, netrik says a lot, but does little. (if you're inclined to be amused, read its code if you're not squeamish, read links' code) my HTML 4.01 validated pages contain too many errors to be displayed at all. Maybe a later version will is more forgiving to valid HTML :) -Andre -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: Mutt, SSH and Urlview
On Thu, 3 Oct 2002, D. J. Bolderman wrote: On Thu, 03 Oct 2002, Robert Ian Smit wrote: Subject says it all: if I'm using Mutt over an ssh connection, how can I execute http links in mails ? Or is this simply not possible ? By executing http links you mean starting a graphical browser? Don't know how to do that, but perhaps using a text browser like lynx or w3m can help you here. Yes, I mean the graphical client on my workstation (winxp...) I got some links that lynx won't show correctly. for example? (a test page or sample url) -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: Where config mutt to use lynx and *not* Galeon?
On Wed, 2 Oct 2002, Elimar Riesebieter wrote: On Mon, 30 Sep 2002 the mental interface of Thomas Dickey told: On Sat, Sep 28, 2002 at 09:13:27AM -0700, [EMAIL PROTECTED] wrote: Default Red Hat 7.3 uses Galeon to read html email in mutt. Where do I change this to lynx??? in your $HOME/.mailcap, a line like this for instance: text/html; lynx-cs -force_html -stdin (there are several ways to do it) i.e. text/html; w3m -dump -T text/html %s; copiousoutput w3m for me is better for viewing tables. how much email do you get that uses tables? -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: Colour problem on Solaris
On Mon, 30 Sep 2002, Hanspeter Roth wrote: On Sep 27 at 11:28, Chris Green spoke: Error in /home/chris/.mutt/muttrc, line 28: default: no such color Mutt (ncurses?) on NetBsd doesn't like this either. If you have a light background you might choose `brightwhite' instead. Then you might get bright gray. NetBSD has a strong not-invented-here faction, which is busily porting chunks of ncurses into their native BSD curses. It's not complete, but the latest version reportedly has use_default_colors(). If the entrypoint exists, but does not work as expected that's a NetBSD bug rather than mutt's. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: replying to unwrapped messages with vi
On Mon, 30 Sep 2002, Ken Weingold wrote: On Thu, Sep 26, 2002, Mike Jackson wrote: If I receive a message from an outlook luser, or similar, and the message is completely unwrapped, how do I fix that part which I quote? I would like to be able to do this automatically. Not sure about vi, but vim has a wonderful method of wrapping text. A simple Q} will wrap the whole paragraph. Or Qdown arrow will do for Outhouse since it seems to make each paragraph all one long line. for vi, look at 'par' -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: replying to unwrapped messages with vi
On Tue, 1 Oct 2002, kevin lyda wrote: On Tue, Oct 01, 2002 at 06:09:47AM -0400, Thomas E. Dickey wrote: On Mon, 30 Sep 2002, Ken Weingold wrote: Not sure about vi, but vim has a wonderful method of wrapping text. A simple Q} will wrap the whole paragraph. Or Qdown arrow will do for Outhouse since it seems to make each paragraph all one long line. huh. neat. i started on vi so i always have had vf and vq for formatting plain and quoted paragraphs: map vf !}fmt map vq !}fmt -p '' for vi, look at 'par' i find fmt to be more standard across unicies. that's arguable (fmt is likely to be installed, but like most Unix utilities would have version dependencies - par is a relative latecomer and is not installed). There's a difference between installed and standard of course - X/Open documents the latter. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: replying to unwrapped messages with vi
On Tue, 1 Oct 2002, Elimar Riesebieter wrote: On Tue, 01 Oct 2002 the mental interface of Or you can have vim do this reformatting automatically by applying patches 6.1.142 and 6.1.143 and adding this to your autocmd: set formatoptions+=a (posted at vim.vim.org!) I don't use either, as a matter of fact (vile's done similar formatting for quoted stuff for some time as well). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: fast conversion of html mail to text
On Tue, 24 Sep 2002, Eric Smith wrote: I am getting a bit irritated by the second or two I need to wait for `lynx -dump' or similiar to work when viewing the _many_ html mails that happen upon my inbox - what are mutters doing to strip the tags faster? someone commented on lynx -dump recently, to the effect that there are some messages which can be optimized in lynx by setting ALERTSECS, INFOSECS and MESSAGESECS to zero. (Actually he wanted to hard-code it into the behavior of the -dump option, but it's easily scripted). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: fast conversion of html mail to text - unhtml
On Tue, 24 Sep 2002, Eric Smith wrote: bill luecke said: On Tue, Sep 24, 2002 at 03:36:49PM +0200, Eric Smith wrote: I have the following line in my .mailcap text/html; unhtml ; copiousoutput good answer - apt-get install unhtml on debian But it is still almost a second delay. I think i will try and kill this problem with procmail. What *SECS values does your lynx.cfg have? -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: fast conversion of html mail to text
On Tue, 24 Sep 2002, Benjamin Pflugmann wrote: Hello. On Tue 2002-09-24 at 15:36:49 +0200, Eric Smith wrote: I am getting a bit irritated by the second or two I need to wait for `lynx -dump' or similiar to work when viewing the _many_ html mails that happen upon my inbox - what are mutters doing to strip the tags faster? Be sure to use the -nopause flag. Else, if lynx display a status message for some reason, it will wait for some second(s). And yes, it also does this with -dump and -source, where one does not get to see the status message at all. At least, last time I tried. That's correct. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: vi startup (not vim?)
On Wed, 18 Sep 2002, darren chamberlain wrote: vim has a :version command, which other vi clones don't seem to; vim :ve is standard. (:version is also recognized by all of the vi's that I recall - including elvis). with cp set will still respond to :version, while elvis will not (well, it will, but with an error ;). one of the annoying things about vim-users is that most of them don't know much about vi, and tend to ascribe lots of things to vim that are standard in vi. (don't be like most vim-users) -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: vi startup (not vim?)
On Wed, 18 Sep 2002, darren chamberlain wrote: * Thomas E. Dickey [EMAIL PROTECTED] [2002-09-18 09:04]: On Wed, 18 Sep 2002, darren chamberlain wrote: vim has a :version command, which other vi clones don't seem to; vim :ve is standard. (:version is also recognized by all of the vi's that I recall - including elvis). OK, I stand corrected. However, :ve will still tell him whether he's using vim or not, eh? yes (I haven't noticed any counter examples - its version message is pretty verbose - even when presumably running in vi-compatibility mode, which can be a problem in itself) with cp set will still respond to :version, while elvis will not (well, it will, but with an error ;). one of the annoying things about vim-users is that most of them don't know much about vi, and tend to ascribe lots of things to vim that are standard in vi. Hey, Sven, calm down, will ya? ;) He's tamer than he once was (we don't often quarrel anymore - I seem to recall this was once an issue) Actually, though, my experience has been the opposite: people who are vim users tend to think that vim features are standard vi features, and get upset when, say, ga doesn't do what they expect. A lot of the vi evangelists I know are actually vim evalgelists, and it annoys me, much as it (apparently) annoys you. I do notice those (ga not working), but they aren't as common as they used to be (Redhat distributes vim ;-) (don't be like most vim-users) Actually, I'm not. In fact, on many of the boxen I use regularly, I'm not a vim user at all. I was unaware that other vi's supported :ve; I thought I remembered elvis, at least, not supporting it. perhaps very old elvis (but that would be very old - 1.8 has a version message; I don't recall what 1.7 did). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: vi startup (not vim?)
On Wed, 18 Sep 2002, Sven Guckes wrote: * Thomas E. Dickey [EMAIL PROTECTED] [2002-09-18 15:33]: one of the annoying things about vim-users is that most of them don't know much about vi, and tend to ascribe lots of things to vim that are standard in vi. Hey, Sven, calm down, will ya? ;) He's tamer than he once was i'm WHAT? (we don't often quarrel anymore - I seem to recall this was once an issue) now what did we quarrel about? who won? comp.editors (I seem to recall that I did). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: flaming tom
On Wed, 18 Sep 2002, Sven Guckes wrote: From: Thomas E. Dickey [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: Re: vi startup (not vim?) Date: Wed, 18 Sep 2002 12:36:55 -0400 (EDT) Message-ID: [EMAIL PROTECTED] To: Sven Guckes [EMAIL PROTECTED] cc: [EMAIL PROTECTED] pine still does not know know how to list-reply - or is it you, Tom? your Reply-To: is still superfluous. in fact, it loses your name on replies. pine, or the system-level config on this host. Initially it was ok, but tt changed some time ago, and I tweaked my personal settings to make it work; otherwise it was giving [EMAIL PROTECTED] as a return-address, which is not correct. Since it works well enough, I'll leave it alone. I do recall some issue with a few people becoming angry that they received two copies from me, but apparently they dropped off those mailing lists. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: Following URLs under Cygwin-mutt
On Mon, 9 Sep 2002, Gary Johnson wrote:
On Mon, Sep 09, 2002 at 01:16:16PM +0200, Thomas Baker wrote:
I use Mutt 1.4i in Cygwin so do not have access to Urlview.
Previous mail to this list regarding alternatives to Urlview
have recommended w3m and lynx, and I have had some success
putting these in mailcap. However, alot of the links do not
display at all in w3m and lynx.
Is it possible to direct mutt to view plain-text mail in a
non-console browser such as Mozilla? Or have others found
console-based options to be satisfactory?
It's a little awkward, but you can do this with w3m. If you use 'M'
instead of Enter to follow a link, w3m will invoke an external browser
to view the link. You can define this browser in the External Browser
entry in the Option Setting Panel ('o').
lynx (and I assume links) support external browsers as well. But it's
not clear from the description what/why w3m or lynx were not able to
satisfy his needs.
--
T.E.Dickey [EMAIL PROTECTED]
http://invisible-island.net
ftp://invisible-island.net
Re: ACS and Slang
On Fri, 6 Sep 2002, Elimar Riesebieter wrote: Hi all, I compiled unpatched sources from mutt.org against slang. This was to have a full background colored headerline! But now I can not view the pager with ACS trees. I have to switch to set ascii_chars in muttrc. my impression (haven't seen any comments that this is fixed yet) is that the slang UTF-8 package doesn't work for line-drawing characters. There were some patches to hardcode the corresponding UTF-8 strings which may make it usable. otoh, ncursesw does support Unicode/UTF-8 line-drawing... perhaps it would be simpler to just patch mutt to add the extra places to fill in the background. The version of slang I am using is: ii slang1 1.4.5-1 ii slang1-utf8-dev 1.4.5-1 ii slang1a-utf81.4.5-1 Any advices? Ciao Elimar -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: ACS and Slang
On Fri, 6 Sep 2002, Elimar Riesebieter wrote: On Fri, 06 Sep 2002 the mental interface of Thomas E. Dickey told: otoh, ncursesw does support Unicode/UTF-8 line-drawing... perhaps it would be simpler to just patch mutt to add the extra places to fill in the background. [...] Is there a patch to add the extra places to fill in the background? Where Do I find it? I haven't made one. Perhaps it's about time. This topic comes up occasionally, and since I'm in the process of checking the pre-release, it's a good idea to work on this end of things. And then compile against ncurses? actually ncursesw, which is built from current source with a different configure option. Debian has a package built from one of the development snapshots earlier this year - close enough to see most of the changes I've made for ACS. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: ACS and Slang
On Fri, 6 Sep 2002, Elimar Riesebieter wrote: On Fri, 06 Sep 2002 the mental interface of Thomas E. Dickey told: I haven't made one. Perhaps it's about time. This topic comes up occasionally, and since I'm in the process of checking the pre-release, it's a good idea to work on this end of things. [...] YEP. But the mutt developers have to put this into the sources. It would be more usefull to act with an option like set hdr_bkgdcolor. So it's in the users choise to configure there headers as they want to. I am not a programmer. So how to tell this wish? A mail to mutt-dev? I'll post it to mutt-dev. (I've pointed out more than once that my previous patches were ignored, and during this year have been told it shouldn't happen again ;-) -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: ACS and Slang
On Fri, 6 Sep 2002, Bill Nottingham wrote: Thomas E. Dickey ([EMAIL PROTECTED]) said: my impression (haven't seen any comments that this is fixed yet) is that the slang UTF-8 package doesn't work for line-drawing characters. There were some patches to hardcode the corresponding UTF-8 strings which may make it usable. Yeah, the tricky thing is getting the same slang library to DTRT when in both unicode and non-unicode locales. hmm - I haven't seen any recent comments. What I did recall was something to the effect that slang wasn't maintaining a table that would let the application tell what the intended effect of the line-drawing characters would be. In (n)curses, that's the acs_map[]. I think I have that sort of thing working reasonably well in current ncurses (until someone comes along and tells it why not ;-). It matches the observed behavior of Tru64 curses, anyway... -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: Numeric Keypad Malfunction -- Mutt, Vim, Gnome-Terminal
On Fri, 26 Jul 2002, John P Verel wrote: On 07/25/02 19:05 -0400, John P Verel wrote: I cannot get my numeric keypad to work with Mutt. Here's my environment: The numeric keypad works correctly within gnome-terminal (e.g. writing code), works fine within mutt, if run from xterm or rxvt. However, if I edit with vim, within mutt, run in a gnome-terminal, the numeric keypad does not work correctly. For example, I press the number 1 on the keypad, I get the letter q inserted above the current line. I should also have noted that if I use other editors -- Emacs, Jed -- within a gnome terminal this problem does not occur. This makes me believe that this is a mutt/vim issue. not really - emacs is termcap-oriented, rather than curses, and tends to ignore things that have been done in curses for some time. (vi, on many systems, is built using curses and the same issue applies) -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: to GNU or not to GNU
On Tue, 23 Jul 2002, Sven Guckes wrote: * V K [EMAIL PROTECTED] [2002-07-21 06:54]: Funny, even just about every GNU app supports readline() and cmdline editing. I have come to think of it as state of the art, or standard. * On Sun, Jul 21, 2002 at 01:00:31PM +0200, Sven Guckes wrote: not every mutt gets linked to the GNU readline. * Doug Kearns [EMAIL PROTECTED] [2002-07-23 04:49]: I must be missing something, but I didn't think _any_ mutt was using the GNU Readline Library? it depends on how you use the configure options: ~/mutt-1.4 ./configure --help | grep GNU --with-regex Use the GNU regex library --with-included-gettextuse the GNU gettext library included here the coice it up to you! Which of those options uses readline? (neither). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: Mutt 1.3.28 internal pager, Screen 3.09.11: right-padded spaces
On Fri, 12 Jul 2002, Rick Moen wrote: Quoting Thomas Dickey ([EMAIL PROTECTED]): the same as before: the 'screen' terminfo which has no 'bce' capability. So, a couple of things about that, if you don't mind: 1. Perhaps you wouldn't mind explaining the relevance. _Is_ Background Color Erase support in one's terminfo setup essential for screen to correctly support X11 copy/paste (without getting spurious right-padded spaces? Is this a known requirement and a known failure mode in its absence? It's a matter of side-effects. bce says that when doing an erase, the terminal doesn't change the background color. (n)curses and other applications use this information to decide when they don't have to repaint the background using spaces, i.e., filling using the current background color setting. xterm uses the explicit writes in contrast to erases to decide what parts of the screen contain text which can be selected. Please note that I've tried to research this in the docs for both screen and mutt, and not found anything. Is this documented somewhere, and I just missed it? 2. If so, why did all this use to work on default Debian (circa 2.2 release) setups, and then suddenly cease to work upon upgrading _mutt_, at some point? Please note that I changed no terminal settings, during that period. I've been using mutt under screen for many years, and all I did was incrementally upgrade both precompiled Debian packages using apt-get. probably the version of screen changed. At one point it didn't pay much attention to the bce feature, iirc. I still have a note in one of my to-do lists from the beginning of 2000 that screen had something hardcoded to assume that $TERM set to xterm-color implied that it supported bce. That may be the source of your confusion. It was incorrect, and presumably has been fixed. (I've sent fixes a several times to screen's maintainers, who have ignored them, btw - my recollection is that the only time I get an email response is when I'm not supplying a patch ;-) 3. Three days ago, when I attempted to enable BCE on someone else's advice, you may recall that I created ~/.terminfo/s/screen as a symlink pointing to /usr/share/terminfo/s/screen-bce . On Debian, the latter is itself a symlink to /etc/terminfo/s/screen-bce, a compiled terminfo entry. Running strings on that binary yields the following header: screen-bce|VT 100/ANSI X3.64 virtual terminal with bce So, are you saying this terminfo entry purports to include BCE support but is mistaken? Or that terminfo is otherwise defective? Or that terminfo BCE support is there but screen is failing to use it, or what? It doesn't mention bce. bce is a boolean flag, and infocmp would print that on the first few lines. The names are ordered according to type. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: key macros
On Wed, 5 Jun 2002, darren chamberlain wrote: I get: $ echo ctrl-v f1 | perl -lpe '$_ = join , unpack(c*, $_)' 27 79 80 $ echo ctrl-v ctrl-F1 | perl -lpe '$_ = join , unpack(c*, $_)' 27 79 53 80 I'm using a happy hacking keyboard, which might make a difference, but I doubt it. esc [ 5 P is XFree86 xterm PC-style control/F1, documented in ctlseqs.ms, e.g., In normal mode, i.e., a Sun/PC keyboard when the sunKeyboard resource is false, xterm recognizes function key modifiers which are parameters appended before the final character of the control sequence. Code Modifiers - 2 Shift 3 Alt 4 Shift + Alt 5 Control 6 Shift + Control 7 Alt + Control 8 Shift + Alt + Control For example, shift-F5 would be sent as CSI 1 5 ; 2 ~ -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: Encripting to multiple recipients thread visualization inKonsole 3.0
On Fri, 31 May 2002, Fernando Schapachnik wrote: % 2) When I switched from KDE 2 to KDE 3, threads indicators in Konsole % started to look strange, any ideas? is that mutt linked with ncurses, or slang? (I've noticed some discussion to the effect that the UTF-8 flavor of slang on Debian doesn't handle line-drawing characters). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: Shell Command function ignores $SHELL
On Mon, 13 May 2002, Aleksey Tsalolikhin wrote: Hi, Is it me or does the Shell Command function use /bin/sh to execute commands regardless of the value of my SHELL variable? For example, I start mutt with SHELL=/usr/local/bin/zsh mutt and then run !ps -p $$ if mutt's using system(), that's usually defined to /bin/sh, ignoring your $SHELL variable. and it shows sh. Am I doing something wrong? I'd like to be able access my shell aliases from mutt via !. Yours truly, -at -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: Shell Command function ignores $SHELL
On Mon, 13 May 2002, Aleksey Tsalolikhin wrote: My C is pretty weak but execl (EXECSHELL, sh, -c, cmd, NULL); looks odd when I know EXECSHELL is /usr/local/bin/zsh. I'm not quite sure what this does, it looks like it specifies the path /usr/local/bin/zsh but then invokes it as sh? That would certainly explain the lack of aliases! yes - the first parameter is the actual executable, but the second is the name that the executable thinks it is invoked by. Some shells (such as bash) check that to decide whether to behave just-like-sh. Aliases are a different matter - some shells may require an option to force them to read their initialization files). In context, it looks as if mutt's shell interface needs a little tweaking for you to get just what you want. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: ugly thread tree display
On Wed, 24 Apr 2002, Ken Weingold wrote: If you like putty and want a REALLY nice ssh client, check out SecureCRT from VanDyke. www.vandyke.com . For Windows I really couldn't ask for more, and VanDyke is a perfect example of how a company should be run. I tested it a few months ago (to see if I should update the 'crt' terminfo to cover this). It did not do as well with vttest as putty. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: ugly thread tree display
On Tue, 23 Apr 2002, David T-G wrote: I wanted to ask about this before but forgot... Are you sure it's cygwin's and not Win's? Where is telnet if you do a which? cygwin dll implements a terminal emulator inside M$'s console window. (running bash in the window makes the terminal emulator startup, it seems) -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: macro problem
On Tue, 16 Apr 2002, Nicolas Rachinsky wrote: * Michael Tatge [EMAIL PROTECTED] [2002-04-16 20:58:08 +0200]: Nicolas Rachinsky ([EMAIL PROTECTED]) muttered: * Eduardo Gargiulo [EMAIL PROTECTED] [2002-04-16 14:07:07 -0300]: i'm not right on the mutt box. I'm connected through ssh using PuTTY client. My settings are: function keys and keypad=Xterm R6 Use VT100+ What's better with VT100+? Everything I needed here seems to work fine. Nicolas PS: using FreeBSD 4.5 with a termcap entry based on xterm-color. FreeBSD maintainers (?) insist on using xterm-color, though it does not closely match XFree86 xterm. It's an faq... http://invisible-island.net/xterm/xterm.faq.html There is a better termcap file distributed with xterm, btw. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: macro problem
On Tue, 16 Apr 2002, Nicolas Rachinsky wrote: * Thomas E. Dickey [EMAIL PROTECTED] [2002-04-16 15:45:37 -0400]: On Tue, 16 Apr 2002, Nicolas Rachinsky wrote: PS: using FreeBSD 4.5 with a termcap entry based on xterm-color. FreeBSD maintainers (?) insist on using xterm-color, though it does not closely match XFree86 xterm. It's an faq... http://invisible-island.net/xterm/xterm.faq.html There is a better termcap file distributed with xterm, btw. I do NOT use xterm, I use putty. xterm-color seems to work better with putty, either with FreeBSD and SuSE Linux. better isn't good enough if it's still not correct. xterm-color is a generic entry, targeted at people who either don't know what their terminal can do, or don't care much. I wrote a putty terminfo some months ago (ncurses 2007, prompted by an earlier thread). There are about 2 dozen differences between that and xterm-color. ymmv. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: syntax highlighting in mutt
On Mon, 8 Apr 2002, darren chamberlain wrote: As a professional perl programmer, I have to say that I've found vim to be the least deficient in parsing perl syntax. Better than Emacs' cperl-mode (not a flame, and observation!) and light year's better than anything else (have you how atrocious enscript's syntax highlighting for perl is?). The things most highlighter seem to have a problem with (inculding emacs) is POD, regexes, and the alternative quoting mechanisms. not at all - I see (whenever I work on that one) that vim has about as many defects in its parser as vile. ymmv. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: M$ Outhouse E. for UNIX
On Tue, 26 Mar 2002, David T-G wrote: % And now all Solaris-users can enjoy the MS Outlook % Express-experience ;-) % % http://www.microsoft.com/unix/ie/evaluation/outlookexp/default.asp ... % % * Outlook Express is easy to set up and use, and provides you with % secure, personalized, and complete features that make creating, % sending, and reading your e-mail a more rich and dynamic % experience. experience is another of those words, that in the context of advertising, is a guarantee that the author is an idiot and should be ignored. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: defining a command - internal langauge
On Fri, 22 Mar 2002, Dave Pearson wrote: * Sven Guckes [EMAIL PROTECTED] [2002-03-21 23:13:28 +0100]: * Jeremy Blosser [EMAIL PROTECTED] [2002-03-21 16:49]: [SNIP scripting in mutt would be nice] [SNIP Sven swears in public] Sven [slang, anyone?] I seem to remember that someone does/did maintain a patch that made mutt programmable via slang. possibly - but I've only seen it mentioned as a possibility that could be developed rather than an accomplished fact. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: defining a command - internal langauge
On Fri, 22 Mar 2002, Thomas E. Dickey wrote: I seem to remember that someone does/did maintain a patch that made mutt programmable via slang. possibly - but I've only seen it mentioned as a possibility that could be developed rather than an accomplished fact. speaking of which (since I followed up with a check in google), this page contains a long-obsolete link for ncurses (has not been active for about 6 years): http://www.math.fu-berlin.de/~guckes/mutt/ I would assume that it is not a currently maintained page, since some of the other information on it is not correct, but the header has a pointer to mutt 1.3.x ... -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: defining a command - internal langauge
On Fri, 22 Mar 2002, Dave Pearson wrote: * Thomas E. Dickey [EMAIL PROTECTED] [2002-03-22 10:28:35 -0500]: On Fri, 22 Mar 2002, Dave Pearson wrote: I seem to remember that someone does/did maintain a patch that made mutt programmable via slang. possibly - but I've only seen it mentioned as a possibility that could be developed rather than an accomplished fact. I've got a pretty clear memory of someone producing and maintain a patch which enabled slang as a scripting language for mutt. I know it was mentioned a good few times, either here or on the developers' mailing list. Am I really miss-remembering that? I don't know - I searched further and found a patch, but it's pre-1.0 (and don't know if the patch was good or not). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: Mutt 1.3.28 + ncurses 5.2 + xterm = blank screen
On Mon, 18 Mar 2002, Pavel Roskin wrote: Hi, Thomas! I've compiled mutt-1.3.28i in the default configuration on RedHat Linux 7.2 (i386) with all updates. If I run it in xterm (from XFree86-4.1.0) or in rxvt-2.7.6, it shows a blank screen. I can quit by pressing Ctrl-C and Enter. The same executable runs on the Linux console just fine. what $TERM value? xterm both under xterm and rxvt. I forgot to mention that I was running xterm from rxvt. I have found that if I run xterm from the window manager the problem goes away! When I run rxvt, it sets the following environment variables beginning with COLOR: COLORFGBG=default;0 COLORTERM=rxvt Both xterm and rxvt are using black background. From .Xdefaults: XTerm*background: black XTerm*foreground: gray85 Unsetting COLORFGBG fixes the problem. that's a bug that I fixed in September. The problem was that when I coded the $COLORFGBG logic (which btw is under-documented in rxvt - you have to read the C code to see it), it didn't occur to me that its format might change. It happens that the format depends on whether xpm is linked in - 2 or 3 fields. The background color is the last field. (Since it's under-documented, it's also possible that in the future anything that relies upon that format will be broken ;-). My interpretation is that mutt uses black text on black background. Probably ncurses interprets default in COLORFGBG as black whereas S-Lang uses the foreground from the X resources. Shouldn't ncurses ignore COLORFGBG if it has unsupported keywords (let's move this discussion elsewhere if you want to continue). $COLORFGBG is marked as an experimental feature. I've gotten 2-3 reports of this particular problem - but only months after I stumbled on it myself. Apparently one or more of the rpm's last year turned that feature on, though it was in the code almost a year. Not exactly mutt problem, but may be useful thing to know if other people ask. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: Mutt 1.3.28 + ncurses 5.2 + xterm = blank screen
On Mon, 18 Mar 2002, Pavel Roskin wrote: Hi, Thomas! I've compiled mutt-1.3.28i in the default configuration on RedHat Linux 7.2 (i386) with all updates. If I run it in xterm (from XFree86-4.1.0) or in rxvt-2.7.6, it shows a blank screen. I can quit by pressing Ctrl-C and Enter. The same executable runs on the Linux console just fine. the term 'blank screen' was misleading (to me). Totally black might have jogged my memory regarding $COLORFGBG (though the unrelated report of the pager which does not display anything was what I was thinking about). It's not a mutt problem, though as you noted. When I first saw it (early September or late August), it was from running the ncurses test program. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: color 'default'
On Fri, 15 Mar 2002, Ken Weingold wrote: Where does 'default' come from, as whether it gets recognized or not? for ncurses, it's implemented by the use_default_colors() function. If the configure script doesn't find that, it won't compile-in the support for default into mutt. I ended up installing ncurses into my home directory and mutt built perfectly. I reported this back the server admin and she said that after looking into it, ncurses on the server was indeed screwed. She said she reinstalled it, and when I tried building 1.3.28 just to try the server ncurses, it built fine, and mutt -v reports ncurses 5.2, but default is not recognized when it starts up. In the version I built from ncurses from my home dir, no problem. Thanks. -Ken -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: mutt and ncurses
On Wed, 13 Mar 2002, Ken Weingold wrote: On Wed, Mar 13, 2002, David Champion wrote: Run ldd mutt. This will tell you what shared dependencies the binary has (including whether it used the shared or static libs from your ncurses build). Oh, cool. So the following means that mutt doesn't need any of the ncurses libraries at all after the binary is built? ./mutt: -lintl.1 = /usr/local/lib/libintl.so.1 -liconv.2 = /usr/local/lib/libiconv.so.2 -lc.12 = /usr/lib/libc.so.12 You have to do something about the terminfo database, if there is no /usr/local/share/terminfo (ncurses normally doesn't default to looking at /usr/share/misc/terminfo, for instance unless you have set $TERMINFO or $TERMINFO_DIRS). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: mutt and ncurses
On Wed, 13 Mar 2002, David Champion wrote: On 2002.03.13, in [EMAIL PROTECTED], Ken Weingold [EMAIL PROTECTED] wrote: Oh, cool. So the following means that mutt doesn't need any of the ncurses libraries at all after the binary is built? ./mutt: -lintl.1 = /usr/local/lib/libintl.so.1 -liconv.2 = /usr/local/lib/libiconv.so.2 -lc.12 = /usr/lib/libc.so.12 Yep. If it were depending on your ncurses build, you'd see another line like -lncurses = /home/hazmat/ncurses-5.2/libncurses.so or something. if it were - but by default ncurses doesn't build shared libraries. (On some systems such as FreeBSD which have poor linker semantics combined with a lagging-edge version of ncurses, that results in linking with the system's copy of ncurses - but ldd shows that, too ;-). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: Mutt configuration tool
On Thu, 7 Mar 2002, Will Yardley wrote: Simon White wrote: Since it's dynamic, he'll have to be running a web server, etc. A shell or PERL script will guarantee functionality across a wider range of Linux distros and setups. and other operating systems; mutt runs on a number of systems other than linux (ie FreeBSD, commercial UNIX, win32, etc). technically not win32 since it's not a native port (cygwin). contrast to pine which I've read does have a native win32 port... -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: News about Mutt - guckes.net/mutt/news.html
On Wed, 6 Mar 2002, Sven Guckes wrote: I have finally moved all the news items about mutt from my main page about mutt to an extra page. So now you can bookmark it and have NetMind send you an update notice when the page changes. further news welcome, of course. :-) perhaps you should send the url in your email (the one in your signature is usable with lynx, so you probably aren't talking about that). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: Pager problems in 1.3.27
On Wed, 6 Mar 2002, Raymond A. Meijer wrote: P.S. I could make screenshots if anybody would want to see what's happening... more useful would be a typescript (from running mutt within 'script'). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: News about Mutt - guckes.net/mutt/news.html
On Wed, 6 Mar 2002, Sven Guckes wrote: * On Wed, 6 Mar 2002, Sven Guckes wrote: I have finally moved all the news items about mutt from my main page about mutt to an extra page. * Thomas E. Dickey [EMAIL PROTECTED] [020306 13:41]: perhaps you should send the url in your email (the one in your signature is usable with lynx, so you probably aren't talking about that). huh? the URL is in the Subject: line... anyway - here it is again: http://guckes.net/mutt/news.html - http://www.math.fu-berlin.de/~guckes/mutt/news.html shrug - you're using a table where a list works just as well. either way, it's readable. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: mutt paints over background image
On Thu, 28 Feb 2002, Dominik Vogt wrote: # Reconstructed via infocmp from file: /usr/lib/terminfo/r/rxvt rxvt|rxvt terminal emulator (X Window System), am, bce, eo, km, mir, msgr, xenl, xon, ... Ah yes, I see. I must have misread the infocmp man page. But the op entry looks exactly like you said. then the problem is likely on the other end - something didn't work in mutt's configure script, so it doesn't see the functions that control color (use_default_colors, for instance). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: mutt paints over background image
On Wed, 27 Feb 2002, Dominik Vogt wrote: I have been using mutt in an rxvt window with a background xpm for a long time, using the version from the SuSE distribution withouth compilling myself. Since SuSE 7.2 however, rxvt covers the background image with a black character background itself. I guess this has something to do with slang vs. ncurses. The older versions were using ncurses and the new ones are compiles with slang. Is there any way to get back my background image without having to compile mutt myself? it's most likely the choice of $TERM (the terminfo entry should have 'op' using \E[39m;\E[49m, for instance). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: keybindings for mutt in Sun's DTTERM
On Fri, 22 Feb 2002, Mike Schiraldi wrote: Anyone else using Mutt on solaris that has a fix for this? I'm using Solaris 8 for x86 (which is now discontinued so I hope to switch it to Linux sometime in the future, but for now, I have to do it this way). As a first step, take a look at what codes PgUp and PdDn are sending -- for example, run od and type pgupenterpgdnenterctrl-d none of the dtterm's I have seen send characters for page-up/down. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: keybindings for mutt in Sun's DTTERM
On Fri, 22 Feb 2002, Carl B. Constantine wrote: * Thomas E. Dickey ([EMAIL PROTECTED]) wrote: On Fri, 22 Feb 2002, Mike Schiraldi wrote: Anyone else using Mutt on solaris that has a fix for this? I'm using Solaris 8 for x86 (which is now discontinued so I hope to switch it to Linux sometime in the future, but for now, I have to do it this way). As a first step, take a look at what codes PgUp and PdDn are sending -- for example, run od and type pgupenterpgdnenterctrl-d none of the dtterm's I have seen send characters for page-up/down. Well, I also tried it in an xterm, same results: 000 005012 002 but with xterm at least, you can modify the translations resource and get characters - Sun's app-defaults file for xterm is setup to perform scrolling for page up/down rather than send characters. So I think this has less to do with the term than it does with CDE or some other OS level event. not really. I see people asking about modifying this for dtterm, but no one seems to have a satisfactory answer. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: slackware term question
On Wed, 6 Feb 2002, Dale Morris wrote: I've changed over from Redhat 7.2 to Slackware 8.0. In slack I'm using the standard kernel 2.2.19. I'm using mutt 1.2.1-1 and a modified .muttrc from Roland Rosenfeld site. It worked fine in Redhat but in slack I have a problem. xterm normally doesn't have color defined (but several Linux distributions alias it to xterm-color -- I thought Slackware 8.0 did that, since it's in my testing notes). The correct $TERM for XFree86 xterm is xterm-xfree86 (using xterm-color means you can't use default-colors). In X, I don't have any color in mutt. Yet from the console the colors are fine. Also my mailbox checking feature that tells me if I have new mail doesn't work in either X or the console. Any suggestions thanks dale -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: rxvt-2.6.4, mutt-1.3.26i, ncurses-5.1, and ascii_chars
On Mon, 4 Feb 2002, Roman Neuhauser wrote: Hi there, yesterday I switched back from aterm (TERM=xterm-color) to rxvt (TERM=rxvt). I had some problems with display in mutt, and during the attempts to solve it I upgraded to 1.3.26i (don't use SSL, so I don't care about the bug). It works quite well, except for one thing: ascii_chars (w3m-0.2.1 also stopped rendering frames properly, while links-0.9.6 works just fine [VT100 frames in the Terminal Options menu]). I've read about a recent problem with w3m which broke line-drawing characters (iirc, it was fixed on in a subsequent package, but I don't know more that that) -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: [OT] Re: Wish about mutt's file browser
On Mon, 4 Feb 2002, Justin R. Miller wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Said Charles Jie on Tue, Feb 05, 2002 at 12:46:17AM +0800: 1. The file manager Konqueror is not mature (crash so oftern) If it crashes, then your setup has issues. It has been stable for years... even for opening big directories like /dev. which reminds me of a case where I was helping someone fix a problem with his email (in 1988 on an Apollo). My directory editor didn't much like that he had 1185 files in his home directory (it was increasing the file-array by one for each realloc - making it perform badly). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: Why is mutt 1.5 using reverse video when 1.3.23 didn't?
On Tue, 29 Jan 2002, Mike Schiraldi wrote: Mh... I trusted you on that patch, and didn't observe any adverse effects myself. ;-) Actually, after further review, this appears to be a bug dating all the way back at least as far as mutt 1.2.5. Try opening an xterm with the command xterm -bg grey -fg black and then run mutt -n -F /dev/null. With the current CVS or any version available at ftp.mutt.org. Instead of keeping the black on gray color scheme, it switches to gray on black. that sounds like default-colors aren't setup -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: your mail
On Sun, 27 Jan 2002, Will Yardley wrote: Thomas Dickey wrote: [this is getting OT, so it might be nicest to continue this discussion off list if necessary] I had in mind (having forgotten that FreeBSD has a not-invented-here mentality) that they'd implemented a copy of the GNU 'ls', and didn't consider that they may have fixed one problem while introducing another... is it gnu's ls? it isn't in /usr/src/gnu/bin - it's in /usr/src/bin, and has a standard BSD license at the top. also the options are different in freebsd - it's 'ls -G' not 'ls --color[=]'. I seem to recall some discussion that there was a port of the GNU ls, and that it was unsatisfactory (since it wasn't part of the base system). There was some related discussion regarding some incompatible changes made to the console's color handling - middle of last year iirc (the 3 *BSD's now have 3 incompatible flavors of the same console driver, making it hard to decide if I should reflect any of that in the terminfo database). The tone of the discussion however was that the color 'ls' was just-like-GNU (but-different-of-course). Part of the discussion was in newsgroups, part I saw in mailing lists via google. (I look at related discussions to see if there are problems for ncurses, etc.). Anyway, the color 'ls' you're talking about is not quite the same as in the FreeBSD 4.1 that I have (which doesn't mention xterm in the manpage, though it does have color support. I might recall that more readily, however I don't use that feature - 'ls' is useful for scripting, but I get color using my directory editor... -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: blind etiquette Re: mutt for blind computerusers
On Wed, 23 Jan 2002, Preben Randhol wrote: Thomas E. Dickey [EMAIL PROTECTED] wrote on 23/01/2002 (19:11) : You're not responding to his question. (w3m doesn't do javascript No I didn't say it did. I just said w3m is better than lynx. tsk, tsk (you should go back and read the paragraph to which you responded) either). And the comment about screen-readers indicates that w3m and links would be worse choices than lynx. Don't know how a screen reader works, so can you please explain why it would be worse? I've been told (more than once) that screen readers are line-oriented. They don't handle two-dimension layout of the sort that people tend to contrive when attempting to use html as a layout description. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: blind etiquette Re: mutt for blind computerusers
On Wed, 23 Jan 2002, Preben Randhol wrote: Thomas E. Dickey [EMAIL PROTECTED] wrote on 23/01/2002 (20:31) : tsk, tsk (you should go back and read the paragraph to which you responded) Yes I have done it 3 times and I don't understand your point. If you could please be more clear when you post comments it would be nice. There were no questions in that paragraph. I've been told (more than once) that screen readers are line-oriented. They don't handle two-dimension layout of the sort that people tend to contrive when attempting to use html as a layout description. Can they handle javascript? According to some webpages, JAWS and a few other applications will read hidden text, including some inferences about JavaScript. But a quick search doesn't say that in so many words - it's not 100% clear: my impression is that they're acting as the browser. The screen readers appear to just render whatever text is put onto the screen. But that's a static view - doesn't account for things moving around or being presented out of order. So I expect that the request was for something that could handle that situation, by directing the screen reader's focus to the newly presented text. None of lynx/w3m/links do that. (Let's leave netrix out of the discussion ;-) -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: how to change xterm title depending on current mailbox
On Wed, 23 Jan 2002, David T-G wrote: Sam -- ...and then Samuel Padgett said... % % darren chamberlain [EMAIL PROTECTED] writes: % % In vim: % %set titleold=My\ Old\ Xterm\ Title % % and it will restore the xterm's title to that string. % % Yes, but I'd like Vim to restore the XTerm title to whatever it % was before I started Vim. This might be something different each % time. He answered this later, too. Check out :help title something like that. Reading the code, I see that it doesn't use the xterm escape sequence for getting that information, but requires that vim is linked with the X libraries. (A little surprising, since they implemented that feature a year or two after I added the escape sequences from dtterm, and I'd assumed they were using those). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: blind etiquette Re: mutt for blind computerusers
On Tue, 22 Jan 2002, Preben Randhol wrote: Cameron Simpson [EMAIL PROTECTED] wrote on 21/01/2002 (22:12) : You can't. It's rude anyway. The amount of time you spend trimming stuff to just the relevant stuff is _more_ than outweghed by the time saved to the list members as a whole, not to mention the readability of the mail archives and everything else. Bullshit. Get a better editor or learn to use vim. indeed. (not that I use vim, but reading your statement literally, vim is not a better editor). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: 1.3.25 builds with S-LANG - PuTTy colors now munged
On Wed, 16 Jan 2002, Nicolas Rachinsky wrote: On Sun, Jan 06, 2002 at 04:18:19PM -0500, Jack Baty [EMAIL PROTECTED] wrote: After installing from the port, colors are no longer working properly using Putty. By not working I mean that it seems the foreground and background colors are reversed in some cases. Text that was previously green on a default background is now black on a green background. The default background does not seem to show through. In other cases, the text color is completely different from those defined in my .muttrc. No other changes were made that I'm aware of, so I started poking around in the makefile. I noticed that during the install that slang was also installed, which I'd not seen before. The Makefile says... # In general you can choose between using the SLANG port (which is really # recommended and is now the default) and ncurses (WITH_MUTT_NCURSES). If you # don't want to use SLANG define WITHOUT_MUTT_SLANG. indeed (I haven't seen any discussion that indicates there was any technical reason for this - a shame, since that tends to increase my own incoming bug reports from people who don't know how to set their environment). Now, before I go around messing with trying to go back to using ncurses, I'd like to know if anyone knows if there's a way to fix the color issue while still using slang, since that seems to now be recommended. I know nothing about curses or S-LANG btw, so I'm pretty much flying blind here. not really (barring bugs in mutt, there's no intrinsic difference between what's doable with ncurses or slang). There were some trivial bugs reported for color support, but my experience with sending patches _to_ mutt-dev was that they were ignored (not even rejected), so there's little reason to pursue that. Same problem here, but mutt seems to work fine, when build with WITHOUT_MUTT_SLANG=YES. Nicolas -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: 1.3.25 builds with S-LANG - PuTTy colors now munged
On Wed, 16 Jan 2002, Jeremy Blosser wrote: Well, FWIW, I'm pretty sure he's talking about his own vendor's mutt package (port is a BSD-ism, right?). Regular Mutt still defaults to ncurses, and there's certainly no mention of the above text in Mutt's Makefile. generally (you're correct there). Some porters do a good job, some don't. Unfortunately (in contrast to Debian), FreeBSD's porters seem to work as a mob (makes it hard to keep track of who is handling a package). not really (barring bugs in mutt, there's no intrinsic difference between what's doable with ncurses or slang). There were some trivial bugs One difference I discovered recently that made me switch my build back to ncurses (heh) is that S-Lang has a rather low value for COLOR_PAIRS. At around 30 color entries, any additional ones started reverting back to normal... this might actually explain the problem Jack is having. (The real number is probably 25, since it has to be a square, but duplicate color pairs don't count against the total, and I didn't research it all the way down yet.) that seems familiar (but ncurses does use a square, though pair 0 is treated specially). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: $display_filter and allow_ansi
On Tue, 15 Jan 2002, John Levon wrote: On Tue, Jan 15, 2002 at 06:20:00AM -0500, Thomas Dickey wrote: Any ideas on what the problem is and how to fix it ? I am using xterm-color on a BSD box ssh'd from Linux. The $display_filter is attached. TERM=xterm-color will always do this (except for some hardcoded crap I've seen), since it's telling the screen library that the terminal cannot do default colors. Then why does color internal in mutt work perfectly ? And cat through the script ? The XFree86 xterm supports ANSI color and VT220 emulation perhaps you have missed my point. perhaps not. You said using xterm-color that you're getting black background for the text instead of the default. The xterm-color description doesn't have bce, so it cannot produce default color (unless it's relying on additional information, e.g., the screen library's been told that default is something other than black). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: failed build
On Sun, 6 Jan 2002, Will Yardley wrote: It won't work (the older wchar_t is a short, not a long). I experimented recently with that sort of combination with lynx and concluded that you can't make libiconv work properly there (you can build it, but it won't run). But unlike mutt, lynx at least doesn't rely on things like libiconv if they won't work... i'm giving another go at getting the beta mutt to compile on an outdated linux machine (for which i don't have root access). i'm not sure what distribution it is, although i'd guess redhat; kernel is really old (2.0.36). i have my own ncurses and libiconv installed in my home directory. i'm configuring with: LDFLAGS=-Wl,-R/home/will/lib ./configure --prefix=/home/will --with-libiconv-prefix=/home/will --with-curses=/home/will/ i then get this error: gcc -DPKGDATADIR=\/home/will/share/mutt\ -DSYSCONFDIR=\/home/will/etc\ -DBINDIR=\/home/will/bin\ -DMUTTLOCALEDIR=\/home/will/share/locale\ -DHAVE_CONFIG_H=1 -I. -I. -Iintl -I/home/will//include -I/home/will/include -I./intl -I/home/will/include -Wall -pedantic -g -O2 -c patchlist.c In file included from protos.h:20, from mutt.h:811, from patchlist.c:5: mbyte.h:23: conflicting types for `wcwidth' /usr/include/wchar.h:209: previous declaration of `wcwidth' make[2]: *** [patchlist.o] Error 1 make[2]: Leaving directory `/home/will/mutt-1.3.25' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/will/mutt-1.3.25' make: *** [all-recursive-am] Error 2 sepia% uname -srm Linux 2.0.36 i686 ideas? w -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: html mails and mutt (was: utf-8 display problem index vs. pager)
On Thu, 20 Dec 2001, Stephan Seitz wrote: lynx produces footnotes for every HREF link, but it doesn't work well in an utf-8 environment. I ought to write a lynx faq... (the utf-8 stuff works well enough with current code compiled against libncursesw). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: utf-8 display problem index vs. pager
On Mon, 17 Dec 2001, Cristian wrote: Hi Stephan! On Mon, Dec 17, 2001 at 11:38:45AM +0100, Stephan Seitz wrote: Strange, never w3m nor lynx can correctly display http://fsing.fs.uni-sb.de/~stse/manga.html. But w3mmee does. Plain w3m had wide character support only the for Japanese character sets Shift_JIS, EUC_JP, and ISO-2022-JP. In order to view UTF-8, you need to get the w3m-m17n patch from http://www2u.biglobe.ne.jp/%7Ehsaka/w3m/ w3mmee is an independent patch for the same purpose. Lynx has a setting for this. My ~/.lynxrc contains the line, character_set=UNICODE (UTF-8) Though I hardly use it now that there's w3m. That works better with the libncursesw. I added a few sample files for UTF-8 as I was testing. w3m itself doesn't do very well on those - you must be referring to one of the patched w3m packages. (I looked into setting one up, but it seemed geared solely toward CJK support). Do you have ncurses compiled with wide-char-support, and mutt is link againts libncursesw.so.5.2? The standard ncurses never really worked for me, but now Debian has It wasn't designed to do this (nor in fact is the standard slang package). the slang-utf8 package in testing, so it works fine with mutt. I have ncurses compiled by SuSE for their distro v7.2. The Mutt I built myself is linked against libncurses.so.5. I don't have libncursesw.so.5.2. I don't think anyone is packaging it. Debian may (it's mostly a matter of people finding time). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: color problems after upgrade
On Tue, 4 Dec 2001, Dave Price wrote: On Tue, Dec 04, 2001 at 05:58:02AM -0500, Thomas Dickey wrote: I tried you colors, and those object where default is specified as the background, the aterm background shows thru - everything else - the message body, and the main index background is still white on black. perhaps your $TERM is xterm-color (except for hardcoded applications that ignore $TERM, you won't see default colors working properly in that case). it is rxvt in both cases - the difference, other than the mutt versions is that one is running to a remote display (that one is good) and one is local - the display in both cases is the dame box. rereading - I addressed the wrong point. You have to use 'default' to get the background to show through in all cases (except where mutt is doing the wrong thing, of course ;-). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: [ Update ] List of 3rd party apps for Mutt
On Tue, 20 Nov 2001, René Clerc wrote: * Prahlad Vaidyanathan [EMAIL PROTECTED] [20-11-2001 15:36]: | Hi, | | Finally got around to updating it : | | http://www.symonds.net/~prahladv/mutt.html | | Feedback ? Looks nice! You could consider adding the text-based browser links. IMO, this is the best alternative for lynx. It supports frames! it's a matter of taste (if I look for an alternate text browser, w3m is more reliable - links has a long way to go on both robustness and portability). (writing nonmaintainable/nonportable code is a waste of time) -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: mice in mutt
On Thu, 8 Nov 2001, Paul Ackersviller wrote: On Wed, Nov 07, 2001 at 10:03:08PM -0500, David T-G wrote: I'll accept that. I'd call it the GUI version of mutt :-) While I see that as a logical evolution, I don't see it happening; mutt runs happily in a GUI (as you point out) terminal and can be made to call GUI helper applications (like image and web programs), and with eterm (IIUC) can even be made mouse aware. All of the work is done, with no extra bloat in the mutt code :-) Please enlighten me about making mutt mouse-aware, I wasn't aware that's possible. Why would it require eterm, couldn't it be done in an xterm like with vim and lynx? eterm implements some of the xterm mouse stuff (same as rxvt and aterm). It's possible that konsole (KDE) does also, but they don't bother documenting what it does (I noticed for instance that konsole recognizes one of the escape sequences I added for XFree86 xterm). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: color
On 1 Nov 2001, John J Kearney wrote: On Wed, 31 Oct 2001, René Clerc wrote: * John J Kearney [EMAIL PROTECTED] [31-10-2001 19:01]: | please can sombody tell me how to enable colors in mutt | i have a color xterm and vim has colors in it | what must i do for mutt ot work here also Configure them in your .muttrc ;) See the 'color' section in `man muttrc`. i think i've it all set up in my muttrc i'm still new and using most of svens config but i can't get any color using XFree86 4.1.0(161) what $TERM are you using? (XFree86 xterm should be xterm-xfree86; its accompanying terminfo file would install that as xterm). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: color
On Thu, 1 Nov 2001, Roman Neuhauser wrote: If xterm-color is incorrect, what should the value be? BTW, 1.2.5 displayed colors in rxvt without this hack, 1.3.23i didn't display colors until I put rxtv.termName = xterm-color in my .Xdefaults. did you use curses/ncurses or slang? rxvt sets $COLORTERM, which is used by slang to circumvent the normal setting of $TERM. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: color
On Thu, 1 Nov 2001, Roman Neuhauser wrote: did you use curses/ncurses or slang? rxvt sets $COLORTERM, which is used by slang to circumvent the normal setting of $TERM. I have installed mutt from the port with the default settings. Looking in the makefile doesn't reveal anything suspicious, so I guess mutt's chose either of them: ncurses is part of the base system on FreeBSD, and I have libslang 1.4.4_1 port installed too. $COLORTERM is rxvt-xpm, so I guess that indicates mutt is linked against ncurses, right? what was $TERM before you set rxvt.termName ? (your version summary says mutt is linked with ncurses 5.1, which sounds reasonable) -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: color
On Thu, 1 Nov 2001, Roman Neuhauser wrote: what was $TERM before you set rxvt.termName ? just xterm. xterm is usually the same as xterm-r6 (no color). (but xterm-color isn't correct - would be nice if FreeBSD installed the correct termcap entries so this wasn't something I had to point out periodically). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: color
On Thu, 1 Nov 2001, Roman Neuhauser wrote: Date: Thu, 1 Nov 2001 10:54:42 -0500 (EST) From: Thomas E. Dickey [EMAIL PROTECTED] To: Roman Neuhauser [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: color On Thu, 1 Nov 2001, Roman Neuhauser wrote: what was $TERM before you set rxvt.termName ? just xterm. xterm is usually the same as xterm-r6 (no color). (but xterm-color isn't correct - would be nice if FreeBSD installed the correct termcap entries so this wasn't something I had to point out periodically). I don't say it's correct. I _don't_ know the correct value. I've seen this suggested on freebsd-questions@, and it works. But if you tell me the correct value, I'll be happy to change the setting. Usually (except of course the suggestions which are secondhand or worse) the suggestion is based on the fact that FreeBSD doesn't install a termcap entry for anything more appropriate. There is a termcap file distributed with rxvt and one with XFree86 xterm. I'd start with those (preferring rxvt and xterm-xfree86). FreeBSD uses a compiled database for termcap, iirc under /usr/share/misc. Edit (save the original of course) the termcap file, putting the new entries at the beginning. Recompile the termcap database (I don't recall the name of the command - something like make_capdb - there is a manpage for it). There is also a better termcap file here (but doesn't necessarily include a few of the specialized console types for FreeBSD): ftp://invisible-island.net/ncurses/termcap.src.gz -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: color
On Wed, 31 Oct 2001, Daniel Farnsworth Teichert wrote: When I was first messing around with Mutt I had similar troubles when trying to use a regular old xterm. It seems like I found that setting the environment variable TERM to color_xterm instead of just xterm made it work. Calling xterm with the -tn color_xterm flag has a similar effect, I think. color_xterm is similar to xterm-color, and both are incorrect for XFree86 xterm and rxvt (ditto Eterm and aterm, konsole and gnome-terminal). to see this, use infocmp to compare their terminfo entries. HTH --Daniel On Wed, Oct 31, 2001 at 06:02:17PM +, John J Kearney wrote: please can sombody tell me how to enable colors in mutt i have a color xterm and vim has colors in it what must i do for mutt ot work here also TIA JJK -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: default: no such color
On Mon, 29 Oct 2001, Jonathan Perkin wrote: Aye, actually had time to investigate this over the weekend and found the offending stuff in mutt's configure script - for the use_default_color checks it only includes curses.h - now on NetBSD this only exists in /usr/include for system curses library, and the ncurses 5 pkgsrc only installs /usr/pkg/include/ncurses.h with no symlink back to curses.h I'm no automake/autoconf expert, so is this a mutt issue where the configure script should be modified to support NetBSD, or should the NetBSD pkgsrc DTRT and symlink /usr/pkg/include/curses.h - ncurses.h ? I think the configure script should be modified - not just NetBSD support. But it does get complicated. The script that I wrote for lynx defaults to curses (which in this case would pick up the NetBSD curses), and allows ncurses as an option. Mutt's configure script tries to find ncurses, but may be relying on a bias toward ncurses rather than making it explicitly an option. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: .mail_aliases
On Thu, 18 Oct 2001, David T-G wrote: In vim: vim filename :set fileformat=unix :wq vile filename :set-u :wq Ta-daa! Even easier than the :%s magic available in any vi or clone. -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: Binding Shift-keys?
On Wed, 19 Sep 2001, David T-G wrote: Hall, Miguel, et al -- ...and then Hall Stevenson said... % quite awkward, and I'd rather remap it to Shift-Tab. % However, I can't % find a way to define this key combination. What am I % missing? % % What do you mean 'define this key combination' ?? Do you set % it up but it doesn't work ?? If so, make sure there's not What he means is probably what I've found: I can't get mutt to recognize any sort of shift-tab key definition. most of the terminal emulators don't pass shift-tab as a different code from tab (XFree86 xterm does - I changed that early in 2000). -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: pb with arrows and numeric keypad (rxvt terminfo)
On Mon, 17 Sep 2001, Vincent Lefevre wrote: On Sun, Sep 16, 2001 at 19:18:19 -0400, Thomas Dickey wrote: but as I said before, you can get what you're looking for by modifying the terminfo description. there's no need to modify the C code. But then, this will break the applications that expect appplication-mode escape sequences. no. (unless you're talking about hardcoded applications) -- T.E.Dickey [EMAIL PROTECTED] http://invisible-island.net ftp://invisible-island.net
Re: Make it simple?
On Mon, 20 Aug 2001, Adam Shostack wrote: On Sun, Aug 19, 2001 at 07:30:40PM -0400, David T-G wrote: % I just upgraded to mutt 1.2.5, and its insisting on coloring % everything. I managed to get close to what I want by commenting Heh :-) % HAVE_COLOR out of config.h, but now I still get things like That's probably a good way to whack most stuff, but you could also check in the system-wide Muttrc and your own .muttrc for any 'color' statements and comment them out or turn them into 'mono' statements. Done, but that didn't leave me colorless; it left me with a grey background. (ee!) honestly - setting the terminfo up is the way to go (even slang will stop trying to set the background color, btw, if you unset $COLORTERM). If the terminal isn't capable of rendering bold, there's no reason for the application to attempt it. % underlining quoted text, boldface in headers, etc. I want plain % text. Suggestions for how to get there? I dunno about bold (like the index status line, right?) but you can turn off quote underlining by unsetting quote_regexp. No, actually bolded, using a heavier font. taking sgr, bold out of the terminfo would work here (though I suspect slang would try to fix the terminfo - ymmv) -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: recompile for updated ncurses?
On Sat, 18 Aug 2001, Ken Weingold wrote: I built mutt with ncurses 5.0, and just updated ncurses to 5.2. Any reason to recompile mutt? perhaps (with 5.1/5.2, I added a function assume_default_colors(), which you may want to configure against if you weren't using the default colors support in mutt). -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: default color no longer valid
On Thu, 9 Aug 2001, Nate Johnston wrote: All, I apologize if this has been discussed and I missed it, but I recently upgraded to 1.3.19i. When I did so, the default color seems to have disappeared. I get about 20 of these errors: Error in /home/nate/.muttrc, line 243: default: no such color you need to build mutt with either ncurses or slang (doesn't the list of compiler options still say what library it was built with? - I don't see that in the summary, though it says it found resizeterm, which is ncurses). The function in ncurses which turns on default colors is called use_default_colors - and that doesn't show in the summary. Perhaps the configure script is getting confused by NetBSD's curses, which won't work afaik. -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: long line handling
On Wed, 8 Aug 2001, Andrew Pimlott wrote: When the markers and smart_wrap options are both off, it would be nice if mutt would print long lines to the screen without a newline. This way, if I copy the line in an xterm, the whole line goes into the cut buffer unbroken. As it is, I get unwanted newlines in the cut buffer. still won't work (xterm won't retain it as a single line if it wasn't written as a single line, and you can't count on any screen optimization library to do this). I tool a look at fixing this, but it didn't look trivial, so I gave up and decided to post it as a feature request. FWIW, vim behaves the way I want, but less does not. see comment above (a little surprising for less - but I expect it's doing some optimization of its own). Also 'screen' does its own optimization, defeating the single-line selection you're asking for. -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: OT patch tutorial?
On Wed, 8 Aug 2001, Ken Weingold wrote: Does anyone know of any sites with tutorials on the basics of writing patches? I would like to modify an older patch, but need some basic direction on what I am looking at. none needed: apply the older patch to current baseline (look at .rej files and apply the missing chunks). test the patched source apply new changes, diff against the patched source to make a new patch. -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: Installing Mutt 1.3.19
On Tue, 24 Jul 2001, Nelson D. Guerrero wrote: Hello everyone. I`ve been forced to downgrade from mutt 1.3.19 to mutt 1.2.5 since I installed Slackware 8.0, I keep getting the following error with ncurses: look at the config.log file, which shows the error messages. Perhaps sl80's got some additional library dependency for ncurses. -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: mutt and HTML
On Fri, 20 Jul 2001 [EMAIL PROTECTED] wrote: text/html; links %s; needsterminal; nametemplate=%s.html in /etc/termcap works just fine for me. perhaps /etc/mailcap -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: mutt and HTML
On Fri, 20 Jul 2001, Alexander Skwar wrote: So sprach »Thomas Dickey« am 2001-07-19 19.07.2001 um 17:53:27 -0400 : On Thu, Jul 19, 2001 at 11:09:24PM +0200, Alexander Skwar wrote: So sprach »Juha Saarinen« am 2001-07-20 20.07.2001 um 09:02:05 +1200 : Links is quite good... does tables, ssl etc, but I guess it's a bit big... Uhm, not compared to lynx :) these are comparable (have ssl - which adds ~600kb) Uhm, mine also have SSL support. Are your bins not stripped? ssl is statically linked. perhaps you have shared libraries. if the programs did similar functions, their sizes would be closer Not neccessarily. I'd argue the point, but am not sure you have a good enough understanding of the issues. -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: xterm colored Mutt
On Wed, 18 Jul 2001, Andre Wyrwa wrote: Hello, I have the problem of having a non-colored mutt, when starting it in xterm. $TERM is xterm. When I change $TERM to linux or xterm-color mutt will start with colors. So I guess it has something to do with terminfo. Unfortunately I don't know a lot about it. On my SuSE-System mutt starts colored within a good place to start is www.google.com (search for xterm) as I point out 2-3 times a week, xterm-color is incorrect for XFree86 xterm, ditto linux. xterm even with $TERM=xterm, so I guess they changed properties of the xterm-terminfo-file or mutt is looking for something else to determine if it should use colors or not. So, can someone help me with this? How can I tell xterm to use xterm-color instead of xterm terminfo without having to set $TERM manually? see the man-page. -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: xterm colored Mutt
On Wed, 18 Jul 2001, Fox Mulder wrote: * Thomas E. Dickey [EMAIL PROTECTED] [21:42 18/07/01]: a good place to start is www.google.com (search for xterm) as I point out 2-3 times a week, xterm-color is incorrect for XFree86 xterm, ditto linux. i am new to this list. what will be the right setting fot xf86 if it is not xterm-color? it seems to be working fine for me.. xterm-xfree86 -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: Is color possible on exceed + Solaris?
On Mon, 9 Jul 2001, Chris Fuchs wrote: Hi, How can I know for certain whether color is supported on version 6.1 of exceed run on NT? I live on xterm sessions which access a solaris box (Sunos 5.5.1) and color would be nice. This works: mono header bold Subject: This doesn't: color header red black Subject: The above suggests my setup is mono even though I can get foreground and background colors using xterm's -fg and -bg options. Any pointers for getting mutt to display colors or even whether this is possible would be greatly appreciated. see my xterm ncurses faq's -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: Revisiting Mutt, Debian, Ncurses, Eterm .....
On Sun, 29 Apr 2001, Jason Helfman wrote: I'm not using any colors, though... white, black and default are colors (if the terminal description says it can do colors, mutt is probably starting colors). On Sun, Apr 29, 2001 at 05:56:52PM -0400, Thomas Dickey muttered: | On Sun, Apr 29, 2001 at 11:23:16AM -0700, Jason Helfman wrote: | I have Debian Sid. | | Eterm | Ncurses | Mutt | | I have no colors for my Eterm and it should be Transparent with the | option flags I am using. If I start a Eterm up and type mutt, it jumps | to a black index, however when editing, it is transparent. And that | would make sense, being in VI at that point. | | Any ideas why I would be experiencing this? | | It doesn't show up in the compile options, but mutt should be configured to | call 'use_default_colors()' - you can verify that with 'nm' on mutt. If it's | configured properly, then the color scheme in .muttrc is the place to look (if | it uses default in the background rather than black). | | -- | Thomas E. Dickey [EMAIL PROTECTED] | http://dickey.his.com | ftp://dickey.his.com -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: Why don't background colors go across the whole screen?
On Wed, 25 Apr 2001, Jim Lambert wrote: one or the other of your terminal definitions has 'bce' set or disabled incorrectly. I used to run mutt on Solaris (which I think uses SLang or ncurses) and background colors went all the way across the screen when did something like this, in my muttrc: color header brightwhite cyan ^(From|Subject): Under Linux, the background color only changes under the 'text' that matches. Can this be fixed? -Jim -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: your mail
On Wed, 18 Apr 2001, Nelson D. Guerrero wrote: * On Mon Apr 16 2001, Robert T.G. Tan screamed: - I've entered some colors in my .muttrc file, but they don't - show up in Eterm, a color monitor I'm using. - - So what's up with that? - - Tnx, rotan. Check the $TERM var. It should be set to 'linux' not 'xterm' run infocmp Eterm linux to see why this is bad advice. -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: Ideal 'xterm' for mutt/vim combination...
On Wed, 18 Apr 2001, Hanif Ladha [4355] wrote: Dear Muttophiles, I am in search for an ideal (yep very subjective i know) 'xterm' that will let me to setup pretty colours for mutt/vim combination. I am running Solaris 8 on a Ultrasparc 5 (very nice machine BTW), alas it only has a 4Mb frame bugger card so I am stuck with 8-bit color (I need the high res.) I am running CDE (the other choice I had was OpenWindows - this I understand may not be supported in future releases of Solaeis - so I was required to use CDE). Under CDE I have access to dtterm, which is okay for color display of mutt/vim. I would like to use say xterm (by dickey) or rxvt. Alas I am having difficulty in getting color on them (need to do more digging). If you got them to compile/run, then they both are ready to do color. Likely the problem is that the $TERM is set to 'xterm', which normally is installed as a non-color terminfo entry. (XFree86 xterm comes with a terminfo file which can be compiled using "tic", and would overwrite the "xterm" terminfo entry with a link to "xterm-xfree86"). -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: Mutt and xEmacs
On Fri, 6 Apr 2001, Dave Pearson wrote: On Fri, Apr 06, 2001 at 06:01:28AM -0400, Thomas Dickey wrote: On Fri, Apr 06, 2001 at 08:24:14AM +0100, Dave Pearson wrote: On Fri, Apr 06, 2001 at 08:12:41AM +0100, Dave Pearson wrote: If that's what you're after perhaps you could run mutt inside an xterm (M-x term RET) [SNIP] That should have ream "eterm", not "xterm". read Ahh, yes. Typo when fixing a typo. what difference does that make? eterm vs xterm? The former is something inside emacs, the latter isn't. ok (I was thinking eterm==Eterm) -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: mutt sources/binaries for SunOS 4.1.3
On Sun, 25 Mar 2001, Wayne Chapeskie wrote: On Fri, Mar 23, 2001 at 07:35:01AM +0530, Suresh Ramasubramanian wrote: % pre-compiled binaries? ... but I'd like to encourage you to make your binaries available for the next guy :-) Speaking of that, I do have access to an old sun os 4.1 box on my LAN - and the best I could manage was a rather antique version (well, it's stable, works for me ) Any idea of where to get a new curses library for smi-4.1? Or would I be better off using slang? We have an old Sun, running SunOS 4.1.4, which has mutt-1.2.5i running with slang-0.99.38. Both slang and mutt build without incident, however that machine has a heavily modified development environment (gcc+gmake, and so on) so I cannot guarantee that you could build with a stock SunOS environment. I don't know whether a binary built on 4.1.4 will run on 4.1.3 -- there may be shared library version problems -- but if anyone wants the binaries, let me know. afaik, ncurses builds/works on any Unix platform that slang does (as well as as few that I've noticed slang won't work properly on such as SCO). We still have a few SunOS 4.1.3's that support a legacy app (not using ncurses) or which I do test builds. -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: Debian, Mutt, Eterm, Ncurses
On Thu, 8 Mar 2001, Jason Helfman wrote: Today I applied updates for my Debian box, running Sid, or unstable. So Ncurses was updated, and when running mutt in an Eterm, before I could get a transparent Eterm with mutt. But now mutt runs a standard looking black/white term. I guess this is because of the upgrade, so I recompiled mutt. Same issue. Is their a way to resolve this, other then go back to the previous ncurses version ? what $TERM value are you using? (what does infocmp show, for instance). mutt is using that to decide if/how to display color. -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: Debian, Mutt, Eterm, Ncurses
On Thu, 8 Mar 2001, Jason Helfman wrote: Well the term is xterm. Eterm has its own terminfo, which differs from "xterm". (The 'bce' and 'op' strings in particular are what the screen library looks at in the terminfo to decide if it can use "default" colors). I have tried to export vt100 and linux, but I am getting the same issue. When I compose a message, though, the window is transparent. I am confused. On Thu, Mar 08, 2001 at 05:56:24AM -0500, Thomas E. Dickey muttered: | On Thu, 8 Mar 2001, Jason Helfman wrote: | | Today I applied updates for my Debian box, running Sid, or unstable. So | Ncurses was updated, and when running mutt in an Eterm, before I could | get a transparent Eterm with mutt. But now mutt runs a standard looking | black/white term. I guess this is because of the upgrade, so I | recompiled mutt. Same issue. Is their a way to resolve this, other then | go back to the previous ncurses version ? | | what $TERM value are you using? | (what does infocmp show, for instance). | mutt is using that to decide if/how to display color. | | -- | T.E.Dickey [EMAIL PROTECTED] | http://dickey.his.com | ftp://dickey.his.com | -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: Word-wrap when printing and quoting
On Wed, 28 Feb 2001, Dirk Laurie wrote:
Jrgen Salk skryf:
Dirk Laurie wrote:
signs to show that a line break was made by the viewer. However, when
printing or quoting (in a reply) these convenient line breaks are
gone, and the result looks terrible. Can I persuade mutt to use the
viewer-formatted version instead of the original when printing or
quoting?
If you edit your mails with vim, you can easily reformat the quoted lines by
the "gq{motion}" command. E.g. "gqj" will format the current
line and places the cursor in the next line. Then proceed with the "."
command. Or just type "gqG" which will reformat every line until the end.
The problem is this: by the time vim gets control, the quote sign ""
has already been prepended to the line. I want the line-break algorithm
to do its thing before the "" sign gets prepended.
vim (and vile, which I use) can reformat the quoted line.
--
T.E.Dickey [EMAIL PROTECTED]
http://dickey.his.com
ftp://dickey.his.com
Re: color on Solaris 2.6
On Wed, 21 Feb 2001, Jack wrote: hi, Here is how I get mutt work on solaris: . compile it with spool pointed to user's directory (nothing special option about term with ./configure . compile xterm (http://www.clark.net/pub/dickey/xterm/) . download xterm-color terminfo (from mutt FAQ) and setenv TERM xterm-color xterm-free86 is correct... problem . the color defined in muttrc is not shown correctly in mutt (you say this color, it gives you other) are you talking about red/blue interchange? that's from an application using (terminfo) setf/setb where setaf/setab are appropriate. . BTW, the color in VIM is totally right. vim has tables that it consults (does not always use termcap/terminfo) I think it is a problem about xterm or locale or related. Some one please shed some light on this so that I can experiment it more. thanks, jack -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: mutt does not recognize xterm size
On Thu, 15 Feb 2001, Frank Derichsweiler wrote: On Thu, Feb 15, 2001 at 08:32:49AM -0500, darren chamberlain wrote: [mutt does not properly recognize screen size] Out of curiosity, what happens when you resize the xterm? Does mutt rearrange itself to take advantage of the full size, after the xterm is resized? yes, that works fine I've seen this sort of thing reported, but only for configurations that I don't have (I did some changes in the last few patches to try to prevent it - current patch #150 is pretty stable, and it would be nice to know if that fixes the problem). If so, I'd take a look at the curses library in use, and compare the version with the version running on the PIII where this problem doesn't occur. I will do that. Thanks a lot for the tip. It's more likely xterm than the screen library. -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
Re: Newbie question - Problems reading image files
On Thu, 1 Feb 2001, Steve Fielding wrote: Hey Everyone, I switched to Mutt the other day as my main MUA and so far, my experience with Mutt has been a good one except for one thing: All of the image files I have sent to myself as attachments keep coming back as text files filled as gibberish (fortunately, I haven't gotten any legit image files)! Rather than open the files, XV will send back an error message stating "Can't open display." Does this lynx may be setting $DISPLAY, which has to be set for xv to run. (you should set it in your environment anyway). have to do with the base encoding or is it perhaps an error in my config files (i.e. /etc/mailcap, .muttrc, mime.types)? I have done much tinkering with the /etc/mailcap file, but to no avail. What's strange is that I have no problems at all viewing gifs and jpg/jpeg files with XV through Lynx, but the problem seems to be only affecting Mutt. Right now, I'm using Mutt 0.9.3 and have even upgraded to 1.0.3, but the problem persists. I have also sent image files to myself from both this web account and from my ISP account via Mutt. TIA, Steve ___ http://www.webmail.co.za the South-African free email service WIN R10 000 by registering for free online options for EasyMoney in http://www.easyinfo.co.za/easymoney/wmindex.asp - Easy Does it - Now!!! -- T.E.Dickey [EMAIL PROTECTED] http://dickey.his.com ftp://dickey.his.com
