Re: [PATCH v2] Add a receive_timeout option for sockets

On Mon, Nov 28, 2022 at 11:24:13PM -0800, Matthew Sotoudeh via Mutt-dev wrote: + ** Causes Mutt to timeout any socket read operation (e.g. SSL_read) after + ** this many seconds. A zero (default) or negative value causes Mutt to wait + ** indefinitely for the read to complete. have you chec

Re: [PATCH] bugfix for handling incomplete IMAP header cache

On Sun, Aug 22, 2021 at 06:35:46AM -0700, Kevin J. McCarthy wrote: I agree the server wasn't behaving nicely. It simply omitted some of the headers. (Probably they were deleted at some point between the "assembly" of the mailbox on its side and sending all the headers - the mailbox was very l

Re: [PATCH] bugfix for handling incomplete IMAP header cache

On Sat, Aug 21, 2021 at 12:50:20PM -0700, Kevin J. McCarthy wrote: On Sat, Aug 21, 2021 at 09:32:11PM +0200, Pieter-Tjerk de Boer via Mutt-dev wrote: Unfortunately I don't think this is the correct fix. There can in fact be holes in the MSN sequence. I'm by no means an IMAP or mutt code expe

Re: Mutt && handling of SIGCHLD while starting $sendmail

On Thu, Nov 12, 2020 at 09:22:45AM -0600, Derek Martin wrote: On Thu, Nov 12, 2020 at 12:18:07PM +0100, Oswald Buddenhagen wrote: with this hack you have no error checking at all, and unexpected output on stdout would mess up things totally. Agree, although I'm not sure about that las

Re: Mutt && handling of SIGCHLD while starting $sendmail

On Thu, Nov 12, 2020 at 10:31:59AM +0100, Matthias Apitz wrote: El día miércoles, noviembre 11, 2020 a las 02:34:57p. m. -0600, Derek Martin escribió: On Sat, Nov 07, 2020 at 01:06:00PM +0100, Matthias Apitz wrote: > El día jueves, noviembre 05, 2020 a las 10:17:25a. m. -0800, Kevin > J. McCart

Re: Mutt && handling of SIGCHLD while starting $sendmail

On Wed, Nov 11, 2020 at 02:34:57PM -0600, Derek Martin wrote: On Sat, Nov 07, 2020 at 01:06:00PM +0100, Matthias Apitz wrote: Does whatever the server is doing affect the mutt process too, despite mutt setting its own handler and blocking SIGCHLD during the fork/exec? No, it does not. Mutt wi

Re: Mutt && handling of SIGCHLD while starting $sendmail

On Sat, Nov 07, 2020 at 02:49:37PM +0100, Matthias Apitz wrote: Can you please elaborate a bit what's not a good idea with this patch? It deals exactly with returning waitpid() -1 and errno=ECHILD, i.e. with the exact problem we have here, why ever the child was and/or SIG_CHLD was lost. and

Re: Mutt && handling of SIGCHLD while starting $sendmail

On Sat, Nov 07, 2020 at 01:06:00PM +0100, Matthias Apitz wrote: There is only a small issue with the handling of SIGCHLD by Mutt which leads to an error message by Mutt that the mail wasn't sent (to STDOUT), which is not even true, because was sent fine. - Forwarded message from "Kevin J. Mc

Re: Taking a break for a bit

On Wed, Aug 12, 2020 at 07:38:22PM -0700, Kevin J. McCarthy wrote: On Thu, Aug 13, 2020 at 02:16:19AM +0200, Oswald Buddenhagen wrote: kevin's hostility is subtle and impersonal, so he can express it while being perfectly soft-spoken. but the message *does* arrive, loud and clear. it sa

Re: Taking a break for a bit

On Wed, Aug 12, 2020 at 05:36:31PM -0500, Derek Martin wrote: I can't speak for what's in Kevin's head, but I'm just suggesting that you may be mistaking the symptom for the disease... In other words, perhaps its not that the change isn't minimal that he's being "hostile" about (and TBH I can onl

Re: Taking a break for a bit

On Wed, Aug 12, 2020 at 03:41:50PM -0500, Derek Martin wrote: On Wed, Aug 12, 2020 at 03:16:46PM +0200, Oswald Buddenhagen wrote: meanwhile, kevin has been actively hostile towards changes he didn't deem "minimal enough". that's a reliable way to make sure the code base i

Re: Taking a break for a bit

moin, a somewhat belated reply, but i just finished cleaning up my mutt-dev folder: On Wed, Jul 29, 2020 Derek wrote: I'll be honest--what I'd really prefer to see is the two projects merge, where "NeoMutt" would be the place were things were tried, fleshed out, and refined so that they coul

Re: Changing how config variables are expanded

On Thu, Jun 25, 2020 at 03:54:24PM -0700, Kevin J. McCarthy wrote: Is it worth correcting this? yes, doing parsing and quoting in the right layers is important. failure to do so leads to insanity and security holes. but make sure to check *all* consumers, lest you actually (re-)introduce secu

Re: [PATCH] Use OpenSSL, GnuTLS, or LFSR113 PRNG for mutt's random needs

On Fri, May 29, 2020 at 03:51:52PM -0400, Remco Rijnders wrote: When mutt is not configured with either of these two libraries, it will now use a built in PRNG function (the LFSR113 algorithm by Pierre L'Ecuyer) to generate high quality pseudo random numbers. fair enough, but you still should tr

Re: [PATCH 1/3] Use LFSR113 PRNG for mutt's internal random needs

On Mon, May 25, 2020 at 09:05:21AM -0400, Remco Rijnders wrote: On Sun, May 24, 2020 at 06:49:03PM -0700, Kevin wrote in <20200525014903.ga1...@afu.lan>: + z1 = ((u_int32_t) tv.tv_sec << 20) | tv.tv_usec; + z2 = getpid(); + z3 = getppid(); + z4 = (intptr_t) &z4; +} Comments on the seed choi

Re: Message-id parsing change

On Thu, May 14, 2020 at 07:18:24AM -0700, Kevin J. McCarthy wrote: On Thu, May 14, 2020 at 11:51:08AM +0200, Oswald Buddenhagen wrote: i think a reasoanble heuristic would be to just accept anything as long as it's a single string with no whitespace. Well, it's not hard to pull the

Re: Message-id parsing change

On Thu, May 14, 2020 at 12:41:59PM +0200, Gero Treuner wrote: This notifies about possible problems and transparently shows sender's responsibility. If one of the users then complains at aliexpress I'm fine with it ;-) if you think that being a dick to the mutt user is a constructive way to add

Re: Message-id parsing change

On Wed, May 13, 2020 at 08:03:02PM -0700, Kevin J. McCarthy wrote: On Sun, Apr 19, 2020 at 01:03:06AM +0200, Oswald Buddenhagen wrote: on a tangent, mutt's thread linking features do not work if the message-ids lack the . i presume these might be invalid, but they are rather common noneth

Re: Use curses' raw instead of cbreak mode to capture \C[cyz\]

On Thu, May 07, 2020 at 09:52:14AM +1000, Cameron Simpson wrote: On 06May2020 11:44, Christopher Zimmermann wrote: uses cbreak and therefore the terminal will still catch and interpret \Cc (SIGINT), \034 (SIGQUIT), \Cy (SIGSTOP on next read), \Cz (SIGSTOP). That is desirable, so that mutt ca

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On Sun, Apr 19, 2020 at 05:35:50PM -0400, Remco Rijnders wrote: +/* Return a Base64 encoded representation of a 64 bit random number */ +char *mutt_gen_base64_enc_rand (void) +{ + unsigned char rbuf[8]; + unsigned char result[12]; + uint64_t r = 0; + + r = rand_uint64(); + + rbuf[0] = r

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On Sun, Apr 19, 2020 at 03:22:00PM +0200, Gero Treuner wrote: On Sun, Apr 19, 2020 at 08:02:05AM -0400, Remco Rijnders wrote: On the proposal to use a hashed value for the GA12345 part, I now have some doubts as I think it would be a small effort to iterate through all plausible values for this

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On Sat, Apr 18, 2020 at 09:13:34PM -0500, Derek Martin wrote: None of these are also compelling, partly because they all describe shady behavior, shadyness lies in the eye of the beholder. They also require either full access to all of your e-mail, or to a very specific set of messages that b

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On Sat, Apr 18, 2020 at 01:23:50PM -0500, Derek Martin wrote: On Sat, Apr 18, 2020 at 01:57:50PM -0400, Remco Rijnders wrote: On Sat, Apr 18, 2020 at 12:26:34PM -0500, Derek wrote in > In other words, this scheme does not guarantee uniqueness, and is > therefore broken. Well, the odds of the sa

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On Sat, Apr 18, 2020 at 12:04:05PM -0500, Derek Martin wrote: OK, please enlighten me: Tell me what you've learned, nothing, because i don't care. ;) how it's any worse than all the other information I demonstrated is necessarily leaked from the headers, and how it is in any way exploitable

Re: [PATCH] Change Message-ID generation to be more unique and leak less information

On Sat, Apr 18, 2020 at 02:40:11AM -0500, Derek Martin wrote: Because those people don't know what they're talking about, and humoring them helps no one. oh the irony ... Because it adds additional complexity to the program for absolutely zero practical gain. actually, the patch makes the

Re: botched display - mutt or ncurses bug?

On Sat, Nov 09, 2019 at 12:11:41PM +0100, Oswald Buddenhagen wrote: i wouldn't be surprised if konsole is internally racy and reports a bogus screen size to ncurses. i'll investigate that and let you know. yep, that was it. someone "removed a hack" by replacing it with a

Re: botched display - mutt or ncurses bug?

On Fri, Nov 08, 2019 at 01:04:37PM -0800, Kevin J. McCarthy wrote: On Fri, Nov 08, 2019 at 09:29:29PM +0100, Oswald Buddenhagen wrote: I've pushed a commit up to the branch 'kevin/sigwinch-fixes'. Would you mind giving that a try and seeing if it resolves the issue? n

Re: botched display - mutt or ncurses bug?

On Fri, Nov 08, 2019 at 08:13:07AM -0800, Kevin J. McCarthy wrote: On Fri, Nov 08, 2019 at 10:38:26AM +0100, Oswald Buddenhagen wrote: anyway, i now have a hypothesis that is consistent with all observations so far: the trigger is an early resize event Do you mean a resize that you perform

Re: botched display - mutt or ncurses bug?

On Thu, Nov 07, 2019 at 06:43:57PM -0500, Thomas Dickey wrote: If you had supplied a "typescript" file (from "script") matching the screenshots, someone could examine that and infer the problem. i take it that you're interested. ;) but the log i have is from opening my inbox and thus not for pu

botched display - mutt or ncurses bug?

hi, for some weeks/months now, i'm getting weird rendering artifacts in mutt. i first thought that it's konsole's fault, because it manifests only there, but the captured raw tty output reveals that the mutt output is already really weird (apart from the rendering bugs it's also rather ineffi

Re: pkg-config usage for sqlite3

On Mon, Aug 12, 2019 at 09:15:57AM -0700, Kevin J. McCarthy wrote: > One common, and increasingly prevalent, solution is to use pkg-config > and the related autoconf macros (e.g. PKG_CHECK_MODULES). > However, this isn't without issues, for example dealing with libraries > installed in non-standa

Re: potentially incorrect conversion of pointer to unsigned long

On Sat, Jun 22, 2019 at 09:42:36AM +0200, Vincent Lefevre wrote: > p->init = (unsigned long) safe_strdup (* ((char **) p->data)); > > IMHO, the best solution for safety would be to use a union (I think > that this would require the use of C99 designators for the MuttVars > initialization).

Re: For vi-like binding users, use Esc key to abort commands

On Wed, Mar 08, 2017 at 03:21:36PM +0100, Walter Alejandro Iglesias wrote: > For those still afraid some user could type ':set esc_key_aborts' *by > accident* and then get scared and cry after some esc-key stopped working > why do you think this would happen by accident? the feature is generally u

Re: For vi-like binding users, use Esc key to abort commands

On Sat, Feb 25, 2017 at 05:37:22PM +0100, Walter Alejandro Iglesias wrote: > I'm not quite skilled in C but I think I figured out how to add a > boolean variable 'esc_key_aborts' to set ESC key as an alternative to > the default emacs-like Ctrl-G to abort commands. I guess vi-like users > will app

Re: mutt: Improve Reply-to vs From comparison when replying. (closes...

On Mon, Jan 23, 2017 at 06:49:31PM -0800, Brendan Cully wrote: > changeset: 6908:7a8ea1bb09f0 > user: Kevin McCarthy > date: Mon Jan 23 18:46:16 2017 -0800 > link: http://dev.mutt.org/hg/mutt/rev/7a8ea1bb09f0 > > Improve Reply-to vs From comparison when replying. (closes #3909) >

Re: [PATCH] Adds compose menu bindings for grouping and moving attachments

On Tue, Aug 30, 2016 at 04:34:37PM -0700, d...@bikeshed.us wrote: > OPS |3 + > compose.c | 165 > > doc/manual.xml.head | 17 + > functions.h |3 + > 4 files changed, 188 insertions(+), 0 deleti

Re: [PATCH] When $flag_safe is set, flagged messages cannot be deleted

On Tue, Aug 30, 2016 at 04:32:20PM -0700, d...@bikeshed.us wrote: > flags.c | 3 ++- > init.h | 5 + > mh.c| 7 +-- > mutt.h | 1 + > 4 files changed, 13 insertions(+), 3 deletions(-) > > > # HG changeset patch > # User David Champion > # Date 1472599870 25200 > # Tue Aug

openssl 1.1

i just attempted to build mutt against openssl 1.1, and got this: mutt_ssl.c:636:18: error: storage size of ‘xsc’ isn’t known X509_STORE_CTX xsc; ^~~ the reason is that openssl finally made many of their structures opaque, so instantiating it won't work any more - instead, yo

Re: [PATCH] Preserve pager position only for ops that redirect back to the same message.

On Sun, Aug 07, 2016 at 09:57:04AM +0200, Eike Rathke wrote: > On Saturday, 2016-08-06 18:03:53 -0700, Kevin J. McCarthy wrote: > > Attached is the revised patch. This version doesn't restrict the > > operations where the pager position is saved. Instead, it just makes > > sure the position is cl

Re: message stored in Sent folder even if sending fails

On Tue, Jul 26, 2016 at 10:26:16AM +0200, Michael Tatge wrote: > On Mon, Jul 25, 2016 04:39PM +0200 Olaf Hering (o...@aepfle.de) muttered: > > Am 25. Juli 2016 14:52:27 MESZ, schrieb Michael Tatge : > > > > >No. Sending from the command line, in scripts, the error might come up > > >later during d

Re: message stored in Sent folder even if sending fails

On Mon, Jul 25, 2016 at 09:38:10AM +0200, Michael Tatge wrote: > * On Mon, Jul 25, 2016 08:47AM +0200 Olaf Hering (o...@aepfle.de) muttered: > > For each iteration another copy of the message to be sent is stored in > > record > > in general that's a good think(tm). If sending fails for whatever r

Re: mutt: 3 new changesets

On Sun, Jul 17, 2016 at 07:48:52PM -0700, Brendan Cully wrote: > +rc = imap_exec_msgset (idata, "UID COPY", mmbox, MUTT_TRASH, 0, 0); > note that here is also a [UID] MOVE extension, which is somewhat more efficient. (caveat: UID MOVE is broken with m$ exchange, so in isync i implemented a way

Re: Sidebar pagedown/up and hidden entries

On Thu, Jul 07, 2016 at 06:24:38PM -0700, Kevin J. McCarthy wrote: > else if (!olduv && !oldun) > /* first check per session, use recent. might need a flag for this. > */ > new = (status->recent > 0); > does the sidebar open the mailboxes read-only for its status queri

Re: Sidebar patches and plan

On Wed, Jun 01, 2016 at 12:36:08PM -0700, Kevin J. McCarthy wrote: > Of course, I could squash-merge the series, but I thought it would be > easier for Rich to see my changes if I started from his patch. > i'd still recommend that you squash it once rich has ack's the series. there is really no po

Re: [PATCH] add open_new_msg operation to struct mx_ops

On Fri, May 13, 2016 at 12:21:45PM -0400, Damien Riegel wrote: > On Fri, May 13, 2016 at 08:51:58AM +0200, Oswald Buddenhagen wrote: > > but that topic was recently discussed on this list ... > > Do you have any pointer to the discussion you mentionned? > http://marc.info/?t=1

Re: [PATCH] add open_new_msg operation to struct mx_ops

On Thu, May 12, 2016 at 07:11:20PM -0400, Damien Riegel wrote: > A few lines in mx_open_new_message are also reindented using spaces > instead of tabs. > that qualifies as an unrelated change in my book. style fixes should only happen on lines which are touched anyway. the rest is for a separte co

Re: [PATCH 1 of 8] create a dedicated structure for mx operations

On Thu, May 12, 2016 at 11:06:26AM -0400, Damien Riegel wrote: > On Thu, May 12, 2016 at 10:39:00AM +0200, Oswald Buddenhagen wrote: > > the series is over-fragmented. 6, 7, and 8 definitely should be > > squashed, as the first two patches make no sense whatsoever without the >

Re: [PATCH 1 of 8] create a dedicated structure for mx operations

On Wed, May 11, 2016 at 09:25:41PM -0400, Damien Riegel wrote: > # HG changeset patch > # User Damien Riegel > # Date 1462391862 14400 > # Wed May 04 15:57:42 2016 -0400 > # Node ID eb3c1cd64366352abc9f182d7269ac24298533d0 > # Parent d18cd04e3f5a07ea6c3d0c0b624c917a0024e037 > create a dedica

Re: [PATCH 0 of 8] Change Mutt to use window structures for screen drawing

On Tue, May 03, 2016 at 11:19:35AM +0200, Vincent Lefevre wrote: > I don't think that a *series* of patches is useful, at least for the > integration in the main branch. The use of window structures should > be seen as a single feature as a whole. Thus a single commit should > be fine. > i won't a

Re: [PATCH 0 of 8] Change Mutt to use window structures for screen drawing

On Mon, May 02, 2016 at 02:41:54PM +0200, Vincent Lefevre wrote: > What I've said is that the work is done in a separate branch (a feature > branch). Then, all that needs to be done is a merge to the main branch > seen as a single commit (e.g., for git, "git merge --no-ff"). That way, > one doesn't

Re: [PATCH 0 of 8] Change Mutt to use window structures for screen drawing

On Mon, Apr 25, 2016 at 06:12:25PM +0200, Vincent Lefevre wrote: > On 2016-04-25 13:18:53 +0200, Oswald Buddenhagen wrote: > > On Mon, Apr 25, 2016 at 10:49:01AM +0200, Vincent Lefevre wrote: > > > Rewriting the history is useful only when [...] > > > > > the w

Re: [PATCH 0 of 8] Change Mutt to use window structures for screen drawing

On Mon, Apr 25, 2016 at 10:49:01AM +0200, Vincent Lefevre wrote: > Rewriting the history is useful only when [...] > the whole argumentation is besides the point, as we're talking about non-mainline branches. > Note that the work in the feature branch should really be kept. This > can be useful i

Re: [PATCH 0 of 8] Change Mutt to use window structures for screen drawing

On Sat, Apr 23, 2016 at 06:01:55PM -0700, Kevin J. McCarthy wrote: > As I mentioned earlier, I was still iterating the patches and I posted > them early just for comment. Pushing to a public repos would make it > difficult to modify the patches afterwards. > the ability to easily discard history

Re: Neomutt - Release 20160404 (Mutt-1.6.0)

On Thu, Apr 07, 2016 at 04:01:59PM -0500, Derek Martin wrote: > I mostly agree, but there are points where you have to simply > acknowledge that what you have does not lend itself to gradual > improvement, and a rewrite really is necessary. > almost every single sizeable project that chose the rou

Re: mutt: Add $pgp_decryption_okay to verify multipart/encrypted are...

On Mon, Feb 15, 2016 at 07:47:00PM -0800, Brendan Cully wrote: > Add a new option, and suggested value of: > set pgp_decryption_okay="^\\[GNUPG:\\] DECRYPTION_OKAY" > any particular reason why this is merely suggested and not the default? it's basically ineffective that way for the majority of us

Re: [PATCH] Add $reflow_space_quotes option. (closes #3309)

On Wed, Dec 16, 2015 at 02:42:49PM -0800, Kevin J. McCarthy wrote: > [patch] > > How does this look? > excellent

Re: [PATCH] Add $reflow_space_quotes option. (closes #3309)

On Sat, Dec 12, 2015 at 01:53:19PM -0800, Kevin J. McCarthy wrote: > +Support for viewing and non-flowed replies > + that seems garbled. > +By default, the quoting style of format=flowed > it doesn't seems sensible to speak of "default" when this isn't actually the default in your version of t

Re: Tidying the Mutt Code

On Mon, Nov 23, 2015 at 08:32:30AM +, Arnt Gulbrandsen wrote: > (I said my commits contained cosmetics. They did in principle; I wrote a > whitespace-fixing emacslisp hook while at Trolltech, and ran on the entire > file before every commit from then on. > Whitespace is a chore and chores ar

Re: Tidying the Mutt Code

On Sun, Nov 22, 2015 at 08:03:34PM +, Arnt Gulbrandsen wrote: > Oswald Buddenhagen writes: > > On Sun, Nov 22, 2015 at 03:20:52PM +, Arnt Gulbrandsen wrote: > >> Oh really? I think I broke that rule about 365 times per year during the > >> years I spent at Tro

Re: Tidying the Mutt Code

On Sun, Nov 22, 2015 at 03:20:52PM +, Arnt Gulbrandsen wrote: > Oswald Buddenhagen writes: > > in qt, the rule is to fix the style of only exactly the lines that are > > being touched anyway. but this works only if the codebase is in a > > reasonable shape in the first pla

Re: Tidying the Mutt Code

On Sun, Nov 22, 2015 at 01:45:43PM +0100, Martin Mares wrote: > > there won't ever be a right time. either you accept that legible code is > > worth it, or you don't. > > This smells of false dichotomy :) Legible code has its advantages and > reformatting large chunks of code has its cost. You jus

Re: Tidying the Mutt Code

On Sat, Nov 21, 2015 at 02:42:32PM -0800, Kevin J. McCarthy wrote: > You raise another good point: reviewing large-scale changes (even, > or especially, unnecessary cosmetic ones) is an additional burden we > can probably do without right now, given the small size of the active > development team.

Re: mutt: Fix error message for attach-message. (closes #3785)

On Sat, Oct 17, 2015 at 02:35:26PM +0200, Moritz Barsnick wrote: > On Sat, Oct 17, 2015 at 14:06:42 +0200, Oswald Buddenhagen wrote: > > > Fix error message for attach-message. (closes #3785) > wrong quote, which makes me think you missed the point. > > fwiw, the use of th

Re: mutt: Fix error message for attach-message. (closes #3785)

On Fri, Oct 16, 2015 at 08:17:03PM -0700, Brendan Cully wrote: > changeset: 6519:19c3406fbad9 > user: Kevin McCarthy > date: Sat Oct 17 11:15:01 2015 +0800 > link: http://dev.mutt.org/hg/mutt/rev/19c3406fbad9 > > Fix error message for attach-message. (closes #3785) > > Currently >

Re: [PATCH] Fix oob reads when fgets returns "\0". (closes #3776)

On Tue, Sep 29, 2015 at 03:30:27PM +0800, Kevin J. McCarthy wrote: > The ticket reported an out of bounds read in mutt_read_rfc822_line() > when a '\0' was embedded on its own line in the headers. The function > assumed if fgets() didn't return NULL, then the string would have at > least [one] ch

Re: [PATCH 0 of 3] patchbomb patch-1.5.24-index_format-ToCc.1.patch

On Sun, Sep 20, 2015 at 11:16:20PM -0400, Derek Schrock wrote: > Seeing that there was already some objections to the delivery and > contents I was going to repatchbomb a split patch (one for %r/R and one > for attribution buffer change). > i don't think it makes sense to split off that part, eith

Re: [PATCH 0 of 3] patchbomb patch-1.5.24-index_format-ToCc.1.patch

On Fri, Sep 18, 2015 at 05:22:18PM -0400, Derek Schrock wrote: > patch to add %r %R index_format expandos and resize attribution to a > LONG_STRING > "patch" is indeed the right plurality - it should be a single commit, not a series of fixups.

Re: crash when imap login fails

On Thu, Jun 18, 2015 at 04:06:41PM -0700, Kevin J. McCarthy wrote: > Oswald Buddenhagen wrote: > > On Thu, Jun 18, 2015 at 01:19:33PM -0700, Kevin J. McCarthy wrote: > > > I'm attaching a patch that does this. > > > > > It keeps the NONULL check in

Re: crash when imap login fails

On Thu, Jun 18, 2015 at 01:19:33PM -0700, Kevin J. McCarthy wrote: > I'm attaching a patch that does this. > It keeps the NONULL check in imap_auth_sasl, because it still seems > possible this could be called without capstr being set. > this seems plain wrong. it would most probably indicate a bu

Re: crash when imap login fails

On Wed, Jun 17, 2015 at 07:58:23PM -0700, Kevin J. McCarthy wrote: > Ah! I misunderstood the cause of the crash. If your first login fails, > then the *second* time you try to login, you were getting the crash. Is > that right? > > I see why this is happening: it's freeing the capstr, even if >

Re: Patch to execute a command when getting new mail

On Wed, Jan 28, 2015 at 04:08:15AM -0600, David Champion wrote: > The second patch implements dbus support, and then adds the call-out > function so that mutt can issue notification events as defined by > "biff" to dbus. > at first sight this doesn't look like anything that would actually need a p

Re: [PATCH] Send the IMAP \Draft flag when postponing a message

On Thu, Jan 15, 2015 at 02:44:14PM -0800, Kevin J. McCarthy wrote: > Attached is a slightly revised version of this patch. The main > difference with this version is a refactoring of the IMAP flag > generation code. The previous patch added one flag too many to set > using ternary operators. > t

Re: The future of mutt... - intermediate aggregation

On Mon, Nov 11, 2013 at 03:18:21PM +0100, jpac...@redhat.com wrote: > Hi Oswald, > > and who makes *that* call? where do you draw the line? it doesn't appear > > magically, somebody with the competence and guts (=> authority) has to > > do it. > > If you're bold enough (devs/committers are :)), yo

Re: The future of mutt... - intermediate aggregation

On Thu, Nov 07, 2013 at 11:20:36AM +0100, jpac...@redhat.com wrote: > > from my experience, people without maintainership ambitions simply adapt > > to lower standards. > > Such people are fast to discover => you can ban them (it may/should have > also a social face, not only sudden change of comm

Re: The future of mutt... - intermediate aggregation

On Mon, Nov 04, 2013 at 11:22:51AM +0100, jpac...@redhat.com wrote: > > try more context. hint: it's a response to what *you* wrote. > > Well, it seems we both have no idea if some of mutt devs are paid or > not, so let's move to the next point :). > actually, i'm pretty confident that none are.

Re: The future of mutt... - intermediate aggregation

On Thu, Oct 24, 2013 at 10:33:22AM +0200, jpac...@redhat.com wrote: > >> In one of your emails you mentioned, there are most probably some paid > >> developers. Now you're writing "would need" as if there were none of > >> them right now. I'm not sure what is actually your point. > >> > > i made no

Re: The future of mutt... - intermediate aggregation

hi, On Fri, Oct 18, 2013 at 10:52:22AM +0200, jpac...@redhat.com wrote: > > chasing behind a quick-moving branch with much lower quality > > standards is anything between deeply demotivating and unrealistic - > > that's why you would need paid people to accomplish that feat. > > In one of your em

Re: The future of mutt... - intermediate aggregation

On Thu, Oct 17, 2013 at 10:29:49AM +0200, jpac...@redhat.com wrote: > On 10/07/2013 10:29 AM, Oswald Buddenhagen wrote: > > mutt already has that anything-goes branch: it's called trac. when > > you make an actual hg branch of it, it will be a fork, and master > >

Re: The future of mutt... - intermediate aggregation

On Mon, Oct 07, 2013 at 08:59:32AM +0200, jpac...@redhat.com wrote: > >> Let me propose a fairly minor change in the development process. > >> > > you are proposing a fork on mutt's own infrastructure. > > Not at all. Look at many other projects. Even huge projects like Fedora > ("not guaranteed t

Re: The future of mutt... - intermediate aggregation

On Thu, Oct 03, 2013 at 03:40:12PM +0200, jpac...@redhat.com wrote: > Let me propose a fairly minor change in the development process. > you are proposing a fork on mutt's own infrastructure. i'm not quite sure whether you are incredibly naive or incredibly sneaky. ;) nope, what it takes to make a

Re: The future of mutt...

On Wed, Oct 02, 2013 at 12:04:46PM +0300, Alexander Gattin wrote: > The "old" design you talk about comes from UNIX > concepts which power all the iThings, Androids and > Kindles you most probably use and adore yourself. > of course somebody had to say that. i call BullShit! on it. the Unix Philos

Re: the mutt development vacuum

On Mon, Apr 08, 2013 at 04:19:03PM +, Michael Elkins wrote: > The culture of this mailing list is pretty negative toward any new > functionality. > i think that's a perception problem. there are exactly two (or three) people who actively torpedo any initiative to add functionality. they make a

Re: [PATCH 4/4] version.sh: Get detailed version info from git

On Fri, Dec 14, 2012 at 06:10:21PM -0600, David Champion wrote: > [...] note that the ${a#b} and ${a%b} family of parameter expressions > is nonportable. These are commonly accepted bashisms [...] > wrong. http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html section 2.6.2 or

Re: [PATCH] allow octal codes with more than three digits

On Thu, Apr 22, 2010 at 11:11:15AM -0700, Michael Elkins wrote: > allow octal codes with more than three digits > little surprisingly, this patch actually works. ;) i modified it as discussed when you created it weeks ago. take it or leav it. :) # HG changeset patch # User Oswald Budde

Re: [patch] fix a few little buglets in mutt HEAD

On Wed, Dec 10, 2008 at 11:46:36AM +0100, Rocco Rutte wrote: > I think all 4 present committers decided against the signing into > covertity for NDA reasons, > what NDA? the only enforcable restriction is that you don't publish the scan results verbatim, but that's pretty much irrelevant, as the r

Re: [PATCH] Parent match

On Thu, Nov 13, 2008 at 12:17:40PM +0100, Jeremie Le Hen wrote: > I needed this pattern because I went offline for a while with a great > bunch of mails to read and I used mutt to copy a snapshot of my maildir > into a mailbox on my thumbdrive. Back online, I performed the reverse > process, copyi

Re: Improving the mutt development cycle

On Fri, Aug 15, 2008 at 10:29:33AM -0700, Brendan Cully wrote: > 2. There's no good means of signalling major compatibility changes to > users. > try that: http://netrik.sourceforge.net//?versions.html -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Confusion, chaos, pan

Re: Abnormal size display

On Sun, May 18, 2008 at 07:47:11PM -0400, Jean-Pierre Radley wrote: > Paul Walker typed (on Mon, May 19, 2008 at 12:32:37AM +0100): > | mutt_pretty_size in muttlib.c seems to be the main place where sizes are > | formatted, but it's not clear how it would end up printing d. Knowing what > | paramet

[PATCH] use bdb automatically

moin, as from the configure sources no reason becomes apparent why bdb should not be automatically used, but it still isn't, the attached patch fixes this behavior. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. diff -

Re: UI enhancements

On Mon, Sep 03, 2007 at 01:15:32AM -0400, Derek Martin wrote: > the current code base desperately needs to be abandoned, and a fresh > rewrite started with modularity and modernization in mind. > that sounds like a revolution - and doesn't make too much sense from a mutt perspective. it would be m

Re: [Mutt] #2947: Refinance approved

On Mon, Aug 27, 2007 at 09:08:50AM -, Mutt wrote: > Closed, spam. > can't this be exterminated completely? -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done.

Re: [ANNOUNCE] mutt 1.5.16 released

On Fri, Jun 15, 2007 at 08:19:15AM -0400, Derek Martin wrote: > On Thu, Jun 14, 2007 at 02:01:21AM +0200, Vincent Lefevre wrote: > > If your vi regards something like a failed pattern search as an error, > > you have to accept that. > > Nonsense. If Mutt behaves badly dealing with a common appli

Re: mime, freedesktop.org and mutt

On Sat, May 26, 2007 at 11:00:51AM +0200, Thomas Roessler wrote: > Not knowing the freedesktop database, is there maybe some command > line helper program that returns some structured representation of > that record when confronted with a MIME type? > xdg-mime -- Hi! I'm a .signature virus! Copy

Re: [Mutt] #2884: 256 color support

cool - nitpicking! :) On Thu, Apr 26, 2007 at 10:43:17AM -0300, Angel Olivera wrote: > I was trying to avoid stating the obvious, but since we're "fixing" > the above mentioned expression, why are you using grep and sed, when > sed alone is perfect at replacing grep? > probably for the same reason

broken url (Re: [Mutt] #2877: List messages from multiple mailboxes)

On Fri, Apr 13, 2007 at 04:41:42PM -, Mutt wrote: > Ticket URL: > that's wrong. interestingly enough, the url is correct in the other mails. a forgotten template? -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic,

Re: [PATCH] better header cache versioning

On Wed, Apr 04, 2007 at 04:27:42PM -0700, Brendan Cully wrote: > On Wednesday, 04 April 2007 at 17:24, Kyle Wheeler wrote: > > On Wednesday, April 4 at 03:23 PM, quoth Brendan Cully: > > > Here's a patch that attempts to version the header cache more > > > accurately. It uses a little script to e

bug resolutions & servers (Re: [Mutt] #2551: imap_sync_mailbox: EXPUNGE failed when synching)

On Mon, Apr 02, 2007 at 03:22:35AM -, Mutt wrote: > #2551: imap_sync_mailbox: EXPUNGE failed when synching mailbox > > Changes (by brendan): > > * status: assigned => closed > * resolution: => wontfix > > Comment: > > Server error. > by any convention, this resolution does not make

Re: [PATCH] Remove absolute paths from gpg.rc

On Thu, Mar 22, 2007 at 08:45:20PM -0400, Derek Martin wrote: > In many places, computers are shared resources, and often groups are > collaborating. It may be that as a matter of policy, the programs > being developed by the group must go into a directory writable by the > group. A malicious use

Re: [OT] ideals 'n stuff (Re: [PATCH] Remove absolute paths from

On Thu, Mar 22, 2007 at 12:26:15AM +, Paul Walker wrote: > On Wed, Mar 21, 2007 at 11:06:32PM +0100, Oswald Buddenhagen wrote: > > preferably skip over it if you are not interested in discussing > > world security policy. > > Or you could take it off-list...? > yes ..

Re: [PATCH] Remove absolute paths from gpg.rc

On Wed, Mar 21, 2007 at 11:07:46PM +, Dave wrote: > On Wed, Mar 21, 2007 at 08:18:52PM +0100, Oswald Buddenhagen wrote: > > the sillier the thing, the stronger the guide should be. simple > > principle. > > You're working on a sliding scale here. Sliding scales ar

  1   2   >