notation, manual

notation, manual

[siepo]

(sorry Berend, het vorige bericht aan jou was voor de lijst bedoeld;
dit is een uitgebreidere versie ervan)

Berend de Boer writes:
 > siepo@client44-3.kabelA.oprit.rug.nl wrote:
 > 
 > > So the number of brackets doesn't necessarily mean anything?
 > 
 > Some brackets are optional (they're in italics).
 > 
 > 
 >  
 > > Another obscure point is when you want to apply more than one
 > > `value-keyword', e.g. if you want a small bold sectionhead. I tried
 > > the following constructs:
 > > 
 > > \setuphead[mysection][style=bold]
 > > \setuphead[mysection][style=small]
 > > 
 > > This produces small headers. Apparently, values for a single keyword
 > > are not accumulated. Well, this is more or less what Berend was
 > > saying.
 > > 
 > > \setuphead[mysection[style={bold,small}]
 > 
 > The style is really a single macro and really is an alias for a font
 > switch. What you want it to do is:
 > 
 > \def\style{\bold\small}
 > 
 > But it doesn't work that way. Say something like:
 > 
 > \setuphead
 > 	[mysection]
 > 	[style={\switchtobodyfont[small]\bf}]
 > 
 > Groetjes,
 > 
 > Berend. (-:
 > 
 > 
 > 
 > > 
 > > Doesn't work either; it puts the text `bold,smallbold,small' before
 > > both the section number and the section title. I seem to remember that
 > > in some other cases such a construct DOES produce the desired
 > > effect. Am I missing something? (Of course, in this particular case
 > > there are other ways to do it.)
 > > 
 > > Siep

So this is the TeX command as value. Other alternatives: {\bfx} or
\bfx or bfx.

Are you meaning that in general you can't combine `value keywords', or
that in some cases you can and in others you can't?

Also some remarks about the manual: since it is intended as reference
manual, it should facilitate quick lookup and not require close
reading of an entire chapter.

For quickly locating examples, the side-by-side display of code and
their output as in the LaTeX books (Lamport and the LaTeX companion)
could be very effective.

Different settings for some typographic parameters would also help:

-> Reserving vertical space only for displayed material and for
sectioning.  Using it to separate paragraphs detracts too much from
its effectiveness in making displayed material stand out.

-> Indenting of displayed material. The measure of the manual is wide
enough for it. In general, indenting is overused in TeX manuscripts,
and in a multicolumn layout indenting it can look very awful very
quickly but that is no reason not to use it at all.

Siep

Re: notation, manual

[Berend de Boer]

siepo@client44-3.kabelA.oprit.rug.nl wrote:

> (sorry Berend, het vorige bericht aan jou was voor de lijst bedoeld;
> dit is een uitgebreidere versie ervan)

Yes, I also hate it that reply replies to the sender instead of the
list. That doesn't facilitate list communication.

> Are you meaning that in general you can't combine `value keywords', or
> that in some cases you can and in others you can't?

Exactly.

> Also some remarks about the manual: since it is intended as reference
> manual, it should facilitate quick lookup and not require close
> reading of an entire chapter.

Hmm, I find it served its purpose. But I agree that we can have more
manuals, one with lots of examples would be nice. Usually I test with a
small test file or look in the source of the manual is not clear, but
usually the manual is clear enough. Perhaps you need to get adjusted to
its style.

Groetjes,

Berend. (-:

Re: manual

[siepo]

Berend de Boer writes:
 > 
 > > Also some remarks about the manual: since it is intended as reference
 > > manual, it should facilitate quick lookup and not require close
 > > reading of an entire chapter.
 > 
 > Hmm, I find it served its purpose. But I agree that we can have more
 > manuals, one with lots of examples would be nice. Usually I test with a
 > small test file or look in the source of the manual is not clear, but
 > usually the manual is clear enough. Perhaps you need to get adjusted to
 > its style.
 > 
 > Groetjes,
 > 
 > Berend. (-:

Yes, I also write small testfiles when the meaning of the manual is
not clear. But when it is necessary to look at the source then there
is clearly something wrong. Especially since Context has pretensions
to user-friendliness that LaTeX doesn't have.

I suspect that the manual fares better for continuous reading than for
lookup. The suggested typographic changes are intended to make lookup
more efficient.

Siep

replies

[Hraban]

Berend de Boer wrote:
> Yes, I also hate it that reply replies to the sender instead of the
> list. That doesn't facilitate list communication.

I get other mailing lists where the list server overwrites
the "reply-to" with the list address -- isn't this possible
for the ntg server?

Grütze für alle!

Hraban.

Re: replies

[Johannes Hüsing]

On Sat 2000-08-12 (19:19), Hraban wrote:
> Berend de Boer wrote:
> > Yes, I also hate it that reply replies to the sender instead of the
> > list. That doesn't facilitate list communication.
> 
> I get other mailing lists where the list server overwrites
> the "reply-to" with the list address -- isn't this possible
> for the ntg server?

It is technically possible but violates an RFC which I don't find right now that 
states that a reply-to is not to be overwritten.

The basic reason that reply-to-sender is set as default instead of reply-to-list
is that it is much less embarrassing to send a message accidentally to a list
which was intended to be sent to one user, instead of the other way round.

Greetings

Johannes

Re: replies

[Ed L Cashin]

Hraban <angerweit@gmx.net> writes:

> Berend de Boer wrote:
> > Yes, I also hate it that reply replies to the sender instead of the
> > list. That doesn't facilitate list communication.
> 
> I get other mailing lists where the list server overwrites
> the "reply-to" with the list address -- isn't this possible
> for the ntg server?

Munging the email headers is a kludge to support broken email
clients.  

An email client should provide a "reply to all" feature which will
reply to the author and the list.  

-- 
--Ed Cashin                     PGP public key:
  ecashin@coe.uga.edu           http://www.coe.uga.edu/~ecashin/pgp/

Re: replies

[Uwe Koloska]

You wrote on Mit, 16 Aug 2000:
>Hraban <angerweit@gmx.net> writes:
>
>> Berend de Boer wrote:
>> > Yes, I also hate it that reply replies to the sender instead of the
>> > list. That doesn't facilitate list communication.
>> 
>> I get other mailing lists where the list server overwrites
>> the "reply-to" with the list address -- isn't this possible
>> for the ntg server?
>
>Munging the email headers is a kludge to support broken email
>clients.  

There are two opposite positions about that:
    http://www.unicom.com/pw/reply-to-harmful.html
    http://www.metasystema.org/essays/reply-to-useful.mhtml

>An email client should provide a "reply to all" feature which will
>reply to the author and the list.  

That's very bad, because normally the sender of an email that is published
in a newgroup is subscribed to this list.  And this means that she gets the
answer to her email twice!

But there is help right at hand (for some of us):
kmail has a nice feature, that by right clicking on an address in the "To:"
or "CC:" field you can choose "send reply to ..." (or similar -- I use the
german version).

and AFAIK there are some mailers that are able to choose an extra answer
address for a folder -- so you can collect all your ConTeXt listmails in
one folder and everytime you send an email out of this folder this special
address is chosen.

Yours
Uwe Koloska

-- 
mailto:koloska@rcs.urz.tu-dresden.de
http://rcswww.urz.tu-dresden.de/~koloska/
--                                    --
right now the web page is in german only
but this will change as time goes by ;-)

Re: replies

[Berend de Boer]

Ed L Cashin wrote:

> Munging the email headers is a kludge to support broken email
> clients.
> 
> An email client should provide a "reply to all" feature which will
> reply to the author and the list.

Having to hit a different button depending on broken mailing list
servers is my idea of a kludge :-)

Groetjes,

Berend. (-:

Re: replies

[Ed L Cashin]

Berend de Boer <berend@pobox.com> writes:

> Ed L Cashin wrote:
> 
>  
> > Munging the email headers is a kludge to support broken email
> > clients.
> > 
> > An email client should provide a "reply to all" feature which will
> > reply to the author and the list.
> 
> Having to hit a different button depending on broken mailing list
> servers is my idea of a kludge :-)

In one situation, the user is empowered: if all the headers remain
intact, then the user can reply to the author, or reply-to-all.
Hitting different keys to do different things is a natural part of
computing.  

The alternative is to change the headers.  When that happens, if I hit
"reply" in order to reply to the author, then I get the wrong thing,
the list address, in my header.  Lots of embarrassing emails have been
posted to lists because of that.  If the headers are changed, then I
have to delete the wrong header from my outgoing email, go find the
author's real address, and retype it or paste it into the headers.  It
shouldn't be that difficult to reply to the author.  When I reply, it
shouldn't go to the list, because the list didn't write the email.

Regarding the extra copy produced from replying to all, that is normal
and is called a courtesy copy.  If someone doesn't want to receive
courtesy copies, then there is a special header that can be added to
outgoing mail which many mail clients will respect by not sending the
courtesy copy.

-- 
--Ed Cashin                     PGP public key:
  ecashin@coe.uga.edu           http://www.coe.uga.edu/~ecashin/pgp/