What is normal these days (display.texi)?

What is normal these days (display.texi)?

[Kim F. Storm]

In display.texi (formatted version) we have this:

|                                            Normally, a `$' in the
| rightmost column of the window indicates truncation; a `\' on the
| rightmost column indicates a line that "wraps" onto the next line,
| which is also called "continuing" the line.  (The display table can
| specify alternative indicators; see *Note Display Tables.)
|
|    On a graphical display, the `$' and `\' indicators are replaced with
| arrow images displayed in the window fringes (*note Fringes).


"Normally" ?

I suggest changing it to:


|                                             Normally, tiny arrow images
| are displayed in the window fringes to indicate truncated and continued
| lines (*note Fringes).
|  
|    On a text terminal, a `$' in the rightmost column of the window
| indicates truncation; a `\' on the rightmost column indicates a
| continued line that "wraps" onto the next line.  (The display table can
| specify alternative indicators; see *Note Display Tables.)

--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: What is normal these days (display.texi)?

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

storm@cua.dk (Kim F. Storm) writes:

> In display.texi (formatted version) we have this:
>
> |                                            Normally, a `$' in the
> | rightmost column of the window indicates truncation; a `\' on the
> | rightmost column indicates a line that "wraps" onto the next line,
> | which is also called "continuing" the line.  (The display table can
> | specify alternative indicators; see *Note Display Tables.)
> |
> |    On a graphical display, the `$' and `\' indicators are replaced with
> | arrow images displayed in the window fringes (*note Fringes).
>
> "Normally" ?
>
> I suggest changing it to:
>
> |                                             Normally, tiny arrow images
> | are displayed in the window fringes to indicate truncated and continued
> | lines (*note Fringes).
> |  
> |    On a text terminal, a `$' in the rightmost column of the window
> | indicates truncation; a `\' on the rightmost column indicates a
> | continued line that "wraps" onto the next line.  (The display table can
> | specify alternative indicators; see *Note Display Tables.)

Actually, I am currently on and off on a rampage through display.texi,
and my changes include the following (which is enough to do the trick
in my book):


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 1376 bytes --]

Index: display.texi
===================================================================
RCS file: /sources/emacs/emacs/lispref/display.texi,v
retrieving revision 1.223
diff -u -r1.223 display.texi
*** display.texi	13 Jun 2006 22:18:06 -0000	1.223
--- display.texi	7 Jul 2006 09:14:02 -0000
***************
*** 130,136 ****
    When a line of text extends beyond the right edge of a window, the
  line can either be continued on the next screen line, or truncated to
  one screen line.  The additional screen lines used to display a long
! text line are called @dfn{continuation} lines.  Normally, a @samp{$} in
  the rightmost column of the window indicates truncation; a @samp{\} on
  the rightmost column indicates a line that ``wraps'' onto the next line,
  which is also called @dfn{continuing} the line.  (The display table can
--- 131,139 ----
    When a line of text extends beyond the right edge of a window, the
  line can either be continued on the next screen line, or truncated to
  one screen line.  The additional screen lines used to display a long
! text line are called @dfn{continuation} lines.
! 
!   On a text terminal, a @samp{$} in
  the rightmost column of the window indicates truncation; a @samp{\} on
  the rightmost column indicates a line that ``wraps'' onto the next line,
  which is also called @dfn{continuing} the line.  (The display table can

[-- Attachment #3: Type: text/plain, Size: 52 bytes --]



-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

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

Re: What is normal these days (display.texi)?

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> ! text line are called @dfn{continuation} lines.
> ! 
> !   On a text terminal, a @samp{$} in

Looks good.

Could you show us the other changes you have to display.texi?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: What is normal these days (display.texi)?

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
>> ! text line are called @dfn{continuation} lines.
>> ! 
>> !   On a text terminal, a @samp{$} in
>
> Looks good.
>
> Could you show us the other changes you have to display.texi?

I've not gotten far as to yet.  Here is what I have so far:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 4302 bytes --]

Index: display.texi
===================================================================
RCS file: /sources/emacs/emacs/lispref/display.texi,v
retrieving revision 1.223
diff -u -r1.223 display.texi
*** display.texi	13 Jun 2006 22:18:06 -0000	1.223
--- display.texi	7 Jul 2006 15:49:43 -0000
***************
*** 55,62 ****
  This function clears and redisplays all visible frames.
  @end deffn
  
!   This function calls for redisplay of certain windows, the next time
! redisplay is done, but does not clear them first.
  
  @defun force-window-update &optional object
  This function forces redisplay of some or all windows.  If
--- 55,62 ----
  This function clears and redisplays all visible frames.
  @end deffn
  
!   The following function redisplays certain windows without clearing
! them first:
  
  @defun force-window-update &optional object
  This function forces redisplay of some or all windows.  If
***************
*** 66,75 ****
  omitted), it forces redisplay of all windows.
  @end defun
  
!   Processing user input takes absolute priority over redisplay.  If you
! call these functions when input is available, they do nothing
! immediately, but a full redisplay does happen eventually---after all the
! input has been processed.
  
    Normally, suspending and resuming Emacs also refreshes the screen.
  Some terminal emulators record separate contents for display-oriented
--- 66,76 ----
  omitted), it forces redisplay of all windows.
  @end defun
  
!   For all of those functions, processing user input takes absolute
! priority over redisplay.  If you call these functions when input is
! available or being processed, they do nothing immediately, but a full
! redisplay does happen eventually---after all the input has been
! processed.
  
    Normally, suspending and resuming Emacs also refreshes the screen.
  Some terminal emulators record separate contents for display-oriented
***************
*** 111,117 ****
  @tindex redisplay-dont-pause
  @defvar redisplay-dont-pause
  If this variable is non-@code{nil}, pending input does not
! prevent or halt redisplay; redisplay occurs, and finishes,
  regardless of whether input is available.
  @end defvar
  
--- 112,118 ----
  @tindex redisplay-dont-pause
  @defvar redisplay-dont-pause
  If this variable is non-@code{nil}, pending input does not
! prevent or halt redisplay; redisplay occurs and finishes
  regardless of whether input is available.
  @end defvar
  
***************
*** 130,136 ****
    When a line of text extends beyond the right edge of a window, the
  line can either be continued on the next screen line, or truncated to
  one screen line.  The additional screen lines used to display a long
! text line are called @dfn{continuation} lines.  Normally, a @samp{$} in
  the rightmost column of the window indicates truncation; a @samp{\} on
  the rightmost column indicates a line that ``wraps'' onto the next line,
  which is also called @dfn{continuing} the line.  (The display table can
--- 131,139 ----
    When a line of text extends beyond the right edge of a window, the
  line can either be continued on the next screen line, or truncated to
  one screen line.  The additional screen lines used to display a long
! text line are called @dfn{continuation} lines.
! 
!   On a text terminal, a @samp{$} in
  the rightmost column of the window indicates truncation; a @samp{\} on
  the rightmost column indicates a line that ``wraps'' onto the next line,
  which is also called @dfn{continuing} the line.  (The display table can
***************
*** 142,148 ****
  
    Note that continuation is different from filling; continuation happens
  on the screen only, not in the buffer contents, and it breaks a line
! precisely at the right margin, not at a word boundary.  @xref{Filling}.
  
  @defopt truncate-lines
  This buffer-local variable controls how Emacs displays lines that extend
--- 145,152 ----
  
    Note that continuation is different from filling; continuation happens
  on the screen only, not in the buffer contents, and it breaks a line
! precisely at the right margin, not at a word boundary.  @xref{Filling},
! @ref{Longlines,, Long Lines Mode, emacs, The GNU Emacs Manual}.
  
  @defopt truncate-lines
  This buffer-local variable controls how Emacs displays lines that extend

[-- Attachment #3: Type: text/plain, Size: 52 bytes --]



-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

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

Re: What is normal these days (display.texi)?

[Richard Stallman]

    ***************
    *** 111,117 ****
      @tindex redisplay-dont-pause
      @defvar redisplay-dont-pause
      If this variable is non-@code{nil}, pending input does not
    ! prevent or halt redisplay; redisplay occurs, and finishes,
      regardless of whether input is available.
      @end defvar

    --- 112,118 ----
      @tindex redisplay-dont-pause
      @defvar redisplay-dont-pause
      If this variable is non-@code{nil}, pending input does not
    ! prevent or halt redisplay; redisplay occurs and finishes
      regardless of whether input is available.
      @end defvar

The existing text is correct; those commas are necessary.

	Note that continuation is different from filling; continuation happens
      on the screen only, not in the buffer contents, and it breaks a line
    ! precisely at the right margin, not at a word boundary.  @xref{Filling},
    ! @ref{Longlines,, Long Lines Mode, emacs, The GNU Emacs Manual}.

That doesn't seem like proper Texinfo usage; is it?

Re: What is normal these days (display.texi)?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> 	Note that continuation is different from filling; continuation happens
>       on the screen only, not in the buffer contents, and it breaks a line
>     ! precisely at the right margin, not at a word boundary.  @xref{Filling},
>     ! @ref{Longlines,, Long Lines Mode, emacs, The GNU Emacs Manual}.
>
> That doesn't seem like proper Texinfo usage; is it?

What's wrong with it?  As far as I can see, it is following the specs
to the letter, and it works.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What is normal these days (display.texi)?

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Sat, 08 Jul 2006 10:31:48 +0200
> Cc: emacs-devel@gnu.org, storm@cua.dk
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> > 	Note that continuation is different from filling; continuation happens
> >       on the screen only, not in the buffer contents, and it breaks a line
> >     ! precisely at the right margin, not at a word boundary.  @xref{Filling},
> >     ! @ref{Longlines,, Long Lines Mode, emacs, The GNU Emacs Manual}.
> >
> > That doesn't seem like proper Texinfo usage; is it?
> 
> What's wrong with it?  As far as I can see, it is following the specs
> to the letter, and it works.

Perhaps this small modification is better:

       Note that continuation is different from filling; continuation happens
       on the screen only, not in the buffer contents, and it breaks a line
     ! precisely at the right margin, not at a word boundary.  @xref{Filling},
     ! and @ref{Longlines,, Long Lines Mode, emacs, The GNU Emacs Manual}.
       ^^^

Re: What is normal these days (display.texi)?

[Richard Stallman]

    Perhaps this small modification is better:

	   Note that continuation is different from filling; continuation happens
	   on the screen only, not in the buffer contents, and it breaks a line
	 ! precisely at the right margin, not at a word boundary.  @xref{Filling},
	 ! and @ref{Longlines,, Long Lines Mode, emacs, The GNU Emacs Manual}.
	   ^^^


That should look better in the TeX output.

Re: What is normal these days (display.texi)?

[Robert J. Chassell]

    >     ! precisely at the right margin, not at a word boundary.
    >     ! @xref{Filling}, @ref{Longlines,, Long Lines Mode, emacs,
    >     ! The GNU Emacs Manual}.
    >
    > That doesn't seem like proper Texinfo usage; is it?

    What's wrong with it?

@ref is for the end of a sentence.

    As far as I can see, it is following the specs to the letter, and
    it works.

No, it is not following the documentation.

    @xref{Filling, , ,emacs, The GNU Emacs Manual}, @ref{Longlines,,
    Long Lines Mode, emacs, The GNU Emacs Manual}.

produces

    *Note Filling: (emacs)Filling, *Note Long Lines Mode:
    (emacs)Longlines.

in Info (and a fairly similar output for DVI).

You need an `and see' before the @ref, since it is without a capital
`S' and in the latter part of a sentence.

Plus, you need to complete the first part of the sentence.
For example:

    @xref{Filling, , ,emacs, The GNU Emacs Manual}, for more
    information; and also see @ref{Longlines,, Long Lines Mode, emacs,
    The GNU Emacs Manual}.

(without the indentation of this example)

The documentation says:

    (texinfo)ref

    `@ref' is nearly the same as `@xref' except that it does not
    generate a `See' in the printed output, just the reference itself.
    This makes it useful as the last part of a sentence.

    ...

(Please bear in mind that the documentation presumes a writer puts an
`and see' or whatever into a reference if needed; my belief is that
most documentation writers do not even notice that, since they learned
the need -- perhaps for a different spoken language -- so early in
their lives.)

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

Re: What is normal these days (display.texi)?

[David Kastrup]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>     >     ! precisely at the right margin, not at a word boundary.
>     >     ! @xref{Filling}, @ref{Longlines,, Long Lines Mode, emacs,
>     >     ! The GNU Emacs Manual}.
>     >
>     > That doesn't seem like proper Texinfo usage; is it?
>
>     What's wrong with it?
>
> @ref is for the end of a sentence.

This is the end of a sentence.

>     As far as I can see, it is following the specs to the letter, and
>     it works.
>
> No, it is not following the documentation.
>
>     @xref{Filling, , ,emacs, The GNU Emacs Manual}, @ref{Longlines,,
>     Long Lines Mode, emacs, The GNU Emacs Manual}.
>
> produces
>
>     *Note Filling: (emacs)Filling, *Note Long Lines Mode:
>     (emacs)Longlines.
>
> in Info

Not here.  Here it produces:

   Note that continuation is different from filling; continuation
happens on the screen only, not in the buffer contents, and it breaks a
line precisely at the right margin, not at a word boundary.  *Note
Filling::, *Note Long Lines Mode: (emacs)Longlines.

(with some of the above invisible, like the "::" and the "Longlines".

> (and a fairly similar output for DVI).
>
> You need an `and see' before the @ref, since it is without a capital
> `S' and in the latter part of a sentence.

But it comes with its own "see", so adding one would make it into
"see see Long Lines Mode".

And the dvi actually looks something like
See section filling, page xxx, section "Long lines" ...

So one would probably just want to add "and", like Eli said.

> Plus, you need to complete the first part of the sentence.
> For example:
>
>     @xref{Filling, , ,emacs, The GNU Emacs Manual}, for more
>     information; and also see @ref{Longlines,, Long Lines Mode, emacs,
>     The GNU Emacs Manual}.
>
> (without the indentation of this example)
>
> The documentation says:
>
>     (texinfo)ref
>
>     `@ref' is nearly the same as `@xref' except that it does not
>     generate a `See' in the printed output, just the reference itself.
>     This makes it useful as the last part of a sentence.

Well, it _does_ add "see" in Emacs' builtin info reader, and I use it
as the last part of a sentence.

I think adding "and" should do the trick here.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What is normal these days (display.texi)?

[Robert J. Chassell]

Today's GNU Emacs CVS snapshot, Sat, 2006 Jul  8  12:11 UTC
GNU Emacs 22.0.50.27 (i686-pc-linux-gnu, GTK+ Version 2.8.18)
started with

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

and with the following evaluated:

    (setq Info-hide-note-references nil)

On evaluating (info "(texinfo)ref"), I do not see a `see' before
`@ref'.  That is because customarily I give
`Info-hide-note-references' a value of nil.

That matches the documentation, which says

    8.6 `@ref'
    ==========

    `@ref' is nearly the same as `@xref' except that it does not generate a
    `See' in the printed output, just the reference itself. 

However, David Kastrup does see `see' plus the reference, not just the
reference itself.  That is because he accepts the default, in which
the value of `Info-hide-note-references' is t.

`describe-variable' on `Info-hide-note-references' (in the plain
vanilla Emacs as described above, after loading `info') says

    Info-hide-note-references is a variable defined in `info.el'.
    Its value is t

    Documentation:
    *If non-nil, hide the tag and section reference in *note and * menu items.
    If value is non-nil but not `hide', also replaces the "*note" with "see".
    If value is non-nil but not t or `hide', the reference section is
    still shown.  
    `nil' completely disables this feature.

This is very interesting.  The format is more variable than I
remembered.  You cannot use `see' in a document that may be output in
various ways.

As David Kastrup says, following Eli, 

    I think adding "and" should do the trick here.

and I agree.

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

Re: What is normal these days (display.texi)?

[Eli Zaretskii]

> Date: Sat, 8 Jul 2006 13:10:41 +0000 (UTC)
> From: "Robert J. Chassell" <bob@rattlesnake.com>
> Cc: 
> 
>     >     ! precisely at the right margin, not at a word boundary.
>     >     ! @xref{Filling}, @ref{Longlines,, Long Lines Mode, emacs,
>     >     ! The GNU Emacs Manual}.
>     >
>     > That doesn't seem like proper Texinfo usage; is it?
> 
>     What's wrong with it?
> 
> @ref is for the end of a sentence.

No, it isn't.  It's for _any_ kind of situation where the leading
`see' in the printed manual might be inappropriate.  It's true that
such situations frequently happen at the end of a sentence, but saying
that @ref is _only_ for the end of a sentence (and that there should
be a mandatory `see' before it) is limiting its use for no good
reason.

> The documentation says:
> 
>     (texinfo)ref
> 
>     `@ref' is nearly the same as `@xref' except that it does not
>     generate a `See' in the printed output, just the reference itself.
>     This makes it useful as the last part of a sentence.

This text was somewhat misleading.  That's why I suggested (and I
think Karl accepted) to change it as follows:

    Sometimes, `See' or `see' before a reference is not what you want,
    because there's some other similar word that fits the text better.
    That's when you need @code{@@ref}.  @code{@@ref} is nearly the same as
    @code{@@xref} except that it does not generate a `See' in the printed
    output, just the reference itself.  It also produces a lower-case
    @samp{*note} instead of @samp{*Note}.  These two features make
    @code{@@ref} useful as the last part of a sentence or in the middle of
    a sentence, if you want to replace `see' with something else, or
    remove it altogether.

Note that the rest of the section already refrains from another
misleading recommendation--to add a `see' before each @ref:

    In general, it is best to use @code{@@ref} only when you need some
    word other than ``see'' to precede the reference.  When ``see'' (or
    ``See'') is ok, @code{@@xref} and @code{@@pxref} are preferable.

Re: What is normal these days (display.texi)?

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> !   This function calls for redisplay of certain windows, the next time
> ! redisplay is done, but does not clear them first.
>   
>   @defun force-window-update &optional object
>   This function forces redisplay of some or all windows.  If
> --- 55,62 ----
>   This function clears and redisplays all visible frames.
>   @end deffn
>   
> !   The following function redisplays certain windows without clearing
> ! them first:
>   
>   @defun force-window-update &optional object
>   This function forces redisplay of some or all windows.  If

IMO, the original text (calls for) is more correct.

force-window-update does not force an immediate redisplay -- it simply
marks the window to be updated on the next redisplay (by clearing the
internal "up-to-date" state of the window).

I will update the doc string and lispref to mention this.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: What is normal these days (display.texi)?

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
>> !   This function calls for redisplay of certain windows, the next time
>> ! redisplay is done, but does not clear them first.
>>   
>>   @defun force-window-update &optional object
>>   This function forces redisplay of some or all windows.  If
>> --- 55,62 ----
>>   This function clears and redisplays all visible frames.
>>   @end deffn
>>   
>> !   The following function redisplays certain windows without clearing
>> ! them first:
>>   
>>   @defun force-window-update &optional object
>>   This function forces redisplay of some or all windows.  If
>
> IMO, the original text (calls for) is more correct.

It is somewhat contorted.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What is normal these days (display.texi)?

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
>> !   This function calls for redisplay of certain windows, the next time
>> ! redisplay is done, but does not clear them first.
>>   
>>   @defun force-window-update &optional object
>>   This function forces redisplay of some or all windows.  If
>> --- 55,62 ----
>>   This function clears and redisplays all visible frames.
>>   @end deffn
>>   
>> !   The following function redisplays certain windows without clearing
>> ! them first:
>>   
>>   @defun force-window-update &optional object
>>   This function forces redisplay of some or all windows.  If
>
> IMO, the original text (calls for) is more correct.
>
> force-window-update does not force an immediate redisplay -- it simply
> marks the window to be updated on the next redisplay (by clearing the
> internal "up-to-date" state of the window).
>
> I will update the doc string and lispref to mention this.

Well, if you take a look at the immediately preceding sentence, you'll
find that this distinction is not made anywhere before:

      The function @code{redraw-frame} clears and redisplays the entire
    contents of a given frame (@pxref{Frames}).  This is useful if the
    screen is corrupted.

    @c Emacs 19 feature
    @defun redraw-frame frame
    This function clears and redisplays frame @var{frame}.
    @end defun

      Even more powerful is @code{redraw-display}:

    @deffn Command redraw-display
    This function clears and redisplays all visible frames.
    @end deffn

All of those functions work by _immediately_ clearing the respective
frame or display, and then marking it for redisplay.

So why change the language in the case that is much less conspicuous
(by not clearing the frame) as it does not cause a large blank window
to show while Emacs is busy?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What is normal these days (display.texi)?

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

>     @defun redraw-frame frame
>     @deffn Command redraw-display
>
> All of those functions work by _immediately_ clearing the respective
> frame or display, and then marking it for redisplay.
>
If that is not stated already in the docs, we should fix it.


> So why change the language in the case that is much less conspicuous
> (by not clearing the frame) as it does not cause a large blank window
> to show while Emacs is busy?

The name "force-window-update" (and the original text) 
indicate an immediate action.  But there is no immediate action.

So if a program wants to use, e.g posn-at-x-y, after making changes,
force-window-update is not the right thing to use to make sure the
display matrix is up-to-date.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: What is normal these days (display.texi)?

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
>>     @defun redraw-frame frame
>>     @deffn Command redraw-display
>>
>> All of those functions work by _immediately_ clearing the respective
>> frame or display, and then marking it for redisplay.
>>
> If that is not stated already in the docs, we should fix it.
>
>
>> So why change the language in the case that is much less conspicuous
>> (by not clearing the frame) as it does not cause a large blank window
>> to show while Emacs is busy?
>
> The name "force-window-update" (and the original text) 
> indicate an immediate action.

Uh, do you mean "the original text" proposed by me?  I fail to guess
what version you are referring to now.

> But there is no immediate action.
>
> So if a program wants to use, e.g posn-at-x-y, after making changes,
> force-window-update is not the right thing to use to make sure the
> display matrix is up-to-date.

Well, what would be?  Is there any purpose, anyway, to have
posn-at-x-y work with an updated display matrix that has not even been
displayed?

I think we have to come to grips about what posn-at-x-y is intended
for: for associating events with simulated (or real) clicks, or for
some sort of absolute positioning.  For the first, you probably want
the display matrix corresponding to the current display, for the
second, for the updated display.

Whatever.  I have no idea by now what semantics would be desired, and
how the given functions correspond to that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: What is normal these days (display.texi)?

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

>> The name "force-window-update" (and the original text) 
>> indicate an immediate action.
>
> Uh, do you mean "the original text" proposed by me?  I fail to guess
> what version you are referring to now.

I meant the original doc string for force-window-update.

> Well, what would be?  Is there any purpose, anyway, to have
> posn-at-x-y work with an updated display matrix that has not even been
> displayed?

I was actually thinking about pos-visible-in-window-p.

It may very well make sense to want to know whether point is visible
in a window after some change.  See line-move for an example.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: What is normal these days (display.texi)?

[Richard Stallman]

      one screen line.  The additional screen lines used to display a long
    ! text line are called @dfn{continuation} lines.
    ! 
    !   On a text terminal, a @samp{$} in

Your change makes it correct, but kim's change is better, because
graphical terminals are the usual case nowadays.  It's better to put
the usual case first.