* 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 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 accomplish particularly other than allow/make people use one hosting system instead of another. > > > Ifdef Conditional config options > > > > -0. Useful but an uncommon approach. Would sort of rather see mutt > > directly support abstract preprocessors so you can plug in m4, cpp, etc. > > I'm not sure I understand. I want the symbols to be available as > strings, so they can be searched at runtime. I see - not just rc preprocessing, but runtime (mainly macro) evaluation too. That's fair. Speaking of macros, one thing I've been interested in is named macros. For example, I have certain macros that I never use on their own; but their pattern happens within other macros. I bind them to some inconvenient key sequence that I don't even remember (since I never punch them directly), and incorporate those keys into other macros. It would serve readability and accuracy if I could instead name the macro "foo" and then call <local:foo> in the macro. > As for the string table, I just took the simplest approach. > The list could be held externally, like OPS, and processed into code. That makes sense to me. What about transforming config.h into this table? Then any autoconf symbol becomes available to the runtime. For example: cpp -dM config.h | grep -v '^#define _' > > > 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 the fact that most of the alphabet is already used up) > > The limiting machinery doesn't take any parameters, it just works on the > globals. Limiting to the "current thread" means passing a variable and > changing a lot of code. Will respond in other thread branch. > > changes the behavior of %<>. I would be very surprised if that affects > > many people, but it is a thing. > > >From the original patch :-) > The '%<...>' notation was used to format the current local time. > But that's not really very useful since mutt has no means of > refreshing the screen periodically. Yeah, I feel like I've since discovered a use case for it but I can't think of it now. :| To be clear, I'm good with this patch (perhaps obviously) -- I think its value is pretty strong. I just wanted to have more yes votes than my own before committing it. > > > Sidebar Panel containing list of Mailboxes > > > > Still riddled with issues, last I heard, > > When was that? Since November, when I assumed ownership, It's largely > been rewritten. It's been a long time, and I didn't know that anyone had substantially revised it. > There are certainly things I'd like to change and ways in which I'd like > to extend the idea. However, sidebar has been waiting on the sidelines > for ten years, already. > > It's stable, it's useful. Time to let the users benefit. The issues were pretty strong at the time. I'm not completely opposed to this but I would like to feel comfortable that it's on a maintainable track and that we can converge it toward code that we like, not just put up with. I'd be interested in any perspective past developers/ maintainers might recall about it (tlr, me, brendan?) > > However if you really need to adjust screen drawing coordinates for > > everything, then the first issue is that it doesn't use > > distinct draw panels. > > Nothing uses distinct draw panels. > Mutt is littered with hard-coded 0, COLS and LINES. > > One awful example is mutt_FormatString(). > It manipulates a string into a buffer. The string can be limited by the > number of bytes it takes or the number of screen columns it occupies. > > However, COLS is hard-coded. Removing it means changing over 40 callers. Again I don't have a strong sense of the mechanics here but my gut feeling is that curses windows are the established and right way to do this, and patching something in on top of a single window is a corner we don't need to paint ourselves into, even if it takes more work to avoid. We should be moving toward the right approach. That doesn't _necessarily_ mean we can't commit. We just need to know that it can be cleaned up. I haven't evaluated this specifically with the current code, and I don't know whether I'll get a chance, but that's my take. > > it's like tag/labels vs folders. > > Speaking of which, your keywords patch is in my in-tray. Great! There are a couple of minor issues with it but I've been using it continuously. Since it changes things somewhat with keyword handling, I've hoped for more field testing (and comments) before committing. NeoMutt can provide that. -- David Champion • [email protected]
