HDTenEightyP/NetNews huggingface dataset:
From: ghenniga@NMSU.Edu
Newsgroups: gnu.epoch.misc
Subject: Arrow keys in xemacs
Date: 21 Aug 92 21:24:02 GMT
Reply-To: ghenniga@NMSU.Edu
Organization: New Mexico State University - Electromagnetics Group


	This may have been covered but since I just upgraded to 4.1 I
probably missed all the bug reports, so....

	We're having problems with xemacs not using the arrow keys properly
on a PC-style keyboard (vt100, I think). What I've done in the past is
put the following in a local lisp file and loaded it into the xemacs
binary:

	(global-set-key "\M-OA" 'previous-line)
	(global-set-key "\M-OB" 'next-line)
	(global-set-key "\M-OC" 'forward-char)
	(global-set-key "\M-OD" 'backward-char)

The above has ALWAYS worked for me but now all-of-the sudden xemacs isn't
recognizing the keys! There is even a problem with the arrow keys on our
HP which send the characters \M-a, \M-b, \M-c and \M-d, respectively, but
if I put these in a .emacs file they are properly assigned.
	The keys function fine when using Epoch but I assume it's using 
message passing rather than binary characters for keystrokes.

Any ideas or suggestions. I'll have to go back to 4.0 if I can't fix this
as it's really annoying to hit an arrow key and hear a bell and see a
capital A, B, C, or D inserted!

Thanks
Gary Hennigan
(ghenniga@NMSU.Edu)
Newsgroups: gnu.epoch.misc
From: lystad@m2.dseg.ti.com (Garr Lystad)
Subject: Re: distinguishing mark!
Organization: TI DSEG, Spring Creek, Plano, Tx.
Reply-To: Garr.Lystad@m2.dseg.ti.com
Distribution: gnu
Date: Wed, 12 Aug 1992 16:16:15 GMT

In article <JSC.92Aug11155712@saxon.Eng.Sun.COM> jsc@saxon.Eng.Sun.COM (John Cooper) writes:


>   I just read Garr Lystad's posting about highlighting the region.  Is
>   there some means to simply have the mark rendered in a different color,
>   and when mark moves, the previous coloring is restored ?

>   Thanks,
>	   --- John.

The mark  could be rendered  in  a  different color by creating a zone
with a distinct  background color.  I'm currently creating such a zone
for  the region (point  to mark).  Although simply coloring mark would
require  one to worry  about changes to mark only, which seems simpler
but is still beyond me,  the  result would be less desirale.  Any time
mark were not within the window one might wonder where  it was,  or if
it were nil.

  --  Garr
Newsgroups: gnu.epoch.misc
From: kaplan@marula.cs.uiuc.edu
Subject: Re: Bug report - Epoch 4.1 keybindings
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 14 Aug 1992 05:14:56 GMT

I agree with all of your comments... for the moment we will have to go with
the tmp patches, and a new, improved handler will be built shortly.

We apologize for the inconveniences this is causing.

Simon
From: rick@cadillac.siemens.com (Rick Taft)
Newsgroups: gnu.epoch.misc
Subject: Meta-Problems
Date: 19 Aug 92 13:28:53 GMT
Distribution: gnu
Organization: GNUs Not Usenet


	 Disregard my last message about problems using the meta-key.
	 I have discovered the cause of the problems.  I thought I had
	 compiled with the X11R5 libraries and includes but in reality
	 they must have been R4.  I recompiled and the problem is
	 solved.

	 Sorry.

	 -Rick Taft
			   rick@siemens.com
		   Siemens Corporate Research, Inc.
	     755 College Road East, Princeton, NJ  08540
			    (609) 734-3324
Newsgroups: gnu.epoch.misc
From: scott@statsci.com (Scott Blachowicz)
Subject: Re: useless files in Epoch distribution...
Reply-To: scott@statsci.com
Organization: Statistical Sciences, Inc., Seattle, WA USA
	<JBW.92Aug16162609@bigbird.bu.edu>
Distribution: gnu
Date: Fri, 21 Aug 1992 00:19:37 GMT

>>>>> "Joe" == Joe Wells <jbw@bigbird.bu.edu>

 Joe> * emacstool.1, emacstool.c

 Joe>   Are you distributing Andy Norman's gnuserv instead?  If not, how do you
 Joe> plan to replace this functionality?  These two files are very useful.
This isn't the emacsclient stuff (which is what corresponds to gnuserv). The
'emacstool' files have to do with SunView support. Doesn't sound particularly
useful in a program like epoch that is really intended for the X Window
System.

--
Scott Blachowicz    Ph: 206/283-8802x240      USPS:  Statistical Sciences, Inc
                                                      1700 Westlake Ave N #500
scott@statsci.com / uunet!statsci!scott                Seattle, WA USA   98109
..or..     Scott.Blachowicz@seaslug.org
From: tony.bennett@East.Sun.COM (t e bennett)
Newsgroups: gnu.epoch.misc
Subject: DEL ignored by epoch4.1/ascii/emacs
Date: 18 Aug 92 16:35:23 GMT
Organization: Sun Microsystems, RTP, NC
Distribution: gnu
NNTP-Posting-Host: uh-oh.east.sun.com


Sun Solaris 2.0
xterm

DEL is ignored by the ascii emacs.

Any ideas?
--
--tbennett     tony.bennett@East.Sun.COM   mailstop: RTP-NC
Newsgroups: gnu.epoch.misc
From: tomppa@fidata.fi (Tomi Vainio)
Subject: Epoch 4.1 with Interactive UNIX 3.0
Reply-To: tomppa@fidata.fi
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 03:57:45 GMT


I tried to compile Epoch 4.1 with Interactive Unix 3.0.
ASCII version and Epoch in local X-terminal works just fine but
Epoch to remote X-terminal dumps core.
I have to computers named worm.fidata.fi and gate.fidata.fi.
DISPLAY=worm:0 everything works fine
DISPLAY=worm.fidata.fi:0 I get core dump
DISPLAY=gate:0 I get core dump
DISPLAY=gate.fidata.fi:0 I get core dump

epoch -display gate.fidata.fi:0
Fatal error (11).Segmentation fault (core dumped)

I tried to use sdb to core and it says the problem is line 719 in screen.c
  XD_display = XOpenDisplay(XD_display_name);

Another question about dispepoch.c in line 727. This looks very strange.
#if OLD
          distinct_minibuffer = 1; /* Default? */

          distinct_minibuffer = 0;
#endif
From: rwhitby@research.canon.oz.au (Rod Whitby)
Subject: Retrieving the baseline offset of a font
Originator: rwhitby@bing
Organization: Canon Information Systems Research, Australia
Distribution: gnu
Date: Fri, 14 Aug 1992 03:24:20 GMT

I want to define an opaque font that exactly overlaps the current
screen's font.

I can use (font) [ which returns ("9x15" 9 15) ] to get the current
screens font, and then use these numbers to define the opaque font's
name, width and height.

But I can't see anywhere which will give me the OFFSET argument I need
to make the opaque font exactly overlap the current font (i.e. 4 pixels
or 26% for the "9x15" font).

Does anyone know a way of retrieving the baseline offset of a font ?


-- 
Rod Whitby (rwhitby@research.canon.oz.au)     _--_|\ 
                                             /      \
Canon Information Systems Research Australia \_.--._/
1 Thomas Holt Drive, North Ryde, N.S.W., 2113.     v 
Newsgroups: gnu.epoch.misc
From: hofmann@cs.uiuc.edu
Subject: Opening a temp screen rather than a temp window
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 09:25:40 GMT

   I got this from Doug Bogia, who works in my lab (hi doug!):

(defun show-temp-buffer (target-buffer)
  (if
    (or
      ;; List of buffers that should get their own screen.
      (equal (buffer-name target-buffer) "*compilation*")
      (equal (buffer-name target-buffer) "*Help*")
    )
    (progn
      (let
        (
          (scr
            (car (epoch::screens-of-buffer target-buffer))
          )
          (xname (concat (buffer-name target-buffer) (sys-name)))
        )
        (when (null scr)
          (setq scr
            (create-screen
              target-buffer
              (list (cons 'title xname) (cons 'icon-name xname))
            )
          )
        )
        (mapraised-screen scr)
      )
    )
    ;; else
    (display-buffer target-buffer nil)
  )
)
(setq temp-buffer-show-hook 'show-temp-buffer)

  I put it in my .epoch file. It opens a new screen rather than a new window
for the *Help* and *compilation* buffers.

                                                        scott

-------------------------------------------------------------------------------
J. Scott Hofmann                        | "R2D2, you know better than
hofmann@cs.uiuc.edu (NeXTmail accepted) |  to trust a strange computer!"
Epoch development team, UIUC            |    -C3PO, _The Empire Strikes Back_
Newsgroups: gnu.epoch.misc
From: mg@bds.bds.com (Mike Gallaher)
Subject: old doc files in Epoch distribution
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 16 Aug 1992 23:35:16 GMT

Yow, I didn't know CCA Emacs was still alive.  Unipress Emacs is
indeed still being sold, but it's not very much like the version
that GOSDIFFS was written for.  I'd vote for nuking as much dead
wood as possible, in any case.  I already have to prune that crud
by hand whenever I get a new distribution.  Each time I promise
to write a script to do it.  Hey, now there's an idea...
Newsgroups: gnu.epoch.misc
From: mg@bds.bds.com (Mike Gallaher)
Subject: Re: useless files in Epoch distribution...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 16 Aug 1992 23:12:31 GMT

> * BABYL, CCADIFF, DIFF, GOSDIFF, ONEWS, OONEWS
>   These files are useful documentation.

Is anyone really using CCA Emacs anymore?  Or Gosling 264 Emacs
(or unipress 1.0)?  I don't think it's useful to describe how
Gnu emacs differs from ancient versions of Emacs that no one
even remembers anymore.
From: frick@aristoteles.karlsruhe.gmd.de (Arne Frick UniKa)
Newsgroups: gnu.epoch.misc
Subject: *Help* buffers on new screen instead of split window in current screen
Date: 19 Aug 1992 17:10:45 GMT
Organization: GMD Forschungsstelle Karlsruhe
NNTP-Posting-Host: i44s2.ira.uka.de
Originator: frick@aristoteles

Has anyone hacked Epoch to get a new screen every time Emacs needs a
new window, e.g. for a *help* buffer or a *compilation* buffer? The
idea is to finally end up with one *help*, *compilation*, ... screen
each, which I can iconify when I don't need them. 

I played around a bit with the *temp-buffer-show-hook* and it almost
worked. The code looks like this:

;;; warning: buggy code ahead!
(defun *help-buffer-other-screen* (help-buffer)
  "create a new screen for the help buffer if necessary"
  (interactive "B")
  (save-excursion
    (setq this-buffer (get-buffer (current-buffer)))
    (setq this-screen (get-screen (current-screen)))
    (setq help-screen-buffer (or help-buffer "*Help*"))
    (setq help-screen (find-buffer-other-screen help-screen-buffer))
    (switch-screen this-screen) ;; switch back to current buffer in general

    ;; exceptions:
    (if (equal help-screen-buffer " *Completions*") (other-window 1))
    (if (equal help-screen-buffer "*Help*")(switch-screen this-screen))))

(setq temp-buffer-show-hook '*help-buffer-other-screen*)
;;; end buggy code

But being a not-so-sophisticated Epoch 'n Elisp programmer I
run into trouble trouble when I made a Minibuffer completion while
putting together the argument for a 'describe-function. What happens
is that one wants the cursor to stay in the Minibuffer, not in the
*Completions* buffer or in the buffer you invoked 'describe-function
from. 

Ideas, Solutions?

-- Arne
-- 
Arne Frick, M.S.		phone: 0721/608-4762	fax: 0721/6622-968
Universitaet Karlsruhe		email: frick@ira.uka.de
Postfach 6980, 			       frick@karlsruhe.gmd.de
Vincenz-Priessnitz-Str. 1, W-7500 Karlsruhe 1, GERMANY	        
Newsgroups: gnu.epoch.misc
From: bob@almeria.inria.fr (Renaud Marlet)
Subject: Some tools available
Organization: INRIA, Sophia-Antipolis (Fr)
Distribution: gnu
Date: Tue, 18 Aug 1992 17:02:59 GMT


decor: Yet another hiliting package.
=====
        Decorate text zones with colors and fonts according to mode.
        It should provides more functions and be easier to parameterize
        than hilit or lhilit (regexp, fonts, X resources, after-change...).
        Runs with Epoch or Lucid Emacs.

viewer: TeX prepreviewer
======
        Minor modes for easier TeX edition. They consist in key bindings,
        abbreviations, and translators from and to TeX. They use heavily
        8bits fonts to display mathematics symbols. Runs with Epoch or
        Lucid Emacs.

rat: Yet another mouse/motion package
===
	More functions to bind to mouse buttons. Uses an extended version
	of thing.el. Epoch only.

portable: (hackers only)
========
        Entry points above Epoch and Lucid Emacs providing some kind
        of compatibily (used by decor and viewer).

They are available via anonymous ftp to babar.inria.fr (138.96.24.21)
in pub/emacs. See the README file.

Renaud  [Renaud.Marlet@sophia.inria.fr]
From: jbw@bigbird.bu.edu (Joe Wells)
Newsgroups: gnu.epoch.misc
Subject: Re: useless files in Epoch distribution...
Date: 16 Aug 92 21:26:08 GMT
Distribution: gnu
Organization: Boston University Computer Science Department
In-reply-to: marca@ncsa.uiuc.edu's message of 8 Aug 92 12:13:06 GMT

In article <9208090213.AA14552@wintermute.ncsa.uiuc.edu> marca@ncsa.uiuc.edu (Marc Andreessen) writes:

   I'm considering axing a bunch of files from the Epoch distribution.

Here are my comments on some of the files you mentioned.

* APPLE

  Please keep, out of respect for the wishes of the FSF.

* BABYL, CCADIFF, DIFF, GOSDIFF, ONEWS, OONEWS

  These files are useful documentation.

* celibacy.1, sex.6

  There is Emacs Lisp code which won't be useful if these files are
  removed.  Also, the combination is a good joke.

* emacstool.1, emacstool.c

  Are you distributing Andy Norman's gnuserv instead?  If not, how do you
  plan to replace this functionality?  These two files are very useful.

-- 
Joe Wells <jbw@cs.bu.edu>
Member of the League for Programming Freedom --- send e-mail for details
Newsgroups: gnu.epoch.misc
From: huub@cwi.NL (Huub Bakker)
Subject: (epoch: :delete-screen <screen>)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 14 Aug 1992 11:03:53 GMT


Dear Mr. Epoch,

The following strange thing happens here. If I call (epoch::delete-screem
<screen>) the screen I want to delete disapears from my display. OK, that's
what I wanted. But the value returned by this function is nil. Something has
been wrong. Creation of a new screen will give a screen number higher than the
number of the deleted one. Is Epoch thinking the screen still exists?
Do I anything wrong or is this a bug in Epoch?

Thanks, Huub.

We are running Epoch 4.0.3 on SGI running Iris 4.0.1.

CWI, P.O. Box 4079 			Huub Bakker (huub@cwi.nl)
1009 AB Amsterdam
The Netherlands			   
Tel. 31 20 5924080
Newsgroups: gnu.bash.bug
From: bartm@cv.ruu.NL (Bart Muyzer)
Subject: Re: BASH 1.12 under HP-UX 8.00 on an HP9000/345 -- problems
Organization: University of Utrecht, 3D Computer Vision Research Group
Distribution: gnu
Date: Wed, 19 Aug 1992 10:21:52 GMT

In <MLARSON.92Aug18170645@larson.corp.hp.com> mlarson@corp.hp.com (Matt Larson) writes:

>I successfully compiled BASH 1.12 under HP-UX 8.00 on an HP9000/345
>without incident, but the resulting shell exhibits some strange
>behavior when expanding wildcards.  For example:
[...]
>As you can see, the wildcard expansion only picks up the first item.
[...]
Yeap. When I ran into this problem, I asked this one to Chet Ramey
<chet@po.CWRU.Edu> and Brian Fox <bfox@ai.mit.edu>, both bash-maintainers.

The cause of this problem is alloca(). The alloca() for HP-UX 8.0 is broken,
so you should NOT use the alloca supplied in the library.

The way to do this is to edit machines.h and to undefine HAVE_ALLOCA.
Recompile and all is fine.

Please contact me by e-mail if you still run into trouble.

Greetings,
						>] Bartm [<
-- 
Bart Muyzer, Systems and Network Administrator, [NIC-Whois handle: BJM9]
     3D Computer Vision, Room E02.222, University Hospital Utrecht,
     Heidelberglaan 100, 3584 CX Utrecht, Holland. E-mail: bartm@cv.ruu.nl
     Fax: +31-30-513399. Tel: +31-30-506711 (w), +31-3402-52157 (h). 


Newsgroups: gnu.bash.bug
From: rantapaa@s6.math.umn.edu (Erik E. Rantapaa)
Subject: `type x' finds the directory x
Organization: University of Minnesota
Distribution: gnu
Date: Tue, 18 Aug 1992 01:55:28 GMT

I don't know if this has been reported before, but on a Sparc
running SunOS 4.1.2, the command

   type x

will return, say, /bin/x even if /bin/x is a directory.
--
        Erik Rantapaa                   rantapaa@math.umn.edu
 Accident, n.:
 	A condition in which presence of mind is good, but absence of
 body is better.

Newsgroups: gnu.bash.bug
From: ghazi@caip.rutgers.edu (Kaveh R. Ghazi)
Subject: patches for bbn butterfly gp1000
Organization: Rutgers Univ., New Brunswick, N.J.
Distribution: gnu
Date: Sat, 15 Aug 1992 22:52:32 GMT

	I got bash-1.12 compiled and working on my BBN Butterfly GP1000 running
Mach 1000 v2.5.  Here is the machines.h diffs:

diff -r bash-1.12/machines.h bbn-bash-1.12/machines.h
1123a1124,1142
> /* ************************ */
> /*                        */
> /*   BBN Butterfly GP1000   */
> /*   Mach 1000 v2.5       */
> /*                        */
> /* ************************ */
> #if defined (butterfly) && defined (BFLY1)
> #define M_MACHINE "BBN Butterfly"
> #define M_OS "Mach 1000"
> #undef HAVE_UNISTD_H
> #define HAVE_SETLINEBUF
> #define HAVE_SYS_SIGLIST
> #define HAVE_GETGROUPS
> #define HAVE_VFPRINTF
> #ifdef BUILDING_MAKEFILE
> MAKE = make
> #endif /* BUILDING_MAKEFILE */
> #endif /* butterfly */

	I also had to tweek builtins/Makefile:
diff -r bash-1.12/builtins/Makefile bbn-bash-1.12/builtins/Makefile
70c70
<       $(SHELL) ./psize.sh > pipesize.h
---
>       @$(SHELL) ./psize.sh > pipesize.h

	I made this change because for some strange reason, the make variable
$(SHELL) evaluated to my environment variable $SHELL (don't ask me why) and
it tried to execute as "/bin/tcsh ./psize.sh > pipesize.h".  This caused
psize.sh to run with csh syntax and it failed.  When I added the @ in the
makefile, it ran with /bin/sh and worked fine.

		--Kaveh
-- 
Kaveh R. Ghazi			CAIP Center, Rutgers University.
ghazi@caip.rutgers.edu		rutgers!caip.rutgers.edu!ghazi

Newsgroups: gnu.bash.bug
From: mcook@merlin.DEv.cdx.mot.COM (Michael Cook)
Subject: $() fails if stdin and stdout are not open
Organization: Motorola Codex, Canton, Massachusetts
Distribution: gnu
Date: Wed, 12 Aug 1992 17:28:31 GMT

If bash is run with stdin and stdout closed, the backquoting mechanism fails.
Look:

bash$ bash -c 'echo foo$(echo bar)baz >/dev/tty' >&- <&-
foobaz

If either stdin or stdout is open, it works okay:

bash$ bash -c 'echo foo$(echo bar)baz >/dev/tty'
foobarbaz
bash$ bash -c 'echo foo$(echo bar)baz >/dev/tty'          <&-
foobarbaz
bash$ bash -c 'echo foo$(echo bar)baz >/dev/tty'      >&-
foobarbaz
bash$ bash -c 'echo foo$(echo bar)baz >/dev/tty'      >&- <&-
foobaz
bash$ bash -c 'echo foo$(echo bar)baz >/dev/tty' 2>&-
foobarbaz
bash$ bash -c 'echo foo$(echo bar)baz >/dev/tty' 2>&-     <&-
foobarbaz
bash$ bash -c 'echo foo$(echo bar)baz >/dev/tty' 2>&- >&-
foobarbaz
bash$ bash -c 'echo foo$(echo bar)baz >/dev/tty' 2>&- >&- <&-
foobaz
bash$

(On our system (ULTRIX 4.2), when an X session is started, the $SHELL that is
run to startup the window manager has stdin and stdout closed.  Lord only
knows why...)

Bash should be made smart enough to handle this, shouldn't it?

Michael.

Newsgroups: gnu.bash.bug
From: mlarson@corp.hp.com (Matt Larson)
Subject: BASH 1.12 under HP-UX 8.00 on an HP9000/345 -- problems
Organization: Hewlett-Packard Company, Palo Alto, CA, USA
Distribution: gnu
Date: Tue, 18 Aug 1992 23:45:47 GMT

I successfully compiled BASH 1.12 under HP-UX 8.00 on an HP9000/345
without incident, but the resulting shell exhibits some strange
behavior when expanding wildcards.  For example:

larson% ls
alias-conv.sh*   scripts/         suncmd.termcap
functions/       startup-files/   whatis
larson% echo *
alias-conv.sh
larson% echo s*
scripts

As you can see, the wildcard expansion only picks up the first item.

Has anyone else compiled BASH under a similar environment?  Is there
something simple that I'm missing?  Any help would be greatly
appreciated -- I'd like to avoid digging around if someone has already
solved this one.

Thanks.
--
--
Matt Larson
Corporate Network Services, Hewlett-Packard Company
matt@hp.com   (415) 424-3610


Newsgroups: gnu.bash.bug
From: kburton@iowa.UUCP (Kevin Burton)
Subject: Arguments for subroutines
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 21 Aug 1992 18:21:18 GMT

I have bash-1.12 and am trying to convert some CSH aliases to subroutines
in bash. I want to be able to get at all of the arguments from a specified
argument on (like !:3* in CSH).

foo ()
{
	echo $1;
# This of course does not work but I want to be able to do something
# like this.
	echo $2*;
}

I have looked on the info pages and found very little documentation at all
on these "subroutines".

Does anyone know how I might do this ? Do I have to concatenate all the the
arguments manually ? I hope not :-(

Thank you.

-
Kevin Burton
Noran Instruments				voice: (608) 831-6511 x317
2551 West Beltline Highway, Room 532		  FAX: (608) 836-7224
Middleton, WI 53562				email: kburton@noran.com

Newsgroups: gnu.bash.bug
From: aas@solnes.nr.no (Gisle Aas)
Subject: 8 bit clean bash
Reply-To: Gisle.Aas@nr.no
Organization: Norwegian Computing Centre, Oslo, Norway
Distribution: gnu
Date: Tue, 11 Aug 1992 09:08:25 GMT

Bash is my favorite shell, despite its problems with handling of 8 bit
characters. We now have an almost 8 bit clean operating system, and it
is a pity to switch to tcsh each time I want to maniplulate files with
8 bit chars in their names.

I tried to hack bash to make it 8 bit clean.  The readline library was
no problem, but fixing it was not enough.  The big problem seams to be
the way quoting is handled in the subst.c source file.  I did't have
time to solve this, so I just gave up...

When do we get an official release of bash that is 8 bit clean?
--
Gisle Aas               |  snail: Boks 114 Blindern, N-0314 Oslo, Norway
Norsk Regnesentral      |  X.400: G=Gisle;S=Aas;O=nr;P=uninett;C=no
voice: +47-2-453561     |  inet:  Gisle.Aas@nr.no


Newsgroups: gnu.bash.bug