On Tue, Apr 12, 2016 at 09:22:29AM +1000, c...@zip.com.au wrote:
> >Anyways, hg is GUI-oriented while git is CLI-oriented so I would say, the
> >whole "git vs hg" thing is human-related one, i.e. it's about what's more
> >comfortable for people, but feature-wide they are not too far away.
>
> GUI
On Sat, Apr 09, 2016 at 09:24:17AM +1000, Cameron Simpson wrote:
> I think choosing git vs hg should not be a "what is more popular" decision,
why not? that's definitely one of the main factors. i mean have you seen
this?
http://www.phoronix.com/scan.php?page=news_item&px=Python-Moves-To-GitHub
On 2016-04-11 19:20:16 +0300, Andrej N. Gritsenko wrote:
> I'm sorry to tell you that but in my experience git is superior compared
> to hg, some things which require few long command lines in hg can be done
> with one short (so less error-prone) command in git. Yes, that's opposite
> to your exper
On 11Apr2016 19:20, Andrej N. Gritsenko wrote:
Cameron Simpson has written on Saturday, 9 April, at 9:24:
I think choosing git vs hg should not be a "what is more popular" decision,
_especially_ for projects (versus users individually). IMO opinion hg is
superior. Also, there's a robust hg-gi
Hello!
Cameron Simpson has written on Saturday, 9 April, at 9:24:
>I think choosing git vs hg should not be a "what is more popular" decision,
>_especially_ for projects (versus users individually). IMO opinion hg is
>superior. Also, there's a robust hg-git extension that will talk to git
On Sat, Apr 09, 2016 at 10:35:14AM +0200, Oswald Buddenhagen wrote:
> almost every single sizeable project that chose the route of a (near)
> rewrite from scratch died, or the rewrite never took off.
Firstly, I was speaking somewhat generally. I'm not suggesting that
mutt needs to be rewritten i
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
On 06Apr2016 18:49, derek martin wrote:
On Tue, Apr 05, 2016 at 11:04:59AM -0700, David Champion wrote:
OK - that's a good track to have. The thing that made me think otherwise
was the removal of hg-related components. Kevin has the final say now
but we've never discussed moving to git, and I
At 18:50 -0700 06 Apr 2016, "Kevin J. McCarthy" wrote:
On Tue, Apr 05, 2016 at 11:04:59AM -0700, David Champion wrote:
OK - that's a good track to have. The thing that made me think otherwise
was the removal of hg-related components. Kevin has the final say now
but we've never discussed moving
On Thu, Apr 07, 2016 at 11:37:28AM -0700, David Champion wrote:
> > I think you're on to the biggest issue: Neither Mutt nor the patch
> > promote maintainability or extensibility of UI enhancements (I'm not
> > really in a position to evaluate this, only stating what I think past
> > objections w
* On 06 Apr 2016, Derek Martin wrote:
>
> I think you're on to the biggest issue: Neither Mutt nor the patch
> promote maintainability or extensibility of UI enhancements (I'm not
> really in a position to evaluate this, only stating what I think past
> objections were). Both Mutt and the patch
* On 06 Apr 2016, Kevin J. McCarthy wrote:
>
> However, there are some strong arguments for not changing. Our
> infrastructure and workflows are working quite nicely (thanks Brendan!),
> and I'm not anxious to redo them all. Mercurial is easy to use, and I'm
> skeptical it's *that* hard for any
On 06-04-2016 18:50:56 -0700, Kevin J. McCarthy wrote:
> On Tue, Apr 05, 2016 at 11:04:59AM -0700, David Champion wrote:
> > OK - that's a good track to have. The thing that made me think otherwise
> > was the removal of hg-related components. Kevin has the final say now
> > but we've never discus
On Tue, Apr 05, 2016 at 11:04:59AM -0700, David Champion wrote:
> OK - that's a good track to have. The thing that made me think otherwise
> was the removal of hg-related components. Kevin has the final say now
> but we've never discussed moving to git, and I don't see what doing
> so would accomp
On Tue, Apr 05, 2016 at 11:04:59AM -0700, David Champion wrote:
> OK - that's a good track to have. The thing that made me think otherwise
> was the removal of hg-related components. Kevin has the final say now
> but we've never discussed moving to git, and I don't see what doing
> so would accomp
On Tue, Apr 05, 2016 at 02:43:15PM +0100, Richard Russon wrote:
> The usual pattern is:
> developer writes some code
> it doesn't meet the mutt-dev standards (for whatever reason)
> developer gives up
> time passes
> variants of the patch turn up (because people like the feature
On Tue, Apr 05, 2016 at 11:04:59AM -0700, David Champion wrote:
> * On 05 Apr 2016, Richard Russon wrote:
> The thing that made me think otherwise was the removal of hg-related
> components.
Don't worry about that.
Each feature has its own branch. Each branch contains ONLY the feature.
They ar
On Tue, Apr 05, 2016 at 06:19:10PM +0200, Vincent Lefevre wrote:
> On 2016-04-05 16:40:14 +0100, Richard Russon wrote:
> > Only the menu object in mutt_index_menu() knows the current email.
> Alternatively, couldn't the current message be part of the context?
> It would be a message number, or 0
* On 05 Apr 2016, Vincent Lefevre wrote:
> On 2016-04-05 16:40:14 +0100, Richard Russon wrote:
> > On Tue, Apr 05, 2016 at 04:32:11PM +0200, Vincent Lefevre wrote:
> > > On 2016-04-05 14:43:15 +0100, Richard Russon wrote:
> >
> > > > The limiting machinery doesn't take any parameters
> >
> > > C
* On 05 Apr 2016, Richard Russon wrote:
> Hi David,
>
> > I realize you're to some extent building your own extension/bundling of
> > mutt here,
>
> Someone likened it to kernel-next (or perhaps mutt-unstable)
> A proving ground for features. Bringing patches to a wider audience.
OK - that's a
On 2016-04-05 16:40:14 +0100, Richard Russon wrote:
> On Tue, Apr 05, 2016 at 04:32:11PM +0200, Vincent Lefevre wrote:
> > On 2016-04-05 14:43:15 +0100, Richard Russon wrote:
>
> > > The limiting machinery doesn't take any parameters
>
> > Couldn't ~. be changed internally to ~m at evaluation tim
On Tue, Apr 05, 2016 at 02:43:15PM +0100, Richard Russon wrote:
> Someone likened it to kernel-next (or perhaps mutt-unstable)
> A proving ground for features. Bringing patches to a wider audience.
>
> The usual pattern is:
> developer writes some code
> it doesn't meet the mutt-dev stand
On Tue, Apr 05, 2016 at 04:32:11PM +0200, Vincent Lefevre wrote:
> On 2016-04-05 14:43:15 +0100, Richard Russon wrote:
> > The limiting machinery doesn't take any parameters
> Couldn't ~. be changed internally to ~m at evaluation time?
1 User: 'l' -> OP_MAIN_LIMIT
2 mutt_index_menu()
3 mutt_pa
On 2016-04-05 14:43:15 +0100, Richard Russon wrote:
> > > Limit-Current-Thread Limit Index View to Current Thread
> >
> > -1. Would prefer a ~. that matches the current message; then a ~(~.)
> > macro would be equivalent.
>
> That's what I thought, but then I looked at the code.
> (Ignoring t
Hi David,
Though this is a reply to your email, most of the my comments are really
directed at all Mutt devs.
> I realize you're to some extent building your own extension/bundling of
> mutt here,
Someone likened it to kernel-next (or perhaps mutt-unstable)
A proving ground for features. Bringi
On Mon, Apr 04, 2016 at 08:18:02PM -0400, Xu Wang wrote:
> On Mon, Apr 4, 2016 at 4:05 PM, Richard Russon wrote:
> I am a user of mutt-kz and for 1.6.0 I might need to move to neomutt.
Karel Zak has just released an updated version of mutt-kz (based on the
NeoMutt repo).
> All of the above feat
On 2016-04-04 15:34:25 -0700, David Champion wrote:
> * On 04 Apr 2016, Richard Russon wrote:
> > This release of NeoMutt contains no new features.
> > It's just a rebase of the code to Mutt-1.6.0.
> >
> > The current list of stable features is:
> > Conditional DatesConditional Date Forma
On Mon, Apr 4, 2016 at 4:05 PM, Richard Russon wrote:
> This release of NeoMutt contains no new features.
> It's just a rebase of the code to Mutt-1.6.0.
>
> The current list of stable features is:
> Conditional DatesConditional Date Formatting
> Fmemopen Use fmemopen(3) fo
Hi Richard -
I realize you're to some extent building your own extension/bundling of
mutt here, which is fine. But a few comments since some discussion has
already been had of whether these patches are mergeable:
* On 04 Apr 2016, Richard Russon wrote:
> This release of NeoMutt contains no new
This release of NeoMutt contains no new features.
It's just a rebase of the code to Mutt-1.6.0.
The current list of stable features is:
Conditional DatesConditional Date Formatting
Fmemopen Use fmemopen(3) for speedier temporary files
IfdefConditional co
30 matches
Mail list logo
