chg pager refactoring

Jun Wu quark at
Mon Dec 26 09:10:05 EST 2016

The goal is to move "pager" logic inside "runcommand" (both client and
server side) and remove the "getpager" API. And I'd like to discuss some
implementation details before sending patches.


  1. Which channel to send "pagercmd" to the client?
  2. After sending "pagercmd" to client by chgui._runpager, how to deal with
  3. How to arrange the signal handling / pager code client side?

Proposed options:

  For 1,

    a) Reuse S channel.
       The format to pass cwd, environ is reusable.
       The format to read exitcode is not reusable.
       An extra "command type" parameter is needed, which may be a minor BC.
       (preferred if we don't care about such minor BC)

    b) Use a separate channel.
       Will not BC old clients on the S channel format.

  For 2,

    a) Pass "attachio" or "chgcmdserver" to "_newchgui" so chgui can use it.
       This is the most direct way.

    b) Move "attachio" related logic to chgui, and delegate chgcmdserver's
       channels to ui. This seems unnecessarily complex and it does not seem
       better than a.

  For 3,

    "pagerpid" is used in sighandler. Assuming we don't want new global
    variables in all cases, I think the options are roughly:

          | pager      | sighandler | new API         | annotate history
      now | chg.c      | chg.c      | -               | no
      a)  | chg.c      | chg.c      | hgc_setrunpager | yes
          |            |            | callback        |
      b)  | hgclient.c | chg.c      | hgc_getpagerpid | no
      c)  | util.c     | util.c     | -               | no
      d)  | pager.c    | sigutil.c  | get/setpagerpid | yes
      e)  | procutil.c | procutil.c | -               | yes

    I slightly prefer e) if we can find a good file name to contain both
    pager and sighandler logic.

More information about the Mercurial-devel mailing list