HDTenEightyP/NetNews huggingface dataset:
From: kennedy@art.INTellection.COM (Brian M Kennedy)
Subject: Comments on comint
Reply-To: Brian M Kennedy <kennedy@intellection.com>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 5 Oct 1992 10:19:22 GMT

(I forwarded this to bug-gnu-emacs because I have been told that
comint will be standard in v19.)

Olin,

I have a few suggestions on comint mode that I would like to make.
If I get around to writing them myself, I will certainly forward them
to you.

1) The msearch-input and related commands have been commented out,
   with claims that the previous-input and related history commands
   are better.  For history-ring usage, I agree.  However, I *love*
   these commands for a different usage -- I often want to back up
   and see the ouput of a previous command.  Since these commands
   outputs are often verbose, and it is fatiguing to use my eyes to
   search for a prompt while pressing M-v, I just use msearch.
   I have them bound:
	(define-key comint-mode-map "\M-\C-p"  'comint-msearch-input)
	(define-key comint-mode-map "\M-\C-n"  'comint-psearch-input)
	(define-key comint-mode-map "\M-\C-s"  'comint-msearch-input-matching)

2) I previously used a version of shell with extensions for history,
   completion, and directory-tracking.  One command I miss is M-o,
   which does a RETURN (send-input) but without resetting the state
   of the ring.  Thus, you can M-p back to the first in a series of
   commands, and then M-o to execute it.  Then M-n gets the next in
   that series of commands, M-o to execute it, and so on.  This can
   be extremely handy at times.

   For what its worth, here is the function from the old shell
   version:
	(defun shell-send-input-preserve-yank ()
	  "Do shell-send-input (as if you hit return), but rotate history so that
	   the next history yank will be the next one."
	  (interactive)
	  (if (not (eq last-command 'shell-yank))
	      (shell-send-input)
	    (let ((old-ptr shell-history-pointer))
	      (shell-send-input)
	      (push-mark (point))
	      (setq shell-history-pointer old-ptr)
	      (setq this-command 'shell-yank)
	      )
	    )
	  )
   It was unclear to me if conversion of this to comint mode would
   simply require changing the shell- prefixed symbols to the comint-
   prefixed equivalents, or whether more would be required.  Comments
   or suggestions are welcome.

3) Our filename completion has a nice feature -- if you press TAB and
   it is complete but not unique, then it cuts the current window in
   half and puts the completion list in one half.  Then a return or
   different history command will restore the window.  We have found
   this to work very nicely, but is best supported by comint rather 
   than added on the outside (since some of the other commands need to
   restore the window, eliminating the completions list).


Incidentally, I am using comint-version 2.03.  Is there a newer
version?  And has anyone written a comint-based dbx mode?

Thanks for listening,

== Brian M Kennedy <kennedy@intellection.com> ==
== Intellection, Inc.  =========================


Newsgroups: gnu.emacs.bug
From: pot@fly.cnuce.cnr.it (Francesco Potorti`)
Subject: rmail/display-time suggestion
Reply-To: pot@cnuce.cnr.it
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 2 Oct 1992 13:57:00 GMT

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

I think this simple patch would do the job without any side-effects.
Anyway, I am not very familiar with processes under emacs, so some
guru should verify it makes no harm.

--- /local/lib/emacs/lisp/local/rmail.el	Wed Apr 15 16:29:56 1992
+++ /users/pot/emacs/rmail.el	Fri Oct  2 12:39:59 1992
@@ -459,7 +459,9 @@
 	    (message "%d new message%s read"
 		     new-messages (if (= 1 new-messages) "" "s"))))
     ;; Don't leave the buffer screwed up if we get a disk-full error.
-    (rmail-show-message)))
+    (rmail-show-message)
+    (if (eq (process-status "display-time") 'run)
+	(display-time-filter display-time-process ""))))
 
 (defun rmail-insert-inbox-text (files renamep)
   (let (file tofile delete-files movemail popmail)



I had started by calling the display-time-filter only if there were
new messages, but it caused an anoying blinking on the screen.  That
was, I guess, because the filter caused a redisplay before the call to
rmail-show-messages.  This way the redisplay is done after
rmail-show-message, with a resulting waste in cpu power, but no
visible effect.

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

Newsgroups: gnu.emacs.bug
From: pot@fly.cnuce.cnr.it (Francesco Potorti`)
Subject: find-tag should be able to search for an exact match
Reply-To: pot@cnuce.cnr.it
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Sep 1992 11:06:00 GMT

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

Perhaps if find-tag was changed to use regular expressions?  Or a
find-tag-regexp was added?

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

Newsgroups: gnu.emacs.bug
From: rsherme%diamond@relay.nswc.navy.mil (Russel Shermer (R43))
Subject: emacs and the tek4014 term type.
Keywords: emacs, tek4014, termtype
Organization: NAVSWC DD White Oak Det.
Distribution: gnu
Date: Sat, 26 Sep 1992 15:14:00 GMT

	I've been trying to use emacs in the tek4014 window of an
xterm.  On some machines, emacs claims that this term type is not
powerful enough to position the cursor (sgi's, suns) while on others
(the NeXT) emacs comes up but in a mangled, unusable state.

Does anyone know why emacs doesn't run under this particular
term type?  Followup or email reply is fine.  Thanks in advance.

(For those dying to know to ask why, I'd like to mix Mathematica
text and graphics under emacs on xterms.)

	---Russ

Newsgroups: gnu.emacs.bug
From: jerry@math.ep.utexas.EDU (Jerry)
Subject: insert-file + undo = modified buffer
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 27 Sep 1992 11:21:29 GMT

In Emacs 18.58, doing

  emacs -q
  C-x i somenonemptyfile RET
  C-x u

leaves the buffer (*scratch*) marked as modified, although it does
undo the insert.  The emacs Undo info node describes:


info>    If you notice that a buffer has been modified accidentally, the
info> easiest way to recover is to type `C-_' repeatedly until the stars
info> disappear from the front of the mode line.  At this time, all the
info> modifications you made have been cancelled.  If you do not remember
info> whether you changed the buffer deliberately, type `C-_' once, and when
info> you see the last change you made undone, you will remember why you
info> made it.  If it was an accident, leave it undone.  If it was
info> deliberate, redo the change as described in the preceding paragraph.

undo-threshold
90000
undo-high-threshold
100000

which is much greater than the files being inserted.

-Jerry

Newsgroups: gnu.emacs.bug
From: dodd@mycenae.cchem.berkeley.edu (Lawrence R. Dodd)
Subject: Re: Comments on comint
Reply-To: dodd@mycenae.cchem.berkeley.edu
Organization: Dept of Chemical Engineering, Polytechnic Univ, NY, USA
Distribution: gnu
Date: Tue, 6 Oct 1992 08:54:34 GMT

Also, cmushell used to be able to create multiple cmushell buffers but
somewhere along in its development this got disabled.  What was the reason for
this and can we get it back?



Newsgroups: gnu.emacs.bug
From: sbo@vlsi.polymtl.ca (Stephane Boucher)
Subject: Bug concerning C-g and inhibit-quit
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 28 Sep 1992 00:14:53 GMT

Oups,
I forgot to give the data of my configuration:

Sun4 sunos4.1 emacs-18.58
sun4 sunos4.1 emacs-19.0 (the publicly unreleased, not lucid)

  ,                          ,                           ,
Stephane Boucher, ing. jr. | Ecole Polytechnique de Montreal
sbo@vlsi.polymtl.ca        | Tel: (514)340-5950
sbo@info.polymtl.ca        | Fax: (514)340-4078

Newsgroups: gnu.emacs.bug
From: kyle@wendy-fate.uu.net (Kyle Jones)
Subject: Re: Back to top level
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 5 Oct 1992 16:53:29 GMT

hunter@work.nlm.nih.gov (Larry Hunter) writes:
 > Using emacs 18.57 on a Silicon Graphics running IRIX 4.0.4:
 > 
 > I rarely exit emacs, often keeping sessions going for many days at a time.  And
 > I edit large files pretty regularly.  Sometimes, usually when working on a
 > large file in an emacs that has been running for a long time, emacs gets into a
 > state where no matter what I do, I get a minibuffer message that says: "Back to
 > top level".

Stock Emacs has virtual memorty limit of 8 MB.  It is very easy
to exceed this limit if you keep a session going for days.  If
you're lucky, when this happens Emacs will get try to write its
text segment, get a SIGSEGV and die, autosaving most if noit all
of your work.  If you're unlucky Emacs will trash some of its
internal structures, continuing to run and emasculate itself for
some time before dying.

 > [...]
 > I can't put together a short way of recreating this problem, alas. Any idea
 > what causes it?  Any way I could get some warning or prevent it from happening?
 > Thanks for any suggestions....

Rebuild Emacs using Zubkoff's modification that raises the VM
limit to 32 MB, i.e. putting 

#define VALBITS 26
#define GCTYPEBITS 5

in src/config.h

See the question 63 in part 2 of the FAQ posting for this gorup
for more information.


Newsgroups: gnu.emacs.bug
From: pot@fly.cnuce.cnr.it (Francesco Potorti`)
Subject: selective display bug
Reply-To: pot@cnuce.cnr.it
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 5 Oct 1992 20:14:00 GMT

   C-x $ with no argument, disabling selective display, should not
   move the cursor.  For example, with selective display enabled,
   putting the cursor at an interesting question in the Emacs FAQ
   (etc/FAQ) and hitting C-x $ should display the answer along with
   the question.  Instead, as it stands, both go way, way, off the
   screen.

I find this diff makes set-selective-display both more useful (I
perfectly agree with Paul Rubin) and aesthetically pleasant (try M-2
C-x $ in the FAQ while you are in the middle of an answer).

--- /local/lib/emacs/lisp/simple.el	Sun Dec  1 04:50:54 1991
+++ /tmp/simple.el	Mon Oct  5 19:04:46 1992
@@ -1242,7 +1242,7 @@
       (error "selective-display already in use for marked lines"))
   (setq selective-display
 	(and arg (prefix-numeric-value arg)))
-  (set-window-start (selected-window) (window-start (selected-window)))
+  (recenter '(nil))
   (princ "selective-display set to " t)
   (prin1 selective-display t)
   (princ "." t))

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

Newsgroups: gnu.emacs.bug
From: barmar@think.com (Barry Margolin)
Subject: Re: emacs
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: gnu
Date: Mon, 5 Oct 1992 20:35:45 GMT

In article <1992Oct2.133603.28087@linus.mitre.org> djb@bambam.ai.mit.EDU (David J. Braunegg) writes:
>In article <1adeseINNnig@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>>>In the definition of insert-buffer in simple.el, I suggest replacing
>>>  (interactive "*bInsert buffer: ")
>>>with
>>>  (interactive "*BInsert buffer: ")

>>The interactive "B" code will allow you to specify a nonexistent buffer,

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

Well, you certainly don't have to go *that* far!  You could also do:

(interactive '(progn
		(barf-if-buffer-read-only)
		(list (read-buffer "Insert buffer: " (other-buffer) t))))

In fact, even without this feature of "interactive", I don't see how
recoding in C would make things any easier than recoding in Lisp to prompt
for the buffer itself (instead of using "interactive").  There are only a
few things in Emacs that you can only do in C code, and prompting for
buffers is not one of them.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

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

Newsgroups: gnu.emacs.bug
From: dough@os-d.isc-br.com (Doug Hockin)
Subject: A change to compile.el
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 25 Sep 1992 22:40:00 GMT

I have added the following line to the top of compile.el.

(provide compile1)

This allowed me to make a new mode in my .emacs file similar to "grep"
mode that uses another program (gid) to produce the output that
compile1 processes.

I think this should be in the standard release of GNU Emacs.

Doug Hockin                     Internet:  dough@mail.isc-br.com
ISC - Bunker Ramo               UUCP:      oliveb!isc-br!dough
22425 East Appleway             Phone:     509 927 5477
Liberty Lake WA 99019-9534 USA  Fax:       509 927 5612

Newsgroups: gnu.emacs.bug
From: jbw@bigbird.bu.edu (Joe Wells)
Subject: doc bug for scroll-other-window
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 4 Oct 1992 11:26:45 GMT

The documentation string for the scroll-other-window function lies.  In,
the minibuffer, the value of the variable minibuffer-scroll-window is
consulted first.  Also, the first line of the documentation string was too
long to fit in an 80 column apropos display.  Here is a patch.

Enjoy,

Joe Wells <jbw@cs.bu.edu>
Member of the League for Programming Freedom --- send e-mail for details
----------------------------------------------------------------------
--- emacs/jjj/emacs-18.58.94/src/window.c	Thu Jun 25 14:07:36 1992
+++ window.c	Sun Oct  4 15:23:35 1992
@@ -1466,10 +1466,11 @@
 }
 
 DEFUN ("scroll-other-window", Fscroll_other_window, Sscroll_other_window, 0, 1, "P",
-  "Scroll text of next window upward ARG lines; or near full screen if no ARG.\n\
+  "Scroll next window upward ARG lines; or near full screen if no ARG.\n\
 The next window is the one below the current one; or the one at the top\n\
-if the current one is at the bottom.\n\
-When calling from a program, supply a number as argument or nil.")
+if the current one is at the bottom.  In the minibuffer, if the variable\n\
+minibuffer-scroll-window has a value that is a window, that window is used\n\
+instead.  When calling from a program, supply a number as argument or nil.")
   (n)
      register Lisp_Object n;
 {
----------------------------------------------------------------------

Newsgroups: gnu.emacs.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: selective display bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 2 Oct 1992 01:12:58 GMT

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

C-x $ with no argument, disabling selective display,
should not move the cursor.  For example, with selective
display enabled, putting the cursor at an interesting question
in the Emacs FAQ (etc/FAQ) and hitting C-x $ should display
the answer along with the question.  Instead, as it stands,
both go way, way, off the screen.

Newsgroups: gnu.emacs.bug
From: wazenski@egr.duke.edu (Michael T. Wazenski)
Subject: Potential Bug with Emacs 18.58.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 2 Oct 1992 19:17:44 GMT

Hello,

Emacs 18.58.1 has recently been built for the sun4 machines in
our department.  I accessing emacs from a non-sun4 machine (either
VAX or 386sx) through Xwindows, the meta key apparently acts like 
'SPC META'.  This is, it inserts a space when depressed before 
the meta key command sequence executes.  This behavior is not 
observed when emacs is run locally on a sun4 machine with Xwindows.

I am not sure where this error originates, nor am I sure this is 
a bug; however, I would welcome any suggestions on how to correct
this uncritical but annoying phenomena.

Thank you,
Mike Wazenski
wazenski@egr.duke.edu
Newsgroups: gnu.emacs.vm.bug
Subject: Re: vm + supercite 2.2
From: grabiner@math.harvard.edu (David Grabiner)
Date: 4 Oct 92 15:59:26 EDT
Distribution: world
Organization: /etc/organization
In-reply-to: grossjoh@lucy.ls6.informatik.uni-dortmund.de's message of 1 Oct 92 13:58:11

In article <GROSSJOH.92Oct1135811@lucy.ls6.informatik.uni-dortmund.de>, Kai Grossjohann writes:

> I use VM 5.31 and Supercite 2.2. They do not work well together because:

I use SC 2.1, and have the same problem.

> Sometimes a message does not have a "From:" field displayed. Then
> Supercite does not know who the message is from and so all headers
> (it's got 7 different headers) are empty. There is always a "From "
> field (note the space!), though it is not displayed.

In addition, when you reply to this message using 'R', or use C-c C-y to
yank the text into a messafe, the included text is preceded by "from
writes:".

Either VM or SC should read the "From " line and display it if there is
no "From:" line.

--
David Grabiner, grabiner@zariski.harvard.edu
"We are sorry, but the number you have dialed is imaginary."
"Please rotate your phone 90 degrees and try again."
Disclaimer: I speak for no one and no one speaks for me.
From: grossjoh@lucy.ls6.informatik.uni-dortmund.de (Kai Grossjohann)
Newsgroups: gnu.emacs.vm.bug
Subject: vm + supercite 2.2
Date: 1 Oct 92 13:58:11
Organization: Universitaet Dortmund, Lehrstuhl Informatik VI
Distribution: world
Reply-To: Kai Grossjohann <grossjoh@ls6.informatik.uni-dortmund.de>
NNTP-Posting-Host: lucy

Hello there!

I use VM 5.31 and Supercite 2.2. They do not work well together because:

Sometimes a message does not have a "From:" field displayed. Then Supercite does
not know who the message is from and so all headers (it's got 7 different
headers) are empty. There is always a "From " field (note the space!), though it
is not displayed.

Do you have any ideas how I could get Supercite and VM to work together?

Maybe I can tell Supercite to get all its information from the field
"X-VM-v5-Data:"?

        ThanX a lot for your help in advance,
                Kai
--
--
  Kai Grossjohann            Phone (voice): 49 231 75 30 15
  Baroper Str. 331 App. 510  E-Mail: 
  W-4600 Dortmund 50         grossjoh@ls6.informatik.uni-dortmund.de
  Germany                    
--
This sentence was in the past tense.
                        -- D. Hofstadter
x-gateway: rodan.UU.NET from bug-vm to gnu.emacs.vm.bug; Sun, 27 Sep 1992 03:36:17 EDT
Date: Sun, 27 Sep 1992 01:35:07 MDT
From: jerry@math.ep.utexas.edu (Jerry)
Subject: vm-expose-hidden-headers changes point in folder buffer
Newsgroups: gnu.emacs.vm.bug
In VM5.32, do

 t t

and point will have moved to the beginning of buffer instead of the
beginning of the displayed message itself.

-Jerry


Dan Quayle is a man of the future, a young man born in the middle of
 this century and from the middle of America.  He's a dynamic young
 leader for the future of our party and the future of the nation.
                -- President George Bush
Newsgroups: gnu.emacs.vm.bug
From: Oliver Schoett <schoett@informatik.tu-muenchen.de>
Subject: Re: vm-isearch-forward
Organization: Inst. fuer Informatik, Technische Univ. Muenchen, Germany
Date: Thu, 1 Oct 1992 20:42:03 GMT

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

 > Maybe the attribute should be "exposed" instead of "read".
 > That's generally what VM means by "read".  It can't really know
 > wheyther you've read the message of course.

That's one of my pet peeves with vm and gnus as compared to rn.  They
mark a message read when it is first exposed.  But this is simply
wrong, as I have not yet read it (for example, I might get
interrupted).  I prefer the approach of rn, where an article is marked
'read' upon leaving it with a command whose meaning is "I've read this
one, go to the next one".


Oliver Schoett     Inst. f. Informatik (H2), Technische Univ. M"unchen
                   Postfach 20 24 20,     8000 M"unchen 2,     Germany
schoett@informatik.tu-muenchen.de    phone +49 89 2105-2399  fax -8207
Newsgroups: gnu.emacs.vm.bug,gnu.emacs.vm.info
From: rens@lorax.shearson.com (Rens Troost)
Subject: Re: vm-confirm-quit should have value meaning ask if folder > some size
Reply-To: rens@shearson.com (Rens Troost)
Organization: Lehman Brothers
	<JBW.92Oct3193217@bigbird.bu.edu>
Date: Mon, 5 Oct 1992 23:05:42 GMT

Hi-

In article <JBW.92Oct3193217@bigbird.bu.edu> jbw@bigbird.bu.edu (Joe Wells) writes:

   In article <9210021722.AA05654@wendy-fate.UU.NET> kyle@uunet.uu.net (Kyle Jones) writes:
      Good idea.  I think size should be in number of messages rather
      than bytes, though.

   What is the relative effect of number of messages vs. number of bytes on
   how long it takes VM to load a folder?

It should really allow either setting dependent on the symbol's
variable value. In fact, I'd like to see it execute the symbol's
function cell, and act on the result. That way I could set my own test
function.

I would not suggest this be the default behavior, just that it
overrride the default vm-confirm-quit behavoir. Is there interest in
this?

-Rens

--
  __   ___  ,    __  
 /__) /__  /| / (    |  J. Laurens Troost    Lehman Brothers Technical Services
/  \ (___ / |/ __)   |  *Opinions expressed herein are mine. Mine, I tell you!*
-------------------------------------------------------------------------------
INET: rens@shearson.com        VOICE: (212) 464-3705        FAX: (212) 464-2040
x-gateway: rodan.UU.NET from bug-vm to gnu.emacs.vm.bug; Fri, 2 Oct 1992 13:22:24 EDT
From: kyle@uunet.uu.net (Kyle Jones)
Date: Fri, 2 Oct 1992 13:22:17 -0400
Subject: vm-confirm-quit should have value meaning ask if folder > some size
Newsgroups: gnu.emacs.vm.bug
Joe Wells writes:
 > It would be really incredibly nice if it were possible to give
 > vm-confirm-quit a value that would mean VM would ask before quitting a
 > folder if the folder were larger than a certain size in bytes.  I propose
 > that a numeric value for vm-confirm-quit should have this meaning.

Good idea.  I think size should be in number of messages rather
than bytes, though.
x-gateway: rodan.UU.NET from bug-vm to gnu.emacs.vm.bug; Thu, 1 Oct 1992 13:34:53 EDT
Date: Wed, 30 Sep 1992 11:58:54 EDT
From: vita@sunny.dab.ge.com (Mark Vita)
Subject: vm digest bug
Reply-To: vita@sunny.dab.ge.com
Newsgroups: gnu.emacs.vm.bug