Re: Teaching emacsclient to act as a pager, and more

[sbaugh@catern.com]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> I don't have time to really review the code, but this part isn't
> quite right.  IIUC you intend "ancillary data" to include potentially
> various things, tho currently the only one it can hold is FDs that were
> passed over a Unix socket, right?
>
> Yet, the way you pass it to the process filter doesn't tag the data as
> being file-descriptors as opposed to other kinds of ancillary data, so
> your design intends to be generic/extensible, but the way the data
> is passed to the filter doesn't have the corresponding extensibility.

Yeah, I was just doing something quick and obviously wrong.

> I have a question: what happens with current Emacs if you send
> a file-descriptor over such a Unix socket.  Are these file descriptors
> just silently ignored, or do they block subsequent transmission (because
> Emacs fails to read them), or...?

I'm answering this question mostly from conjecture, but...

Current Emacs should silently ignore passed file descriptors. That's what
happens by default if you aren't using recvmsg.

> The reason I ask is that if current Emacs misbehaves when receiving such
> file-descriptors, maybe we don't need the `ancillary_data' bit.
> We could simply call the process filter with something else than
> a string (e.g. with a list of the form (:file-descriptors . FDS)) when
> we receive file-descriptors.

Couldn't we still do that anyway, even if current Emacs does not
misbehave when getting FDs? As long as it's opt-in.