HDTenEightyP/NetNews huggingface dataset:
From: barmar@think.com (Barry Margolin)
Subject: Re: emacs
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: gnu
Date: Wed, 30 Sep 1992 23:57:02 GMT

In article <9209301431.AA04303@bambam.mitre.org> djb@babypuss.mitre.org (David J. Braunegg) writes:
>In the definition of insert-buffer in simple.el, I suggest replacing
>  (interactive "*bInsert buffer: ")
>with
>  (interactive "*BInsert buffer: ")

The interactive "B" code will allow you to specify a nonexistent buffer,
which you don't want for insert-buffer.  You'll at least have to change the
code for insert-buffer to check whether get-buffer returns a buffer or nil,
so it can print an error if the user specifies a nonexistent buffer.
Unfortunately, there's no code character for "existing buffer, defaulting
to previous buffer".

The reason is that the "b" code was designed for C-x b (switch-to-buffer),
which is used both to cycle between two buffers and to create new buffers,
while "B" was designed for C-x k (kill-buffer), which is usually used to
kill the current buffer.  You can't change either one without screwing
thousands of users who have been typing C-x k Return and C-x b Return for
years.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

Newsgroups: gnu.emacs.bug
From: paul@devon.lns.pa.US (Paul Sutcliffe Jr.)
Subject: PROBLEM: Emacs won't startup under X
Reply-To: paul@devon.lns.pa.us (Paul Sutcliffe Jr.)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 28 Sep 1992 00:52:47 GMT

This is with Emacs 18.58.

    Hardware:	no-name 80486/33 ISA clone
    Software:	ESIX 4.0.3a  (System V/386 Release 4 Version 3)
		X11R4 as distributed with ESIX 4.0.3a
		Using TWM as distributed with ESIX 4.0.3a

I am running X from the system console; TCP/IP is not running, as
there is no Ethernet hardware in the system.

Problem:

When using emacs at the console (or any multiscreen; all TERM types
are AT386-UL) everything is fine.

When I attempt to start emacs from within an xterm, the
"emacs: Emacs @ devon" window grid-lines appear.  Then, immediately
after I click to place the window, I get the following error:

XIO:  fatal IO error 14 (Bad address) on X server "devon:0.0"
      after 53 requests (18 known processed) with 0 events remaining.

No core file is produced.  Can anyone provide some insight?

- paul

-- 
INTERNET:  paul@devon.lns.pa.us      |    Why doesn't anything ever
UUCP:      ...!rutgers!devon!paul    |    vanish into THICK air?  --Me

Newsgroups: gnu.emacs.bug
From: pot@fly.cnuce.cnr.it (Francesco Potorti`)
Subject: insert-buffer
Reply-To: pot@cnuce.cnr.it
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 3 Oct 1992 15:05:00 GMT

I believe I saw this patch earlier on this list, but I couldn't trace
it, so I rewrote it myself.  If it will prove to do its job without
any side effects, it would be nice to see it incorporated in emacs
18.59 (if it isn't already).

--- /local/lib/emacs/lisp/simple.el	Sun Dec  1 04:50:54 1991
+++ /users/pot/emacs/simple.el	Sat Oct  3 13:50:43 1992
@@ -654,7 +654,9 @@
   "Insert after point the contents of BUFFER.
 Puts mark after the inserted text.
 BUFFER may be a buffer or a buffer name."
-  (interactive "*bInsert buffer: ")
+  (interactive
+   (list (progn (barf-if-buffer-read-only)
+		(read-buffer "Insert buffer: " (other-buffer) t))))
   (or (bufferp buffer)
       (setq buffer (get-buffer buffer)))
   (let (start end newmark)

		    Francesco Potorti`	| pot@cnuce.cnr.IT (Internet)
				 	| 39369::pot       (DECnet)
					| (39)(50)593203   (voice)

Newsgroups: gnu.emacs.bug
From: jbw@bigbird.bu.edu (Joe Wells)
Subject: running out of memory (was: Back to top level)
Organization: Boston University Computer Science Department
Distribution: gnu
Date: Wed, 7 Oct 1992 02:34:15 GMT

In article <1aq07hINNaj1@wendy-fate.UU.NET> kyle@wendy-fate.uu.net (Kyle Jones) writes:

   If you're unlucky Emacs will trash some of its internal structures,
   continuing to run and emasculate itself for some time before dying.
                         ^^^^^^^^^^

Don't you mean emacsulate?  :-)

-- 
Joe Wells <jbw@cs.bu.edu>
Member of the League for Programming Freedom --- send e-mail for details

Newsgroups: gnu.emacs.bug
From: geuder@informatik.uni-stuttgart.DE (Uwe Geuder)
Subject: Re: Manual enhancement (was: none)
Organization: IPVR, University of Stuttgart, Germany
Distribution: gnu
Date: Thu, 1 Oct 1992 12:48:51 GMT

erich> I think there should be an entry for "wrapping text" in the
erich> "Concept Index" of the Emacs manual.  It should refer to the
erich> discussions of the variables `truncate-lines' and
erich> `truncate-partial-width-windows', since

Seconded! I keep forgetting the names of these variables and they are
hard to find in the manual.  Usually takes me several regexp-searches
through the whole manual.
--
Uwe Geuder, geuder@informatik.uni-stuttgart.de

Newsgroups: gnu.emacs.bug
From: solensky@andr.ub.COM (Frank T. Solensky)
Subject: Bad text after rebuild?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 26 Sep 1992 01:04:37 GMT

I've recently pulled over a good portion of the X software from mit and
rebuilt and installed emacs (v18.58) and am running into some problems with
messages:  when I try to go into "info" (^H i), I get a message along the
lines of "End of file during parsing"; the describe key functions (^H k)
display what appears to be a large number of null characters.

Now I _think_ that this is described in the PROBLEMS file,..

>* Self documentation messages are garbled.
>
>This means that the file `etc/DOC-...' doesn't properly correspond
>with the Emacs executable.  Redumping Emacs and then installing the
>corresponding pair of files should fix the problem.

.. but I'm not sure if messages that appear in the main portion of the display
window is what is meant by the term "self documentation messages" or not.
Also, what is meant by "redump": delete some executable in the src
subdirectory and run "make install" again?  Which files are "the
corresponding pair", and will running "make install" already take care of
this?

I feel pretty bad about sending what is obviously a FAQ, but it's been a
long day and I'm just not parsing this text well at all.

					-- Frank


Newsgroups: gnu.emacs.bug
From: jerry@math.ep.utexas.EDU (Jerry)
Subject: fill-paragraph + undo = buffer modified
Organization: Department of Mathematical Sciences--University of Texas at El Paso
Distribution: gnu
Date: Mon, 28 Sep 1992 21:22:57 GMT

In Emacs 18.58,

    emacs -q nonemptyfile
    M-q
    C-x u

leaves buffer modified.  Same cause as with C-x i?  Also fixed in 19?

-Jerry

Newsgroups: gnu.emacs.bug
From: ramey@ra.CSc.ti.COM (Joe Ramey)
Subject: emacs can lose RMAIL file if system crashes
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 7 Oct 1992 00:11:42 GMT

We're running Emacs version 18.58 on Sun 4s running SunOS 4.1.2.

A few times over the past couple of years I've had users report that
their RMAIL files were truncated when the system on which they were
reading their mail crashed.  They happened to be saving their RMAIL
files at the time that the system crashed.

I read through some of the Emacs lisp code and here's what I think is
happening:

RMAIL mode sets the file-precious-flag for the RMAIL buffer, so when
Emacs saves the RMAIL buffer it first renames it to #RMAIL, then
writes the new version of the buffer to RMAIL.  Suppose the system
crashes during that save.  Then the RMAIL file that exists is a
partial one.  When the system comes back up and the user runs RMAIL
again, Emacs brings in the partial version of the RMAIL file, reads in
the new mail, and saves out this new version of the truncated RMAIL
file.  The #RMAIL is now gone, because the file-precious-flag has
caused it to be overwritten and then deleted, and the RMAIL~ file
contains the original truncated version of the RMAIL file.

I haven't tried to fix the problem yet, but it seems that one fix
would be to write the new version of the RMAIL file under a different
name, say #RMAIL, and only if that write completes should you rename
#RMAIL to RMAIL.  Then if the system should crash in the middle of the
save, the RMAIL file will contain the last complete save of the file.

Is a fix for this problem already available (or am I overlooking
something)?

Joe Ramey
<ramey@csc.ti.com>



Newsgroups: gnu.emacs.bug
From: rudolf@llanda.enet.DEc.COM (Rudi Strasser at the CEC-Vienna)
Subject: Running EMACS(X-Windows version) on VMS
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 1 Oct 1992 08:08:05 GMT

Dear GNU Members,

I have compiled Emacs on a VMS platform but emacs only works in the terminal and 
this is not as comfortable as Emacs is working under Unix. My question is: Is 
there a version of Emacs that runs Emacs in an independent X-Window under VMS.

And if this is so, how can I make Emacs running in X-Windows Mode ?

I am fond of Emacs and it could be question of Life and Death . So please help 
me !! 


Regards,

Rudi Strasser
Campusbased Engineering Center,
Digital Equipment Corporation, Vienna Austria
rudolf@cectuv.enet.dec.com


Newsgroups: gnu.emacs.bug
From: gildea@expo.lcs.mit.edu (Stephen Gildea)
Subject: Re: Potential Bug with Emacs 18.58.1
Organization: X Consortium, MIT Laboratory for Computer Science
Distribution: gnu
Date: Sun, 4 Oct 1992 20:34:53 GMT

				    the meta key apparently acts like 
    'SPC META'.  This is, it inserts a space when depressed before 
    the meta key command sequence executes.

Your X keyboard mappings are wrong.  The key you want to use as Meta
has a keysym of "space" (or something similar).  You can verify this
as follows: run "xmodmap" and look at the "mod1" line of the output.
It ahould contain only keys with names like Meta_L or Alt_R.

The most likely cause of this error is using xmodmap to incorrectly
change the keyboard mapping.  Look for invokations of xmodmap in
your .xsession or other init files.

 < Stephen
   MIT X Consortium

Newsgroups: gnu.emacs.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: rmail/display-time suggestion
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 28 Sep 1992 22:38:16 GMT

If you read your mail with rmail (M-x rmail or by using the "g" command),
it should signal display-time that you no longer have pending mail.
This isn't totally reliable (you could read your mail some other way),
and it's not terribly important, but it would be a nice improvement
if someone were energetic enough to make it.

Newsgroups: gnu.emacs.bug
From: gsw@aloft.ATt.COM
Subject: Emacs bug report
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 25 Sep 1992 20:36:55 GMT

I was running Emacs version 18.57.1 under X-windows and noticed a
problem.  Here is the result of M-x emacs-version:

exptools GNU Emacs 18.57.1 of Tue Dec 17 1991 on bell2 (berkeley-unix)

The problem is this:

-----BEGIN FACTS-----

I added the following lines to my .Xdefaults file:

Emacs*Foreground: Burlywood1
Emacs*Background: black

expecting Emacs to start up (after running xrdb .Xdefaults) in
burlywood on black.  When I restarted Emacs, the cursor color and
pointer colors DID change to burlywood, although the text remained
black on white.

I was eventually able to change the text color, although to do this I
removed the default X settings I had in the same file.  To be precise,
I removed the lines:

*foreground: black
*background: white

from the end of the file.  I first tried moving these two lines to
before the Emacs*Foreground line to see if that worked (it didn't).

-----END FACTS-----
-----BEGIN SPECULATION-----

Perhaps this was meant as a feature, I don't know.  I guess it could
be advertised as one. (?) :-)

Regardless, it is normal for X-windows programs to use the first
resource setting that they find and can match, thus allowing users to
put X application defaults at the end of the .Xdefaults file.

-----END SPECULATION-----

Jerry Williams
gsw@aloft.att.com
(215)439-7237


Newsgroups: gnu.emacs.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: suggestion: M-. and M-, should push point onto the mark ring
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 6 Oct 1992 20:24:23 GMT

In GNU Emacs 18.58.1 of Wed Apr  8 1992 on yoyo (berkeley-unix)

Then if you use the tags commands to chase down a chain of calls,
you can get back to where you were, sort of like the "l" command
in Info.

Newsgroups: gnu.emacs.bug
From: jlewis@cse.ogi.edu (Jeff Lewis)
Subject: Re: evi bug
Organization: Oregon Graduate Institute
Distribution: gnu
Date: Sun, 4 Oct 1992 17:15:58 GMT

ryanr@beethoven.cs.colostate.edu (richard ryan) writes:
>I didn't know if this was an evi bug or not, but in evi I tried to delete
>a suffix with "%s/\.mf//g" and it didn't work ...

Richard:

Thanks for the report.  Apply the following patch to function
ex-scan-addresses.  Alternately, version 0.99, which will incorporate
this patch, is available via e-mail at mail-server@brandx.rain.com.

*** /tmp/,RCSt1a14284	Sun Oct  4 09:58:08 1992
--- evi.el	Sun Oct  4 09:55:29 1992
***************
*** 3296,3302 ****
  (defun ex-scan-addresses ()
    (skip-chars-forward " \t")
    (if (= (following-char) ?%)
!     (cons (cons (cons 'number 1) 0) (cons (cons 'dollar nil) 0))
      (if (looking-at "[-+0-9.$'/?]")
        (cons
  	(ex-scan-address)
--- 3296,3303 ----
  (defun ex-scan-addresses ()
    (skip-chars-forward " \t")
    (if (= (following-char) ?%)
!       (progn (forward-char)
! 	     (cons (cons (cons 'number 1) 0) (cons (cons 'dollar nil) 0)))
      (if (looking-at "[-+0-9.$'/?]")
        (cons
  	(ex-scan-address)

--Jeff

Newsgroups: gnu.emacs.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: find-tag should be able to search for an exact match
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 25 Sep 1992 19:50:43 GMT

There should be a way for meta-. to search for the routine
foo(), without showing foobar(), foobaz(), struct mumble_foo {}, etc.
In a large source tree, M-. can give so many false hits
as to be almost useless.  I don't know whether exact match
should be the default.

Newsgroups: gnu.emacs.bug
From: jkh@esel.UUCP (Jordan K Hubbard)
Subject: 18.58 with X11 support under SCO ODT 2.0?
Organization: Lotus Ireland
Distribution: gnu
Date: Thu, 1 Oct 1992 18:57:54 GMT

Not wanting to get too involved with this (I try to avoid even
standing close to the machine SCO's running on), I compiled 18.58
under SCO ODT 2.0 and noticed that X11 support was hosed - the old
dreaded "Xlib ...  sequence lost" messages indicating that something
had gone wrong with I/O to the xlib connection socket.  I've seen this
previously with other braindead SYSV machines trying to use SIGIO, and
taken the provided SIG_{UN}BLOCK fix, but this is more of a puzzler
since SCO doesn't even use SIGIO.  Like I said, I didn't want to get
too involved with this (and so just compiled emacs without X support
for now), but I'd appreciate it if anyone has a fix for this that I
can just apply and forget that I ever logged into a SCO machine.  Ugh!
I'm getting hives just thinking about the experience.  Ik ik ik ik ik
ik..  Cooties!  I touched it!  I'm diseased!

					Jordan

Newsgroups: gnu.emacs.bug
From: Frank_Ritter@shamo.soar.cs.cmu.edu
Subject: variables in doc-strings
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Sep 1992 10:10:31 GMT

there are ways to put keybindings and such in documentation strings, I
just ran across a place where I would like to put a variable string in
a doc-string.  E.g.,  I would like to put the version number into a
mode's doc string.  Fairly common.  could be done by hand, but prone
to error.

No response is necessary.

Frank Ritter@cs.cmu.edu       best mail drop
      ritter@psy.cmu.edu      my real affiliation
        fr07@andrew.cmu.edu   where the above two point to
(412) 268-2969
(412) 681-5739 (incoming fax)

Newsgroups: gnu.emacs.bug
From: huttar@hp750.ITg.ti.COM (Lars Huttar)
Subject: repeatedly asking whether to re-visit TAGS file
Organization: IEF Development, Texas Instruments Inc., Plano Texas
Distribution: gnu
Date: Tue, 29 Sep 1992 13:31:26 GMT


GNU Emacs 18.58.2 of Sat Jul 25 1992 on hp720a (hpux)

I'm using a tags package maintained by Sam Kendall, apparently
revision 1.13, 6/4/92, which is a modification of the standard
one to include completion etc.  But I've tried this with the
standard tags package and get the same problem.

The problem is this:
When I do a find-tag or something and the TAGS file has been erased,
I get a message "Tags file has changed, read new contents?"
It's debatable whether I should be asked this at all if there is no
tags file (if I say yes I don't get prompted for a new tags file name),
but that's not my main point.
The point is that if I type "no", I get asked the same question again
before it actually does the find-tag.  (For a total of two times.)
Then, the next time I do a find-tag, it asks me again, even though
the tags file hasn't changed since last time I said "no, don't read it
again."
I get the impression the designer didn't think people would type "no"
much at all, which is probably true, but sometimes I do a "make clean"
and I don't want to bother to recreate the tags file right this second.
        Anyway, it seems to me, if you're going to ask the user whether
or not to read in the tags file, you might as well respect their wishes.
Once they say "no", don't ask them again until the tags file changes
again.  If they change their minds, they can always use visit-tags-table.

Thanks for your time,

Lars Huttar

| |    Lars Huttar                          3
 \|/|  huttar@hp750.itg.ti.com      ||   _______           ____      ||
  |    (Opinions herein are not     ||:  |  |  |   |   |   |  |   | :||  Mars
       necessarily those of TI.)    ||  _| _| _|  _|  _|  _| _|  _|  ||

Newsgroups: gnu.emacs.bug
From: djb@babypuss.mitre.org (David J. Braunegg)
Subject: emacs
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 06:31:34 GMT

I would like to suggest a change to insert-buffer.  As it stands now,
the default buffer to be inserted is the current buffer.  In almost 10
years of using Emacs, I have never wanted to insert a buffer into
itself.  With Gnu Emacs, I always need to type a buffer name to
replace the default (current) one supplied.

In the definition of insert-buffer in simple.el, I suggest replacing

  (interactive "*bInsert buffer: ")

with

  (interactive "*BInsert buffer: ")

I have tried this.  It causes the previously selected buffer
(other-buffer), instead of the current buffer, to be supplied as the
default.  9 times out of 10, this is the behavior I want out of
insert-buffer.  If I am working on two buffers, the insertions that I
typically make are from one buffer into the other.

Please let me know what you think about this suggestion.

Thanks,
Dave

Newsgroups: gnu.emacs.bug
From: djb@bambam.ai.mit.EDU (David J. Braunegg)
Subject: Re: emacs
Organization: The MITRE Corporation, Bedford MA
Distribution: gnu
Date: Fri, 2 Oct 1992 13:36:03 GMT

In article <1adeseINNnig@early-bird.think.com> barmar@think.com (Barry Margolin) writes:

>>In the definition of insert-buffer in simple.el, I suggest replacing
>>  (interactive "*bInsert buffer: ")
>>with
>>  (interactive "*BInsert buffer: ")
>
>The interactive "B" code will allow you to specify a nonexistent buffer,
>which you don't want for insert-buffer.  You'll at least have to change the
>code for insert-buffer to check whether get-buffer returns a buffer or nil,
>so it can print an error if the user specifies a nonexistent buffer.


OK, this would be a reasonable change and also keep the changes
minimal.

Or, insert-buffer could be re-written in C instead of elisp.  Then the
default could be the previous buffer and nonexistent buffers could be
handled correctly.  The C programming for this is a little beyond me,
though.



>... the "b" code was designed for C-x b (switch-to-buffer)
>... while "B" was designed for C-x k (kill-buffer) ...
>... You can't change either one without screwing
>thousands of users who have been typing C-x k Return and C-x b Return for
>years.


I agree.  That's why I didn't suggest changing the "b" or "B" codes.
I would just like a more useful insert-buffer.  Changing the
interactive code was the easiest way I saw to do it.

Dave

Newsgroups: gnu.emacs.bug
From: kevin@edscom.demon.co.uk (Kevin Broadey)
Subject: Justification of paragraphs with a fill-prefix is wrong
Reply-To: Kevin Broadey <kbroadey@edscom.demon.co.uk>
Organization: EDS-Scicon, Milton Keynes, UK
Distribution: gnu
Date: Thu, 1 Oct 1992 14:18:10 GMT

Emacs version is 18.57.

I came across this problem while using Barry Warsaw's Supercite 2.2.  I
filled a cited paragraph with justification turned on and it was
justified to the wrong column.  After a bit of digging around I found
the fault was in Emacs' fill.el package.

Reproduce as follows:-

Switch to a buffer in fundamental mode, set a fill column, turn on
auto-fill (for convenience), type in a few letters (eg "xxx> ") and make
this the fill prefix with C-x .

Now type in a few lines of gibberish...

xxx> gibberish gibberish gibberish gibberish gibberish gibberish
xxx> gibberish gibberish gibberish gibberish gibberish gibberish
xxx> gibberish gibberish gibberish gibberish gibberish gibberish
xxx> gibberish gibberish gibberish gibberish gibberish gibberish

Now position point within the paragraph and do M-1 M-q to fill and
justify...

xxx> gibberish   gibberish  gibberish    gibberish     gibberish    gibberish
xxx> gibberish     gibberish  gibberish    gibberish  gibberish     gibberish
xxx> gibberish  gibberish     gibberish  gibberish    gibberish     gibberish
xxx> gibberish gibberish gibberish gibberish gibberish gibberish

I did the above with fill-column set to 72.  It's been justified to
xxx> column 77, which is (+ fill-column (length fill-prefix)).


The fault is in `justify-current-line' in fill.el.  This does a
`narrow-to-region' on the text from the end of the fill prefix to the
end of the line, then pads that out to fill-column.  Hence the extra
characters.

The fix is to change the LET line from:-

    (let (ncols beg)

to:-

    (let ((fill-column (- fill-column (length fill-prefix)))
	  ncols beg)
      (if (< fill-column 1)
          (error "Fill prefix is too long for fill column."))

This compensates for the extra characters on the line.

Kevin

Newsgroups: gnu.emacs.bug