[EMAIL PROTECTED] (Rob Browning) wrote on 23.06.97 in <[EMAIL PROTECTED]>:
> Ricardas Cepas <[EMAIL PROTECTED]> writes:
>
> > As of current documentation, you can search only current
> > .html file. This is not very usefull.
> > Lynx ( on non-gzipped docs) is much slower then info
Am 23.06.97 schrieb pdm # informatics.muni.cz ...
Moin Milan!
MZ> - It's non-free.
That's a real problem.
MZ> - It's big.
But not bigger than xemacs!
MZ> - It can't run on text console.
But lynx can.
MZ> - Limited possibilities of handling gzip files (typing xxx.html
MZ> doesn't find xxx.
On 25 Jun 1997, Marco Budde wrote:
> Am 23.06.97 schrieb pdm # informatics.muni.cz ...
>
> MZ> - Limited possibilities of handling gzip files (typing xxx.html
> MZ> doesn't find xxx.html.gz) => problems with links (may be solvable by
>
> Right, but typing xxx.html.gz will work! We can write a
<[EMAIL PROTECTED]> writes:
[snip]
> For every .html request that comes in (or perhaps for any request in
> general), look for a file fitting the traditional spec.
>
> If that fails, look for a .gz version of that file in the same directory.
>
> If that fails, return the usual 404 error.
Sound
[...]
> > Right, but typing xxx.html.gz will work! We can write a litte sed script
> > to change the links from xxx.html to xxx.html.gz inside the documents.
>
> What do the popular http daemons do about this? I think a good solution
> would be:
>
> For every .html request that comes in (or p
Am 26.06.97 schrieb liw # iki.fi ...
Moin Lars!
LW> Nothing, as far as I know. dwww, however, fixes thing correctly. That
But dwww is very slow (on my 486SL notebook).
LW> doesn't help people who wish to browse documentation without using a
Right, for this people I've written an online help sy
Am 26.06.97 schrieb branden # purdue.edu ...
Moin!
b> For every .html request that comes in (or perhaps for any request in
b> general), look for a file fitting the traditional spec.
b> If that fails, look for a .gz version of that file in the same directory.
b> If that fails, return the usual 404
> "Rob" == Rob Browning <[EMAIL PROTECTED]> writes:
Rob> Ricardas Cepas <[EMAIL PROTECTED]> writes:
>> As of current documentation, you can search only current .html
>> file. This is not very usefull. Lynx ( on non-gzipped docs) is
>> much slower then info ( on gzipped).
On Mon, Jun 23, 1997 at 02:56:37PM +0200, Milan Zamazal wrote:
> I can see no reason for *dropping* info.
My dislike for info is for the same reasons as my dislike
for emacs; the command set is huge and not at all intuitive.
Hamish
--
Hamish Moffatt, StudIEAust[EMAIL PROTEC
> > "ghughes" == ghughes <[EMAIL PROTECTED]> writes:
> ghughes> True. However, it can't handle gzipped pages, and
> ghughes> hacking it to do so seems a) special case (because
> Ermm... on my system it can. lynx 2.7-1 (self compiled).
> netscape also handles it very well. I can't say
> "ghughes" == ghughes <[EMAIL PROTECTED]> writes:
ghughes> [1 ] On Jun 22, Bruce Perens
ghughes> wrote
>> Lynx can browse files directly, and can execute CGI scripts
>> directly.
ghughes> True. However, it can't handle gzipped pages, and
ghughes> hacking it to do s
Ricardas Cepas <[EMAIL PROTECTED]> writes:
> As of current documentation, you can search only current
> .html file. This is not very usefull.
> Lynx ( on non-gzipped docs) is much slower then info ( on
> gzipped).
Oh, right I forgot to add "recursive" to my previous comment about
> "MB" == Marco Budde <[EMAIL PROTECTED]> writes:
MZ: I don't know any good browser for HTML, that's the main
MZ: problem of HTML documentation.
MB: Your're kidding ;-)? There're several really great HTML
MB: browsers like netscape, lynx etc.
No.
Problems with netscape:
- It
On Jun 22, Bruce Perens wrote
> Lynx can browse files directly, and can execute CGI scripts directly.
True. However, it can't handle gzipped pages, and hacking it to do so
seems a) special case (because chimera, w3, netscape and all the others
still don't) and b) outside of its domain of relevanc
On Jun 22, Chris Lawrence wrote
> On Jun 22, Mark Eichin wrote
> > I don't think he's kidding. Lynx is *awful* for searching (it doesn't
> > even have a keystroke for "same pattern, next occurance"...)
>
> Eh? 'n' seems to do a pretty good job. Seems like it searches just fine to
> me :-)
>
On Jun 22, Mark Eichin wrote
> I don't think he's kidding. Lynx is *awful* for searching (it doesn't
> even have a keystroke for "same pattern, next occurance"...)
Eh? 'n' seems to do a pretty good job. Seems like it searches just fine to
me :-)
Chris
--
=
> Your're kidding ;-)? There're several really great HTML browsers like
> netscape, lynx etc. And you should remember that for example KDE will use
I don't think he's kidding. Lynx is *awful* for searching (it doesn't
even have a keystroke for "same pattern, next occurance"...) Netscape,
wel
[EMAIL PROTECTED] (Marco Budde) wrote on 21.06.97 in <[EMAIL PROTECTED]>:
> But this requires a www server! Not a good idea for slow systems like my
> notebook. And the result doesn't look great.
From: [EMAIL PROTECTED] (Kai Henningsen)
> Isn't there a mini www server in Perl's web modules
Lynx
On 22 Jun 1997, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Marco Budde) wrote on 21.06.97 in <[EMAIL PROTECTED]>:
>
> > But this requires a www server! Not a good idea for slow systems like my
> > notebook. And the result doesn't look great.
>
> There are other options. Getting a minimal, fast
[EMAIL PROTECTED] (Marco Budde) wrote on 21.06.97 in <[EMAIL PROTECTED]>:
> But this requires a www server! Not a good idea for slow systems like my
> notebook. And the result doesn't look great.
Isn't there a mini www server in Perl's web modules, about one or two
screend of Perl? (I don't re
Am 21.06.97 schrieb edd # rosebud.sps.queensu.ca ...
Moin Dirk!
DE> But they get html via the dwww package! Which gives them _more_
DE> documentation then there is in html only.
But this requires a www server! Not a good idea for slow systems like my
notebook. And the result doesn't look great
Am 20.06.97 schrieb pdm # informatics.muni.cz ...
Moin Milan!
MZ> There is one good info browser: GNU Emacs. On the other side I don't
MZ> know any good browser for HTML, that's the main problem of HTML
MZ> documentation.
Your're kidding ;-)? There're several really great HTML browsers like
n
Am 20.06.97 schrieb schwarz # monet.m.isar.de ...
Moin Christian!
CS> Just unpack all .tar.gz files in the same directory and use the file
CS> "HOWTO-INDEX-3.html" as "index.html". It contains an overview over all
CS> available HOWTOs and mini-HOWTOs and hyperlinks to them.
Oh no, that's not a g
"Scott K. Ellis" <[EMAIL PROTECTED]> writes:
> Okay, show me how to search a HTML version of the bash info documentation
> for a concept and I'll believe you.
Absolutely, anything without regex and incremental search is broken
and unacceptable for documentation purposes (IMO).
--
Rob
--
TO UN
[ CC'ed to Christian for policy question, and to Manoj for VM example. ]
Marco> Ask the users! The most people hate the info format and it's
Marco> browsers. We should include the HTML documentation in the package.
But they get html via the dwww package! Which gives them _more_ documentation
Dirk> However, Christian Schwarz asked me to do html as well. That will be
Dirk> some work as HOWTO packages comes as tar.gz files with no
Dirk> surcompassing index.html. I'll have to do some perl hacking. No
Dirk> promises for the June release, maybe for July.
Christian> Just unpack
-BEGIN PGP SIGNED MESSAGE-
On 20 Jun 1997, Marco Budde wrote:
> SVD> The simplest solution is to ship html in a different package. This way
> SVD> the user will be able to choose to not install the html docs if he/she
> SVD> believes info2www is enough.
>
> Ask the users! The most people
Am 16.06.97 schrieb sanvila # unex.es ...
Moin Santiago!
SVD> The simplest solution is to ship html in a different package. This way
SVD> the user will be able to choose to not install the html docs if he/she
SVD> believes info2www is enough.
Ask the users! The most people hate the info format a
> "MB" == Marco Budde <[EMAIL PROTECTED]> writes:
MB: The most beginners don't like info because there's no good
MB: browser. I would vote for texi2html because it look's much
MB: better than info2html and the user doesn't need a WWW server.
There is one good info browser: GNU Ema
On Thu, 19 Jun 1997, Dirk Eddelbuettel wrote:
[snip]
> However, Christian Schwarz asked me to do html as well. That will be some
> work as HOWTO packages comes as tar.gz files with no surcompassing
> index.html. I'll have to do some perl hacking. No promises for the June
> release, maybe for July
Lars> It was decided many moons ago that Debian would use HTML as its
Lars> primary on-line documentation format. HTML should be the default.
Marco> That's right. But a lot of important packages like doc-linux don't
Marco> use HTML.
Well, the maintainer (that's me) prefers info as the b
Am 16.06.97 schrieb liw # iki.fi ...
Moin Lars!
LW> It was decided many moons ago that Debian would use HTML as its
LW> primary on-line documentation format. HTML should be the default.
That's right. But a lot of important packages like doc-linux don't use
HTML.
LW> is done with texi2html. Fo
-BEGIN PGP SIGNED MESSAGE-
Christian Schwarz <[EMAIL PROTECTED]> writes:
>
> On 15 Jun 1997, Ardo van Rangelrooij wrote:
>
> > I have another policy issue which is related to topic 11 (see below).
> >
> > The current layout of Info entries in the main Info menu (in the file
> > /usr/in
On Jun 17, Christian Schwarz wrote:
> > > Original-Site: site/URL at which the package is originally stored
>
> Ok. I think "Original-Site" is used in the .lsm entries. Wouldn't
> something like "Upstream-Site" be better?
It is important that more than one "Upstream-Site" field is allowed.
Not fo
[EMAIL PROTECTED] (Fernando) wrote:
>Author: name and email of main upstream author (copyright holder)
>License: code describing license type
>Original-Site: site/URL at which the package is originally stored
Yes.
>We could even go further and specify the type of non-free license.
>Common types
On Jun 17, Santiago Vila Doncel wrote
> Sorry, I didn't explain well. I said:
>
> *---
> I wonder why we are supporting this packages in the `contrib' section:
>
> * whose copyright permission notices (or patent problems) al
-BEGIN PGP SIGNED MESSAGE-
Sorry, I didn't explain well. I said:
*---
I wonder why we are supporting this packages in the `contrib' section:
* whose copyright permission notices (or patent problems) allow only
On Mon, 16 Jun 1997, Santiago Vila Doncel wrote:
> On Sun, 15 Jun 1997, Christian Schwarz wrote:
>
> > TOPIC 7: new definition of ``free software''
>
> This is only about the "main" section.
>
> In addition to that, I wonder why we are supporting this packages in the
> `contrib' section:
>
>
On Mon, 16 Jun 1997, Erik B. Andersen wrote:
> I cannot agree more. We should definatly add these fields to the
> .deb package format! This will involve a bit of work, but will be
> VERY worth it. No more licensing surprises, for instance.
I second that!
This would even make my proposed READM
Santiago Vila Doncel <[EMAIL PROTECTED]> writes:
[snip]
> The simplest solution is to ship html in a different package. This way
> the user will be able to choose to not install the html docs if he/she
> believes info2www is enough.
It might be nice if different types of duplicate documentation
I cannot agree more. We should definatly add these fields to the
.deb package format! This will involve a bit of work, but will be
VERY worth it. No more licensing surprises, for instance.
-Erik
--
Erik B. Andersen Web:http://www.inconnect.com/~andersen/
email: [EMA
In article <[EMAIL PROTECTED]>,
Christian Schwarz <[EMAIL PROTECTED]> writes:
> The current structure (of packages installed on my system) is:
>
> Miscellaneous
> Development
> Document Preparation
> Information
> Emacs
> Programming
> teTeX
>
-BEGIN PGP SIGNED MESSAGE-
On Sun, 15 Jun 1997, Christian Schwarz wrote:
> TOPIC 11: policy about including documentation
>
> The current policy concerning docs is:
>
> - HTML is the preferred format
> - if the package includes docs than can be converted into HTML,
>th
-BEGIN PGP SIGNED MESSAGE-
On Sun, 15 Jun 1997, Christian Schwarz wrote:
> TOPIC 7: new definition of ``free software''
This is only about the "main" section.
In addition to that, I wonder why we are supporting this packages in the
`contrib' section:
* whose copyright permission n
>
> TOPIC 8: packages have to specify their source urls
> ---
> STATUS: DISCUSSION
>
In addition to what you propose below, I think that "dpkg -I" should be
concerned with some of that info. Specifically, three important fields are
missing:
A
On 15 Jun 1997, Ardo van Rangelrooij wrote:
> I have another policy issue which is related to topic 11 (see below).
>
> The current layout of Info entries in the main Info menu (in the file
> /usr/info/dir) looks rather messy. I found the following "descrepencies":
>
> - not all packages are p
On Mon, 16 Jun 1997, joost witteveen wrote:
[snip]
> > I'm somehow confused now. Is registering to "dwww" any different from the
> > "menu" system? Joost, perhaps you can give use some hints here (I think
> > Jim is offline now).
>
> It used to be the same, and that's why I also asked Jim about t
On 16 Jun 1997, Rob Browning wrote:
> Christian Schwarz <[EMAIL PROTECTED]> writes:
>
> > This really is an _excellent_ idea! So, we just need a volunteer to
> > implement and maintain this "upstream library". (The packaging for Debian
> > should not be a problem.)
>
> Ideally we could provide C
Christian Schwarz <[EMAIL PROTECTED]> writes:
> This really is an _excellent_ idea! So, we just need a volunteer to
> implement and maintain this "upstream library". (The packaging for Debian
> should not be a problem.)
Ideally we could provide C, perl, python, etc versions of the code.
--
Rob
> On Sun, 15 Jun 1997, Jim Pick wrote:
>
> >
> > > > All packages that provide HTML documentation should register these
> > > > documents to the menu system, too. Check out section section 4.1,
> > > > `Web
> > > > servers and applications' for details.
> > >
> > > Is that as wel
On Sun, 15 Jun 1997, Jim Pick wrote:
>
> > > All packages that provide HTML documentation should register these
> > > documents to the menu system, too. Check out section section 4.1,
> > > `Web
> > > servers and applications' for details.
> >
> > Is that as well as registering w
On 15 Jun 1997, Rob Browning wrote:
> [EMAIL PROTECTED] (Mark Baker) writes:
>
> > Would programs _have_ to use this library, or is implementing the same thing
> > in acceptable? The latter has problems in that it forces us to keep the same
> > method, but I don't want to see lots of #ifdef debia
-BEGIN PGP SIGNED MESSAGE-
Hi,
I have another policy issue which is related to topic 11 (see below).
The current layout of Info entries in the main Info menu (in the file
/usr/info/dir) looks rather messy. I found the following "descrepencies":
- not all packages are placed in an ap
Miquel van Smoorenburg wrote:
>SystemV has standard library functions for this. Qpopper can use them if
>compiled under Solaris. So for qpopper, I just created those functions myself.
>It might be a good idea to put them in a small (not shared) library, so
>other programs can use them. And the cha
In article <[EMAIL PROTECTED]>,
Mark Baker <[EMAIL PROTECTED]> wrote:
>
>In article <[EMAIL PROTECTED]>,
> Christian Schwarz <[EMAIL PROTECTED]> writes:
>Currently some packages do one and some the other.
>
>> 2. Build a shared library ``libdebian'', that contains
>> functions
> > All packages that provide HTML documentation should register these
> > documents to the menu system, too. Check out section section 4.1, `Web
> > servers and applications' for details.
>
> Is that as well as registering with dwww?
I'm changing the way documents register themse
[EMAIL PROTECTED] (Mark Baker) writes:
> Would programs _have_ to use this library, or is implementing the same thing
> in acceptable? The latter has problems in that it forces us to keep the same
> method, but I don't want to see lots of #ifdef debian appearing in the
> original source; apart fro
In article <[EMAIL PROTECTED]>,
Christian Schwarz <[EMAIL PROTECTED]> writes:
> All packages that provide HTML documentation should register these
> documents to the menu system, too. Check out section section 4.1, `Web
> servers and applications' for details.
Is that as w
Note, that this is the first message of this type. My apologizes if
the mail is too large. I was thinking about creating an extra mailing
list of policy related discussions, or about setting up a HyperNews
server to discuss these topics. However, I think this is (better:
should) be important for a
59 matches
Mail list logo
