Hi Gregory, On Sun, Nov 15, 2020 at 01:24:36PM +0000, Gregory Heytings wrote: > > I'm not convinced this would be a generally useful feature, though, and > > I don't like to add options that have a user-size of "one". > > > > I know, but in fact I'm convinced it could be a killer feature. It's a > first step to make Mutt useable as a "library" by other programs. [...] > > The filter part of the function is *really* clunky. > > > > In fact this wasn't my code, I copied and adapted a part of > muttlib.c:mutt_FormatString(), thinking indeed that this code was clunky. I > should have looked closer to other parts of the code, sorry. I attach an > updated patch, which is indeed much cleaner. Now I think a common function > should be defined in muttlib.c, used by both mutt_FormatString() and > mutt_process_status_line().
... useable as a library ... Please think about whether the path to that goal driven "feature by feature" is the right way. The current form is the result of creating a lean and efficient solution with low consumption of ressources in mind with intentionally limited features. If migrating to a modularized and suitable as library shape, for a very long time we would neither meet the old nor the new design goals, probably with extra work to bind old and new structures for many intermediate steps. So IMO it would be best to start a new branch and create a development plan, maybe analyzing the big pains and eventually starting from scratch with a new core and then adding the pieces with the valuable algorithms. As the topic of a scripting language was also raised recently, this could be the right time. (Note to Neomutt: I'm aware of the statements and invitations from that corner, but I see major differences.) Kind regards, Gero
