[Mutt] #3098: $SHELL differs from $0 in subshell

#3098: $SHELL differs from $0 in subshell

 I set the subshell in the .muttrc[[BR]]
 `set shell="/usr/bin/zsh"`[[BR]]
 mainly to have the .zsh_env sourced, which adjusts variables like $DISPLAY
 in reatached screen sessions. Unfortunately this doesn't work.

 in mutt[[BR]]
 `<shell-escape>echo $SHELL; echo $0`[[BR]]
 reports that SHELL is set to zsh, but nevertheless a sh is executed. So
 what i would have expected is that $0 was also a zsh.

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3098>

Re: [Mutt] #3098: $SHELL differs from $0 in subshell

#3098: $SHELL differs from $0 in subshell

Comment (by vinc17):

 I don't think this is a bug. The $shell variable is used only for
 interactive shells: <shell-escape>\r

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3098#comment:1>

Help needed to configure w3m as my HTML viewer

Hi,

I've been using w3m to render HTML messages within my mutt window for
quite a while.  My HTML mailcap entries are as follows:

text/html;$HOME/bin/mutt_opera %s
text/html; w3m -dump %s; nametemplate=%s.html; copiousoutput

However, I've noticed that if I view an HTML file outside of mutt by
executing "w3m <filename>" within the same terminal type (mrxvt) that
the HTML file is rendered much better and the hyperlinks work.

Is there a configuration that will allow me to get the same type of w3m
rendering within mutt that I get outside of mutt?  Note that I only want
to change the auto_view rendering, and still use the 'mutt_opera' script
when I'm within the attachments view.

Thanks in advance.

--

-- 
Mun

Re: Help needed to configure w3m as my HTML viewer

On Tuesday, August  5 at 09:51 PM, quoth Mun Johl:
> I've been using w3m to render HTML messages within my mutt window 
> for quite a while.  My HTML mailcap entries are as follows:
>
> text/html;$HOME/bin/mutt_opera %s 
> text/html; w3m -dump %s; nametemplate=%s.html; copiousoutput

Looks good.

> However, I've noticed that if I view an HTML file outside of mutt by 
> executing "w3m <filename>" within the same terminal type (mrxvt) 
> that the HTML file is rendered much better and the hyperlinks work.
>
> Is there a configuration that will allow me to get the same type of 
> w3m rendering within mutt that I get outside of mutt?

Mmmm, maybe, but probably not. Certainly you can't get the hyperlinks 
to work (those "work" because w3m is in charge of the terminal and 
directly interacting with the user, whereas when you use w3m within 
mutt, mutt is doing the user-interaction---you cannot send keypresses 
to w3m from within mutt). However, that the HTML is rendered "much 
better" is interesting. Better in what way? Is it still "much better" 
if you execute "w3m -dump <filename>" at the commandline? If it is, 
then there may be something in your environment that isn't getting 
passed on to w3m from mutt at the moment, that we can try to pass. If 
it isn't... well, then you're stuck. If the difference is *color*, 
you're also stuck. There's no way to force w3m to include the color 
encoding in it's dump output (short of editing the w3m source 
yourself), and mutt can only can only display the dump output. If, 
however, the "better" rendering is that w3m recognizes a larger 

Re: Help needed to configure w3m as my HTML viewer

Hi Kyle,

Thanks for the quick reply.

Please see my comments below.

On Tue, Aug 05, 2008 at 10:27 PM PDT, Mun Johl wrote:
> On Tuesday, August  5 at 09:51 PM, quoth Mun Johl:
>> I've been using w3m to render HTML messages within my mutt window for 
>> quite a while.  My HTML mailcap entries are as follows:
>>
>> text/html;$HOME/bin/mutt_opera %s text/html; w3m -dump %s; 
>> nametemplate=%s.html; copiousoutput
>
> Looks good.
>
>> However, I've noticed that if I view an HTML file outside of mutt by  
>> executing "w3m <filename>" within the same terminal type (mrxvt) that 
>> the HTML file is rendered much better and the hyperlinks work.
>>
>> Is there a configuration that will allow me to get the same type of  
>> w3m rendering within mutt that I get outside of mutt?
>
> Mmmm, maybe, but probably not. Certainly you can't get the hyperlinks to 
> work (those "work" because w3m is in charge of the terminal and directly 
> interacting with the user, whereas when you use w3m within mutt, mutt is 
> doing the user-interaction---you cannot send keypresses to w3m from 
> within mutt).

Oh, I see.

Re: Help needed to configure w3m as my HTML viewer

Mun Johl writes:
> Hi,
> 
> I've been using w3m to render HTML messages within my mutt window for
> quite a while.  My HTML mailcap entries are as follows:
> 
> text/html;$HOME/bin/mutt_opera %s
> text/html; w3m -dump %s; nametemplate=%s.html; copiousoutput
> 
> However, I've noticed that if I view an HTML file outside of mutt by
> executing "w3m <filename>" within the same terminal type (mrxvt) that
> the HTML file is rendered much better and the hyperlinks work.

 w3m <filename> views the file like any other web browser.

 -dump dumps a formatted version of the page to stdout, so you lose all
 hyperlinks.

[Mutt] #3099: (pager.c) Background of quoted text doesn't fill the whole line

#3099: (pager.c) Background of quoted text doesn't fill the whole line

 In the pager, suppose there is a quoted line

 {{{
 >> abcd
 }}}

 Only the background of "abcd" is painted with the color specified in
 muttrc, resulting in ugly quoted blocks.  The correct behavior should be
 to paint the background of the _whole line_.

 Something like the following should fix it.
 (But please double check, since I modified pager.c at multiple places and
 I'm not quite sure this is indeed the trunk fixing this problem).

 In pager.c:
 {{{
      else
        def_color = ColorDefs[ (*lineInfo)[m].type ];

 +    if ((*lineInfo)[m].type == MT_COLOR_QUOTED) {
 +        struct q_class_t *class = (*lineInfo)[m].quote;
 +
 +        if (class)
 +        {
 +          def_color = class->color;
 +
 +          while (class && class->length > cnt)
 +          {

[Mutt] #3100: forward_attribution missing

#3100: forward_attribution missing

 I don't like the hardcoded "----- Forwarded message from " when forwarding
 German mails. I think there should be a variable "forward_attribution"
 just like "attribution" for replies. It was discussed on mutt-users
 before: [[BR]]
 http://marc.info/?l=mutt-users&m=101896623130535&w=2 [[BR]]
 http://marc.info/?l=mutt-users&m=101896903601414&w=2 [[BR]]

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3100>

Re: [PATCH] Interix support in regexp.c

Hi Fabian, list,

On Sat, Jul 19, 2008 at 23:59:25 +0200, Fabian Groffen wrote:
> * Interix doesn't have btowc, but it does have mbtowc.  Linux manpage
>   also discourages the use of btowc.

Same on some obscure version of Solaris - SunOS 5.5.1 to be precise. It
does have wide char support, but doesn't have btowc(), which mutt
(wrongly) assumes. Now, since this is one of very rare cases where this
occurs, I understand that mutt doesn't work around this case.

Now, if you say it is discouraged to use btowc(), I very much
appreciate you finding another way of doing it.

I thought I had previously (last millennium? [*]) posted my patch here
on this list, but I can't find a posting with Google.  I'll do that
post now, though very much obsoleted. What I do in it is to actually
check for a missing btowc, and include a replacement if required.

Oh well, old code revived. (I still patch all my mutt versions with it,
it's become a tradition.)

Moritz :)

[*] Actually, the oldest version I can find here is from 2002, for
    version 1.3.25. :)

diff -ur mutt-1.5.15/PATCHES mutt-1.5.15-btowc/PATCHES
--- mutt-1.5.15/PATCHES	2007-03-15 16:49:37.000000000 +0100

Re: [PATCH] Interix support in regex.c

On 07-08-2008 19:51:14 +0200, Moritz Barsnick wrote:
> Hi Fabian, list,
> 
> On Sat, Jul 19, 2008 at 23:59:25 +0200, Fabian Groffen wrote:
> > * Interix doesn't have btowc, but it does have mbtowc.  Linux manpage
> >   also discourages the use of btowc.
> 
> Same on some obscure version of Solaris - SunOS 5.5.1 to be precise. It
> does have wide char support, but doesn't have btowc(), which mutt
> (wrongly) assumes. Now, since this is one of very rare cases where this
> occurs, I understand that mutt doesn't work around this case.
> 
> Now, if you say it is discouraged to use btowc(), I very much
> appreciate you finding another way of doing it.

FWIW: I based my "other way" on what the manpage suggested, and how in
other places the same thing is done (within Mutt).

> I thought I had previously (last millennium? [*]) posted my patch here
> on this list, but I can't find a posting with Google.  I'll do that
> post now, though very much obsoleted. What I do in it is to actually
> check for a missing btowc, and include a replacement if required.
> 
> Oh well, old code revived. (I still patch all my mutt versions with it,
> it's become a tradition.)

:)

I think your patch would work fine on Interix too.  I use my patch
without problems on Solaris, Darwin and Linux for a while now.