HDTenEightyP/NetNews huggingface dataset:
From: gkb1@chempc1.york.ac.uk (Graham Barlow)
Newsgroups: gnu.gcc.help
Subject: gcc for MSDOS
Date: 23 Jul 92 14:31:15 GMT
Organization: University of York, UK

Sorry for such a naive question, but I am new to all this.

Where can I ftp a copy of gcc to run on a 80486/33 pc
running MSDOS 5.

Thanks, Graham

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Graham Barlow                      Internet gkb1@chempc1.york.ac.uk
NMR Service                              or gkb1@tower.york.ac.uk
Department of Chemistry             JANET   gkb1@uk.ac.york
University of York, UK                                
__________________________________________________________________________________
Newsgroups: gnu.smalltalk.bug
From: rfalanga@triton.unm.edu (Rod Falanga)
Subject: A few questions.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 21 Jul 1992 02:30:12 GMT

Hello,

	I recently got version 1.1 of GNU Smalltalk, which I am attempting to
get going on a DECstation 5000 that is at the place where I work (not at thie
University of New Mexico.)  It has compiled and linked just fine.  I am trying
to learn how to use Smalltalk (I probably will also get GNU C++, but I don't
want to talk about that right now.)  I have _v_e_r_y _l_i_m_i_t_e_d exposure to Smalltalk,
having taken a class on programming languages in the fall in 1991.  We used a
book titled "Programming Languages: An Interpreted Based Approach" by Samual H.
Kamin.  In it, all languages introduced were given using a Lisp like syntax,
including Smalltalk.  So, I don't know how to use a regular Smalltalk
interpreter, like GNU's.  Anyway, some of the questions that I have are very
bone-headed ignorant.  I hope that you will bear with me.

	First of all, how do I execute any of the example .st files that came
with GNU Smalltalk?  

	Do I have to be in the same subdirectory where all of the .st files
are before I get into mst?  For that matter, all of the development that I do
in Smalltalk, (writing of Smalltalk files, not modifications to the
interpreter), do I have to be in the subdirectory where the .st files are?  

	How do you do assignment in Smalltalk?  In books that I've seen (I'm
currently going through Timothy Budd's book "An Introduction to Object-Oriented
Programming", he uses the "<-" sign to indicate assignment.  Is that the way
it's done?  I've determined, looking at your .st files that to indicate that an
instance of an object returns a value by using the "^" sign.

	Do you think that GNU Smalltalk will have a browser anytime soon?

	I'm sorry for all of these bone-head simple questions, but if I don't
ask them, I won't learn.

Rod Falanga


Newsgroups: gnu.smalltalk.bug
From: jf41+@andrew.cmu.edu (Jonathan R. Ferro)
Subject: Bug in mst texinfo file
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 24 Jul 1992 16:40:08 GMT

I downloaded smalltalk-1.1.1.tar.Z from st.cs.uiuc.edu and ran
'makeinfo mst.texinfo' to get information on installing it.  makeinfo
gave me the error:

mst.texinfo:145: `Features' has an Up field of `Introduction', but
`Introduction' has no menu item for `Features'.

On further investigation, it appears the Up field for 'Features' should
be 'Top'.  Fortunately, the information contained in the file was
uncorrupted and I am now happily swimming around in my new programming
environment.

(FYI, this was compiled with -DUSE_READLINE using the 'ds3100' config
target on a DECstation 3100 running Ultrix 4.2A.  It ran perfectly on
the first try.)

--
Jon Ferro		MIT Transportation Modelling Research Center (TMRC)
jf41+@andrew.cmu.edu	"We can hack it!"
SGNTR VRS VRSN 3.1B: Strppd nd cmprssd fr qckr trnsmssn! nfct yrs tdy!

Newsgroups: gnu.smalltalk.bug
From: Steven.Byrne@eng.SUn.COM (Steve Byrne)
Subject: Bug in mst texinfo file
Organization: Gnus Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 16:37:48 GMT

"Jonathan R. Ferro" writes:
 > I downloaded smalltalk-1.1.1.tar.Z from st.cs.uiuc.edu and ran
 > 'makeinfo mst.texinfo' to get information on installing it.  makeinfo
 > gave me the error:
 > 
 > mst.texinfo:145: `Features' has an Up field of `Introduction', but
 > `Introduction' has no menu item for `Features'.
 > 
 > On further investigation, it appears the Up field for 'Features' should
 > be 'Top'.  Fortunately, the information contained in the file was
 > uncorrupted and I am now happily swimming around in my new programming
 > environment.
 > 
 > (FYI, this was compiled with -DUSE_READLINE using the 'ds3100' config
 > target on a DECstation 3100 running Ultrix 4.2A.  It ran perfectly on
 > the first try.)

Thanks for the report!  I tried to fix all of the reference bugs in mst.texinfo
(using makeinfo & friends), but it looks like I missed one.  

Steve


Newsgroups: gnu.emacs.bug
From: shulick@navajo.ucs.indiana.edu (Sam Hulick)
Subject: *SERIOUS* problem.  C-s from home.
Reply-To: shulick@navajo.ucs.indiana.edu
Organization: Vallen Software
Distribution: gnu
Date: Fri, 24 Jul 1992 03:36:40 GMT

Granted, C-s will work from a console..  but from home, Control-S pauses the
screen flow!  So how can we possibly use C-s from home?  There's no possible
way.

-- 
Sam Hulick  ///  E-mail: shulick@indiana.edu (including NeXT mail)
------------------------------------------------------------------------
  "The pen is the mouth and the paper is the soon-to-be-wise one."

Newsgroups: gnu.emacs.bug
From: meggin@epas.utoronto.ca (David Megginson)
Subject: Re: #XXX# file remains after killing modified buffer for XXX
   From: siemens!intime.intime.com!scottm (Scott Michel)
   Date: Fri, 24 Jul 1992 17: 16: 15 GMT
Organization: University of Toronto - EPAS
Distribution: gnu
Date: Mon, 27 Jul 1992 13:55:02 GMT

In article <9207271606.AA04175@beast.mountain> cdr@beast.UUCP (CD Rasmussen) writes:

   What I want to know it: will the GNU project accept the changes if I submit
   them?  Len, RMS, what say you?

I know that #<file># backups left around can be annoying, but dired
mode lets you get rid of them fast enough.  Perhaps the best thing
would be for emacs the offer to delete or restore orphaned backups THE
NEXT TIME IT RUNS.  In any case, I want to be able to keep them --
they've saved my butt quite a few times, and I've been working with
computers since 1978 (fortran on punch cards).


David

--
                 o--------------- ---------------o
                 |...            |meggin@vm.epas.|
                 |.  .avid meggin|utoronto.ca on |
                 |.  .son.centre |the internet.  |
                 |... for mediev |               |
                 |al studies.univ|               |
                 |ersity of toron|  .explicit.   |
                 |to             |               |
                 |       ..meggin|               |
                 o--------------- ---------------o


Newsgroups: gnu.emacs.bug
From: jf41+@andrew.cmu.edu (Jonathan R. Ferro)
Subject: Re: A Bug! (undesired feature??)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 24 Jul 1992 14:34:57 GMT

davis@tonedeaf.lanl.gov (Scott Davis) writes:
> Since the foo and bar are linked, whatever I add to bar should be
> added to foo, but foo is unchanged. Instead, "bar~" (the backup file)
> and foo are linked, and bar is a new file!

This can be fixed by putting "(setq backup-by-copying t)" in your .emacs
file.  It sounds like you discovered this by reading the manual, but I
wasn't sure by the way you described it so I wrote it out explicity
here.  This is usually the second little tweak I give out to help new
users, right after "(setq inhibit-local-variables t)".

Any chance these two changes might become the defaults?

--
Jon Ferro		MIT Transportation Modelling Research Center (TMRC)
jf41+@andrew.cmu.edu	"We can hack it!"
SGNTR VRS VRSN 3.1B: Strppd nd cmprssd fr qckr trnsmssn! nfct yrs tdy!

Newsgroups: gnu.emacs.bug
From: nickel@cs.tu-berlin.DE (Juergen Nickelsen)
Subject: Save *scratch* on exit (Was Re: #XXX# file remains ...)
Followup-To: gnu.emacs.help
Reply-To: nickel@cs.tu-berlin.de
Organization: STONE Project, Technical University of Berlin, Germany
Distribution: gnu
Date: Sun, 26 Jul 1992 14:28:53 GMT

In article <DODD.92Jul25114245@mycenae.cchem>
dodd@mycenae.cchem.berkeley.edu (Lawrence R. Dodd) writes:

> On a related issue, I think someone a while back asked how one can
> get emacs to ask the user about saving *scratch* buffers when
> exiting emacs.  Right now standard emacs just wipes them is there a
> way to get it to attach some importance to *scratch* buffers?  Just
> a simple "save buffer to disk?" would be nice.

Put the following into your ~/.emacs:

(save-excursion
  (set-buffer "*scratch*")
  (setq buffer-file-name "~/*scratch*"))

Since this seems more like a "help" issue to me, I redirected
followups to gnu.emacs.help.

--
Juergen Nickelsen

Newsgroups: gnu.emacs.bug
From: jbw@bigbird.bu.edu (Joe Wells)
Subject: Re: C code formating!
Organization: Boston University Computer Science Department
Distribution: gnu
Date: Sun, 26 Jul 1992 06:34:21 GMT

In article <MEF.92Jul10160302@ehsl.mitre.org> mef@ehsl.mitre.org (Marc E. Fiucznski) writes:

   There seems to be a minor bug in the emacs C code formating code.  If
   there seems to be a function embedded within a comment, emacs actually
   formats the remaining variable definitions with indentations.  Is there
   a way of turning this off, or is this a bug?

This is a bug.  I fixed it a while back.  Bug me about it and I'll work on
getting my fix into format for submission.  (I could submit the file the
fix is in, but it's not well annotated.)

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

Newsgroups: gnu.emacs.bug
From: keith@aragorn.ori.ORG (Keith Smolkowski)
Subject: Mulitple CC Entries Mail
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 20 Jul 1992 22:22:14 GMT

In GNU Emacs 18.58.3 of Mon Apr 13 1992 on aragorn (berkeley-unix)
 
We've encountered two possibly related errors.  First, mail incorrectly
sends a mail message when it contains multiple Cc recipients.  Second,
aliases with multiple addresses appear to "bounce back" when they, in
fact, make it to their destination.  Below, I described each error in
more detail.
 
If I specify two or more users on the Cc line, the messages bounces back
for those particular users.  Sendmail successfully sends the message to
any number of users specified on the To line.  If I specify both To and
Cc fields, with more than one Cc recipient, then the mail goes to the
addresses on the To field, but not to those in the Cc field.
 
For the second bug, if I send any message to a distribution list (alias
for several users) then the a return mail message reports that the user
(alias) is unknown.  The message reaches all recipients of the list,
however.  In this case, the alias is specified on the Unix host server
and posted to all other machines.  Aliases are not in specified in local
.mailrc files.
 
I send mail from a Sun SPARCstation 2, on a network of 18 SPARCstations,
over 100 PCs, and about 10 Macs.  The bugs I described do not
discriminate between machines on the network.  Neither of these errors
occur from unix mail or sendmail.  In addition, we can send mail
correctly via OpenWindows MailTool, LifeLine Mail (networked PCs), or
uMail (networked Macs).  These errors only occur with mail sent from
within Emacs.
 
One additional anomaly.  When our system administrator added my name to
the global alias list (aliased "keith" to "keith@bombadil"), I could no
longer successfully send any mail from within Emacs.  Apparently I am
the only user with that particular problem.  Below I supplied my
mail-mode-hook, just in case.
 
If you have any recommendations, we would be willing to try things to
get this to work.  At least a few of us find vm and mail in Emacs a very
useful mail environment.
 
Thanks.  ks.
 
 
(setq mail-mode-hook
      (function
       (lambda ()
         "Set fill column and turn on auto-fill-mode"
         (setq fill-column 72)
         (setq indent-line-function 'indent-relative-maybe)
         (auto-fill-mode 1)
         (local-set-key "\es" 'center-line)
         (local-set-key "\eS" 'center-paragraph))))
 
------------------------------------------------------------------------
Keith Smolkowski                                           keith@ori.org
 
                       OREGON RESEARCH INSTITUTE
                  Research in the Behavioral Sciences
 
        1899 Willamette                           (503) 484 2123
      Eugene, Oregon 97401                      FAX (503) 484 1108
------------------------------------------------------------------------

Newsgroups: gnu.emacs.bug
From: eprice@sql.UUCP (Ed Price)
Subject: trivial but aesthetically-pleasing addition to man.el
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 28 Jul 1992 12:59:09 GMT

On my machine (a Sun4, SunOS 4.1.1, running Emacs 18.58) when I do M-x
man <something> the following kind of thing appears (eg, from `ld'),
except I replaced the real control-H characters with fake ones:

          o^H+  simple object files, which typically end in  the  .o
             suffix, and are referred to as dot-oh files

          o^H+  ar(1V) library archives (.a), or libraries

Yuck! So in the function nuke-nroff-bs I added the following code,
doesn't really matter where I don't think, except note that the ^H in
the search-string should be a real ^H (I used C-q C-h to get it in
there):

  ;; "bullets" that look like `o^H+' should look like `o'.
  
  (goto-char (point-min))
  (while (search-forward "o\+" nil t)
    (replace-match "o"))
  
Now the bullets look very nice when I do M-x man.  Victory!

In exchange for this brilliant ingenious and oh so subtle algorithm
that everyone may now freely distribute for the betterment of society
as a whole... would someone enlighten me as to the proper way of
including a control-character in a string of this kind?  Is it
different for a regular expression (which is what I was using at
first)?  I looked in the regexp info page and did not see any mention
of this.  (I guess public followups should go to help-gnu-emacs or
whatever it's called...)

Enjoy, and thank you for any advice on my question (or corrections to
my patch)!

-Ed Price
eprice@sql.sybase.com
Of course, I'm sure everyone is using x-super666-hyper-man.el now and I'm
a total loser for not knowing about it...

Newsgroups: gnu.emacs.bug
From: cdr@beast.UUCP (CD Rasmussen)
Subject: Re: #XXX# file remains after killing modified buffer for XXX
   From: siemens!intime.intime.com!scottm (Scott Michel)
   Date: Fri, 24 Jul 1992 17: 16:15 GMT
Organization: Gnus Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 16:06:28 GMT

   In article <9207201711.AA14459@beast.mountain> cdr@beast.UUCP (CD Rasmussen) writes:
   >In GNU Emacs 18.57.4 of Wed Oct  2 1991 on beast (berkeley-unix)
   >
   >If I edit a file named XXX and then decide to toss the changes by deleting the
   >buffer, the #XXX# file remains in the file system.
   >
   >  Constantine Rasmussen      508-750-7500 x7048     siemens.com!sme!cdr
   >

   This is a feature, not a bug. It saves this backup file just in case you
   really do want the changes you made.

   scottm

I'm not getting involved in a bug or feature de+bate.  The point is, I find
the behavior unreasonable and out of character based on this reasoning:

In elisp, when you want a user to take full (not temporary) responsibility
for an action you make them confirm the decision with a yes-or-no-p
instead of a y-or-n-p.  After that I expect the action to be fully
carried out, with out any left overs that I have to manually go undo.

It is out of character for emacs to assume that I didn't really mean the
command when I gave it and it would really be doing this hapless user a
favor by not really completing the task.  Emacs has always been industrial
strength software for grownups and it does not second guess you when you
ask for something to be done.  That's why it asked me for the confimation
in the first place, so I WOULD take the responsibility for the action.

What I want to know it: will the GNU project accept the changes if I submit
them?  Len, RMS, what say you?


  Constantine Rasmussen      508-750-7500 x7048     siemens.com!sme!cdr

Newsgroups: gnu.emacs.bug
From: jbw@bigbird.bu.edu (Joe Wells)
Subject: bug in Emacs Lisp mode indentation
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 28 Jul 1992 10:32:52 GMT

(emacs-version)
"GNU Emacs 18.57.99 of Thu Feb 13 1992 on bigbird (berkeley-unix)"

Here are two forms that are indented incorrectly by Emacs Lisp mode:

  ((
    ()) ""
    ;; Wrong, one column off.
    )
  ((
    ) ""
      ;; Wrong, three columns off.
      )

I presume that the cause is putting something on a line after a closing
parenthesis.

-- 
Enjoy,

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

Newsgroups: gnu.emacs.bug
From: rsm@math.arizona.edu (Robert S. Maier)
Subject: rmail.el: setq's in wrong function
Organization: Mathematics Department, University of Arizona
Distribution: gnu
Date: Wed, 22 Jul 1992 16:20:17 GMT

The definition of the function `rmail', in rmail.el, includes the 
following two lines:

	  (or rmail-last-file
	      (setq rmail-last-file (expand-file-name "~/xmail")))
	  (or rmail-last-rmail-file
	      (setq rmail-last-rmail-file (expand-file-name "~/XMAIL")))

which set the default names of files to which messages will be stored.
I think these lines are misplaced: they really belong in the function
`rmail-mode'.

Why is this?  Well, I myself have a lot of rmail (i.e., Babyl-format)
files.  Sometimes I visit them as regular files, in fundamental mode, and
sometimes I run M-x rmail on them.  And sometimes I want to switch from
fundamental mode to rmail mode.

To do this I just type M-x rmail-mode.  (I added a line to my .emacs file
to autoload rmail.el when rmail-mode is invoked, of course.)  This is 99%
satisfactory: the buffer is immediately switched to rmail mode, and all 
the single-letter rmail commands begin to work.

However... the `o' command to output messages to another rmail file
doesn't.  Nor does `\C-o', to output them in ASCII format.  The reason is
simple: the default values of rmail-last-file and rmail-last-rmail-file
aren't set!

That's why the above lines need to be moved from the rmail defun to the
rmail-mode defun.

-- 
Robert S. Maier   | Internet: rsm@math.arizona.edu, rsm@cs.arizona.edu
Dept. of Math.    | UUCP: uunet!arizona!amethyst!rsm
Univ. of Arizona  | Bitnet: maier@arizvms
Tucson, AZ  85721 | FAX: +1 602 621 8322
U.S.A.            | Voice(POTS): +1 602 621 6893  /  +1 602 621 2617

Newsgroups: gnu.emacs.bug
From: maennig@siggi.informatik.uni-dortmund.de (Olaf Maennig)
Subject: Error when using indent-relative-maybe
Organization: University of Dortmund, Germany
Distribution: gnu
Date: Tue, 28 Jul 1992 11:03:29 GMT

When doing (indent-relative-maybe) in this situation:


     this is a test
   this is a test       (point is in this line on a blank before the 'this')

emacs displays  #<marker in no buffer>, and either does not do anything, or
does (indent-relative), but without deleting whitespaces first (could not
find out the exact behaviour).

Is that an error by emacs or by me? What do I have to do?
What does the error message mean?

Thanks for help.
	Olaf
-- 

 ---------------------------------------------------------------------------
     _                   Department of Computer Science IV
    / \     |\/|         University of Dortmund, Germany
    \_/laf  |  |aennig   e-mail: maennig@siggi.informatik.uni-dortmund.de
 ---------------------------------------------------------------------------

Newsgroups: gnu.emacs.bug
From: jla@lucid.com (Joseph Arceneaux)
Subject: elisp: interactive calling of C subroutines
Reply-To: jla@ai.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 28 Jul 1992 18:28:20 GMT

   From: acevedo@athena.mit.edu
   Date: Tue, 28 Jul 92 13:59:54 -0400

   Hmmm... thanks for the info.  Does the optimization happen only with
   those three functions, or with any C subroutines called interactively
   like that?

	   Raul

Just these three.  Try your example with another subr (say,
beginning-of-line), and it will work.

Joe

Newsgroups: gnu.emacs.bug
From: scottm@intime.INTime.COM (Scott Michel)
Subject: Re: #XXX# file remains after killing modified buffer for XXX From: siemens!intime.intime.com!scottm (Scott Michel) Date: Fri, 24 Jul 1992 17: 16: 15 GMT
Organization: IntelliMED Corporation, Santa Monica, CA
Distribution: gnu
Date: Tue, 28 Jul 1992 02:10:19 GMT

In article <9207271606.AA04175@beast.mountain> cdr@beast.UUCP (CD Rasmussen) writes:
>   In article <9207201711.AA14459@beast.mountain> cdr@beast.UUCP (CD Rasmussen) writes:
>   >In GNU Emacs 18.57.4 of Wed Oct  2 1991 on beast (berkeley-unix)
>   >
>   >If I edit a file named XXX and then decide to toss the changes by deleting the
>   >buffer, the #XXX# file remains in the file system.
>   >
>   >  Constantine Rasmussen      508-750-7500 x7048     siemens.com!sme!cdr
>   >
>
>   This is a feature, not a bug. It saves this backup file just in case you
>   really do want the changes you made.
>
>   scottm
>
>I'm not getting involved in a bug or feature de+bate.  The point is, I find
>the behavior unreasonable and out of character based on this reasoning:
>
>In elisp, when you want a user to take full (not temporary) responsibility
>for an action you make them confirm the decision with a yes-or-no-p
>instead of a y-or-n-p.  After that I expect the action to be fully
>carried out, with out any left overs that I have to manually go undo.
>
>It is out of character for emacs to assume that I didn't really mean the
>command when I gave it and it would really be doing this hapless user a
>favor by not really completing the task.  Emacs has always been industrial
>strength software for grownups and it does not second guess you when you
>ask for something to be done.  That's why it asked me for the confimation
>in the first place, so I WOULD take the responsibility for the action.
>

I see your point, but I don't know how many times after I've made a series
of changes that I've suddenly decided that I really wanted >some< of the
changes. SO I for one appreciate "Emacs' irresponsibility." The adult vs.
child argument has no rational content, mostly emotional. Secondly, EMACS
asks you if you want to delete your buffer, not the auto save file.

According to your original post, I believe you were asking if this was a
reasonable behavior, and whether or not it was a bug. So you opened
yourself up to the "feature vs. bug" forum.

>What I want to know it: will the GNU project accept the changes if I submit
>them?  Len, RMS, what say you?
>
>
>  Constantine Rasmussen      508-750-7500 x7048     siemens.com!sme!cdr
>
-- 
------------------------------------------------------------------------------
Scott Michel, IntelliMED Corporation  | "For the words of the profits were
E-mail:    scottm@intime.intime.COM   |  written on the studio walls!"
CI$:       72600,1657                 | [Rush - _Permanent Waves_]


Newsgroups: gnu.emacs.bug