Nicolas Goaziou writes: > Eric Abrahamsen writes: > >> If we really want to get all the message-specific stuff refactored into >> orgstruct++ mode, I guess we could (in the `orgstruct++-mode' function) >> bind `normal-auto-fill-function' and `adaptive-fill-function' to new >> functions, which first check for message-mode specific stuff (and any >> other modes that need to be handled),then delegate to >> `org-auto-fill-function' and `org-adaptive-fill-function'. > > Indeed. There's also `org-fill-paragraph' to purge from Message mode > stuff. > > Ultimately, Orgstruct minor mode could be moved into its own library, > e.g., "org-struct.el". > >> Actually, all `org-auto-fill-function' does is conditionally call >> `org-adaptive-fill-function', so maybe we could just have one new >> function, `orgstruct++-auto-fill-function', that does everything. > > Probably, yes. > >> How does that sound? > > It sounds good. Okay, here's my first attempt at this. So far as I can tell, it works. By which I mean "it works, but I don't understand why". I don't have any experience twiddling with the filling mechanism, and I found it very baffling, but in all my tests so far this patch does what it is supposed to. Likely areas of ugliness: 1. I haven't succeeded in merging `orgstruct-auto-fill-function' with `orgstruct-adaptive-fill-function', mostly because I don't really understand what "adaptive fill" actually means. 2. I have overridden the `org-element-paragraph-separate' altogether, rather than adding message-mode stuff to it. And yet, it works okay, to wit: the plain list I'm currently typing. 3. There's almost certainly refactoring that could be done. Oops, it doesn't work okay after all -- when I hit RET at the end of the third list item, it indented itself. So obviously this isn't quite there yet. I'll keep working at it, which means actually learning how filling works. In the meantime, any code comments would be appreciated. Eric