[PATCH] chgserver: wrap ui without calling its constructor
raf at durin42.com
Mon Mar 14 22:39:13 EDT 2016
> On Mar 14, 2016, at 10:02 AM, Yuya Nishihara <yuya at tcha.org> wrote:
> I haven't started writing the patches yet for two reasons:
> a) I considered it would be a pure clean-up series.
> b) I might want to extend the 'S' channel to handle pager request. If the
> pager extension gets into the core, it might have more precise logic when
> to start a pager, such as ui.startpager(). Current "getpager" command can't
> handle such situation.
I’ve been slowly tinkering with cleaning up the pager code, and I’ve also come to the conclusion that something along the lines of ui.pager() is going to be required. So far, I’ve made it this far in my analysis:
* ui.pager() probably needs to take the “command type” or similar - that is, it’d be something like ‘ui.pager(“diff")’ or ‘ui.pager(“log”)’, so that it’s easy(-ish) to disable entire categories of pagers trivially.
* Moving to ui.pager() probably means we can ditch the entire notion of the “attend” list for anything other than people wanting to forcibly page commands that don’t make sense to be paged (like summary, maybe?)
* There probably needs to be a registry of post-pager-activation actions. At a minimum, the color extension needs to (potentially) reconfigure how it’s emitting color labels once the pager activates.
Some probable wins out of this:
* User-defined aliases can still be paged (or not) by default in a sane way
* commands which want to emit a progress bar until some results are ready (grep?) can emit progress info until the first line of output becomes available, then enable the pager (which would disable progress bars).
Anyway, I figured I should share those notes since you’re also thinking about this. Maybe we should talk at the sprint.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Mercurial-devel