3 dots vanish at end of filled line

3 dots vanish at end of filled line

[Karl Berry]

Bob sent me this bug report for the current CVS version of Emacs about
three dots disappearing in the Info display (they are present in the
actual .info file).  It doesn't happen in 21.3.

Can someone look at it, please?

Thanks,
Karl


Date: Fri, 7 Oct 2005 19:28:29 +0000 (UTC)
From: "Robert J. Chassell" <bob@rattlesnake.com>
To: karl@freefriends.org
Subject: 3 dots vanish at end of filled line

Today's GNU Emacs CVS snapshot, Fri, 2005 Oct  7  13:53 UTC
GNU Emacs 22.0.50.103 (i686-pc-linux-gnu, GTK+ Version 2.6.10) 
started with

     /usr/local/src/emacs/src/emacs -Q -D

and using   texinfo-4.8

The bug:  in *info* the three dots of the @dots{} comand, when the
@dots{} comand just happens to fall on a line of its own when the
previous line is filled, does not show the three dots.  


Thus, in *info*

    Here are three dots ...

    Here are three dots with the @dots{} on a filled line xxxxxxxxxxxxx

    Contents of chapter 1.


but the three dots appear when the line is copied from the *info* file
...

(on a line of its own, as shown).

The DVI, as seen by xdvi, is OK. 


Here is a test file:


\input /usr/local/src/texinfo-4.8/doc/texinfo.tex  @c -*-texinfo-*-
@comment %**start of header
@setfilename foo.info
@settitle Texinfo Test
@smallbook
@comment %**end of header

@ignore

 ## Summary of shell commands to create various output formats:

    pushd /u/texinfo/

    ## Info output
    makeinfo --force --fill-column=70 --no-split --paragraph-indent=0 \
    --verbose foo.texi

    ## ;; (kill-buffer "*info*")
    ## ;; (info "/u/texinfo/foo.info" nil)

    ## DVI output
    texi2dvi foo.texi

    ## View DVI output
    ##     xdvi foo.dvi &

    ## HTML output
    makeinfo --no-split --html foo.texi

    ## Plain text output
    makeinfo --fill-column=70 --no-split --paragraph-indent=0 \
    --verbose --no-headers --output=foo.txt  \
    foo.texi

    ## DocBook output
    makeinfo --docbook --no-split --paragraph-indent=0 \
    --verbose foo.texi

    ## XML output
    makeinfo --xml --no-split --paragraph-indent=0 \
    --verbose foo.texi

    popd 

@end ignore

@titlepage
@sp 6
@center @titlefont{Test document}
@sp 4
@center by Robert J. Chassell

@page
@vskip 0pt plus 1filll
@end titlepage

@contents

@ifnottex
@node Top, Chapter One, (dir), (dir)
@top Test Top
@end ifnottex

@menu
* Chapter One::                 
@end menu

@node Chapter One
@chapter Chapter One

Jared Diamond@footnote{@cite{Collapse:@* How Societies Choose to Fail or
Succeed},@*
Jared Diamond,@*
2005, Viking,@*
ISBN 0-670-03337-5} has written a book, @cite{Collapse: How Societies
Choose to Fail or Succeed}, on this theme.  Before publishing his
book, in March 2003, he asked why societies can make disastrous
decisions?  (See
@url{http://www.edge.org/@/documents/@/archive/@/edge114.html}.)

Here are three dots @dots{}

Here are three dots with the @@dots@{@} on a filled line xxxxxxxxxxxxx
@dots{}

More contents of chapter 1.

@bye

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: 3 dots vanish at end of filled line

[Juri Linkov]

> Bob sent me this bug report for the current CVS version of Emacs about
> three dots disappearing in the Info display (they are present in the
> actual .info file).  It doesn't happen in 21.3.
>
> Can someone look at it, please?

The Emacs Info reader interprets a line of dots as an underlining
below the Info title line, so it hides this line and highlights its
preceding line in the face `info-title-4', since dots are used for
4th-level titles, like in:

  1.3.7.1 A Sample Function Description
  .....................................

The current code doesn't take into account the length of the line,
so for the Emacs Info reader this case is equivalent to:

  Here are three dots with the @dots{} on a filled line xxxxxxxxxxxxx
  ...

Perhaps this should be fixed to process such lines only in the case
when lengths of underlining and title lines are the same.

Or maybe there is a filling bug in the makeinfo program so that it
leaves the dangling dots on a line of its own?  Wouldn't it be more
correct to convert

  Here are three dots with the @@dots@{@} on a filled line xxxxxxxxxxxxx
  @dots{}

into

  Here are three dots with the @dots{} on a filled line
  xxxxxxxxxxxxx...

thus not breaking `xxxxxxxxxxxxx...'?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: 3 dots vanish at end of filled line

[Karl Berry]

Hi Juri,

    Or maybe there is a filling bug in the makeinfo program so that it

It is not a bug in makeinfo -- there is whitespace in the input, and
that (almost) always means it's ok to break a line in the output.  It's
just doing what the user said to do.

Please fix Emacs.  It was fine in 21.3.

Thanks,
k

Re: 3 dots vanish at end of filled line

[Juri Linkov]

> Please fix Emacs.  It was fine in 21.3.

Highlighting the title with hiding the line of dots under it
is quite an old feature and can be observed in the released
21.4 version (and the same bug occurs in 21.4 too).  So to not
produce different results than the previous Emacs releases,
before implementing the idea of handling underlining and title
lines only with equal lengths, I want to ask you one question:
could you confirm that all title lines produced by makeinfo
have the same lengths with their succeeding underlines (i.e.
lines with characters `*', `=', `-' and `.')?  If so, then
I think it is safe to fix that in a way of comparing their lengths
before highlighting.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: 3 dots vanish at end of filled line

[Karl Berry]

    could you confirm that all title lines produced by makeinfo
    have the same lengths with their succeeding underlines (i.e.
    lines with characters `*', `=', `-' and `.')?  

Yes, that is so.

    If so, then I think it is safe to fix that in a way of comparing
    their lengths before highlighting.

I agree.

    is quite an old feature and can be observed in the released
    21.4 version (and the same bug occurs in 21.4 too).  So to not

I guess it didn't happen for me because I use Emacs in an xterm and not
under X.

Thanks,
k

Re: 3 dots vanish at end of filled line

[Luc Teirlinck]

Juri Linkov wrote:

   I want to ask you one question: could you confirm that all title
   lines produced by makeinfo have the same lengths with their
   succeeding underlines (i.e.  lines with characters `*', `=', `-'
   and `.')?  If so, then I think it is safe to fix that in a way of
   comparing their lengths before highlighting.

That is _still_ a very unreliable heuristic.  There is no reason why a
line followed by a line of equal length consisting of `*',`=',`-' or
`.' should be a title line.  These characters could, for instance, be
part of an ASCII picture surrounding text.  There are plenty of other
possibilities.  A line of these characters is *not* markup.

Why not get rid of such flawed heuristics and simply underline titles
the way they are underlined in the .info files, as the standalone Info
reader does?  This makes it also easier to see the nesting depth of
the node.  Why try to be tricky for no other reason than to be tricky?

I personally have the line:

(add-hook 'Info-mode-hook (lambda () (setq buffer-invisibility-spec nil)))

in my .emacs to get rid of all this abuse of the invisibility property in
info.el.

Sincerely,

Luc.

Re: 3 dots vanish at end of filled line

[Luc Teirlinck]

>From my previous message:
      
      If so, then I think it is safe to fix that in a way of
      comparing their lengths before highlighting.

   That is _still_ a very unreliable heuristic.

For instance, in Bob's example file foo.texi, after the:

Here are three dots with the @@dots@{@} on a filled line xxxxxxxxxxxxx
@dots{}

Paste in the extra text (separated by blank lines):

@verbatim
*****
*BOX*
*****
@end verbatim

run makeinfo on it and see how horribly badly this gets displayed in
`emacs -Q -nbc'

Not only is the ending ***** line not displayed, the *BOX* line in
displayed in a ridiculously large font.  The displayed stuff does not
even remotely resemble the intended box.  I do not believe that the
"fix" you proposed fixes this.

The standalone info gets this completely correct.  I also get it
correct with my .emacs file, which solidly corrects these types of
bugs in info.el (both the bugs in font and invisibility).

Sincerely,

Luc.

Re: 3 dots vanish at end of filled line

[Richard M. Stallman]

	Or maybe there is a filling bug in the makeinfo program so that it

    It is not a bug in makeinfo -- there is whitespace in the input, and
    that (almost) always means it's ok to break a line in the output.  It's
    just doing what the user said to do.

I agree this is a bug in Emacs, but I think the output from Texinfo is
wrong.  Perhaps the input is wrong too.  There should not be
whitespace before an ellipsis in English text.

Can you change Makeinfo to warn when there is space before @dots{}?

We should fix the Emacs bug anyway, though.

    Why not get rid of such flawed heuristics and simply underline titles
    the way they are underlined in the .info files, as the standalone Info
    reader does?

That is easy to say, but how would one do it?  How would Info
recognize these titles if not by the following like which "underlines"
them?

Re: 3 dots vanish at end of filled line

[Karl Berry]

    There should not be
    whitespace before an ellipsis in English text.

I must beg to differ.  Virtually every book I've seen has space before
(most) ellipses.

Aside from typographical matters, ellipses seem to most often be used to
stand for a word rather than as "trailing" punctuation.  Here are a few
random samples from the Texinfo manual:

    Permission is granted to @dots{}
    ...
    one (not Info, not @TeX{}, @dots{}).
    ...
    @item @@iftex @dots{} @@end iftex
    ...
    than `It is recommended that @dots{}''.

It seems wrong to me to omit such spaces.

There are over 130 occurrences of spaces before @dots in the Texinfo
manuals (I didn't search others).  At a glance, the spaces seem
desirable and even necessary to me.  I think a blanket warning would be
a bad mistake, and I don't see any way to distinguish the problematic
cases.

Certainly there are times when no space should be there; so then the
author should leave out the space in the input.  Or no line break; then
the author should use a tie.

karl

Re: 3 dots vanish at end of filled line

[Luc Teirlinck]

Richard Stallman wrote:

       Why not get rid of such flawed heuristics and simply underline titles
       the way they are underlined in the .info files, as the standalone Info
       reader does?

   That is easy to say, but how would one do it?  How would Info
   recognize these titles if not by the following like which "underlines"
   them?

What I proposed in the above was to do what the standalone Info reader
does: to leave the titles underlined exactly the way they are in the
.info files and not to process them specially.  Hence, info.el would
not need to recognize titles.

If this would be unacceptable, then a less radical departure from the
current Emacs Info situation would be to recognize titles by the top
of the node pattern:

A line with an isolated literal Control-underscore, then a line
starting with: "File:", then a blank line, then a non-blank line (the
title) followed by a line of the same length consisting entirely of
one of the special characters.

That would only leave the @...heading series, where the title occurs
within the body of the note.  These are completely indistinguishable
to a computer program from certain non-title lines, although a human
reader usually will be easily able to distinguish from appearance and
context.

Leaving @...heading type titles unprocessed would avoid the bugs and
would not constitute a radical departure from the current Emacs style:
@...heading seems to be seldom used (the only example I know is
`(info)Advanced') and titles in the body of a node feel very different
from node titles anyway, so that displaying them differently makes sense.

In other words looking at the beginning of `(info)Advanced' (as it
appears in the standalone Info):

    2.1 Advanced Info Commands
    ==========================

    Here are some more Info commands that make it easier to move around.

    `g' goes to a node by name
    --------------------------

    If you know a node's name, you can go there by typing `g', the name,
    and <RET>.  Thus, `gTop<RET>' would go to the node called `Top' in this

The most radical proposal is to have Emacs display this exactly like
the standalone Info does, that is, literally as above.  The less
radical proposal is to keep displaying the node title
"2.1 Advanced Info Commands" as Emacs currently does (hide the
underlining and display the title bold and in a larger font), but
leave the subtitle:

`g' goes to a node by name
--------------------------

displayed exactly like that, without any processing.  Again, such
subtitles are relatively rare.  Both proposals would get rid of the
type of bugs we are discussing.

Sincerely,

Luc.

Re: 3 dots vanish at end of filled line

[Juri Linkov]

> Leaving @...heading type titles unprocessed would avoid the bugs and
> would not constitute a radical departure from the current Emacs style:
> @...heading seems to be seldom used (the only example I know is
> `(info)Advanced')

There are other Texinfo commands that produce a line of underlining
charcaters within the body of the node: `@section', `@subsection',
`@subsubsection'.

> and titles in the body of a node feel very different from node
> titles anyway, so that displaying them differently makes sense.

They are already displayed differently with different faces:

`info-title-1' - for @chapter (`***' in Info output),
`info-title-2' - for @section (`==='),
`info-title-3' - for @subsection (`---'),
`info-title-4' - for @subsubsection (`...').

> [...] but leave the subtitle:
>
> `g' goes to a node by name
> --------------------------
>
> displayed exactly like that, without any processing.  Again, such
> subtitles are relatively rare.

Such subtitles are not rare.  Within the Emacs documentation in CVS
there are more than 200 such subtitles that would lose their
highlighting after your proposed less radical change.  In quite
a large base of Info files I can find about 2000 such subtitles.
I don't think that users who accustomed for many years in the released
Emacs versions to see such titles post-processed in the Emacs Info
reader will agree with this change.  OTOH, the artificial case you
described in another mail (the word BOX with asterisks around it) is
extremely rare in the large Info base I looked at.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: 3 dots vanish at end of filled line

[Karl Berry]

    juri> There are other Texinfo commands that produce a line of
    underlining charcaters within the body of the node: `@section',
    `@subsection', `@subsubsection'.

They aren't "within the body" of a node, they're at the top.  Luc was
proposing that those still be recognized.

As far as recognizing @headings goes, I don't feel strongly either way.
The matching-line-length heuristic seems about as good as it will get.

Re: 3 dots vanish at end of filled line

[Luc Teirlinck]

Karl Berry wrote:

   As far as recognizing @headings goes, I don't feel strongly either way.
   The matching-line-length heuristic seems about as good as it will get.

It is trying to do the impossible.  The problem is that we are dealing
with plain text, not formatted text with special markup for titles.

It does not fix all potential bugs, it only reduces their frequency.
And this type of bug can be very nasty when it does occur.  Even with
the equal length heuristic, the situation leading to bugs is not
really that excessively unlikely in certain situations, like, for
instance, quoting program output or input inside @verbatim or
@verbatiminclude.  Several computer programs generate lines of one of
the four special characters.  The program might deliberately make such
lines of equal length as the preceding line (as Makeinfo does when it
underlines titles) or this might happen by coincidence.

I believe that to deliberately fail to eliminate the possibility of
bugs, even infrequent bugs, one needs a _really_ good reason.

If it did not cause any bugs, then the best way to display @headings
titles in the node body would be a matter of taste.  Even disregarding
the possibility of bugs, I prefer to see them underlined and
unprocessed.  But whatever one's taste, the special processing of the
@headings titles serves no truly important purpose.  Certainly not
important enough to deliberately fail to eliminate the possibility of
nasty bugs.

Sincerely,

Luc.

Re: 3 dots vanish at end of filled line

[Stefan Monnier]

> It is trying to do the impossible.  The problem is that we are dealing
> with plain text, not formatted text with special markup for titles.

Indeed.  And we've been through this discussion already.  And since Emacs's
Info mode does even more of those "dangerous" guessing games now than
before, I think it's pretty clear that we've decided it's worth the risk.

Actually, the problem is in the Info format, which is even not clearly
unambiguous when it comes to the syntax of menus: there several places
(typically in index nodes for manuals which include things like infix
operators in their index) where we have no other option but to guess.

> And this type of bug can be very nasty when it does occur.  Even with
> the equal length heuristic, the situation leading to bugs is not
> really that excessively unlikely in certain situations, like, for
> instance, quoting program output or input inside @verbatim or
> @verbatiminclude.

I think such sample text should be indented, otherwise even a human reader
could get confused.

If those risks are too high for you, then I'd suggest you turn off font-lock
in your info buffers.


        Stefan

Re: 3 dots vanish at end of filled line

[Karl Berry]

    Actually, the problem is in the Info format

The problem is not, IMHO, Info format, which was always designed to be
displayed as-is, not interpreted, since long before font-lock,
highlighting, or any of this other stuff came into existence.

The problem was, IMHO, starting down this road of "interpreting" Info
files when they were never meant for that.  Unfortunately it's too late
now that (I gather) users are used to fontified Info output, so the
guessing games have to just be finagled as best they can.

    (typically in index nodes for manuals

In the last Texinfo release I added a cookie (^@^H[index^@^H] to index
nodes for precisely this purpose.  You may recall the long discussion we
had about it.  I hope Emacs will take advantage of it, since that's the
only reason it is there.

     turn off font-lock in your info buffers.

I'd love to turn off font-lock everywhere, I hate the incessant
pseudo-underlining and bolding in my various buffers (even running under
xterm it won't just give me plain text any more), but there is
apparently no way to do it without maintaining a list of dozens of
individual variables to be set to nil.  (At least when I asked/searched
about it a couple months ago, that was the answer I got.)  (setq-default
global-font-lock-mode nil) is insufficient, in fact I don't think even
think it undoes Info fontification.  Sigh ... if anyone has a practical
solution, I'd be grateful to know about it.

Thanks,
Karl

Re: 3 dots vanish at end of filled line

[Stefan Monnier]

>      turn off font-lock in your info buffers.

> I'd love to turn off font-lock everywhere, I hate the incessant
> pseudo-underlining and bolding in my various buffers (even running under
> xterm it won't just give me plain text any more), but there is
> apparently no way to do it without maintaining a list of dozens of
> individual variables to be set to nil.  (At least when I asked/searched
> about it a couple months ago, that was the answer I got.)  (setq-default
> global-font-lock-mode nil) is insufficient, in fact I don't think even
> think it undoes Info fontification.  Sigh ... if anyone has a practical
> solution, I'd be grateful to know about it.

In Emacs-CVS, keeping global-font-lock-mode to nil *should* get rid of such
highlighting.  I don't claim it does, but in general I'd consider it a bug
if it doesn't, so if you report it we may fix it.

For info-mode, it currently only partly works: it removes the highlighting
but it doesn't put the ASCII-art underlines back in.  I think it's a bug.


        Stefan

Re: 3 dots vanish at end of filled line

[Richard M. Stallman]

    In Emacs-CVS, keeping global-font-lock-mode to nil *should* get rid of such
    highlighting.

I am not sure of that.  There used to be some modes that did
fontification spontaneously.  We changed them so that M-x font-lock
would turn this fontification on and off; but did we change them
also to make it off by default?

    For info-mode, it currently only partly works: it removes the highlighting
    but it doesn't put the ASCII-art underlines back in.  I think it's a bug.

I agree.

Re: 3 dots vanish at end of filled line

[Stefan Monnier]

>     In Emacs-CVS, keeping global-font-lock-mode to nil *should* get rid of
>     such highlighting.

> I am not sure of that.  There used to be some modes that did
> fontification spontaneously.  We changed them so that M-x font-lock
> would turn this fontification on and off; but did we change them
> also to make it off by default?

You're right, I forgot that we preserved the default behavior.
But at least the users can remove highlighting by explicitly turning
font-lock off in those modes.  I think it's the most important aspect.


        Stefan

Re: 3 dots vanish at end of filled line

[Richard M. Stallman]

      (setq-default
    global-font-lock-mode nil) is insufficient, in fact I don't think even
    think it undoes Info fontification.

A few major modes turn on font-lock by default,
but nowadays it should always be possible to turn it off
with M-0 M-x font-lock.  If you find any mode where this
does not work, please send a specific bug report.

Re: 3 dots vanish at end of filled line

[Richard M. Stallman]

	(typically in index nodes for manuals

    In the last Texinfo release I added a cookie (^@^H[index^@^H] to index
    nodes for precisely this purpose.  You may recall the long discussion we
    had about it.  I hope Emacs will take advantage of it, since that's the
    only reason it is there.

I have no memory of this discussion, but what should we do in Emacs
to take advantage of it?

Re: 3 dots vanish at end of filled line

[Luc Teirlinck]

Stefan Monnier wrote:

   > And this type of bug can be very nasty when it does occur.  Even with
   > the equal length heuristic, the situation leading to bugs is not
   > really that excessively unlikely in certain situations, like, for
   > instance, quoting program output or input inside @verbatim or
   > @verbatiminclude.

   I think such sample text should be indented, otherwise even a human reader
   could get confused.

@verbatim and @verbatiminclude (and @format) do not indent.  See
`(texinfo)GNU Sample Texts' for an example of actual unindented
verbatimly quoted program input.  (It does not suffer from the bug we
are discussing, but other similarly quoted text easily could.)  The
unindented @verbatim block is the last thing in the file and is
clearly introduced as such.  Because of that, there is no danger of
confusion.  The block of text is so large that it would look bad if
indented.  If there were a node "Sample Texinfo File" containing
nothing but the quoted text, indenting the entire node would even look
worse.  The idea is to make the quoted text look as close as possible
to the actual file.  When literally quoting heavily indented text,
with the purpose of illustrating that indentation, it might be
difficult to distinguish unindented lines from lines with one or two
lines of indentation if extra indentation were added,

Of course, if you insert unindented @verbatim blocks _in the middle of
a node_, then you have to be very careful to avoid confusion.

Sincerely,

Luc.

Re: 3 dots vanish at end of filled line

[Luc Teirlinck]

   Indeed.  And we've been through this discussion already.  And since Emacs's
   Info mode does even more of those "dangerous" guessing games now than
   before, I think it's pretty clear that we've decided it's worth the risk.

For other types of abuse of the Info format by info.el, at least
customizable variables were provided to get around them.  The patch
below provides such a variable.

   If those risks are too high for you, then I'd suggest you turn off font-lock
   in your info buffers.

I do not want to turn off font-lock entirely, only the part of it that
I consider reckless and senseless: the games played with the titles.
There is for example nothing wrong with Font Lock fontifying links
because if Font Lock gets confused about them, then probably info.el
is confused and will incorrectly try to follow them or fail to follow
then and hence there is a bug to be fixed.

I still believe that it would be a lot better not to mess with mode
titles in the middle of a node.  If I would not be able to convince
people of that then I believe that we need a customizable variable
allowing people to turn the processing of titles off without having to
give up on fontification of links and menus.

If fontification of titles in the body of a node would not be disabled
by default then I believe that it makes more sense to make the new
variable turn off fontification for all titles, even the node titles,
as people who explicitly customize it probably are not going to worry
about the fact that this constitutes a change from previous Emacs
versions.  They are more typically going to worry about uniformity of
style between the different ways of reading Info: Emacs under X,
emacs -nw and the standalone Info reader.

The patch below would provide a customizable variable allowing to turn
the processing of titles off entirely or partially (only the hiding
part).  The present situation would remain the default, although I
personally still believe that this is a mistake. 

If I could convince people that it is better not to process titles in
the middle of a node, then I would provide a fourth option disabling
processing of titles only in the body of a node and make that the default.

As usual, I can install if desired.

===File ~/info.el-diff======================================
*** info.el	04 Oct 2005 09:11:27 -0500	1.448
--- info.el	10 Oct 2005 20:05:52 -0500	
***************
*** 3626,3631 ****
--- 3626,3647 ----
      keymap)
    "Keymap to put on the Up link in the text or the header line.")
  
+ (defcustom Info-fontify-titles t
+   "If non-nil fontify titles in Info nodes.
+ This uses the faces `info-title-1' through `info-title-4'.
+ If the value is t, also hide the underlining.
+ If nil, leave the titles exactly as in the .info files.  This makes
+ the titles look like they do in the standalone Info reader.
+ If neither nil not t, fontify the titles, but do not hide the underlining,
+ The latter option looks bad with the default values of `info-title-1'
+ and friends, so if you choose it, you will probably also want to customize
+ those faces."
+   :type '(choice (const :tag "Fontify and hide underlining" t)
+ 		 (const :tag "Fontify but do not hide underlining" 'no-hiding)
+ 		 (const :tag "Neither fontify nor hide" nil))
+   :group 'info
+   :version "22.1")
+ 
  (defun Info-fontify-node ()
    "Fontify the node."
    (save-excursion
***************
*** 3700,3723 ****
                (put-text-property (point) header-end 'invisible t)))))
  
        ;; Fontify titles
!       (goto-char (point-min))
!       (when not-fontified-p
!         (while (re-search-forward "\n\\([^ \t\n].+\\)\n\\(\\*\\*+\\|==+\\|--+\\|\\.\\.+\\)$"
!                                   nil t)
!           (let* ((c (preceding-char))
!                  (face
!                   (cond ((= c ?*) 'info-title-1)
!                         ((= c ?=) 'info-title-2)
!                         ((= c ?-) 'info-title-3)
!                         (t        'info-title-4))))
!             (put-text-property (match-beginning 1) (match-end 1)
!                                'font-lock-face face))
!           ;; This is a serious problem for trying to handle multiple
!           ;; frame types at once.  We want this text to be invisible
!           ;; on frames that can display the font above.
!           (when (memq (framep (selected-frame)) '(x pc w32 mac))
!             (add-text-properties (1- (match-beginning 2)) (match-end 2)
!                                  '(invisible t front-sticky nil rear-nonsticky t)))))
  
        ;; Fontify cross references
        (goto-char (point-min))
--- 3716,3741 ----
                (put-text-property (point) header-end 'invisible t)))))
  
        ;; Fontify titles
!       (when Info-fontify-titles
! 	(goto-char (point-min))
! 	(when not-fontified-p
! 	  (while (re-search-forward "\n\\([^ \t\n].+\\)\n\\(\\*\\*+\\|==+\\|--+\\|\\.\\.+\\)$"
! 				    nil t)
! 	    (let* ((c (preceding-char))
! 		   (face
! 		    (cond ((= c ?*) 'info-title-1)
! 			  ((= c ?=) 'info-title-2)
! 			  ((= c ?-) 'info-title-3)
! 			  (t        'info-title-4))))
! 	      (put-text-property (match-beginning 1) (match-end 1)
! 				 'font-lock-face face))
! 	    ;; This is a serious problem for trying to handle multiple
! 	    ;; frame types at once.  We want this text to be invisible
! 	    ;; on frames that can display the font above.
! 	    (and (memq (framep (selected-frame)) '(x pc w32 mac))
! 		 (eq Info-fontify-titles t)
! 		 (add-text-properties (1- (match-beginning 2)) (match-end 2)
! 				      '(invisible t front-sticky nil rear-nonsticky t))))))
  
        ;; Fontify cross references
        (goto-char (point-min))
============================================================

Re: 3 dots vanish at end of filled line

[Richard M. Stallman]

The issue at hand is how to make this feature work correctly.
I don't want to digress from that into the issue of how to turn
it off.

Re: 3 dots vanish at end of filled line

[Luc Teirlinck]

Richard Stallman wrote:

   The issue at hand is how to make this feature work correctly.
   I don't want to digress from that into the issue of how to turn
   it off.

It is impossible to make it work correctly without reverting the
processing of titles _within the body of a node_.

Info files should be able to discuss _any_ topic,  One such topic could
be the use of ASCII art.  In such a discussion one might want to
include examples of actual files containing ASCII art in separate nodes
of their own using @verbatim.  That ASCII art may include titles
underlined Info style: a line followed by an equal number of one of
these four characters.  Those titles obviously should be displayed as
ASCII art, because that is what they are supposed to illustrate.

Displaying examples of diff output using @verbatim in nodes of their
own could potentially create trouble too.  The same applies to output
or input files of many other programs.

Stefan Monnier wrote:

   Indeed.  And we've been through this discussion already.  And since Emacs's
   Info mode does even more of those "dangerous" guessing games now than
   before, I think it's pretty clear that we've decided it's worth the risk.

In the particular case of titles it is not clear what the "it" in
"it's worth the risk" is.  Titles already clearly stand out in the
.info files by the underlining and that underlining makes the level
very clear.  I personally believe that the processing actually makes
things less clear.  Am I correct in assuming that the "it" refers to
getting rid of ASCII art, which could be important to some people (not
to me) because ASCII art looks "unsophisticated"?  In that case, I
believe that there are more Info nodes containing various other forms
of ASCII art in their body, than there are nodes containing titles in
their body, so one can not get rid of ASCII art in Info anyway.

Sincerely,

Luc.

Re: 3 dots vanish at end of filled line

[Stefan Monnier]

> The issue at hand is how to make this feature work correctly.
> I don't want to digress from that into the issue of how to turn
> it off.

I've installed the patch below.


        Stefan


--- info.el	12 oct 2005 12:46:26 -0400	1.449
+++ info.el	12 oct 2005 15:42:23 -0400	
@@ -3698,9 +3698,15 @@
 
       ;; Fontify titles
       (goto-char (point-min))
-      (when not-fontified-p
-        (while (re-search-forward "\n\\([^ \t\n].+\\)\n\\(\\*\\*+\\|==+\\|--+\\|\\.\\.+\\)$"
+      (when (and font-lock-mode not-fontified-p)
+        (while (and (re-search-forward "\n\\([^ \t\n].+\\)\n\\(\\*\\*+\\|==+\\|--+\\|\\.\\.+\\)$"
                                   nil t)
+                    ;; Only consider it as an underlined title if the ASCII
+                    ;; underline has the same size as the text.  A typical
+                    ;; counter example is when a continuation "..." is alone
+                    ;; on a line.
+                    (= (- (match-end 1) (match-beginning 1))
+                       (- (match-end 2) (match-beginning 2))))
           (let* ((c (preceding-char))
                  (face
                   (cond ((= c ?*) 'info-title-1)

Re: 3 dots vanish at end of filled line

[Richard M. Stallman]

Thanks for fixing it.

Re: 3 dots vanish at end of filled line

[KOBAYASHI Yasuhiro]

In message Re: 3 dots vanish at end of filled line
 on Wed, 12 Oct 2005 15:47:53 -0400
 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> --- info.el	12 oct 2005 12:46:26 -0400	1.449
> +++ info.el	12 oct 2005 15:42:23 -0400	
> @@ -3698,9 +3698,15 @@
 
>        ;; Fontify titles
>        (goto-char (point-min))
> -      (when not-fontified-p
> -        (while (re-search-forward "\n\\([^ \t\n].+\\)\n\\(\\*\\*+\\|==+\\|--+\\|\\.\\.+\\)$"
> +      (when (and font-lock-mode not-fontified-p)
> +        (while (and (re-search-forward "\n\\([^ \t\n].+\\)\n\\(\\*\\*+\\|==+\\|--+\\|\\.\\.+\\)$"
>                                    nil t)
> +                    ;; Only consider it as an underlined title if the ASCII
> +                    ;; underline has the same size as the text.  A typical
> +                    ;; counter example is when a continuation "..." is alone
> +                    ;; on a line.
> +                    (= (- (match-end 1) (match-beginning 1))
> +                       (- (match-end 2) (match-beginning 2))))
>            (let* ((c (preceding-char))
>                   (face
>                    (cond ((= c ?*) 'info-title-1)

It causes that Japanese titles are not fontified.

How about the following.

--- lisp/info.el.orig	2005-10-28 13:37:47.203249400 +0900
+++ lisp/info.el	2005-10-28 13:03:51.225355900 +0900
@@ -3706,8 +3706,8 @@
                     ;; underline has the same size as the text.  A typical
                     ;; counter example is when a continuation "..." is alone
                     ;; on a line.
-                    (= (- (match-end 1) (match-beginning 1))
-                       (- (match-end 2) (match-beginning 2))))
+                    (= (string-width (match-string 1))
+                       (string-width (match-string 2))))
           (let* ((c (preceding-char))
                  (face
                   (cond ((= c ?*) 'info-title-1)


-- 
KOBAYASHI Yasuhiro <kobayays@otsukakj.co.jp>

Re: 3 dots vanish at end of filled line

[Juri Linkov]

>     juri> There are other Texinfo commands that produce a line of
>     underlining charcaters within the body of the node: `@section',
>     `@subsection', `@subsubsection'.
>
> They aren't "within the body" of a node, they're at the top.

There are quite many places in the Emacs documentation where these
commands (and their underlined output) are in the middle of a node.
I don't know is it bad style or what.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: 3 dots vanish at end of filled line

[Luc Teirlinck]

Juri Linkov wrote (talking about my proposal to display subtitles _inside
the body of nodes_ the same way that the standalone Info reader does):

   I don't think that users who accustomed for many years in the released
   Emacs versions to see such titles post-processed in the Emacs Info
   reader will agree with this change.

Countless much more radical and more widespread changes to the
appearance of Info nodes have been made from 21.3 to the present Emacs
CVS.  Most of these changes did not fix any bugs.  What makes you
think that users would be so terribly upset with my change and not
with all these other much more radical and more widespread departures
of what they have been used to for years?

The titles that would "loose their highlighting" would still be
clearly (I personally even believe _more_ clearly, but that is a matter
of taste) recognizable as titles, because the underlining would no
longer be hidden.

Sincerely,

Luc.

Re: 3 dots vanish at end of filled line

[Richard M. Stallman]

    If this would be unacceptable, then a less radical departure from the
    current Emacs Info situation would be to recognize titles by the top
    of the node pattern:

How about recognizing them based on the number of characters in each
line?  For a title or heading, you have a certain number of characters
of text, and the following line has the same number of characters, all
the same, and they are one of the fixed set used for "underlining".

If filling leaves an ellipsis on a line by itself, the previous
line will be a lot more than 3 characters long.  So this criterion
will not match.

This criterion should work both for node titles
and for headings in the middle of a node.

Re: 3 dots vanish at end of filled line

[Stefan Monnier]

> How about recognizing them based on the number of characters in each
> line?  For a title or heading, you have a certain number of characters
> of text, and the following line has the same number of characters, all
> the same, and they are one of the fixed set used for "underlining".

And to avoid the "box bottom" problem, we could additionally check that the
text is preceded by an empty line.


        Stefan

Re: 3 dots vanish at end of filled line

[Richard M. Stallman]

    And to avoid the "box bottom" problem, we could additionally check that the
    text is preceded by an empty line.

It was hard for me to figure out what the "box bottom" problem means,
and I still am not quite sure.  Do you mean text like this?

    =============
    =  foo bar  =
    =============

If that is written inside @example, it will come out indented.
Thus, it is enough not to highlight lines of ='s that are indented.

Re: 3 dots vanish at end of filled line

[Robert J. Chassell]

   ... There should not be whitespace before an ellipsis in English
   text.

The Chicago Manual of Style, 13th Edition, 1982, shows whitespace
before an ellipsis in all examples.

The manual discusses two methods, one of which the University of
Chicago Press prefers.  In both methods, there is whitespace before an
ellipsis.

The preferred method incorporates other punctuation as needed:

    Other punctuation may be used on either side of the three ellipsis
    dots if it helps the sense or better shows what has been omitted.
    [10.41]

    When four dots indicate the omission at the end of a sentence, the
    first dot is the period--that is, there is no space between it and the
    preceding word [but there is after it].
    [10.42]

The other method uses an ellipsis only, in all situations.

Here is how the makeinfo in texinfo-4.8 formats ellipsis:

    1.  Without space, here are three dots@dots{}
        Without space, here are three dots...

    2.  With space, here are three dots @dots{}
        With space, here are three dots ...

    3.  Without space, here is a period and three dots.@dots{}
        Without space, here is a period and three dots....

    4.  With space, here is a period and three dots. @dots{}
        With space, here is a period and three dots. ...

In *info*, if we use the methods preferred by the University of
Chicago Press, the second and third are correct,

Unfortunately, in a printed manual using DVI, in the third example,
the distance between the period and the first ellipsis dot is less
than the spacing between the ellipsis dots.

So to handle both *info* and DVI output, we should adopt the `other'
method and in all situations use three dots only.

Moreover, we should put a space between the word and the @dots{}
command.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: 3 dots vanish at end of filled line

[Richard M. Stallman]

	1.  Without space, here are three dots@dots{}
	    Without space, here are three dots...

	2.  With space, here are three dots @dots{}
	    With space, here are three dots ...

	3.  Without space, here is a period and three dots.@dots{}
	    Without space, here is a period and three dots....

	4.  With space, here is a period and three dots. @dots{}
	    With space, here is a period and three dots. ...

I can go along with #2 for an ellipsis within a sentence, but #4 is
simply too illogical to be borne.

    Unfortunately, in a printed manual using DVI, in the third example,
    the distance between the period and the first ellipsis dot is less
    than the spacing between the ellipsis dots.

The right way to produce output #3 is to use @enddots; it was designed
specifically for that case.  I presume it does not have that problem
of uneven spacing.

The ellipses which M-e should stop at are those at the end of a
sentence.  If people use this convention carefully, they will
use four dots.  So sentence-end should match four dots, followed
by whitespace.

In Texinfo mode, it should also treat any use of @enddots{}
as the end of a sentence.  Can someone try to set that up?

Re: 3 dots vanish at end of filled line

[Robert J. Chassell]

    The right way to produce output #3 is to use @enddots; it was designed
    specifically for that case.  I presume it does not have that problem
    of uneven spacing.

I had forgot about @enddots.  Sadly, it is not usable in texinfo 4.8.

@enddots does not work in DVI.  Using texi2dvi, the command produces
only three dots on its own.  The spacing is wrong if you add a period.

(I have not checked the other usual output formats, HTML, PostScript,
PDF, and plain text.  If it fails in one output format, the command
fails Texinfo.)

In DVI, we see:

 1. Without space, here is @enddots{}...

 2. With space, here is @enddots{} ...

Note that both show only three dots.

When you do put a period in front of the @enddots{} command, the
spacing between the period and the ellipsis is different than the
spacing within the ellipsis.

(Also, the example in texinfo.txi,v 1.128 2004/12/29 15:06:41, which
came with Texinfo 4.8 fails using texi2dvi; it shows only three dots.
The Info output shows four.)

Here is the Texinfo source:

   Without space, here is @@enddots@{@}.@enddots{}

In *info*, this procedure gives us five dots, like this:

    Without space, but with a period first, here is @enddots{}.....

(The DVI output shows four dots, with wrong spacing.)

The without-space and no period Info option works, as seen here in *info*:

    Without space, no period, here is @enddots{}....

    With space, no period, here is @enddots{} ...

The without-space, no-period option is OK for *info*.  In Info, it
produced what we hope to see: four dots, equal spacing between them,
no space between the end of the last word and the period.  But, as I
said, the command cannot be used in Texinfo, since it fails another
output format.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: 3 dots vanish at end of filled line

[Richard M. Stallman]

One issue with @enddots is that the recommended way to use @enddots
should also qualify as an end-of-sentence.

One idea that occurs to me is that you should write `@enddots{.}',
with a period in the argument.  That period would be ignored by the
command, but using it will make this look like end-of-sentence to
Emacs.  In this test case,

	Foo@enddots{.}  Bar.

both M-e and M-a recognize the sentence end in the middle.

It's possible that use of the period there requires no change in
either texinfo.tex or makeinfo--only a change in the manual.

Karl, what do you think?

Re: 3 dots vanish at end of filled line

[Robert J. Chassell]

   One idea that occurs to me is that you should write `@enddots{.}',
   with a period in the argument.  

Using Texinfo 4.8, that looks fine in *info*, but not in DVI as viewed
with xpdf.

In DVI, there is less space between the last two dots (dots two and
three of the ellipsis) than the period and the first dot of the
ellipsis and between dots one and two of the ellipsis.  (I did not
expect this!  It looks to me to be a side effect of the \hfil in the
@dots{} command from which @enddots{} is derived.)

In Texinfo. 

    Without space, but with a period between braces, @@enddots@{.@}, and
    some more words to push everything over@enddots{.}  And then more
    words.

In Info:

    Without space, but with a period between braces, @enddots{.}, and
    some more words to push everything over.....  And then more words.

In DVI (except the width difference is less than shown here):

    Without space, but with a period between braces, @enddots{.}, and
    some more words to push everything over. . . ..  And then more words.

As is, M-e and M-a work successfully both with Texinfo and with Info.

Unless the bug with TeX output is fixed, the suggestion cannot be used.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: 3 dots vanish at end of filled line

[Juri Linkov]

> In Texinfo mode, it should also treat any use of @enddots{}
> as the end of a sentence.  Can someone try to set that up?

The following patch does that:

Index: lisp/textmodes/texinfo.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/textmodes/texinfo.el,v
retrieving revision 1.111
diff -c -r1.111 texinfo.el
*** lisp/textmodes/texinfo.el	31 Aug 2005 10:32:55 -0000	1.111
--- lisp/textmodes/texinfo.el	20 Oct 2005 09:08:10 -0000
***************
*** 593,598 ****
--- 593,608 ----
  	(concat "\b\\|@[a-zA-Z]*[ \n]\\|" paragraph-separate))
    (make-local-variable 'paragraph-start)
    (setq paragraph-start (concat "\b\\|@[a-zA-Z]*[ \n]\\|" paragraph-start))
+   ;; Append a copy of `sentence-end' where [.?!] is replaced with @(end)dots{}
+   ;; to the default value of `sentence-end'.
+   (make-local-variable 'sentence-end)
+   (setq sentence-end (concat (sentence-end) "\\|"
+ 			     (if sentence-end-without-period "\\w  \\|")
+ 			     "\\(@\\(end\\)?dots{}[]\"'\xd0c9\x5397d)}]*"
+ 			     (if sentence-end-double-space
+ 				 "\\($\\| $\\|\t\\|  \\)" "\\($\\|[\t ]\\)")
+ 			     "\\|[" sentence-end-without-space "]+\\)"
+ 			     "[ \t\n]*"))
    (make-local-variable 'adaptive-fill-mode)
    (setq adaptive-fill-mode nil)
    (make-local-variable 'fill-column)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: 3 dots vanish at end of filled line

[Richard M. Stallman]

I think this is a cleaner way to implement what Texinfo mode needs.
Does it work?

*** paragraphs.el	06 Aug 2005 14:38:37 -0400	1.79
--- paragraphs.el	20 Oct 2005 18:52:37 -0400	
***************
*** 159,178 ****
    :group 'paragraphs
    :type '(choice regexp (const :tag "Use default value" nil)))
  
  (defun sentence-end ()
    "Return the regexp describing the end of a sentence.
  
  This function returns either the value of the variable `sentence-end'
  if it is non-nil, or the default value constructed from the
! variables `sentence-end-double-space', `sentence-end-without-period'
! and `sentence-end-without-space'.  The default value specifies
! that in order to be recognized as the end of a sentence, the
! ending period, question mark, or exclamation point must be
! followed by two spaces, unless it's inside some sort of quotes or
! parenthesis.  See Info node `(elisp)Standard Regexps'."
    (or sentence-end
        (concat (if sentence-end-without-period "\\w  \\|")
!               "\\([.?!][]\"'\xd0c9\x5397d)}]*"
                (if sentence-end-double-space
                    "\\($\\| $\\|\t\\|  \\)" "\\($\\|[\t ]\\)")
                "\\|[" sentence-end-without-space "]+\\)"
--- 159,185 ----
    :group 'paragraphs
    :type '(choice regexp (const :tag "Use default value" nil)))
  
+ (defcustom sentence-end-base "\\([.?!][]\"'\xd0c9\x5397d)}]*"
+   "*Regexp matching the basic end of a sentence, not including following space."
+   :group 'paragraphs
+   :type 'string
+   :version "22.1")
+ 
  (defun sentence-end ()
    "Return the regexp describing the end of a sentence.
  
  This function returns either the value of the variable `sentence-end'
  if it is non-nil, or the default value constructed from the
! variables `sentence-end-base', `sentence-end-double-space',
! `sentence-end-without-period' and `sentence-end-without-space'.
! 
! The default value specifies that in order to be recognized as the
! end of a sentence, the ending period, question mark, or exclamation point
! must be followed by two spaces, with perhaps some closing delimiters
! in between.  See Infonode `(elisp)Standard Regexps'."
    (or sentence-end
        (concat (if sentence-end-without-period "\\w  \\|")
! 	      sentence-end-base
                (if sentence-end-double-space
                    "\\($\\| $\\|\t\\|  \\)" "\\($\\|[\t ]\\)")
                "\\|[" sentence-end-without-space "]+\\)"
*** texinfo.el	01 Sep 2005 01:53:14 -0400	1.111
--- texinfo.el	20 Oct 2005 18:54:35 -0400	
***************
*** 593,598 ****
--- 593,601 ----
  	(concat "\b\\|@[a-zA-Z]*[ \n]\\|" paragraph-separate))
    (make-local-variable 'paragraph-start)
    (setq paragraph-start (concat "\b\\|@[a-zA-Z]*[ \n]\\|" paragraph-start))
+   (make-local-variable 'sentence-end-base)
+   (setq sentence-end-base
+ 	"\\(\\(@\\(end\\)?dots{}\\|[.?!]\\)[]\"'\xd0c9\x5397d)}]*"
    (make-local-variable 'adaptive-fill-mode)
    (setq adaptive-fill-mode nil)
    (make-local-variable 'fill-column)

Re: 3 dots vanish at end of filled line

[Juri Linkov]

> I think this is a cleaner way to implement what Texinfo mode needs.
> Does it work?

There is a dangling opening paren in the default value of sentence-end-base.
I think it is not good to break the grouping construct by moving its
opening paren to sentence-end-base, and leaving the closing paren
in sentence-end.  (Also there were two typos: missing space in `Info
node' and one missing Lisp paren in texinfo.el.)  With the following
fix to your patch I can confirm that it works:

*** emacs/lisp/textmodes/paragraphs.el.orig	Fri Oct 21 14:52:52 2005
--- emacs/lisp/textmodes/paragraphs.el	Fri Oct 21 14:54:09 2005
***************
*** 159,165 ****
    :group 'paragraphs
    :type '(choice regexp (const :tag "Use default value" nil)))
  
! (defcustom sentence-end-base "\\([.?!][]\"'\xd0c9\x5397d)}]*"
    "*Regexp matching the basic end of a sentence, not including following space."
    :group 'paragraphs
    :type 'string
--- 159,165 ----
    :group 'paragraphs
    :type '(choice regexp (const :tag "Use default value" nil)))
  
! (defcustom sentence-end-base "[.?!][]\"'\xd0c9\x5397d)}]*"
    "*Regexp matching the basic end of a sentence, not including following space."
    :group 'paragraphs
    :type 'string
***************
*** 176,185 ****
  The default value specifies that in order to be recognized as the
  end of a sentence, the ending period, question mark, or exclamation point
  must be followed by two spaces, with perhaps some closing delimiters
! in between.  See Infonode `(elisp)Standard Regexps'."
    (or sentence-end
        (concat (if sentence-end-without-period "\\w  \\|")
! 	      sentence-end-base
                (if sentence-end-double-space
                    "\\($\\| $\\|\t\\|  \\)" "\\($\\|[\t ]\\)")
                "\\|[" sentence-end-without-space "]+\\)"
--- 176,185 ----
  The default value specifies that in order to be recognized as the
  end of a sentence, the ending period, question mark, or exclamation point
  must be followed by two spaces, with perhaps some closing delimiters
! in between.  See Info node `(elisp)Standard Regexps'."
    (or sentence-end
        (concat (if sentence-end-without-period "\\w  \\|")
! 	      "\\(" sentence-end-base
                (if sentence-end-double-space
                    "\\($\\| $\\|\t\\|  \\)" "\\($\\|[\t ]\\)")
                "\\|[" sentence-end-without-space "]+\\)"

*** emacs/lisp/textmodes/texinfo.el.orig	Fri Oct 21 14:52:59 2005
--- emacs/lisp/textmodes/texinfo.el	Fri Oct 21 14:54:09 2005
***************
*** 595,601 ****
    (setq paragraph-start (concat "\b\\|@[a-zA-Z]*[ \n]\\|" paragraph-start))
    (make-local-variable 'sentence-end-base)
    (setq sentence-end-base
! 	"\\(\\(@\\(end\\)?dots{}\\|[.?!]\\)[]\"'\xd0c9\x5397d)}]*"
    (make-local-variable 'adaptive-fill-mode)
    (setq adaptive-fill-mode nil)
    (make-local-variable 'fill-column)
--- 595,601 ----
    (setq paragraph-start (concat "\b\\|@[a-zA-Z]*[ \n]\\|" paragraph-start))
    (make-local-variable 'sentence-end-base)
    (setq sentence-end-base
! 	"\\(@\\(end\\)?dots{}\\|[.?!]\\)[]\"'\xd0c9\x5397d)}]*")
    (make-local-variable 'adaptive-fill-mode)
    (setq adaptive-fill-mode nil)
    (make-local-variable 'fill-column)

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: 3 dots vanish at end of filled line

[Richard M. Stallman]

    There is a dangling opening paren in the default value of sentence-end-base.
    I think it is not good to break the grouping construct by moving its
    opening paren to sentence-end-base, and leaving the closing paren
    in sentence-end.

I agree.  Thanks.