[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Allow specifying services as symbols?
From: |
Ted Zlatanov |
Subject: |
Re: Allow specifying services as symbols? |
Date: |
Wed, 20 Oct 2010 06:32:34 -0500 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) |
On Tue, 19 Oct 2010 18:20:55 -0400 Chong Yidong <address@hidden> wrote:
CY> "Davis Herring" <address@hidden> writes:
>>> ! :service SERVICE -- SERVICE is name of the service desired (a string
>>> ! or a symbol) or an integer specifying a port number to connect to. If
>>> ! SERVICE is t, a random port number is selected for the server. (If
>>> ! Emacs was compiled with getaddrinfo, a port number can also be
>>> ! specified as a string, e.g. "http", as well as an integer. This is
>>> ! not portable.)
>>
>> As more of a philosophical objection than anything, t is a symbol.
CY> Hmm, good catch. So's nil.
OK, I will exclude t and nil. That was a problem with the patch (t was
converted to "t" and nil to "nil"). Thanks for catching that! Revised
version attached.
CY> So let's back up for a moment, here. Lars, could you provide an example
CY> that shows why it's convenient to allow symbols to name services?
The issue came up as a customization user-side problem and I suggested
allowing symbols. Using symbols is consistent with many other Emacs
facilities (too many to list) that use symbols to enumerate a small set
of choices. It makes customization simpler and less error-prone for
software that uses `make-network-process'. It doesn't really cost
anything. The only downside is that if in the future we decide to add
options to the :service parameter besides t and nil, they won't be easy
to retrofit.
It's really not a big deal though, so if you're concerned about the
downside I listed or any others, let's kill the idea.
Ted
make-network-connection-with-symbol-service.patch
Description: Text Data
- Re: Allow specifying services as symbols?, (continued)
- Re: Allow specifying services as symbols?, Eli Zaretskii, 2010/10/19
- Re: Allow specifying services as symbols?, Ted Zlatanov, 2010/10/19
- Re: Allow specifying services as symbols?, Davis Herring, 2010/10/19
- Re: Allow specifying services as symbols?,
Ted Zlatanov <=
- Re: Allow specifying services as symbols?, Andreas Schwab, 2010/10/20
- Re: Allow specifying services as symbols?, Ted Zlatanov, 2010/10/20