bug#11091: 24.0.94; emacsclient -t

[Dani Moncayo <dmoncayo@gmail.com>]

>> Allow me a few comments.
>> On the "-c" option:
>>
>> > [...] Emacs can create a graphical frame even if it was started in a
>> > text-only terminal, provided it is able to connect to a graphical
>> > display, and provided it can create graphical frames when started
>> > from a text-only terminal.
>>
>> Isn't this wording a bit awkward?  "Emacs can do X, provided it is
>> able to do Y, and provided it can do X"
>
> I don't see anything awkward here.  Using only one "provided that"
> would produce an ambiguous sentence, so I used it twice.

The problem are not the two "provided that", but having "X" as a
prerequisite for itself.

>> On the "-t" option:
>>
>> > Create a new Emacs frame on the current text-only terminal, instead
>> > of using an existing Emacs frame.  If Emacs can open a text-only
>> > terminal even if it was started in another text-only terminal, or on
>> > a graphical display, it will create a text-only frame on the current
>> > terminal.
>>
>> That is, "Do X instead of Y.  If Emacs can do X even if Z, it will do
>> X.".  Not much clean, IMHO.
>
> The second "X" is not really a literal "X", it uses different
> wording.  I see no problem.

The second sentence of this paragraph is IMO too long (not easy to parse).

>> > Otherwise(2), it will create a new frame, either GUI or text-only,
>> > on the same terminal where Emacs was started.
>>
>> Here the last part ("on the same terminal where...") gives the
>> impression that the new frame will be created on a terminal,
>> regardless of whether it is GUI or text-only.
>
> "Terminal" is used here in its Emacs sense, and you seem to think
> about something slightly different.

I think of "terminal" as a shell program designed to interact with the
system using a text-only command-oriented interface.  So far I've not
seen in the manual other meanings for this.  So, saying that a
graphical Emacs frame will be created on a terminal marks no sense to
me, but I can be wrong, of course.


In short: I prefer my version of the doc fix because, IMHO, it is more
clean and easier to parse.  But if you disagree, I'll be ok with the
current one.

Thanks.

-- 
Dani Moncayo