HDTenEightyP/NetNews huggingface dataset:
From: Hamish.Macdonald@x400gate.bnr.ca (Hamish Macdonald)
Subject: Re: easier killing
Organization: Bell Northern Research
Distribution: gnu
Date: Tue, 17 Nov 92 18:40:02 GMT

>>>>> On 17 Nov 92 05:33:33 GMT,
>>>>> In message <CARLTON.92Nov16213333@scws7.harvard.edu>,
>>>>> carlton@scws7.harvard.edu (david carlton) wrote:

david> Has anybody written a function for GNUS that sticks a kill
david> command for the current subject (without re's, hopefully) in
david> the kill file for the current newsgroup and performs all of
david> those kills?  That seems to be the format of most of my kills.

(defun my-gnus-kill-this-subject ()
  "Kill the current subject and add it to the local KILL file."
  (interactive)
  (gnus-Subject-edit-local-kill)
  (gnus-Kill-file-kill-by-subject)
  (gnus-Kill-file-exit)
  (gnus-Subject-kill-same-subject nil)
  (gnus-Subject-show-article)
  )

I bind it to 'K' in the *Subject* buffer.

I don't think that it does any re: removal, unless
gnus-Kill-file-kill-by-subject does so.
Newsgroups: gnu.emacs.gnus
From: brian@dsm.fordham.edu (Brian Downing)
Subject: Why can't I sort groups alphabetically?
Organization: Fordham University/CLC, Division of Science and Math
Distribution: gnu
Date: Mon, 23 Nov 1992 11:11:36 GMT


 Well? When I browse killed groups I'd like to be able to sort-lines
on the buffer. Why isn't there a  gnus-Group-sort-groups function?
--

 Brian...

 brian downing@->fordham university, nyc ny
         brian@dsm.fordham.edu       bdowning@mary.fordham.edu
Newsgroups: gnu.emacs.gnus
From: ns14@crux2.crux2.cit.cornell.edu (Nathan Otto Siemers)
Subject: whoops; lost something
Organization: Department of Chemistry, Cornell Univ.
Date: Sun, 22 Nov 1992 18:52:06 GMT
Distribution: gnu
X-Posted-From: crux2.cit.cornell.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

Would someone please mail me the little lisp routine that posts to a
different inews program or alternate nntp server.  I lost my copy.

	Thanks

	Nathan
--
					   "The Messiah has returned.
					   You are in the Shithouse."
						L. Bruce	
/  | /  /__|    /    /---/  /__|    /  | / 

Newsgroups: gnu.emacs.gnus
From: liblit@cs.psu.edu (Benjamin R. Liblit)
Subject: killed groups / updating newsrc.el
Distribution: gnu
Date: Mon, 23 Nov 1992 22:03:24 GMT

I'm sure there's a simple hook for this, but my brain hurts today, so
I'm calling for ideas.

Consider the following sequence of actions:

	1. Enter GNUS
	2. Kill some groups via "C-k" or (gnus-Group-kill-group)
	3. Save all buffers via "C-u C-x s" or (save-some-buffers 't)
	4. Quit GNUS via "q" or (gnus-Group-exit)

Since saving all buffers saved the buffer holding .newsrc, quitting
GNUS does not update the .newsrc.el file.  No problem, right?  The
next time GNUS starts up, it should realize that .newsrc.el is
out-of-date, and just use .newsrc instead.

Well, that seems to work for determining which articles I have read,
but it fails to remember the groups that I killed in step 2.  They
appear in the groups list as though I had never killed them.

My instinct is to use gnus-Exit-gnus-hook, probably using
file-newer-than-file-p to decide if .newsrc.el needs to be updated.
However, I'd *really* like a solution that does not depend upon me
exiting GNUS via gnus-Group-exit.  That is, if I spontaneously issue
"C-x C-c", or (save-buffers-kill-emacs), I'd like GNUS to have its
head on straight the next time it starts up.

Any suggestions?

--
Ben Liblit   -----   "Fais que tes reves soient plus longs que la nuit."
liblit@cs.psu.edu   --   brl102@psuvm.psu.edu   --   brl102@psuvm.bitnet
Xref: sparky gnu.announce:151 gnu.utils.bug:2082
From: pinard@iro.umontreal.ca (Francois Pinard)
Newsgroups: gnu.announce,gnu.utils.bug
Subject: recode
Date: 19 Nov 92 14:02:39 GMT
Followup-To: bug-gnu-utils@prep.ai.mit.edu
To: info-gnu@prep.ai.mit.edu

The program recode is now available on prep.ai.mit.edu, in directory
pub/gnu, as file recode-3.2.4.tar.Z.

This tool has the purpose of recoding various character sets to one
another.  Recoding is currently possible between any pair of these
character sets:

  * usual 7-bit ASCII: without any diacritics, or else: using
  backspace for overstriking; Unisys' ICON convention; TeX/LaTeX
  coding; easy French conventions for electronic mail;

  * 8-bit extensions to ASCII: ISO Latin-1, IBM's code for the PC,
  Apple's code for the Macintosh;

  * 6-bit escaped ASCII based on CDC display code: 6/12 code from NOS;
  bang-bang code from Universite' de Montre'al;

  * non-ASCII codes: EBCDIC as seen by Perkin Elmer; EBCDIC as seen by
  Control Data.

By making recode available outside the context for which it has been
developped, it is likely that people would add support for other
character sets, in particular for taking care of various national
European habits.

We still have to see how recode will evolve in this wider context.
Meanwhile, please report any problem with recode to myself or to
bug-gnu-utils@prep.ai.mit.edu.

-- 
Franc,ois Pinard        ``Vivement GNU!''        pinard@iro.umontreal.ca
(514) 588-4656                                    ...!uunet!iros1!pinard
Consider joining the League for Programming Freedom.  Email for details!

      [ Soon to be at these ftp sites as well.  Please try them
	before prep.ai.mit.edu!  thanx -gnu@prep.ai.mit.edu

	Japan: ftp.cs.titech.ac.jp, utsun.s.u-tokyo.ac.jp:ftpsync/prep
	Australia: archie.oz.au:gnu
	Europe: src.doc.ic.ac.uk:gnu, ftp.informatik.tu-muenchen.de,
	  ftp.informatik.rwth-aachen.de:pub/gnu,
          nic.funet.fi:pub/gnu, ugle.unit.no, isy.liu.se,
	  ftp.stacken.kth.se, sunic.sunet.se, ftp.win.tue.nl,
	  ftp.diku.dk, ftp.eunet.ch, archive.eu.net
	United States: wuarchive.wustl.edu ftp.cs.widener.edu,
	  uxc.cso.uiuc.edu, col.hp.com, gatekeeper.dec.com:pub/GNU,
	  ftp.uu.net:systems/gnu

	For information on how to order GNU software on tape, check
	the file etc/DISTRIB in the GNU Emacs distribution, or e-mail
	a request to:	gnu@prep.ai.mit.edu
      ]
Xref: sparky gnu.announce:153 gnu.utils.bug:2084
From: pinard@iro.umontreal.ca (Francois Pinard)
Newsgroups: gnu.announce,gnu.utils.bug
Subject: wdiff announcement
Date: 19 Nov 92 14:32:23 GMT
Followup-To: bug-gnu-utils@prep.ai.mit.edu
To: info-gnu@prep.ai.mit.edu

The program wdiff is now available on prep.ai.mit.edu, in directory
pub/gnu, as file wdiff-0.03.tar.Z.

The program wdiff is a front end to diff for comparing files on a word
per word basis.  A word is anything between whitespace.  This program
is particularily useful for comparing two texts in which a few words
have been changed and for which paragraphs have been refilled.

This program does not require termcap, but takes advantage of it.  If
your system does not have termcap, you might feel like getting and
installing GNU termcap first.  Also grab termcap-1.1.tar.Z.  If you do
not have an ANSI-C compiler, you might still install wdiff, but you
need to install Flex first.  So, get flex-2.3.7.tar.Z.  The next
release of wdiff will not require Flex for non-ANSI compilers.

An incoming change is that the automatic use of an output pager will
be removed, probably being put under the control of some option.  Much
later, when wdiff will have matured enough, it *might* be integrated
into GNU diff distribution, or in GNU diff itself.

Expect a new release of wdiff in a few weeks, because a few problems
have been reported already.  Please report any wdiff problems to me or
to bug-gnu-utils@prep.ai.mit.edu.

-- 
Franc,ois Pinard        ``Vivement GNU!''        pinard@iro.umontreal.ca
(514) 588-4656                                    ...!uunet!iros1!pinard
Consider joining the League for Programming Freedom.  Email for details!

      [ Soon to be at these ftp sites as well.  Please try them
	before prep.ai.mit.edu!  thanx -gnu@prep.ai.mit.edu

	Japan: ftp.cs.titech.ac.jp, utsun.s.u-tokyo.ac.jp:ftpsync/prep
	Australia: archie.oz.au:gnu
	Europe: src.doc.ic.ac.uk:gnu, ftp.informatik.tu-muenchen.de,
	  ftp.informatik.rwth-aachen.de:pub/gnu,
          nic.funet.fi:pub/gnu, ugle.unit.no, isy.liu.se,
	  ftp.stacken.kth.se, sunic.sunet.se, ftp.win.tue.nl,
	  ftp.diku.dk, ftp.eunet.ch, archive.eu.net
	United States: wuarchive.wustl.edu ftp.cs.widener.edu,
	  uxc.cso.uiuc.edu, col.hp.com, gatekeeper.dec.com:pub/GNU,
	  ftp.uu.net:systems/gnu

	For information on how to order GNU software on tape, check
	the file etc/DISTRIB in the GNU Emacs distribution, or e-mail
	a request to:	gnu@prep.ai.mit.edu
      ]
Newsgroups: gnu.epoch.misc
From: mjruss+@rchland.ibm.COM (Mike Russell)
Subject: Partial Mode line
Reply-To: "Mike Russell" <mjruss@rchland.vnet.ibm.com>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 18 Nov 1992 06:09:02 GMT

We are using epoch  4.0.2 with pulldown windows.   Functions
delete-window  and delete-other-wondows  sometimes leave a partial mode
line.   Has anyone seen this?
Is this fixed with epoch 4.2?    The partial mode line is approximately
the size of the
pulldown menu and in the middle of the current screen.   It only occurs
if text would
normally exist under the old mode line.

I have tried

 (delete-window)
 (scroll-down 0)   ;;  Try to force redraw of mode-line
 (epoch::redisplay-screen)  ;;  force redisplay
 (sit-for 0)  ;without this, screen doesn't redisplay until mouse movement




                                                              Mike J. Russell
(507)253-3545
D266/040-3
Rochester Mn. 55901

Internet address
MJRUSS@RCHLAND.VNET.IBM.COM
Newsgroups: gnu.epoch.misc
From: richter@gauss.math.nwu.edu (Bill Richter)
Subject: Re:Epoch and interaction with Openwindows
Organization: Northwestern University, Evanston, Illinois, USA
Date: Fri, 20 Nov 1992 04:40:07 GMT

I don't know about Openwindows, but in the straight Xwindows you need
to put the following code in your .Xresources file:

! emacs only copies to cut buffer 0.  xterm by default
! wants to paste from the PRIMARY selection
XTerm*VT100.Translations: #override ~Meta <Btn2Up>: insert-selection(CUT_BUFFER0)

Maybe this would work in Openwindows also.

Bill Richter
Newsgroups: gnu.epoch.misc
From: douglis@MITL.COM (Fred Douglis)
Subject: Re: looking for Epoch goodies, e.g. screens for completion & compilation
Organization: Matsushita Information Technology Laboratory
Date: Wed, 18 Nov 1992 21:49:59 GMT

scotth@oldman.com (Scott Herzinger) writes:

>I've recently started using Epoch 4.2. I'm in search of Epoch goodies
>that augment conventional Emacs functionality that I use often. Are
>there any recommended packages?

Ditto.

>At the moment, I'd particularly like things like name completion and
>M-x compile/grep to pop up screens instead of Emacs windows.  I've
>seen the Epoch-specific elisp descriptions in the FAQ, and didn't see
>anything specifically mentioned that addresses this functionality.

Yes, the same thing occurred to me.  What I'd like is for just about
everything that currently splits a screen into multiple windows to instead
create new X windows of appropriate size.  Plus of course new ones could
be created that would overlap or go someplace else or whatever.  

The real reason I want this is because it seems that if I try to make a
particular buffer have its own background color, this causes only the
places where characters are displayed to have that background.  So I might
have

	yyyyyyyyyyyybbbbbbbbbbb
	yyyyyyyyyyyyyyyybbbbbbb
	yyyyyybbbbbbbbbbbbbbbbb
	bbbbbbbbbbbbbbbbbbbbbbb

Where "y" and "b" stand for two different background colors.

If I make the buffer have its own screen I can set the background for
the whole screen, which works quite nicely.  

Anyway, if anyone has a fix for epoch 4.2 for the background styles,
or a way to define window-related operations to deal with screens 
instead, please post or send me a copy as well as the first author.


-- 
Fred Douglis
Matsushita Information Technology Laboratory  | Email: douglis@mitl.com
182 Nassau Street			      | Phone: +1 609 497-4600
Princeton, NJ 08542 USA 		      | Fax:   +1 609 497-4013
Newsgroups: gnu.epoch.misc
From: kburton@iowa.UUCP (Kevin Burton)
Subject: infinite-beep-mode
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 16 Nov 1992 01:08:11 GMT

>>>>> On Fri, 30 Oct 1992 20:31:15 GMT, uunet!mitre.org!blk (Brian L. Kahn) said:


	Brian> I get a very annoying problem with epoch once in a while.  I'm
	Brian> wondering if anyone else has seen this behavior.

	Brian> Every once in a while, I'll click on something in epoch and find that
	Brian> I've accidentally entered infinite-beep-mode.  The message area
	Brian> displays "marker does not point anywhere" and the keyboard beeps
	Brian> forever.  Epoch is hung, and so is the keyboard, and the Xserver, and


I have a Sparcstation 1 and I also see this behavior sometimes. Let me
know if you here of a patch.

Newsgroups: gnu.epoch.misc
From: hxl@yanni.UUCP (Charlie Xiaoli Huang)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 18 Nov 1992 01:59:53 GMT

Hi,

I'm trying to bring up epoch 4.0 p2 on an HP 710 system ('uname -a'
output is HP-UX hp710 A.08.07 A 9000/710). The build is quite smooth.
I got both the X11 version and the ascii version to compile and link
and run --- i.e. they both produced the dumped version successfully.
Yet the dumped versions got a 'fatal error (11)' when invoked. This is
built on a X11R4, not R5, but I suspect it has nothing to do with the
version of X11 --- the ascii version suffered from the same problem. 

I do have a few byte-compiled .elc files that are loaded in .emacs.
The byte-compiled code was generated on a sparc. Is this the cause? 

Thanks,

hxl

Newsgroups: gnu.epoch.misc
From: robert@cogsci.edinburgh.ac.UK
Subject: Missing elc files
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 16 Nov 1992 11:20:00 GMT


I'm a happy epoch user, I've just built Epoch (4.2) for the first time, for
running under 386BSD, for my home machine.

I am a comparative novice at this: I've only built one or two things
before, and nothing as big as epoch.

The good news: I got it running, with very little help from my friends.

The bad news: I had some problems that I think clearer instructions
could have sorted.  Two points in particular.  

* The grounds on which I should choose between "make" and "build-install"
  were not clear to me.  In the end I went with "build-install"...

* Because I was transferring Epoch on floppy disks, I tried to minimise the
  amount of stuff I took.  In particular, I didn't bother to shift the
  ".elc" files, thinking that I could simply re-constitute them from the
  ".el"s.  This was not a straightforward exercise: I certainly could not
  simply "do Meta-x byte-compile-file repeatedly from xemacs" as it says in
  the PROBLEMS file.  Unfortunately
  it was late at night, and I don't remember the exact details now (plus I
  am off on holiday for two weeks, so don't have time to reconstruct them:
  sorry).  But several files refused to byte-compile.  Sometimes it was
  because other files were not loaded first, but in some cases it seemed to
  be the fact that the missing definition was later in the same file: it
  appeared that the file would not compile, or load, until it had already
  been loaded.  I found problems with compilations stopping because of
  missing definitions for at least the following: when, functionp, cadr
  and epoch-add-setup-hook.
  
  I got round this by a combination of measures, including loading cl.el
  before byte-compiling mini-cl.el, and evaluating the definitions of a
  number of functions (e.g. functionp) from within the files that defined
  them, even though the file itself wouldn't load.

If byte-compiling really should be dead easy, then I must have blundered at
a high level in some way, but I really don't know how.  Or is it that
nobody has actually DONE a byte-compile of all these files from scratch
lately, and a web of inter-dependencies has built up.  If the latter, then
somebody should either explain in detail what is needed, or try to build a
"script" file, complete with duplicated definitions as needed, to do it all
in a oner.

Sorry that this is not the worlds clearest bug report, but I am rushing to
get things done before I go away for a couple of weeks.

I think Epoch is pretty damn good: keep up the good work.

Robert.
From: brian@strl.labs.tek.com (Brian Walker)
Newsgroups: gnu.epoch.misc
Subject: Re: Got a good Epoch icon for root menus?
Date: 16 Nov 92 22:25:57 GMT
Reply-To: brian@strl.labs.tek.COM
Organization: Software Technology Research Labs, Tektronix Inc, Beaverton, OR

In article <17904@autodesk.COM>, dansmith@Autodesk.COM (Daniel Smith) writes:
|> 
|> 	Howdy, I'm looking for a bitmap that would make a good
|> Epoch icon, to be used in an mwm or olvwm root menu.  Email would be fine.

I modified the Emacs icon to produce this for the Epoch beta versions.  Epoch
faithful, be warned.

#define epoch_width 48
#define epoch_height 48
static char epoch_bits[] = {
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xf0, 0x00,
   0x00, 0x00, 0x00, 0x00, 0x80, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x06, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0c,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x18, 0x00, 0x00, 0x00, 0x00, 0x00, 0xf8,
   0x00, 0x00, 0x00, 0x80, 0xff, 0x8f, 0x00, 0x00, 0x00, 0x80, 0x00, 0x80,
   0x00, 0x00, 0x00, 0x80, 0xfe, 0xdf, 0x00, 0x00, 0x00, 0x80, 0x02, 0x50,
   0x00, 0x00, 0x00, 0x00, 0x01, 0x50, 0x00, 0x00, 0x00, 0x80, 0x01, 0x50,
   0x00, 0x00, 0x00, 0x20, 0x0d, 0x50, 0x00, 0x00, 0x00, 0x40, 0x02, 0x50,
   0xfc, 0xff, 0xff, 0xff, 0xff, 0xdf, 0xc2, 0xff, 0xff, 0xff, 0xff, 0x5f,
   0x82, 0x03, 0x00, 0x00, 0x00, 0xdc, 0x1e, 0x03, 0x00, 0x00, 0x00, 0x1c,
   0x10, 0x03, 0x00, 0x00, 0x00, 0xfc, 0x10, 0xe3, 0x03, 0x00, 0x04, 0x0c,
   0x10, 0x23, 0x00, 0x00, 0x04, 0x0c, 0x10, 0x23, 0x38, 0xc6, 0x1c, 0x0c,
   0x10, 0xe3, 0x49, 0x29, 0x2d, 0x0c, 0x10, 0x23, 0x48, 0x29, 0x24, 0x0c,
   0x10, 0x23, 0x48, 0x29, 0x25, 0x0c, 0x10, 0xe3, 0x3b, 0xc6, 0x24, 0x0c,
   0x10, 0x03, 0x08, 0x00, 0x00, 0x0c, 0x10, 0x03, 0x08, 0x00, 0x00, 0x0c,
   0x10, 0x07, 0x00, 0x00, 0x00, 0x0e, 0x10, 0xfe, 0x3f, 0xfe, 0xff, 0x07,
   0x10, 0xfc, 0x7f, 0xff, 0xff, 0x03, 0x10, 0x20, 0x60, 0x03, 0x00, 0x00,
   0x10, 0x30, 0x40, 0x81, 0x0f, 0x00, 0x10, 0x30, 0x40, 0x41, 0x10, 0x00,
   0x10, 0x00, 0x40, 0x21, 0x27, 0x00, 0x10, 0x00, 0x40, 0xa1, 0x28, 0x80,
   0x10, 0x30, 0x40, 0x91, 0x28, 0x20, 0x10, 0x30, 0x40, 0x4e, 0x28, 0x48,
   0x10, 0x10, 0x80, 0x20, 0x28, 0xb2, 0x10, 0x00, 0x00, 0x1f, 0xa8, 0x44,
   0x10, 0x20, 0x00, 0x00, 0x68, 0xaa, 0x10, 0x30, 0x00, 0x00, 0xa8, 0x44,
   0x10, 0x30, 0x00, 0x00, 0x28, 0x92, 0x10, 0x00, 0x00, 0x00, 0x28, 0x48,
   0x10, 0x00, 0x00, 0x00, 0x28, 0x20, 0x10, 0x30, 0x00, 0x00, 0x28, 0x80};

-- 
Brian Walker              Software Technology Research Lab, Tektronix, Inc. 
Brian.R.Walker@tek.com    PO Box 500, MS 50-662, Beaverton, OR  97077
Newsgroups: gnu.epoch.misc
From: liberte@cs.uiuc.edu
Subject: Re:  isearch & mouse
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 19 Nov 1992 03:29:23 GMT

Some fixes to isearch-mode were required for working properly with
epoch.  I'm not in a position to be able to make those fixes, but
I'll include anything offered.  In addition, it would be nice to
use epoch hilighting ability.

Get the latest version from me if you are interested.

dan
Newsgroups: gnu.epoch.misc
From: blk@mitre.org (Brian L. Kahn)
Subject: Re: Scrolling broken, detailed info enclosed
Organization: The MITRE Corp. Bedford, MA
Date: Sat, 14 Nov 1992 20:07:03 GMT

In article <1992Nov12.222638.2886@nas.nasa.gov> lonhyn@gulag.nas.nasa.gov (Lonhyn T. Jasinskyj) writes:


   VERSION:  Epoch 4.2, but the same held for Epoch 4.x, not sure about 3.x

   on an SGI Iris running Irix 4.0.x (not really important, I think
   this should happen on any architecture)


   The problem we are having here is that when you scroll-down
   (i.e. M-v) the following happens:

	In Emacs:
	 - move back by one "height of window" (height) number of lines
	 - the cursor is left at the last visible line in the window
	 - can continue this until you are at the beginning at which time
	   your cursor is on line height (or height minus one)
	   AND the first line in the file is at the top of the window

	In Epoch:
	 - move back by one "height of window" (height) number of lines
	 - the cursor is left at the last visible line in the window
	 - the function layout_window() then RECENTERS that line to the
	   middle of the window.
	 - continue this scrolling by height lines until you are at the
	   beginning at which point your cursor is on line "height"
	   BUT that line has now been recentered leaving the first
	   height/2 lines perpetually unreachable using scroll-down



I just experienced a very similar problem on my Sun Sparc, so the
problem doesn't rest in the Iris.  The problem doesn't happen in all
my epoch incarnations, only in this one "application" that I've built
on top of epoch.  By application, I mean a great big bunch of elisp
code.

I get the undesired recentering of the window as I scroll with
(scroll-down 1).  In the application that has the problem, I can
easily produce the effect by binding that to a key such as
(local-set-key "\M-n" '(func () (scroll-down 1)) and invoking [M-n]
when the cursor is on the bottom line of the window.  You have to be
partway through a file that is bigger than the window, of course.


OK, I've now tracked down the problem in my application.  Scroll-down
breaks when I have fonts of two different sizes on the mode line!
My app highlights the file name in the mode line using modeline
styles, and I only have this problem when I mix fonts on the modeline.

This may not be the real true and only problem, but it solved my
problem and sure is a big hint!





--
B<   Brian Kahn   blk@mitre.org   "may the farce be with you"

Newsgroups: gnu.epoch.misc
From: nelson@reed.edu (Nelson Minar)
Newsgroups: gnu.epoch.misc
Subject: Re: looking for Epoch goodies, e.g. screens for completion & compilation
Date: 17 Nov 92 23:08:47 GMT
Article-I.D.: reed.1992Nov17.230847.23183
Reply-To: nelson@reed.edu (Nelson Minar)
Organization: Reed College, Portland, OR

What I really want is a bit of elisp so that help windows (ie when you
type M-x apropos mail) come up in seperate screens.

Have people tried to enforce a one screen / one window policy on
epoch, by replacing the new window lisp code with new screen lisp
code? I think there'd be problems, but it might be feasible. This
would be a general solution, although possibly too extreme.
                __
nelson@reed.edu \/   You're free, so anything could happen, so happy birthday
Newsgroups: gnu.epoch.misc
From: mjruss+@rchland.ibm.COM (Mike Russell)
Subject: Minibuf truncate-lines
Reply-To: "Mike Russell" <mjruss@rchland.vnet.ibm.com>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 19 Nov 1992 10:41:44 GMT

(epoch 4.0.2)
I am using the following  to turn off line wrap in all windows.
(setq default-truncate-lines t)

I do not want this as a default in the minibuffer so I wrote the
following elsp to  set the buffer-local variable truncate-lines
in the minibuffer.   Unfortunately this does not work.

Does truncate-lines apply to the minibuffer also?

(defun set-minibuf-truncate()
  "Set the minibuffer to not wrap lines."
  (save-excursion
    (set-buffer (window-buffer (minibuffer-window)))
    (setq truncate-lines nil)))

(set-minibuf-truncate)





                                                              Mike J. Russell
(507)253-3545
D266/040-3
Rochester Mn. 55901

Internet address
MJRUSS@RCHLAND.VNET.IBM.COM
Newsgroups: gnu.epoch.misc