typo in accept-process-output (process.c)

typo in accept-process-output (process.c)

[Dieter Wilhelm]

Hi 

There's a typo in Emacs 22.1 (still there in EMACS_22_BASE).  Is it OK
when I post typos here or should I do it with a bug report?

Index: process.c
===================================================================
--- process.c	(revision 7)
+++ process.c	(working copy)
@@ -3920,7 +3920,7 @@
 If optional fourth arg JUST-THIS-ONE is non-nil, only accept output
 from PROCESS, suspending reading output from other processes.
 If JUST-THIS-ONE is an integer, don't run any timers either.
-Return non-nil iff we received any output before the timeout expired.  */)
+Return non-nil if we received any output before the timeout expired.  */)
      (process, seconds, millisec, just_this_one)
      register Lisp_Object process, seconds, millisec, just_this_one;
 {

-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

Re: typo in accept-process-output (process.c)

[David Kastrup]

Dieter Wilhelm <dieter@duenenhof-wilhelm.de> writes:

> Hi 
>
> There's a typo in Emacs 22.1 (still there in EMACS_22_BASE).  Is it OK
> when I post typos here or should I do it with a bug report?
>
> Index: process.c
> ===================================================================
> --- process.c	(revision 7)
> +++ process.c	(working copy)
> @@ -3920,7 +3920,7 @@
>  If optional fourth arg JUST-THIS-ONE is non-nil, only accept output
>  from PROCESS, suspending reading output from other processes.
>  If JUST-THIS-ONE is an integer, don't run any timers either.
> -Return non-nil iff we received any output before the timeout expired.  */)
> +Return non-nil if we received any output before the timeout expired.  */)
>       (process, seconds, millisec, just_this_one)
>       register Lisp_Object process, seconds, millisec, just_this_one;

That is not a typo.

>From The Free On-line Dictionary of Computing (27 SEP 03) [foldoc]:

  iff
       
          <mathematics, logic> if and only if, i.e. necessary and
          sufficient.  For example, two figures are {congruent} iff one
          can be placed over the other so that they coincide.
       
          (2002-12-28)


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: typo in accept-process-output (process.c)

[Glenn Morris]

David Kastrup wrote:

>> -Return non-nil iff we received any output before the timeout expired.  */)
>> +Return non-nil if we received any output before the timeout expired.  */)
>>       (process, seconds, millisec, just_this_one)
>>       register Lisp_Object process, seconds, millisec, just_this_one;
>
> That is not a typo.

It is, however, a deprecated usage that consistently confuses people,
exactly as it has done here.

This motivates me to tackle the TODO item to get rid of the "iff"s.

So the job only has to be done once, what replacement will people be
happy with? Personally, I think plain "if" would be just fine, except
perhaps to the tediously literal-minded. Failing that, "only if".
As a last resort, "if and only if" (yuck).

Re: typo in accept-process-output (process.c)

[Richard Stallman]

We decided some months ago to get rid of "iff" from Emacs doc strings
because quite a number of users are unfamiliar with it.

Would someone like to carry this out?

Re: typo in accept-process-output (process.c)

[Dieter Wilhelm]

Glenn Morris <rgm@gnu.org> writes:

> David Kastrup wrote:
>> That is not a typo.
>
> It is, however, a deprecated usage that consistently confuses people,
> exactly as it has done here.

But on the other hand I really love to be taught by Emacs ;-)

> This motivates me to tackle the TODO item to get rid of the "iff"s.

Interesting enough this seems to affect only 28 .c and no .el files:

dieter@debby:/usr/local/emacs-22.1$ find -name \*el -or -name \*.c -exec grep -l "\<iff\>" {} \;

./src/category.c
./src/intervals.c
./src/casetab.c
./src/fileio.c
./src/process.c
./src/lread.c
./src/editfns.c
./src/getloadavg.c
./src/regex.c
./src/dired.c
./src/msdos.c
./src/keyboard.c
./src/w32term.c
./src/callproc.c
./src/fontset.c
./src/window.c
./src/indent.c
./src/keymap.c
./src/ccl.c
./src/xdisp.c
./src/textprop.c
./src/xterm.c
./src/search.c
./src/macterm.c
./src/charset.c
./src/eval.c
./lib-src/etags.c

>

-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

Re: typo in accept-process-output (process.c)

[Nick Roberts]

 > Interesting enough this seems to affect only 28 .c and no .el files:

 > dieter@debby:/usr/local/emacs-22.1$ find -name \*el -or -name \*.c -exec grep -l "\<iff\>" {} \;

 >...

Hmm, that would make things easier if it were true (I can find 108):

find -name \*el -exec grep -l  "\<iff\>" {} \;

./leim/quail/latin-ltx.el
./leim/quail/sgml-input.el
./leim/quail/vntelex.el
./lisp/wid-edit.el
./lisp/strokes.el
./lisp/iswitchb.el
./lisp/image.el
./lisp/term.el
./lisp/ediff-diff.el
./lisp/gnus/gnus-async.el
./lisp/gnus/mailcap.el
./lisp/gnus/gmm-utils.el
./lisp/gnus/gnus-msg.el
./lisp/gnus/gnus-uu.el
./lisp/gnus/imap.el
./lisp/gnus/gnus-util.el
./lisp/gnus/nnimap.el
./lisp/gnus/gnus-score.el
./lisp/userlock.el
./lisp/net/tramp.el
./lisp/files.el
./lisp/whitespace.el
./lisp/custom.el
./lisp/simple.el
./lisp/term/tvi970.el
./lisp/term/sun-mouse.el
./lisp/window.el
./lisp/eshell/em-smart.el
./lisp/allout.el
./lisp/skeleton.el
./lisp/obsolete/fast-lock.el
./lisp/xt-mouse.el
./lisp/abbrev.el
./lisp/frame.el
./lisp/erc/erc.el
./lisp/erc/erc-log.el
./lisp/printing.el
./lisp/icomplete.el
./lisp/dired-aux.el
./lisp/view.el
./lisp/url/url-auth.el
./lisp/url/url-dav.el
./lisp/url/url-cache.el
./lisp/url/url-file.el
./lisp/url/vc-dav.el
./lisp/autorevert.el
./lisp/loaddefs.el
./lisp/t-mouse.el
./lisp/shadowfile.el
./lisp/ldefs-boot.el
./lisp/emacs-lisp/rx.el
./lisp/emacs-lisp/easymenu.el
./lisp/emacs-lisp/advice.el
./lisp/emacs-lisp/checkdoc.el
./lisp/emacs-lisp/byte-opt.el
./lisp/emacs-lisp/unsafep.el
./lisp/emacs-lisp/autoload.el
./lisp/mh-e/mh-loaddefs.el
./lisp/mh-e/mh-show.el
./lisp/mh-e/mh-letter.el
./lisp/mh-e/mh-folder.el
./lisp/font-lock.el
./lisp/winner.el
./lisp/mail/rmail.el
./lisp/mail/mspools.el
./lisp/bindings.el
./lisp/info-look.el
./lisp/textmodes/sgml-mode.el
./lisp/textmodes/nroff-mode.el
./lisp/textmodes/reftex-global.el
./lisp/textmodes/two-column.el
./lisp/textmodes/artist.el
./lisp/textmodes/flyspell.el
./lisp/textmodes/ispell.el
./lisp/textmodes/refill.el
./lisp/double.el
./lisp/ibuf-ext.el
./lisp/ibuffer.el
./lisp/log-edit.el
./lisp/progmodes/gudmi.el
./lisp/progmodes/antlr-mode.el
./lisp/progmodes/gdb-ui.el
./lisp/progmodes/hideshow.el
./lisp/progmodes/cperl-mode.el
./lisp/progmodes/fortran.el
./lisp/progmodes/python.el
./lisp/progmodes/xscheme.el
./lisp/progmodes/cc-awk.el
./lisp/progmodes/cc-engine.el
./lisp/progmodes/cc-vars.el
./lisp/progmodes/which-func.el
./lisp/progmodes/etags.el
./lisp/progmodes/cpp.el
./lisp/progmodes/meta-mode.el
./lisp/progmodes/octave-mod.el
./lisp/progmodes/gud.el
./lisp/ido.el
./lisp/isearch.el
./lisp/expand.el
./lisp/select.el
./lisp/diff.el
./lisp/hilit-chg.el
./lisp/imenu.el
./lisp/international/ja-dic-cnv.el
./lisp/international/mule-cmds.el
./lisp/international/latin1-disp.el
./lisp/international/quail.el
./lisp/vc.el


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: typo in accept-process-output (process.c)

[Dieter Wilhelm]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > Interesting enough this seems to affect only 28 .c and no .el files:
>
>  > dieter@debby:/usr/local/emacs-22.1$ find -name \*el -or -name \*.c -exec grep -l "\<iff\>" {} \;
>
>  >...
>
> Hmm, that would make things easier if it were true (I can find 108):
>
> find -name \*el -exec grep -l  "\<iff\>" {} \;
>
...

Your are right, I haven't used find properly, I think the following
should do:

dieter@debby:/usr/local/emacs-22.1$ find \( -name \*.el -or -name \*.c \) -exec grep -l "\<iff\>" {} \;

Thanks!

-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

Re: typo in accept-process-output (process.c)

[Richard Stallman]

    So the job only has to be done once, what replacement will people be
    happy with? Personally, I think plain "if" would be just fine, except
    perhaps to the tediously literal-minded.

In some cases, just "if" is clear.

					     Failing that, "only if".
    As a last resort, "if and only if" (yuck).

Where just "if" is not clear, you need to get creative.  Find a
rewrite which is clear.  "If and only if" is ok when you need it, but since it is a bit longer, you might look for a better method.

Re: typo in accept-process-output (process.c)

[Michael Olson]

[-- Attachment #1.1: Type: text/plain, Size: 1093 bytes --]

Richard Stallman <rms@gnu.org> writes:

>     So the job only has to be done once, what replacement will people
>     be happy with? Personally, I think plain "if" would be just fine,
>     except perhaps to the tediously literal-minded.
>
> In some cases, just "if" is clear.
>
>     Failing that, "only if".  As a last resort, "if and only if"
>     (yuck).
>
> Where just "if" is not clear, you need to get creative.  Find a
> rewrite which is clear.  "If and only if" is ok when you need it, but
> since it is a bit longer, you might look for a better method.

The conditionals "only if" and "if" are both unidirectional, whereas "if
and only if" is bidirectional.  If you want to preserve the logic, it is
best to change "iff" to "if and only if".  It's not nearly as gross as
changing the meaning would be.

-- 
       Michael Olson -- FSF Associate Member #652     |
 http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net  |  /` |\ | | |
            Sysadmin -- Hobbies: Lisp, GP2X, HCoop    | |_] | \| |_|
Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: typo in accept-process-output (process.c)

[Stephen Berman]

On Mon, 06 Aug 2007 16:50:45 -0400 Michael Olson <mwolson@gnu.org> wrote:

> Richard Stallman <rms@gnu.org> writes:
>
>>     So the job only has to be done once, what replacement will people
>>     be happy with? Personally, I think plain "if" would be just fine,
>>     except perhaps to the tediously literal-minded.
>>
>> In some cases, just "if" is clear.
>>
>>     Failing that, "only if".  As a last resort, "if and only if"
>>     (yuck).
>>
>> Where just "if" is not clear, you need to get creative.  Find a
>> rewrite which is clear.  "If and only if" is ok when you need it, but
>> since it is a bit longer, you might look for a better method.
>
> The conditionals "only if" and "if" are both unidirectional, whereas "if
> and only if" is bidirectional.  If you want to preserve the logic, it is
> best to change "iff" to "if and only if".  It's not nearly as gross as
> changing the meaning would be.

The logic textbook by Kalish and Montague uses "`exactly on condition
that', and sometimes `just in case', as stylistic variants of `if and
only if'."

Steve Berman

Re: typo in accept-process-output (process.c)

[David Kastrup]

Stephen Berman <Stephen.Berman@gmx.net> writes:

> On Mon, 06 Aug 2007 16:50:45 -0400 Michael Olson <mwolson@gnu.org> wrote:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>>     So the job only has to be done once, what replacement will people
>>>     be happy with? Personally, I think plain "if" would be just fine,
>>>     except perhaps to the tediously literal-minded.
>>>
>>> In some cases, just "if" is clear.
>>>
>>>     Failing that, "only if".  As a last resort, "if and only if"
>>>     (yuck).
>>>
>>> Where just "if" is not clear, you need to get creative.  Find a
>>> rewrite which is clear.  "If and only if" is ok when you need it, but
>>> since it is a bit longer, you might look for a better method.
>>
>> The conditionals "only if" and "if" are both unidirectional, whereas "if
>> and only if" is bidirectional.  If you want to preserve the logic, it is
>> best to change "iff" to "if and only if".  It's not nearly as gross as
>> changing the meaning would be.
>
> The logic textbook by Kalish and Montague uses "`exactly on condition
> that', and sometimes `just in case', as stylistic variants of `if and
> only if'."

"just in case" is pretty much the worst replacement since it has a
well-established colloquial meaning of "as a precaution against the
improbable event of".

-- 
David Kastrup

Re: typo in accept-process-output (process.c)

[Jason Rumney]

Michael Olson wrote:
> The conditionals "only if" and "if" are both unidirectional, whereas "if
> and only if" is bidirectional.  If you want to preserve the logic, it is
> best to change "iff" to "if and only if".  It's not nearly as gross as
> changing the meaning would be.
>   

I think the logic can be preserved by changing iff to "if", and for any
instances of "if" that do not mean "iff", there should be some wording
like "... may be ... if ... " to indicate that there is not a
bidirectional correspondence.

In general, bidirectionality is assumed by most speakers of English (as
opposed to mathematical logic) for a bare "if".

Re: typo in accept-process-output (process.c)

[Stefan Monnier]

>> The conditionals "only if" and "if" are both unidirectional, whereas "if
>> and only if" is bidirectional.  If you want to preserve the logic, it is
>> best to change "iff" to "if and only if".  It's not nearly as gross as
>> changing the meaning would be.

> I think the logic can be preserved by changing iff to "if", and for any
> instances of "if" that do not mean "iff", there should be some wording
> like "... may be ... if ... " to indicate that there is not a
> bidirectional correspondence.

> In general, bidirectionality is assumed by most speakers of English (as
> opposed to mathematical logic) for a bare "if".

I think a better approach is to keep using `iff' (also known as `ssi' in
French), but to make it such that the user can click on it to get to the
Glossary where we add an entry for it.
We could later on use the same feature for some other terms (e.g. "fringe").


        Stefan

RE: typo in accept-process-output (process.c)

[Drew Adams]

> I think a better approach is to keep using `iff' (also known as `ssi' in
> French), but to make it such that the user can click on it to get to the
> Glossary where we add an entry for it.
> We could later on use the same feature for some other terms (e.g.
> "fringe").

I agree. It is better to avoid varying the terminology for things like
this - using different terms for the same thing in different places (e.g. by
different authors). It is best to use a term such as "iff" consistently, and
define it clearly.

The meaning of "if" can vary in informal English, and different people
sometimes understand it differently. In more formal use, these are often
used as synonyms: "A implies B", "if A then B", "A only if B", "B if A", "B
whenever A", and "B provided A". And these are used as synonyms: "A if and
only if B", and "A is equivalent to B".

The problem with using "iff" is that some readers will not notice that it is
not "if", or they might think that it is a typo. If we use "iff" as Stefan
suggested, then it is important that users have a _visual_ clue that this is
a glossary term and that they can click it to see its definition. That
visual clue would be enough to signal that this is not just "if" or a typo.

Until we have such a glossary-term indicator, we should use "if and only if"
(or we could temporarily take the risk of misunderstanding and use "iff").
It is not appropriate for us to use "if" (or "only if") in place of "iff",
when the meaning of the latter is important to the context.

This is so, in spite of the fact that, as Jason pointed out, many readers
assume bidirectionality for "if"; that is, they do not distinguish "if" from
"if and only if".

In some cases, of course, the "if" direction is of primary importance, and
the "only if" case can be ignored or glossed over in the doc. That is, when
it makes little difference whether readers confuse "if" with "iff", we could
get away with using just "if". Still, in general it is better to clearly
state what happens in each case or, if they are equivalent, to use "iff" (or
"if and only if").

Because careful use of such terms can result in language that is more like a
spec than doc, it is sometimes helpful and appropriate to use both a short,
introductory, informal, easy-to-read description and a more rigorous,
detailed explanation. Those who are interested will take the time to parse
the latter, and the others will generally understand enough to get the job
done.

Re: typo in accept-process-output (process.c)

[Dieter Wilhelm]

"Drew Adams" <drew.adams@oracle.com> writes:

>> I think a better approach is to keep using `iff' (also known as `ssi' in
>> French), but to make it such that the user can click on it to get to the
>> Glossary where we add an entry for it.
>> We could later on use the same feature for some other terms (e.g.
>> "fringe").
>
> The problem with using "iff" is that some readers will not notice that it is
> not "if", or they might think that it is a typo. If we use "iff" as Stefan
> suggested, then it is important that users have a _visual_ clue that this is
> a glossary term and that they can click it to see its definition. That
> visual clue would be enough to signal that this is not just "if" or a typo.

A glossary with hyperlinks was planned for Emacs?  Great stuff, but I
can't find it either in the TODO List nor in the etc/NEWS file.

-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

Re: typo in accept-process-output (process.c)

[Lennart Borgman (gmail)]

>>> I think a better approach is to keep using `iff' (also known as `ssi' in
>>> French), but to make it such that the user can click on it to get to the
>>> Glossary where we add an entry for it.
>>> We could later on use the same feature for some other terms (e.g.
>>> "fringe").
>> The problem with using "iff" is that some readers will not notice that it is
>> not "if", or they might think that it is a typo. If we use "iff" as Stefan
>> suggested, then it is important that users have a _visual_ clue that this is
>> a glossary term and that they can click it to see its definition. That
>> visual clue would be enough to signal that this is not just "if" or a typo.


Just a thought: Is there any other (non-math and non-logical) software 
that uses iff in the documentation?

RE: typo in accept-process-output (process.c)

[Drew Adams]

> Just a thought: Is there any other (non-math and non-logical) software
> that uses iff in the documentation?

Of course. (Some of the results of googling `iff software documentation' are
examples.)

Also, the Emacs user community includes mostly developers so far, and many
of them produce software, specs, and documentation that are aimed at other
developers. My guess is that many (most?) Emacs users will already be
familiar with "iff", but I could be wrong about that.

On the other hand, I see no special reason to use "iff" when "if and only
if" can be used instead. It could argued that "iff" can be handy for the
first line of a doc string, where space is at a premium, but in most cases
such rigor is not needed in that first line. And of course there is no
hyperlinked glossary for doc strings (either).

Overall, I'd say we don't need to use "iff". In any case, we should not
substitute "if" for "if and only if" in contexts where the distinction is
important.

If we had glossary links with visual cues, then it could be OK to use "iff",
but I see no real reason not to always use "if and only if" instead.

It can be OK to use just "if" informally, at first (say in a doc string
first line), provided that the rest of the text tells the whole truth, and
provided that doing so improves readability (e.g. by sounding less formal).

Rules of thumb:

1. Use "if A then B" or "A implies B" for implication. These are generally
clearer to readers than the equivalents "B if A" and "A only if B".

2. Use "if and only if" for logical equivalence, not "if".

(Even though "A if B" and "A only if B" can confuse readers about the
direction, there is no such problem when both directions are meant.)

Re: typo in accept-process-output (process.c)

[Jason Rumney]

Drew Adams wrote:
> Also, the Emacs user community includes mostly developers so far, and many
> of them produce software, specs, and documentation that are aimed at other
> developers. My guess is that many (most?) Emacs users will already be
> familiar with "iff", but I could be wrong about that.
>   

Many may be familiar, but many are also not familiar, even developers. I
had never encountered the term until the original bug report a few
months ago. I suspect it is seldom encountered outside of the field of
computer science and certain branches of mathematics and philosophy.

RE: typo in accept-process-output (process.c)

[Drew Adams]

> > Also, the Emacs user community includes mostly developers so 
> > far, and many of them produce software, specs, and documentation
> > that are aimed at other developers. My guess is that many
> > (most?) Emacs users will already be
> > familiar with "iff", but I could be wrong about that.
> 
> Many may be familiar, but many are also not familiar, even developers. I
> had never encountered the term until the original bug report a few
> months ago. I suspect it is seldom encountered outside of the field of
> computer science and certain branches of mathematics and philosophy.

All the more reason to use "if and only if" rather than "iff".

Re: typo in accept-process-output (process.c)

[Eli Zaretskii]

> From: Dieter Wilhelm <dieter@duenenhof-wilhelm.de>
> Date: Wed, 08 Aug 2007 00:01:22 +0200
> Cc: emacs-devel@gnu.org
> 
> A glossary with hyperlinks was planned for Emacs?  Great stuff, but I
> can't find it either in the TODO List nor in the etc/NEWS file.

There's already a Glossary node in the manual, has been there since
time immemoriam.  Is that what you want?

Re: typo in accept-process-output (process.c)

[Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dieter Wilhelm <dieter@duenenhof-wilhelm.de>
>> Date: Wed, 08 Aug 2007 00:01:22 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> A glossary with hyperlinks was planned for Emacs?  Great stuff, but I
>> can't find it either in the TODO List nor in the etc/NEWS file.
>
> There's already a Glossary node in the manual, has been there since
> time immemoriam.  Is that what you want?

Not quite, since it is of little use when one does not expect the term
in it.  The idea of S. Monnier and D. Adams with the visual hint is
what is exciting about.

I'm coming from an engineering background and never encountered "iff"
before.  By the way, it is even indicated by aspell (british) as a
typo. 

With a visual hint to the Glossary Emacs would be even more
educational.

-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

Re: typo in accept-process-output (process.c)

[Glenn Morris]

Richard Stallman wrote:

> We decided some months ago to get rid of "iff" from Emacs doc strings
> because quite a number of users are unfamiliar with it.
>
> Would someone like to carry this out?

done

Re: typo in accept-process-output (process.c)

[Eli Zaretskii]

> Cc: drew.adams@oracle.com,  emacs-devel@gnu.org
> From: Dieter Wilhelm <dieter@duenenhof-wilhelm.de>
> Date: Wed, 08 Aug 2007 07:50:52 +0200
> 
> > There's already a Glossary node in the manual, has been there since
> > time immemoriam.  Is that what you want?
> 
> Not quite, since it is of little use when one does not expect the term
> in it.

You should expect any Emacs related terminology to be in the Glossary
node.  I think you will find that it lives up to this expectation very
well, even for terms such as "iff" that are not Emacs-specific.

Re: typo in accept-process-output (process.c)

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: drew.adams@oracle.com,  emacs-devel@gnu.org
>> From: Dieter Wilhelm <dieter@duenenhof-wilhelm.de>
>> Date: Wed, 08 Aug 2007 07:50:52 +0200
>> 
>> > There's already a Glossary node in the manual, has been there since
>> > time immemoriam.  Is that what you want?
>> 
>> Not quite, since it is of little use when one does not expect the term
>> in it.
>
> You should expect any Emacs related terminology to be in the
> Glossary node.  I think you will find that it lives up to this
> expectation very well, even for terms such as "iff" that are not
> Emacs-specific.

It does not merely live up to this expectation, but surpasses it by
far.  Which is actually the problem.  What can we do to make people
_expect_ the explanation to be in the glossary?  The hyperlink
suggestion was one way to achieve just that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: typo in accept-process-output (process.c)

[Stefan Monnier]

> You should expect any Emacs related terminology to be in the Glossary
> node.  I think you will find that it lives up to this expectation very
> well, even for terms such as "iff" that are not Emacs-specific.

Actually "iff" is not there.


        Stefan

Re: typo in accept-process-output (process.c)

[martin rudalics]

> Actually "iff" is not there.

Iff
      "Iff" means "if and only if."  This terminology comes from
      mathematics.

Re: typo in accept-process-output (process.c)

[Stefan Monnier]

>> Actually "iff" is not there.

> Iff
>      "Iff" means "if and only if."  This terminology comes from
>      mathematics.

Hmm... indeed... sorry 'bout that.
And thanks for pointing out a bug in my Makefile (which doesn't update the
`info' subdir since a while ago, apparently, so I was looking at an
out-of-date version).


        Stefan

Re: typo in accept-process-output (process.c)

[Richard Stallman]

Thank you very much for dealing with the iffs.

Re: typo in accept-process-output (process.c)

[Richard Stallman]

I do not think that a visible glossary indication is a good substitute
for words that are clear.

Re: typo in accept-process-output (process.c)

[Christian Schlauer]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: drew.adams@oracle.com,  emacs-devel@gnu.org
>> From: Dieter Wilhelm <dieter@duenenhof-wilhelm.de>
>> Date: Wed, 08 Aug 2007 07:50:52 +0200
>> 
>> > There's already a Glossary node in the manual, has been there since
>> > time immemoriam.  Is that what you want?
>> 
>> Not quite, since it is of little use when one does not expect the term
>> in it.
>
> You should expect any Emacs related terminology to be in the Glossary
> node.  I think you will find that it lives up to this expectation very
> well, even for terms such as "iff" that are not Emacs-specific.

Why isn't there an index entry for the Glossary? I tried to find it by
doing

C-h i d m Emacs RET i gloss TAB

gives [No match]. So the only way (known to me) to find it seems to be

C-h i d m Emacs RET m gloss TAB

which is inconvenient when I'm somewhere deep down in the Emacs manual
and would like to get to the Glossary quickly.

(Admittedly, it is the 5th entry in the menu in (info "(emacs)Top"),
so I should have found it. But nevertheless I overlooked it as it is
placed between menu entries like `Copying', `GNU Free Documentation
License', `Antinews', `Manifesto', `Acknowledgements' -- I think I had
found the glossary if it had been under the "heading" (if that is the
right word) `Indexes (each index contains a large menu)' or `Important
General Concepts'.)

Also, what about

* Glossary::	        Emacs terminology used in this manual, explained.

instead of

* Glossary::	        The glossary.

-- 
Christian Schlauer

Re: typo in accept-process-output (process.c)

[Stephen Berman]

On Sun, 12 Aug 2007 22:33:04 +0200 Christian Schlauer <cs-muelleimer-rubbish.bin@arcor.de> wrote:

> Why isn't there an index entry for the Glossary? I tried to find it by
> doing
>
> C-h i d m Emacs RET i gloss TAB
>
> gives [No match]. So the only way (known to me) to find it seems to be
>
> C-h i d m Emacs RET m gloss TAB
>
> which is inconvenient when I'm somewhere deep down in the Emacs manual
> and would like to get to the Glossary quickly.

If you type `g glo TAB' you'll see Glossary listed as the second item
in the *Completions* buffer.

Steve Berman

Re: typo in accept-process-output (process.c)

[Richard Stallman]

I will improve the menu entry for the glossary.
Thanks.