bug#36591: 26.2; Term's pager seems broken

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I think Noam is right -- the "we may not have the socket yet" refers to
>> this bit:
>> 
>>   if (p->infd >= 0)
>>     set_process_filter_masks (p);
>
> So you are saying that the commit log message wanted to explain the
> code which existed there already?  Because the condition that tested
> p->infd was already there before you refactored the code into
> set_process_filter_masks.
>
> That's somewhat strange, but I guess is OK.  However, I still wonder
> what was the rationale for making the code change in the first place.
> It seems to me that the real reason was the addition of the call to
> set_process_filter_masks in connect_network_socket, but why was that
> necessary?

Yes, it was refactored out into its own function so that we can call it
from connect_network_socket, too.

I think the logic is slowly coming back to me...  Lisp programs
typically call `set-process-filter' after calling
`make-network-process' -- even when opening an asynchronous connection.
This worked before because the connection wouldn't really be all that
synchronous -- it would do name resolution, and then open the socket, so
when `make-network-process' had returned, then p->infd would (almost)
always be valid.

When `make-network-process' was made more asynchronous, then p->infd
typically not be initialised yet, so `set-process-filter' would not do
the main bit any more.  To avoid having to rewrite all the callers of
`set-process-filter' with async connections, I just made it do the
filter setup in connect_network_socket, by which time we really have a
p->infd.

Logically speaking, it would make more sense if nobody called
`set-process-filter' until we have a connection, but that wouldn't be
backwards compatible.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no