Re: master ed84f24a21: Make `signal-process' allow completing over signal names

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 27 Jun 2022 09:20:26 +0800
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > +DEFUN ("signal-names", Fsignal_names, Ssignal_names, 0, 0, 0,
> > +       doc: /* Return a list of known signal names on this system.  */)
> > +  (void)
> > +{
> > +  char name[SIG2STR_MAX];
> > +  Lisp_Object names = Qnil;
> > +  for (int i = 0; i < 255; ++i)
> > +    {
> > +      if (!sig2str (i, name))
> > +	{
> > +	  names = Fcons (build_string (name), names);
> > +	}
> > +    }
> > +  return names;
> > +}
> > +
> 
> Shouldn't the "255" be NSIG instead? And what about systems where POSIX
> signal handling doesn't really apply, such as MS Windows and MS-DOS?

I admit that I don't understand the purpose and the intended uses of
this new primitive.  Is it there only for signal-process or more
generally for read-signal-name or even more generally for providing
the exhaustive list of names of all the signals known to the OS?

If it's only for signal-process, then is it really useful to produce a
completion table of 63 or 255 signal names, quite a few of which
cannot be usefully delivered to another process?  Perhaps it would be
better to have a much shorter (system-dependent) list of signals that
can be delivered to processes on each system?  IOW, if this is
supposed to be a convenience feature, then why not provide the user
with a convenient short list of signals that he/she would reasonably
consider delivering, and leave the rest to numbers?