[neomutt-devel] IRC discussion about clang-format and big features

[toogley at mailbox.org]

See Attachments.
-------------- next part --------------
<flatcap> and release on friday
<guiniol> clang-format \o/
<flatcap> :-)
<toogley> flatcap: and afterwards? :)
<flatcap> nothing.  after that, neomutt is complete ;-)
<toogley> hehe. :D
<flatcap> I don't know.  There are quite a few LARGE features I want to look at...
<toogley> which ones?
<flatcap> scripting -- I don't want to tread on zmo's toes, but if he's busy I'd like to put out something as a temptation to users
<toogley> aah, interesting
<flatcap> windowing -- changing the windows to be nested would allow more flexible layouts and easier reflow logic
<flatcap> colours -- rip out and rewrite the colour support to make it useful (and 24-bit)
<flatcap> each (and there are more) would require a lot of work/focus
<toogley> so i guess you'd want to direct that in some way? first feature 1 then 2 etc?
<toogley> btw. i still like the idea to rename the bool functions to sth meaningful.
<toogley> i guess that isn't so much work to do?
<toogley> i.e. some easy task?
<flatcap> well, many people say that naming things is the hardest part of programming :-)
<zmo> hi ? 
<flatcap> I'm happy to accept function renames in a PR
<toogley> hey zmo :D
<flatcap> hi zmo
<zmo> I'm being busy doing stuff far less fun than neomutt :/
<zmo> (but puts food on the table)
<zmo> flatcap - you cannot step on my toes on scripting, as I've only added the bare minimum
<guiniol> food's nice on the table
<flatcap> ok, thanks
<zmo> basically, next batch of work I want to do on scripting is carefully extending the API to expose a bit more of the internals
<zmo> but I believe that doing so will get easier as the internals gets cleaned up first
<flatcap> another big task is "account separation" -- make mutt better dealing with multiple accounts
<toogley> zmo: +1 on your last point.
<zmo> (like exposing the ability to manipulate attachments, the index and/or the pager)
<zmo> (and TBH, I've added the scripting feature because ultimately that's those that I really want to script, but I haven't done that because I'm too afraid of exposing it wrong)
<zmo> anyway, I'm with gahr on that we need to create useful scripts with what we've got now, just hope I'll get a bit of time to do so
<zmo> got an idea
<zmo> maybe I should write a blog article about the scripting feature, where I show off what can be done with a few examples and ask people to try it out and ask for feedback
<flatcap> all publicity is good publicity
<toogley> btw. i think it would be great to call lua functions inside macros/bindings
<guiniol> toogley: that's already possible
<guiniol> if I'm not mistaken
<toogley> guiniol: ah, really? how?
<guiniol> with the 'lua' command, but you need to 'lua-source' in the muttrc
<toogley> ah. hm.
<toogley> nice. :D
<guiniol> it would have to be a macro probably, other wise, you wouldn't be able to add the args of the 'lua' command
<toogley> thanks, guiniol 
<guiniol> no worries
<zmo> yup 👍
<zmo> you don't *need* to lua-source
<zmo> you can define whole lua stuff using :lua
<zmo> calling lua scripts with lua-source is just easier and makes lua scripting more readable
<toogley> ;)
[...]
<dkc> flatcap: about account separation: YES!
<flatcap> I haven't investigated *how* I'd actually do it yet
<flatcap> I'm open to suggestions
<dkc> I took a look it's gonna be complicated to say the least
 flatcap fleaz1 flip214 flokli flo[m] 
<toogley> hm. maybe, when scripting is very stable and can expose account data, we could make the user create an account object for each account?
<toogley> exposes*
<toogley> i'm not sure how compliacted that is. :D
<dkc> well, it should be the other way around
<dkc> when internal are clear and separate per account, then it can be exposed
<dkc> but for now we have globals and folder-hook as workaround
<toogley> yes, of course. your dependency was implied^^
<dkc> ah my bad then ^^
<toogley> hm. i think we should first answer the question, wether we want to fix mutt (fix the design, remove global variables, etc.) first or start working on the big features directly. 
<toogley> (i'm not sure what you guys think about that, therefore the open question^^)
<dkc> we should try to do both, depending on people's interest
<flatcap> a lot of the ideas I've had would require a good bit of internal redesign before starting
<dkc> let's keep it fun :)
<toogley> hm, true. but i fear that starting to work on the big features directly is a bit cumbersome and what is more important: i fear that we might have to throw PR's away, as we realize that the design is too bad for realizing a proper quality
<dkc> that's probably true yes
<toogley> or that the work to realize the feature is too ugly.
<toogley> therefore i'm questioning if it's really useful to encourage working on the big features if the refactoring hasn't been done yet.
* flatcap is still thinking...
<flatcap> clearly the refactoring will have to come first (for many big features)...
<flatcap> but we also need big feature ideas to work out what might need refactoring (and in what order we should attempt the work)
<toogley> yep.
<toogley> but i think we clearly can try to remove/reduce the global variables, independently from what feature we'll start with. :)
<flatcap> yes
-------------- next part --------------

<flatcap> there was talk, ages ago, about running clang-format automatically -- all source, every commit...
<flatcap> looking at the results, I'm wondering about an alternative -- only format .c
<flatcap> it seems that the header files use a lot more manual formatting to make things look good
<flatcap> (I think we should still run clang-format on the headers, to start with)
<toogley> so you mean automatically run clang-format on *.h ?
<toogley> eh, i mean *.c
<flatcap> I'm looking at a lot of #defines whose constants don't line up any more
<flatcap> probably, yes
<flatcap> in the .c we can be stricter because there are fewer large lists, etc, that need aligning
<toogley> hm.
<toogley> i agree with you
<guiniol> could be a good compromise
<toogley> hm. should we still keep the long // clang-format off things in functions.h ?
<toogley> i mean, it could be useful to reformat the headers occaisionally
<guiniol> we do have to run clang-format regularly if we want to keep the code clean, so if it's mostly painless on c files, we can run it on that and fail if there's a problem, and we can run in warning modes on h files (of course, the same warnings would always be there, but we can show the number of warnings instead, if it grows, trouble!)
<toogley> hm.
<flatcap> yes, indeed
<guiniol> if it's not being run automatically, then we could drop them
<guiniol> probably
<toogley> guiniol: what do you mean by "them" in your last sentence?
<toogley> ah the comments?
<toogley> / clang-format off ?
<guiniol> yes
<toogley> well, my idea is that those comments could be helpful even if we don't run clang-format automatically.
<guiniol> I know, but I think we could drop them, if there's a way to run clang-format in warning/report mode
<flatcap> I think clang-format only has one mode -- DO IT
<toogley> but if we do that, clang-format would complain about e.g. functions.h
<toogley> because, at the moment, that is aligned prettily
<toogley> flatcap: yes, but measuring git diff after clang-format can be seen as a warning/report mode, imho
<toogley> kind of.
<flatcap> hehe, that's going to be an interesting measurement
<toogley> (well i haven't tried yet, but i think its doable)
<toogley> https://github.com/cloderic/clang_format_check :)
<toogley> and http://stackoverflow.com/questions/22866609/can-clang-format-tell-me-if-formatting-changes-are-necessary
<flatcap> ooh, interesting
<toogley> ;)
<guiniol> the DO IT only part is a bit annoying
<toogley> hm, regarding functions.h: i have been mistaken, it doesn't matter much if we drop the // clang-format off lines, as long as we run clang-format never on functions.h afterwards. so, yes i think dropping it and only run clang-format automatically on *.c is nice. 
<flatcap> good :-)
<toogley> btw. i'm happy about the progress :)
<toogley> (that is, your ideas for the future, flatcap)
<toogley> (and everything else)
<flatcap> lovely :-)