Hello,

Recently I learned about the pager-mode built into M-x term. I tried
it with some excitement, but discovered that, while it works fine in
emacs 24, it seems completely broken in emacs 25-26.

To reproduce, simply open a terminal (M-x term); enable the pager (C-c
C-q); and run any command that outputs more than a screenful (like
`seq 100`). After paging to the end (with the spacebar), try to type
another command (like `echo foo`). The terminal appears to hang until
killed. (Actually, the inferior process is still running and receiving
your input, but the term buffer displays no further output. You can
force it to dump some output with C-c M-x term-continue subjob, but it
goes back to being hung after.)

I hacked up this little elisp function to demonstrate the bug:


```
(defun test-bug () "demonstrate bug" (interactive)
  (progn
    (term "/bin/bash")
    (sit-for 2)
    (term-pager-enable)
    (term-send-raw-string "seq 50\n")
    (sit-for 2)
    (term-pager-page 50)
    (term-send-raw-string "echo foo\n")
    (sit-for 2)
    (term-line-mode)
    (move-beginning-of-line nil)
    (forward-line -1)
    (let ((code  (if (= (string-to-char "f") (char-after)) 0 1)))
      (kill-emacs code)
      ;;(message "answer: %d" code)
      )
    )
  )
(test-bug)
```

Then, I wrote this little bash script for use in `git bisect`:

```
#!/bin/bash
set -euxo pipefail
date
git clean -dxf
./autogen.sh || exit 125
./configure --with-x=no --without-makeinfo --with-gnutls=yes || exit 125
make -j4 || exit 125
exec src/emacs -Q -l ../bisect.el
```

The bisect was a bit rougher than I expected, for three reasons: (1)
my dumb elisp has some kind of race condition, and sometimes will
neither pass nor fail but hang waiting for further input; (2) the
repo's autogen/autotools/Makefile don't seem to agree with `git
checkout` about timestamps, so I had pretty much had to do a clean
build rather than an incremental build at each step; (3) several
commits in the vicinity of the First Bad Commit have builds which are
broken without gnutls.

However, I was eventually able to get this output as the First Bad
Commit:

9755b75300b7c451bc79984eed2e346ce0a4ffb5 is the first bad commit
commit 9755b75300b7c451bc79984eed2e346ce0a4ffb5
Author: Lars Ingebrigtsen <larsi@gnus.org>
Date:   Tue Feb 16 13:37:33 2016 +1100

    Allow setting the filter masks later
    * src/process.c (Fset_process_filter): Don't set the socket
    masks here, because we may not have a socket yet.
    (set_process_filter_masks): New function.
    (connect_network_socket): Set the filter masks here.


I hope that this is helpful in tracking down the bug.

Please let me know if any further details are required.

Thanks,

--Adam