From: Stefan Monnier <monnier@iro.umontreal.ca>
To: rms@gnu.org
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: Terminology in multi-tty primitives
Date: Tue, 30 Dec 2008 14:53:38 -0500 [thread overview]
Message-ID: <jwvzlidtpn2.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <E1LGzRt-00066w-Um@fencepost.gnu.org> (Richard M. Stallman's message of "Sun, 28 Dec 2008 12:29:09 -0500")
> . Sometimes we use "tty", as in `suspend-tty' and
> `make-frame-on-tty', and sometimes "terminal", as in
> `delete-terminal'.
> These examples suggest the distinction that `terminal' refers
> to any kind of terminal (including X), whereas `tty' implies that
> the function applies only to text terminals.
> But there's no delete-tty or suspend-terminal.
> Here's how it appears to me. The function to delete works on any kind
> of terminal, so its name says "terminal". The function to suspend
> works only on ttys, so its name says "tty".
> I am not sure that those facts are accurate, but if they are, the
> names make sense.
> So the current usage is consistent. However, we don't have to
> make this distinction. We could rename `tty' to `terminal'
> in these function names, and that would also be consistent.
Indeed, we could rename suspend-tty to suspend-terminal. If we ever
come up with a meaningful behavior for it on non-tty terminals, that
would be a good name.
But I think all the suspend-tty/resume-tty functionality is likely to be
too specific to ttys to be meaningful for non-tty devices. So we may as
well keep the `tty' in its name.
> . `terminal-name' returns the name of the _terminal_device_, such
> as "/dev/tty", while a terminal object itself does not really
> have a name.
> Perhaps `terminal-device' would be a clearer name for that.
Yes.
> . `get-device-terminal' accepts not only a device name (like
> "/dev/tty" or "foo:0.0"), as its name might suggest, but also a
> frame or a terminal.
> It could be called `get-terminal' by analogy with `get-buffer'.
Indeed, just like get-buffer it accepts as input the output looked for,
in which case it just returns it.
> . Doc strings of several functions use the term "terminal id", but
> the functions accept a _terminal_object_, not an ID. Since a
> terminal has an integer ID associated with it
> (cf. `get-device-terminal's return value), a user could easily be
> confused to think that we mean that integer identifier.
> The term "ID" is misleading here, and should be changed.
> In the manual I see
> + Emacs represents each terminal on which it displays frames as a
> +special @dfn{terminal object} data type, see @ref{Terminal Type}. The
> +terminal object has a unique integer identifier and the following
> +attributes:
> The terminal does have a unique integer identifier, but is this useful
> to mention here? Do users ever use it? If not, we may as well
> leave it unmentioned.
The terminal ID should indeed not be mentioned. In the original
multi-tty code, terminal IDs (small integers) were used all over the
place instead of terminal objects (which were not exported to Elisp).
I changed the code so as to make terminal objects into first class Elisp
objects, which made it possible to get rid of the terminal IDs.
Obviously, I failed to update some of the docstrings. AFAIK, the
terminal ID is only ever used of by `print' and friends.
We could/should use the terminal's address (in hex) in its place.
Stefan
next prev parent reply other threads:[~2008-12-30 19:53 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-27 18:23 Terminology in multi-tty primitives Eli Zaretskii
2008-12-28 1:00 ` Chong Yidong
2008-12-28 4:09 ` Eli Zaretskii
2008-12-28 4:28 ` Chong Yidong
2008-12-28 19:18 ` Eli Zaretskii
2008-12-28 19:43 ` Juanma Barranquero
2008-12-29 5:31 ` Chong Yidong
2008-12-29 19:26 ` Eli Zaretskii
2008-12-29 22:09 ` Richard M Stallman
2008-12-30 2:18 ` Stephen J. Turnbull
2008-12-30 22:26 ` Richard M Stallman
2008-12-31 2:06 ` Stefan Monnier
2008-12-31 2:20 ` Dan Nicolaescu
2008-12-31 3:20 ` Stefan Monnier
2008-12-31 4:29 ` Eli Zaretskii
2008-12-31 6:25 ` Stefan Monnier
2008-12-31 18:47 ` Eli Zaretskii
2008-12-31 21:39 ` Dan Nicolaescu
2008-12-31 21:48 ` Eli Zaretskii
2008-12-31 21:55 ` Dan Nicolaescu
2008-12-31 22:10 ` Eli Zaretskii
2008-12-31 23:03 ` Dan Nicolaescu
2008-12-31 16:38 ` Richard M Stallman
2008-12-31 17:22 ` Stefan Monnier
2008-12-31 19:05 ` Eli Zaretskii
2009-01-01 17:13 ` Stefan Monnier
2009-01-02 13:56 ` Eli Zaretskii
2009-01-03 2:32 ` Stefan Monnier
2009-01-03 9:59 ` Eli Zaretskii
2009-01-04 3:14 ` Stefan Monnier
2009-01-04 3:29 ` Chetan Pandya
2009-01-04 3:41 ` Jason Rumney
2009-01-04 4:54 ` Chetan Pandya
2008-12-30 22:27 ` Richard M Stallman
2008-12-31 5:31 ` Stephen J. Turnbull
2008-12-31 6:28 ` Stefan Monnier
2008-12-31 8:33 ` Stephen J. Turnbull
2008-12-31 14:18 ` Chong Yidong
2008-12-31 15:42 ` Stephen J. Turnbull
2008-12-28 17:29 ` Richard M Stallman
2008-12-28 19:33 ` Eli Zaretskii
2008-12-30 19:53 ` Stefan Monnier [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-12-27 18:16 Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvzlidtpn2.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.