headers
Alain Bench | 1 May 12:26
Picon
Favicon

Re: xlabel request

Hello Antoine, David,

 On Monday, April 28, 2008 at 20:24:23 +0200, Antoine Reilles wrote:

> either remap the edit-label command to another key (but i like 'y'),
> or remap the macros in the default Muttrc:
>| macro index,pager y "<change-folder>?" "show incoming mailboxes list"
>| bind browser y exit
> to something else.

    That's an annoying conflict: The browse mailboxes macro [y] is
consistent with "mutt -y". OTOS <edit-label> bound to the [y] key is
consistent with the ~y search pattern, and with the %y and %Y expandos.

    The macros can act as a quick toggle, show/hide mailboxes browser:
They'd like to keep the easy single key [y].

    <edit-label> leads to a prompt, wanting both hands on keyboard: It
should be able to bear with a more complex binding, like shift-y (or
something else like <Esc>y, ^Y, or whatever). And X-Labels already
picked an uppercase for the %Y expansion.

Bye!	Alain.
Permalink | Reply | 2 comments |
headers
Mutt | 1 May 16:48

Re: [Mutt] #3049: c<ret> won't work on the spoolfile in a solid way

#3049: c<ret> won't work on the spoolfile in a solid way

Comment (by Alain Bench):

 {{{
 Hello,

  On Monday, April 21, 2008 at 22:45:19 -0000, Mutt wrote:

 >| mailboxes ! +inbox
 > when I get a new mail into the =inbox (set as spoolfile=+inbox) [...]
 > then I can't c<ret> unless when I do that just right after getting the
 > message after a new message in =inbox.

     I can't reproduce this problem: When pressing [c], the prompt
 defaults to "=inbox" as soon and as long as the inbox is considered new.
 Pressing <Enter> then opens the inbox.

     Maybe something is reading the inbox, or messing with its access or
 modification timestamps?

 > my muttrc http://www.calmar.ws/tmp/.mutt/muttrc

     404

 Bye!    Alain.
 }}}

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3049#comment:>
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Champion | 1 May 17:27
Favicon

Re: xlabel request

>     That's an annoying conflict: The browse mailboxes macro [y] is
> consistent with "mutt -y". OTOS <edit-label> bound to the [y] key is
> consistent with the ~y search pattern, and with the %y and %Y expandos.

It is annoying, but so it goes.  When the x-label patch was first
developed, it was %x/X and ~x, but then mutt started using ~x for
something else. ('x' would have been a bad binding for edit-label
anyway.)  So x-label went to the next letter in the alphabet that wasn't
in use, and then got accepted upstream.

Then edit-label came, and used 'y' as a binding because it made sense,
but some years later 'y' was also taken -- first by the NNTP patch, and
then by mutt itself.

I'm happy to change to anything without a conflict it if it will go
upstream.  At some point changing the patch's default binding is just
chasing a moving target, but if it will help Rocco or Brendan, I'll
repost with a change.  It should also affect the x-label sorting
keystroke.

>     <edit-label> leads to a prompt, wanting both hands on keyboard: It
> should be able to bear with a more complex binding, like shift-y (or
> something else like <Esc>y, ^Y, or whatever). And X-Labels already
> picked an uppercase for the %Y expansion.

Shift-Y would be a good choice.  <Esc> bindings are to be used as a last
resort, since in some environments you must wait an uncomfortable amount
of time (500 ms or more) between ESC and the other key to distinguish
the separate keystrokes from an ESC sequence generated by the keyboard
(e.g., f-keys, arrow keys).  Control is less bad, but also a second
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mutt | 1 May 22:21

[Mutt] #3052: Tablet of happiness is here

#3052: Tablet of happiness is here

 {{{

 You won't find High-quality low-priced incredible at unbelievable low
 prices incredible to your local chemist's

 You do not have to talk to a doctor to get the sexual help that you need.
 Take a look here.

 The best prices you ever seen.

 In our LICENSED dr <at> gstore you buy meds right from warehouse!.
 }}}

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3052>
Permalink | Reply | 0 comments |
headers
Mutt | 4 May 21:40

Re: [Mutt] #2981: opening a Maildir takes forever

#2981: opening a Maildir takes forever

Changes (by madduck):

  * keywords:  header cache, performance => header cache, performance,
               Maildir, sorting
  * component:  header cache => mutt
  * summary:  header_cache: opening a changed Maildir takes way longer than
              it => opening a Maildir takes forever

Comment:

 I noticed today that this may well be the 'mailboxes' setting; from
 strace,
 every time mutt opens a mailbox, while it says "Sorting mailbox", it
 actually
 stats all other files in my Maildir hierarchy, which sums to several
 hundred
 thousand.

 Could it be that mutt prints "Sorting mailbox" but doesn't clear the
 message
 when it's done, so that it still shows up while it scans all 'mailboxes'
 for
 new mail?

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/2981#comment:4>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mutt | 5 May 07:01

[Mutt] #3052: Feature request: (customisable?) non-empty description field for application/pgp attachments

#3052: Feature request: (customisable?) non-empty description field for
application/pgp attachments

 When using PGP with GPGME to sign messages, an application/pgp-signature
 part is added to the message, containing the GPG-signed hash of the text
 part.

 This attachment does not have a description, which tends to confuse non
 tech-savy recipients (depending on their MUA) who try to manually open the
 signature and, of course, fail.

 Adding a default description when signing (with PGP, but maybe also using
 other schemes?) a message would help preventing this type of situation.
 Additionally, a user-configurable variable could be supplied (say,
 `pgp_signature_description`).

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3052>
Permalink | Reply | 2 comments |
headers
Mutt | 5 May 07:02

Re: [Mutt] #3052: Feature request: (customisable?) non-empty

#3052: Feature request: (customisable?) non-empty description field for
application/pgp attachments

Changes (by shtrom):

  * type:  defect => enhancement

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/3052#comment:1>
Permalink | Reply | 0 comments |
headers
Brendan Cully | 6 May 09:00
Gravatar

mutt: 2 new changesets

2 new changesets in mutt:

http://dev.mutt.org/hg/mutt/rev/0eacf5297484
changeset:   5367:0eacf5297484
branch:      HEAD
tag:         tip
user:        Rocco Rutte <pdmef <at> gmx.net>
date:        Mon May 05 19:32:23 2008 +0200
summary:     Fix some compiler warnings if compiling without system wide character functions

http://dev.mutt.org/hg/mutt/rev/2ce792b31ae4
changeset:   5366:2ce792b31ae4
branch:      HEAD
user:        Rocco Rutte <pdmef <at> gmx.net>
date:        Mon May 05 19:26:35 2008 +0200
summary:     Pass buffer size to mutt_wctoutf8() to prevent crashes if MB_LEN_MAX<6

--

-- 
Repository URL: http://dev.mutt.org/hg/mutt
Permalink | Reply | 0 comments |
headers
Mutt | 6 May 19:10

Re: [Mutt] #2981: opening a Maildir takes forever

#2981: opening a Maildir takes forever

Comment (by madduck):

 Arguably, mutt should bring up the index and let the user do stuff and
 then start to poll the mailboxes in the background...

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/2981#comment:5>
Permalink | Reply | 0 comments |
headers
Mutt | 7 May 12:13

Re: [Mutt] #2985: segfault in mx_update_context

#2985: segfault in mx_update_context

Comment (by cmsj):

 I am able to reproduce a very very similar backtrace to this using mutt
 1.5.17+20080114-1ubuntu1 from Ubuntu 8.04 (hardy).
 In my situation, I have mutt showing my INBOX which is on imaps:// I also
 have thunderbird running on the same account, applying filters to the
 INBOX to move mail to other folders and in my case it's this which seems
 to be the problem:

 the call to crypt_query() in mx_update_content() segfaults because
 h->content is invalid because h is NULL. I suspect this is because
 thunderbird has moved the mail out of the way before (or while) mutt
 inspects it.

--

-- 
Ticket URL: <http://dev.mutt.org/trac/ticket/2985#comment:2>
Permalink | Reply | 0 comments |

Gmane