HDTenEightyP/NetNews huggingface dataset:
From: eirik@elf.tn.cornell.edu (Eirik Fuller)
Newsgroups: gnu.emacs.bug
Subject: core dump in x_io_error_handler
Date: 25 Jan 1993 20:22:12 -0500
Organization: GNUs Not Usenet
Distribution: gnu

The enclosed patch cures a core dump in x_io_error_handler, in emacs
18.59 under SunOS 4.1.3.  The core dump occurs with the command line
"emacs <&-" (assuming a suitable choice of shell, i.e. bash or sh).
This core dump occurs only when emacs is running as an X client.


*** x11term.c~	Sat Oct 24 00:31:56 1992
--- x11term.c	Sat Jan 23 21:52:27 1993
***************
*** 2100,2121 ****
--- 2100,2123 ----
  x_init_1 ()
  {
  #ifdef F_SETOWN
  	extern int old_fcntl_owner;
  #endif
  
+ 	if (ConnectionNumber(XXdisplay) != 0) {
  	dup2 (ConnectionNumber(XXdisplay), 0);
  #ifndef SYSV_STREAMS
  	/* Streams somehow keeps track of which descriptor number
  	   is being used to talk to X.  So it is not safe to substitute
  	   descriptor 0.  But it is safe to make descriptor 0 a copy of it.  */
  	close (ConnectionNumber(XXdisplay));
  	ConnectionNumber(XXdisplay) = 0;	/* Looks a little strange?
  						 * check the def of the macro;
  						 * it is a genuine lvalue */
  #endif
+       }
  
  #ifdef USG
  	setpgrp ();		/* No arguments but equivalent in this case */
  #else
  	setpgrp (0, getpid ());
  #endif /* USG */
From: wohler@sap-ag.DE (Bill Wohler)
Newsgroups: gnu.emacs.bug
Subject: Re: quoted-insert inserts in overwrite-mode
Date: 26 Jan 1993 21:55:52 -0500
Organization: SAP AG  Walldorf, Germany
Distribution: gnu
Reply-To: Bill Wohler <wohler@sap-ag.de>

Martin says:
> I said:
> >i think the design came about because quoted-insert can insert
> >1, 2 or more characters.
> 
> Not!  quoted-insert can insert only one character, although characters
> can be displayed in various ways. 

martin,

  you hit the nail on the head.

  what you said, in other words, is that in overwrite mode, one
  character should be replaced by one character, even with quoted
  insert.  *visibly*, something else might happen.  therefore, in
  overwrite mode, you should be able to go from "hunchen" to
  "h\207nchen" and vice-versa without having to delete any characters.

						--bw
From: karl@owl.HQ.ILeaf.COM
Newsgroups: gnu.emacs.bug
Subject: rmail-output doesn't clear deletion flag
Date: 25 Jan 1993 21:01:46 -0500
Organization: GNUs Not Usenet
Distribution: gnu
Reply-To: karl@hq.ileaf.com

rmail-output-to-rmail-file doesn't clear the deleted attribute in the
saved message.  Thus, if you delete a message in your main rmail file,
then output it to a file foo, run rmail on foo, and then do a save, the
message will be deleted.  If the user goes to the trouble of doing the
save, I can't think of when it would be desirable to have the saved
message deleted.
From: eirik@elf.tn.cornell.edu (Eirik Fuller)
Newsgroups: gnu.emacs.bug
Subject: stdout and stderr
Date: 25 Jan 1993 20:28:31 -0500
Organization: GNUs Not Usenet
Distribution: gnu

In emacs 18.59, correct behavior of child processes depends on emacs
having file descriptors 1 and 2 open.  Otherwise, child_setup closes
one or more of the file descriptors passed to it.

One consequence is that child processes do not work properly in an
emacs process started as "emacs >&- 2>&-".  A shell buffer, for
example, exits immediately because of its input being closed.  If only
one of the file descriptors is closed, as in "emacs >&-", the shell
doesn't exit, but none of its output is visible.

If emacs is running on an ordinary terminal, it is unreasonable to
expect it to work with file descriptors 1 and 2 closed.  However, if
it is running as an X client, it seems reasonable that it should work
properly even if file descriptors 1 and 2 are closed.  As a point of
comparison, xterm works just fine if file descriptors 0, 1, and 2 are
all closed.  The child code xterm uses to map its tty into the
standard file descriptors looks like this:


		    for (i = 0; i <= 2; i++)
			if (i != tty) {
			    (void) close(i);
			    (void) dup(tty);
			}


I don't have a patch which allows emacs child processes to work when
file descriptors 1 and 2 are closed.  I see a few likely alternatives.


1)  Leave it as is, and don't worry about whether it is reasonable to
run emacs with file descriptors 1 and 2 closed.

2)  In the code that allocates a pty or pipe for a child process, check
whether the file descriptors are bigger than 2; if not, dup them until
they are.

3)  Complicate the code in child_setup to handle file descriptors for
in, out, and err which are less than 3.

4)  In the emacs initialization, open file descriptors 1 and 2 if they
are not already open.  Perhaps they could be opened as /dev/null if
they are not already open, or dup'd to something else.


Of these alternatives, the third and fourth seem the most robust.  The
first one doesn't fix the problem, and the second one probably leaves
some cases unfixed.  The problem, in essence, is that child_setup
assumes its arguments never overlap the standard file descriptors.  It
is both possible and (in my opinion) reasonable to violate this
assumption.

If the fourth alternative is chosen, it might be reasonable to
implement it in x_init_1 (which initializes X keyboard input), since
it only seems reasonable to close file descriptors 1 and 2 when emacs
is running as an X client.
From: gamin@ireq-robot.hydro.qc.ca (Martin Boyer)
Newsgroups: gnu.emacs.bug
Subject: Re: quoted-insert inserts in overwrite-mode
Date: 25 Jan 1993 19:57:44 -0500
Organization: Le laboratoire de robotique de l'Institut de recherche
	d'Hydro-Quebec
Distribution: gnu

>>>>> Bill Wohler writes:

>i think the design came about because quoted-insert can insert
>1, 2 or more characters.

Not!  quoted-insert can insert only one character, although characters
can be displayed in various ways.  For example, patches allow
characters with the 8th bit set to be displayed as is, provided the
screen allows it (e.g.  uses an ISO 8859 font).  In general the
'ctl-arrow' variable controls this.

I really don't think the input mode should mess with the way
characters are displayed, and vice-versa.  Those are two orthogonal
concepts which should stay independent.  In my opinion, then,
quoted-insert should NOT overwrite more than one character in
overwrite-mode, regardless of the value of 'ctl-arrow'.

--
Martin Boyer                            mboyer@ireq-robot.hydro.qc.ca
Institut de recherche d'Hydro-Quebec    mboyer@ireq-robot.uucp
Varennes, QC, Canada   J3X 1S1
+1 514 652-8412
From: kgallagh@digi.lonestar.ORG (Kevin Gallagher)
Newsgroups: gnu.emacs.bug
Subject: Re: Emacs problem
Date: 25 Jan 1993 20:50:18 -0500
Organization: DSC Communications Corp, Plano, TX
Distribution: gnu

In article <1jq1clINNqk2@usenet.INS.CWRU.Edu> cb147@cleveland.freenet.edu (David Barzilai) writes:
>I have recently been attempting to use the gnu version of
>emacs but have encountered a major difficulty:  My erase
>character has been interpreted as "delete" rather than
>"backspace."  Please note that my terminal emulation is
>vt102 on my IBM-compatible xt computer.

You did not identify the vt102 emulator you are using, which makes it harder
to respond.

By default, the PC Backspace key transmits a C-h character.  Entering a
CTRL-Backspace key conbination transmits a DEL character, which not too many
people realize.  (The PC Del key does NOT transmit a DEL character, by the
way.)

Emacs, by default, uses the DEL character as an erase character.  When IBM
designed the PC keyboard, it copied the Apple II use of C-h as an erase
character, instead of using DEL, which was becoming the more accepted
character to use.

Digital Equipent uses the DEL character as an erase character in its editors
and its Delete key on its VT terminals (in the same position as the PC
Backspace key is located) generates a DEL character.

The more recent versions of GNU Emacs come with a lisp file called bobcat.el
which switches the GNU Emacs interpretation of C-h and DEL.  It uses the GNU Emacs
keyboard translation table to accomplish this.

Once loaded, GNU Emacs will treat C-h as if a DEL were entered and DEL as if a
C-h were entered.

-- 
----------------------------------------------------------------------------
Kevin Gallagher        kgallagh@digi.lonestar.org OR ...!uunet!digi!kgallagh
DSC Communications Corporation   Addr: MS 152, 1000 Coit Rd, Plano, TX 75075
----------------------------------------------------------------------------
From: tromey@cns.CAltech.EDU (Tom Tromey)
Newsgroups: gnu.emacs.bug
Subject: Re: quoted-insert inserts in overwrite-mode
Date: 25 Jan 1993 21:03:45 -0500
Organization: California Institute of Technology
Distribution: gnu

I think there should definitely be at least an option to make
quoted-insert overwrite in overwrite-mode.  I only ever used
overwrite-mode when I'm editing binaries (eg to change string
constants without recompiling), and I need to preserve the length of
the file exactly.  It is a pain to have to remember to delete an extra
character when I insert a trailing \0.

Tom

--
tromey@cns.caltech.edu
"In a riddle whose answer is chess, what is the only prohibited word?"
I thought a moment and replied, "The word chess".
	-- Jorge Luis Borges
From: shankar@sgi.com (Shankar Unni)
Newsgroups: gnu.emacs.bug
Subject: Re: quoted-insert inserts in overwrite-mode
Date: 25 Jan 1993 21:16:32 -0500
Organization: Silicon Graphics, Inc.
Distribution: gnu

Bill Wohler (wohler@sap-ag.DE) wrote:

>   joe, i think the design came about because quoted-insert can insert
>   1, 2 or more characters.  if quoted-insert overwrote, then if i had
>   the word "hunchen" and i wanted to replace the 'u' with an
>   "u-umlaut", the result would be "h\207en", NOT what i would want.
> 
>   perhaps an alternative design would be for quoted-insert in
>   overwrite mode to overwrite only one character and insert the rest
>   (ie "hunchen" -> "h\207nchen").  richard?

Barry Margolin adds:

> Assuming we get a variant of overwrite mode where quoted-insert overwrites,
> would it be correct for it to overwrite just one character?  If I type C-q
> C-a, the resulting character displays as "^A", so maybe it should overwrite
> two characters.  And if I type C-q 200, the result is "\200", so it should
> presumably replace four characters.

Excuse me? Am I missing something?  This sounds like a major red herring..

Consider the following case: suppose the existing text says:

   h\207nchen

where the \207 is a single character. If you position the cursor on the
\207 in overwrite-mode and type "u", what does the display show now?
hu207nchen or hunchen? It's not like you're replacing 4 characters with 1.
4 *screen positions* maybe, but not characters.

I see no reason why the reverse should not also be true: if you do a
quoted-insert in overwrite-mode, *and if we adopt Joe Wells' definition*, I
don't see that there are any logical contradictions or anomalies. If you
are on the "u" in "hunchen", and type \2074, say, you should get
"h\2074chen", where the single character "\207" has overwritten the "u" and
the "4" has overwritten the "n".

So what the argument boils down to is, as always, "That's how it is done".
--
Shankar Unni				E-Mail:	shankar@sgi.com
Silicon Graphics Inc.			Phone:	+1-415-390-2072
From: woods@elegant.COM (Greg A. Woods)
Newsgroups: gnu.emacs.bug
Subject: Re: quoted-insert inserts in overwrite-mode
Date: 26 Jan 1993 22:22:40 -0500
Organization: Elegant Communications Inc.
Distribution: gnu

In article <9301190312.AA12589@mole.gnu.ai.mit.edu> you write:
>     The correct way to insert characters in overwrite mode is to leave
>     overwrite mode.  The fact that quoted-insert always inserts regardless of
>     whether overwrite mode is active is a BUG.
> 
> No, it is a feature.

I don't really care what you call it (i.e. bug or feature), it is wrong,
i.e. not correct, with fault, etc. etc.; which should be obvious given
the definition:

	In overwrite mode, printing characters typed in replace existing text
	on a one-for-one basis, rather than pushing it to the right.

especially given the normal congruence between self-insert-command and
quoted-insert when not in overwrite mode.

-- 
						Greg A. Woods
woods@Elegant.COM, woods@robohack.UUCP  VE3TCP	ECI & UniForum Canada
+1-416-443-1734 [h]  +1-416-362-XRSA [w]	Toronto, Ontario; CANADA
Political speech and writing are largely the defense of the indefensible-ORWELL
From: wohler@sap-ag.DE (Bill Wohler)
Newsgroups: gnu.emacs.bug
Subject: Re: quoted-insert inserts in overwrite-mode
Date: 22 Jan 1993 21:26:41 -0500
Organization: SAP AG  Walldorf, Germany
Distribution: gnu
Reply-To: Bill Wohler <wohler@sap-ag.de>

> jbw@bigbird.bu.edu (Joe Wells) writes:
> >In article <9301192038.AA15952@mole.gnu.ai.mit.edu> rms@gnu.ai.mit.edu (Richard Stallman) writes:
> >>   This is a feature because it was designed intentionally.
> >>   I can affirm this because I did it.
> >I understood this already.  It is still a bug.  The fact that the bug
> >first occurred in the design rather than in the implementation does not
> >change things.

  joe, i think the design came about because quoted-insert can insert
  1, 2 or more characters.  if quoted-insert overwrote, then if i had
  the word "hunchen" and i wanted to replace the 'u' with an
  "u-umlaut", the result would be "h\207en", NOT what i would want.

  perhaps an alternative design would be for quoted-insert in
  overwrite mode to overwrite only one character and insert the rest
  (ie "hunchen" -> "h\207nchen").  richard?

						--bw
From: me@sunburn.stanford.edu (Martin Frost)
Newsgroups: gnu.emacs.bug
Subject: rmail-get-new-mail bug after rmail file changed by another process
Date: 25 Jan 1993 20:29:04 -0500
Organization: Computer Science Dept., Stanford University
Distribution: gnu
Reply-To: me@cs.stanford.edu

When rmail has to re-read the rmail file from the disk because it has been
changed by another process since last written by the current process, rmail
seems to lose track of the inbox file -- the g command doesn't seem to do
anything at that point, nor does M-x rmail read the inbox.  One has to kill
the buffer, it seems, to get the inbox read (with a fresh buffer created by
a new M-x rmail).

To reproduce the problem:

Read your mail with rmail and save the result.

Start another emacs (as if you walked into another office or went home) and
read your mail with rmail there (if there's no new mail, just alter the
rmail file in any way, such as by adding a label to the last message) and
save the changed rmail file.

Now mail yourself a message.

Go back to the first emacs and try to read the new mail.  It will
say something like "file has changed on disk; OK to re-read from disk?"
Type "yes".

At that point, it will reread the rmail file, but it won't read in any new
mail.  Typing "g" won't read the new mail either.
--
Martin Frost		Computer Science Department, Computer Facilities
Systems Programmer	Stanford University, Stanford, CA  94305-2140
me@CS.Stanford.EDU	(or mfrost@stanford.bitnet)
From: michalj@fuw.EDU.PL (Michal Jankowski)
Newsgroups: gnu.emacs.bug
Subject: Re: quoted-insert inserts in overwrite-mode
Date: 25 Jan 1993 20:37:10 -0500
Organization: Warsaw University Physics Dept.
Distribution: gnu

>>>>> On 19 Jan 1993 21:57:09 -0500, shankar@sgi.com (Shankar Unni) said:

Shankar> Well, strictly speaking, RMS is right: the documentation for
Shankar> "quoted-insert" says:

Shankar>   quoted-insert:
Shankar>   Read next input character and insert it.
Shankar>   Useful for inserting control characters.
Shankar>   You may also type up to 3 octal digits, to insert a character with that code

Shankar> That's "insert it", not "do whatever is appropriate with it according
Shankar> to the minor-mode".

Well, the documentation for self-insert-command is similar:

self-insert-command:
Insert this character.  Prefix arg is repeat-count.

Yet self-insert-command does not insert in overwrite-mode.

Of course, RMS is right: this is a feature, because it was designed
this way. Let's call it a misfeature. 8-)

 Michal
From: barmar@think.com (Barry Margolin)
Newsgroups: gnu.emacs.bug
Subject: Re: quoted-insert inserts in overwrite-mode
Date: 22 Jan 1993 21:50:12 -0500
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: gnu

The answer to this whole issue seems to be that there's no one right
answer.  Perhaps an option variable would be appropriate.

Assuming we get a variant of overwrite mode where quoted-insert overwrites,
would it be correct for it to overwrite just one character?  If I type C-q
C-a, the resulting character displays as "^A", so maybe it should overwrite
two characters.  And if I type C-q 200, the result is "\200", so it should
presumably replace four characters.

But maybe not.  These representations of non-printing characters are only
used within Emacs and a few other utilities.  If you print the files out
the alignment of columns will be wrong, since different control characters
have different effects on output.

This makes me wonder why anyone would use quoted-insert in overwrite mode
in the first place.

My personal complaint about overwrite-mode is the behavior of deletion
commands.  I think they should overwrite whatever they're deleting with
spaces, so that the position of text beyond them isn't affected.  Actually,
what I'd really like is for it to know what used to be there and restore
it.  I often use overwrite-mode for filling in forms that have rows of
underlines, and it would be nice if editing the fields would fill back in
the underlines.

But I'd be satisfied if it just filled in with spaces.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: plyidp@mips.ccc.nottingham.ac.uk (D.Peakall)
Newsgroups: gnu.emacs.bug
Subject: movemail bug?
Date: 21 Jan 1993 18:03:56 -0500
Organization: Nottingham University
Distribution: gnu
Reply-To: "D.Peakall" <plyidp@mips.ccc.nottingham.ac.uk>
Keywords: movemail security

I've been unable to persuade my sysadmin to make the movemail routine
setuid because they believe it will compromise system security.  I
assume that they are referring to the bug that I seem to remember
being described in Clifford Stoll's book `The Cukoo's Egg'.  We have
version 18.58.1 for berkeley unix.  Is this still a problem?

Dale Peakall
plyidp@mips.ccc.nottingham.ac.uk
From: wolfgang@wsrcc.COM (Wolfgang S. Rupprecht)
Newsgroups: gnu.emacs.bug
Subject: Re: quoted-insert inserts in overwrite-mode
Date: 21 Jan 1993 18:24:30 -0500
Organization: W S Rupprecht Computer Consulting, Fremont CA
Distribution: gnu

jbw@bigbird.bu.edu (Joe Wells) writes:
>In article <9301192038.AA15952@mole.gnu.ai.mit.edu> rms@gnu.ai.mit.edu (Richard Stallman) writes:
>>   This is a feature because it was designed intentionally.
>>   I can affirm this because I did it.
>I understood this already.  It is still a bug.  The fact that the bug
>first occurred in the design rather than in the implementation does not
>change things.

I have never found the current operation of "C-q" in overwrite mode
useful.  I always end up follow up the quoted-insert command with a
"C-d". 

On the other hand, its never bothered me enough to bind another
command or hack quoted insert either.  (I doubt I'd ever save the
keystrokes spend in making the changes. ;-))

-wolfgang
-- 
Wolfgang Rupprecht    wolfgang@wsrcc.com (or) decwrl!wsrcc!wolfgang
Snail Mail:           39469 Gallaudet Drive, Fremont, CA 94538-4511
From: gamin@ireq-robot.hydro.qc.ca (Martin Boyer)
Newsgroups: gnu.emacs.bug
Subject: Re: quoted-insert inserts in overwrite-mode
Date: 22 Jan 1993 21:08:31 -0500
Organization: Le laboratoire de robotique de l'Institut de recherche
	d'Hydro-Quebec
Distribution: gnu

I write in French, using ISO 8859-1 alphabet.  The only way I know to
insert accented characters in emacs is with quoted-insert (e.g. C-q
351 for e with acute accent).  I have to agree with Joe that the
current behavior of quoted-insert in overwrite-mode is a bug, or
misfeature if you like.  The important is that is should be changed
for the sake of consistency and usefulness.

--
Martin Boyer                            mboyer@ireq-robot.hydro.qc.ca
Institut de recherche d'Hydro-Quebec    mboyer@ireq-robot.uucp
Varennes, QC, Canada   J3X 1S1
+1 514 652-8412
From: kevin@traffic.den.mmc.com (Kevin Rodgers)
Newsgroups: gnu.emacs.bug
Subject: Re: KB mapping
Date: 21 Jan 1993 18:22:48 -0500
Organization: Martin Marietta Western Internal Systems, Technical Operations
Distribution: gnu

In article <9301201512.AA06053@xyplex.com> engman@dxe.ai.mit.EDU (Dave Engman) writes:
>HELP. I give up. How does one map top function keys and left and right keypads
>on a Sun 4 to emacs functions? If this is non-trivial, can we buy some hand-
>holding time? Thanks.

See lisp/term/sun.el to see how to map the keys, and see src/x11term.c
to see what escape sequences are sent by each key under X11.  You should
make sure sun-esc-bracket is set to t in your ~/.emacs or
lisp/default.el:

;; Enable Sun function key bindings:
(if (string-match "^sun" (getenv "TERM"))
    (setq sun-esc-bracket t))		; see term/sun.el

And also map the escape sequences from within the term- and
window-setup-hook; e.g.:

(setq term-setup-hook
      (function (lambda ()
		  (define-key sun-map "224" 'save-buffers-kill-emacs) ; F1
		  ...
		  (define-key sun-map "232" 'save-buffers-kill-emacs) ; F9
		  )))	


If you want more complete utilization of the keyboard:

Patch stringFuncVal() in src/x11term.c to return escape sequences for
the function keys you're interested in.  The 18.58 sources failed to
translate the XK_F10, XK_Help, XK_Insert, XK_Home, XK_Begin, and XK_End
keysyms (as well as others not mapped to keys on the Sun keyboard).

Then patch term/sun.el to bind those escape sequences to the appropriate
functions.
-- 
Kevin Rodgers				kevin@traffic.den.mmc.com
Martin Marietta MS A16401		(303) 790-3971
116 Inverness Dr. East
Englewood CO 80112 USA			GO BUFFS!
From: t2101fs@sun1.lrz-muenchen.de
Newsgroups: gnu.emacs.bug
Subject: emacs18-58 etc/FTP bug
Date: 25 Jan 1993 21:15:15 -0500
Organization: GNUs Not Usenet
Distribution: gnu

theres a bug in file etc/FTP: none of the sites which are supposed to
carry vms-versions of emacs does have one. where can i get it?
(binaries, not sources)
thank you
From: wam@tfn.COM (Wayne MacLaughlin)
Newsgroups: gnu.emacs.bug
Subject: Losing RMAIL headers
Date: 26 Jan 1993 22:13:12 -0500
Organization: GNUs Not Usenet
Distribution: gnu

Greetings,

I am using RMAIL (emacs 18.57.1) with SCO Unix (3.2 v.2) and am finding
that I lose the subject lines when I send mail.  From within RMAIL
everything appears fine.  I see the following:

To:
Subject:
Reply-to:
--text follows this line--

When I compose and send the mail it looks like this upon receipt.

>From dev2!wam Tue Jan 26 11:42:04 1993
From: wam@tfn.com (Wayne MacLaughlin)
X-Mailer: SCO System V Mail (version 3.2)
To: wam
Date: Tue, 26 Jan 93 11:42:03 EST

To: wam
Subject: test
Reply-to: wam@tfn.com

test


It looks like what I consider to be the RMAIL header gets wrapped by
SCO and the subject doesn't make it into the new header.  We don't
have sendmail, so we are using fakemail to /bin/mail.

My guess is that this should be common on SCO systems.  Has anyone else
seen this?

Thanks.

--------------------------------------------------------------------------
| Wayne MacLaughlin                           Thomson Financial Services |
| wam@tfn.com   			            12 Pittsburgh Street | 
| tfn!wam	                                        Boston, MA 02210 |
| A planet where apes evolved from men?                   (617) 345-2315 |
--------------------------------------------------------------------------