various info cross ref corrections

I spotted some bad cross references in the info files, either typos or
outdated node names.

Has the "Support Modes" node about lazy lock etc in the emacs manual
disappeared, or have I badly missed something?  Assuming it's gone the
patch below to lispref/windows.texi points to lazy-lock.el instead of
the emacs manual.

cd man
patch <man.diff

	* building.texi (Compilation): Cross ref to "Top" node of make.

	* cmdargs.texi (General Variables): Cross ref to "Top" of smtpmail.

	* faq.texi (Setting up a customization file): Period after cross ref.
	(Valid X resources): Cross ref now to emacs "X Resources".
	(Forcing Emacs to iconify itself): Cross ref now to emacs "Frame
	Commands".

	* sending.texi (Mail Sending): Cross ref to "Top" node of smtpmail.
	(Mail Methods): Cross ref to "Top" node of mh-e, and of message.

	* viper.texi (Vi State): Cross ref now to emacs "Regexps".

cd lispref
patch <lispref.diff

	* backups.texi (Auto-Saving): Cross ref now to emacs "Auto Save".

Re: Gtk scrollbar: thumb too short

Owen Taylor wrote:

   What I'm opposed to is having dragging the scrollbar to the bottom
   scroll to the last page of the document, then dragging it _past_
   the bottom overscroll the buffer. I don't think dragging past
   the end is a meaningful feature to have for this widget.

I believe I misunderstood you in my earlier reply.  I believe I
understand it now: you are opposed to the thumb hitting the bottom
while actual scrolling is still possible.

Sincerely,

Luc.

ScanMail Message: To Recipient Match eManager setting and take ac tion.

**************** eManager Notification *****************

The following mail was blocked since it contains sensitive content.

Source mailbox: user42 <at> zip.com.au
Destination mailbox(es): emacs-devel <at> gnu.org
Rule/Policy: Anti-Spam(Para el W32/Bugbear 40 (various))
Action: Quarantine to d:\Trend\SMCF\Quarantine\2003-04-01\01-24-29.5387

Este correo ha sido eliminado por el Antivirus.

******************* End of message *********************

info-look elisp matching

I'd like to propose some matching for the elisp mode support, so
lookups will go to an exact position.

	* info-look.el (emacs-lisp-mode): Add prefix/suffix matching regexps.

*** info-look.el.~1.30.~	Tue Apr  1 08:55:07 2003
--- info-look.el	Tue Apr  1 09:56:52 2003
*************** (info-lookup-maybe-add-help
*** 756,764 ****
  (info-lookup-maybe-add-help
   :mode 'emacs-lisp-mode
   :regexp "[^][()'\" \t\n]+"
!  :doc-spec '(("(emacs)Command Index")
! 	     ("(emacs)Variable Index")
! 	     ("(elisp)Index")))

  (info-lookup-maybe-add-help
   :mode 'lisp-interaction-mode
--- 756,774 ----
  (info-lookup-maybe-add-help
   :mode 'emacs-lisp-mode
   :regexp "[^][()'\" \t\n]+"
!  :doc-spec '(;; Commands with key sequences appear in nodes as `foo' and
!              ;; those without as `M-x foo'.
!              ("(emacs)Command Index"  nil "`\\(M-x[ \t\n]+\\)?" "'")
!              ;; Variables normally appear in nodes as just `foo'.
!              ("(emacs)Variable Index" nil "`" "'")
!              ;; Almost all functions, variables, etc appear in nodes as

cvs head crash in GC

GNU Emacs 21.3.50.30 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2003-03-31 on loiso.podval.org

Program received signal SIGSEGV, Segmentation fault.
0x4207a8d5 in bcopy () from /lib/tls/libc.so.6
(gdb) where
#0  0x4207a8d5 in bcopy () from /lib/tls/libc.so.6
#1  0x0804feee in safe_bcopy (from=0x99390cc "\2649o\b", 
    to=0x99b4458 "\324y\316\bnnimap+mail.podval.org:.imap/lisp/misc", 
    size=504716) at dispnew.c:484
#2  0x0811c7e1 in compact_small_strings () at alloc.c:1641
#3  0x0811f4b3 in gc_sweep () at alloc.c:5069
#4  0x0811e4e4 in Fgarbage_collect () at alloc.c:4302
#5  0x08132254 in Ffuncall (nargs=1, args=0xbfffcbec) at eval.c:2680
#6  0x08131c92 in run_hook_with_args (nargs=1, args=0xbfffcbec, 
    cond=until_failure) at eval.c:2410
#7  0x08131baf in Frun_hook_with_args_until_failure (nargs=1, args=0xbfffcbec)
    at eval.c:2341
#8  0x080eea2e in Fkill_buffer (buffer=880) at buffer.c:1316
#9  0x0813216e in Ffuncall (nargs=2, args=0xbfffcc94) at eval.c:2740
#10 0x0815a144 in Fbyte_code (bytestr=412605412, vector=1, 
    maxdepth=-1073754992) at bytecode.c:709
#11 0x081317ba in Feval (form=136789944) at eval.c:2095
#12 0x0812f2f9 in Fprogn (args=504716) at eval.c:425
#13 0x08132bf7 in unbind_to (count=53, value=405486764) at eval.c:3096
#14 0x0815a196 in Fbyte_code (bytestr=412390308, vector=4, 
    maxdepth=-1073754560) at bytecode.c:730
#15 0x0813245f in funcall_lambda (fun=1217542192, nargs=2, 
    arg_vector=0xbfffcef0) at eval.c:2927
#16 0x0813232e in apply_lambda (fun=1217542192, args=405486812, eval_flag=1)

Re: Gtk scrollbar: thumb too short

Owen Taylor wrote:

   While you may think of the scrollbar as a miniature view of the
   document, it is also presented to the user as a physical control,
   with obvious limits as to how far the scrollbar can be dragged.

I believe that this all boils down to the difference between (1) a
character and (2) a pixel based philosophy.  For efficiency reasons,
Emacs has no choice but to adopt (1).  Given that, it should do it
consistently, otherwise things would become unpredictable.

For (1) the thumb indicates the percentage of total "content"
contained in the part of the buffer that is represented above, on and
below the screen.  I believe that for (2) the thumb indicates how much
more upward and downward scrolling is possible, regardless of how much
extra content that is going to bring into view.

Start with an empty buffer in a window that has room for 60 lines of
regular character size and type:

a NEWLINE b

I believe that according to (1) the thumb should still cover the
entire length of the scrollbar, but according to (2), it should only
cover the top 60/61 of the scrollbar.  That is because there is now
one extra screen line we can scroll down to and according to the
visually based philosophy of (2), that matters.  According to the
character based philosophy of (1), there are no extra characters that
can be brought into view, even though extra scrolling is possible.

Re: Status of MAC/W32/X consolidation -- third major patch committed.

storm <at> cua.dk (Kim F. Storm) writes:

> I have now consolidated the common code related to frame-parameter
> handling from xfns.c, w32fns.c, and macfns.c into frame.c.
> 
> Again, I have only been able to test this on X (under GNU/Linux), so
> there may be some problems compiling (and running) the consolidated
> code on W32 and MAC.  [...]

A few small changes were required to build on Mac OS X with Carbon.  I
have just checked these in.

Re: skeleton.el _ versus <at>

On Mon, 2003-03-31 at 09:40, Stefan Monnier wrote:
> > > The current code allows the following trick:
> > > 
> > > 	"fun f ("  <at>  ")" \n "{" \n _ \n "}"
> > >
> > > such that selecting a region and calling the skeleton will
> > > put the region in the body of the function (because of the _)
> > > and point will be put at the right place for you to enter the
> > > arglist (because of the  <at> ).
> > 
> > This is using skeletons in "region" mode.  I am not changing region
> > mode, or at least I can modify the  <at>  behavior so that it works in region
> > mode this way.
> 
> But I also want point to end up at the "args" position in simple
> insertion which your patch would break.

If you want the point to end at args in "simple insertion", put the _
between the parens.

Your skeleton is a "region-insertion", not a "simple insertion".

You cannot have it both ways.

> I hate such modal interfaces, sorry.

I am sorry.  Get over it.  Modal interfaces are a good thing.

I feel it is now incumbent upon you to propose an alternative patch.

Re: cvs head crash in GC

> From: Sam Steingold <sds <at> gnu.org>
> Date: 31 Mar 2003 19:24:56 -0500
> 
> GNU Emacs 21.3.50.30 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
>  of 2003-03-31 on loiso.podval.org

Someone please change the CVS version to say 21.4.50, now that Emacs
21.3 has been released.

TIA

Re: gdb-ui almosts works in NT

> From: Nick Roberts <nick <at> nick.uklinux.net>
> Date: Mon, 31 Mar 2003 22:04:00 +0100
> 
> The output from the inferior could be sent directly to the input/output buffer
> but the author of this part of the code from gdba.el (Tom Lord?) used cat
> because:
> 
> ;; We want to use comint because it has various nifty and familiar
> ;; features.  We don't need a process, but comint wants one, so create
> ;; a dummy one.

I don't understand why is this important; perhaps someone else does.

> I downloaded Emacs for NT and MinGW for the first time today and this didn't
> seem to be just a problem with gdb-ui.el. `M-x gdb' from gud.el also sent the
> output from the inferior to its own DOS window. Even if `gdb mytest' is run in
> a DOS window (no Emacs) then the inferior outputs to its own DOS window and
> does not seem able to share the window with gdb like in GNU/Linux.

Yes, I suspected that much.  Thanks for verifying.