From: "Robert J. Chassell" <bob@rattlesnake.com>
Cc: emacs-devel@gnu.org
Subject: Re: Gtk patch version 3, part 1
Date: Sun, 5 Jan 2003 16:38:17 +0000 (UTC) [thread overview]
Message-ID: <m18VDmz-000IeIC@localhost> (raw)
In-Reply-To: <5xy95zk2n1.fsf@kfs2.cua.dk> (storm@cua.dk)
"Robert J. Chassell" <bob@rattlesnake.com> writes:
> > Yes. If it is not on your machine, you may not be able to access it:
>
> Well if it is not on your machine -- you definitely cannot access it
> without accessing the Internet.
>
> That is false! I do not access over the Internet most of the material
> that is not on my machine. You must be living in a rich and different
> world! Mostly, I get software and documentation from CDs. It would
> take me over 500 hours to download the Debian CDs that I use.
The basic statement is not false! If the document is not on your
machine, you cannot access it locally.
That is not true! I can and often do access documents and programs
locally that are not on my machine. I put in a CD. A CD is less
convenient than accessing the document on my machine, but it is local.
... If I have to choose between swapping CDs or visiting a URL, I'd
choose the URL.
This means you have a fast and inexpensive Internet connection. I
envy you.
If I have a choice between spending a great deal of time visiting a
URL or spending one-hundreth that time downloading from a local CD, I
use the CD.
But if the file you need is on a CD of yours, why didn't you
install it locally in the first place?
Because I don't know that I want it -- often I don't know that the
document exists. The only part of my Debian CD set that is on my
local machine is the table of contents.
I'm arguing about files which ARE NOT AVAILABLE LOCALLY.
What's wrong about specifying a URL where you can access it?
As a user, you are free(!) to follow or ignore the URL.
Because you should plan to create documents that can be made available
locally. If you specify a URL, a GNU distributor is not likely to put
that document on a CD or on a hard drive. The distributor probably
does not ever know about the document.
If you create a situation in which the document fails to reach the
user, you have told the user you do not think it worth providing
resources to them.
I fully agree that having an local, well-written info file is much
better than having to rely on a remote HTML or PDF document.
That is the whole point. If you make it a policy that a remote
document substitutes for a local document, then everyone loses.
This is because many of the GNU distributors and hackers have cheap,
convenient, and fast Internet access for themselves and do not have
correspondents who live in Bennington, VT, USA or in Cameroon, in
Africa, correspondents whose Internet connections are slow and
expensive. Such distributors and hackers often have no reason to
think of the rest of us.
But in my experience, you cannot rely on any specific documentation to
be available locally -- unless you include that documentation as part
of your own software distribution -- and even in that case, there's no
guarantee that whoever puts your software into a distribution will
also include the docs....
That is true; but the key point is that whoever puts your software
into a distribution is much more likely to include documentation if
you provide it to them than if you do not provide it to them.
Exactly! The real issue is to write the necessary documentation and
include it in the emacs distribution.
Until that's done, I don't see what's wrong with supplying a URL
where you can find the "best docs currently available" .
It is very wrong supply a URL rather than the documentation to which
it points. The reason is that supplying just the URL reduces the
motivation many people have to create local documentation. I possess
the contents of URLs on my local machine: often it is in an
inefficient HTML format rather than plain text or Texinfo, but it
better than none. None is what you are actually talking about for
many people if the document is not part of a CD distribution or on a
local hard disk.
--
Robert J. Chassell Rattlesnake Enterprises
http://www.rattlesnake.com GnuPG Key ID: 004B4AC8
http://www.teak.cc bob@rattlesnake.com
next prev parent reply other threads:[~2003-01-05 16:38 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-31 3:17 Gtk patch version 3, part 1 Jan D.
2003-01-01 16:46 ` Richard Stallman
2003-01-01 18:48 ` Jan D.
2003-01-02 1:10 ` Eric Gillespie
2003-01-02 7:57 ` Jan D.
2003-01-03 19:46 ` Eric Gillespie
2003-01-02 5:56 ` Eli Zaretskii
2003-01-02 8:07 ` Jan D.
2003-01-03 3:32 ` Richard Stallman
2003-01-03 3:30 ` Richard Stallman
2003-01-03 12:39 ` Alfred M. Szmidt
2003-01-04 4:20 ` Richard Stallman
2003-01-04 13:40 ` Alfred M. Szmidt
2003-01-04 16:04 ` Alex Schroeder
2003-01-04 17:43 ` Raja R Harinath
2003-01-04 18:30 ` Eric Gillespie
2003-01-04 19:25 ` Alfred M. Szmidt
2003-01-03 22:42 ` Robert J. Chassell
2003-01-04 0:48 ` Kim F. Storm
2003-01-04 2:55 ` Luc Teirlinck
2003-01-04 3:58 ` Luc Teirlinck
2003-01-04 4:17 ` Luc Teirlinck
2003-01-04 13:30 ` Jan D.
2003-01-04 16:16 ` Luc Teirlinck
2003-01-04 16:39 ` Jan D.
2003-01-04 18:00 ` Luc Teirlinck
2003-01-04 19:46 ` Luc Teirlinck
2003-01-04 21:02 ` Eric Gillespie
2003-01-04 21:55 ` Luc Teirlinck
2003-01-04 22:54 ` Eric Gillespie
2003-01-05 18:33 ` Richard Stallman
2003-01-04 13:11 ` Jan D.
2003-01-04 14:55 ` Alfred M. Szmidt
2003-01-05 18:33 ` Richard Stallman
2003-01-04 15:51 ` Alex Schroeder
2003-01-04 23:44 ` Richard Stallman
2003-01-06 0:17 ` Eric Gillespie
2003-01-06 17:13 ` Richard Stallman
2003-01-06 19:52 ` Alex Schroeder
2003-01-04 7:20 ` Texinfo/info: scrolling images (Re: Gtk patch version 3, part 1) Karl Eichwalder
2003-01-11 19:50 ` Stefan Monnier
2003-01-11 21:03 ` Robert J. Chassell
2003-01-12 5:05 ` Karl Eichwalder
2003-01-12 14:41 ` Robert J. Chassell
2003-01-13 20:41 ` Texinfo/info: scrolling images Karl Eichwalder
2003-01-04 23:44 ` Gtk patch version 3, part 1 Richard Stallman
2003-01-05 13:23 ` Robert J. Chassell
2003-01-05 16:00 ` Kim F. Storm
2003-01-05 15:46 ` Alfred M. Szmidt
2003-01-05 16:38 ` Robert J. Chassell [this message]
2003-01-06 0:33 ` Kim F. Storm
2003-01-04 18:26 ` Eric Gillespie
2003-01-03 3:32 ` Richard Stallman
2003-01-02 15:47 ` Kim F. Storm
2003-01-03 3:31 ` Richard Stallman
2003-01-03 19:50 ` Eric Gillespie
[not found] ` <E18Ufn2-0003pp-00@fencepost.gnu.org>
2003-01-04 18:34 ` Eric Gillespie
2003-01-05 18:33 ` Richard Stallman
2003-01-06 0:19 ` Eric Gillespie
2003-01-02 5:52 ` Eli Zaretskii
2003-01-02 8:05 ` Jan D.
2003-01-02 17:24 ` Eli Zaretskii
2003-01-03 3:31 ` Richard Stallman
[not found] <200212310414.gbv4et0u014643@stubby.bodenonline.com>
2002-12-31 5:33 ` Phillip Garland
2002-12-31 14:49 ` Jan D.
2002-12-31 21:07 ` Phillip Garland
2002-12-31 23:59 ` Jan D.
[not found] <200212311545.gbvfjt0u023298@stubby.bodenonline.com>
2002-12-31 18:06 ` Phillip Garland
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m18VDmz-000IeIC@localhost \
--to=bob@rattlesnake.com \
--cc=emacs-devel@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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).