HDTenEightyP/NetNews huggingface dataset:
From: rossini@hsph.harvard.edu (Anthony Rossini)
Newsgroups: alt.lucid-emacs.help
Subject: auctex-6.1 and lemacs-19.3
Date: 16 Oct 92 02:26:36 GMT
Distribution: alt
Organization: Biostat Dept, HSPH, Boston MA, USA.


Thanks for all comments about the combination.  It looks like everything
will work (and works fairly well!) unless one tries to specify the file mode
within the .tex file via a first line such as:

; -*- LaTeX -*-

or 

; -*- mode:latex -*-

(or any other sensible capitalization scheme of the above 2).  In this case,
while the TeX-buffer command still works, the preview and print commands do
not.  It was commented by one responder that this was caused by a call to
hack-local-variables, and that this removed whatever the file name was
supposed to be from the proper variable.  I checked the code, and couldn't
figure out any workable fixes (short of removing that line from my file).
(Caveat: I'm not an elisp hacker, just a sometimes programmer...)

Does anyone have any ideas on how to fix this problem, short of removing the
calls to hack-local-variables in tex-buf.el?  I'd rather not do that, since
it is the primary reason for having the mode-line there in the first place!

If not, I guess the work around is not to specify file-mode in TeX files to
be used in auc-tex...?

(by the way, installation is fairly simple, as far as just putting the
directory that one gets from iesd.auc.dk into the lisp directory -- I
really, really like this auto-directory reading on start-up feature for
setting the elisp-path!!)

-tony


--
Anthony Rossini       -       rossini@biostat.harvard.edu
Department of Biostatistics, Harvard School of Public Health
677 Huntington Ave, Boston MA 02115  617-432-1056
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Mon, 12 Oct 1992 20:37:34 EDT
Return-Path: <lam@saifr00.cfsat.honeywell.com>
Date: Mon, 12 Oct 1992 17:33:07 MST
From: lam@saifr00.cfsat.honeywell.com (Josh Lam)
Subject: Novice Help On Key Binding
Newsgroups: alt.lucid-emacs.help
Hi,

I am no emacs or lisp guru so please pardon me if this is a simple
question:

I have been using GNU Emacs on a Sun and in my .emacs file, I did the
following: 

(global-set-key "\e[214z" 'beginning-of-buffer) ; binds R7 key to
                                                ; beginning-of-buffer 
                                                ; command

However when I started lucid emacs, it loaded my .emacs file but when I
tried to use the R7 key it says "f27 not defined"

Why do I get f27 when I press the R7 key? What do I need to do in my .emacs
file in order to make the R7 key bind to beginning-of-buffer?

Thanks in advance.

Josh Lam
Honeywell Inc
lam@saifr00.cfsat.honeywell.com
From: davidh@muppet.bt.co.uk (David Hobley)
Newsgroups: alt.lucid-emacs.help
Subject: mark-whole-buffer
Date: 7 Oct 92 15:14:25 GMT
Reply-To: davidh@muppet.bt.co.uk
Followup-To: alt.lucid-emacs.help
Organization: British Telecom Research Laboratories

I was just trying to write a function to re-format the whole file.
To test which functions I would need I tried:

C-x h
M-x indent-region

However, when I typed the i of indent-region, the mark was cleared.
In an emacs 18.58 we keep lying around, this worked. Anyone any ideas ?
Am I doing something stupid ?
Cheers,

---
        David Hobley    davidh@muppet.bt.co.uk
Through the darkness of future past / the magician longs to see.
One chants out between two worlds   / 'Fire walk with me.'
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Mon, 12 Oct 1992 21:50:31 EDT
Subject: Re: epoch and lucid
Date: Mon, 12 Oct 1992 18:56:53 PDT
From: "Frame By Frame" <John.Cooper@Eng.Sun.COM>
Newsgroups: alt.lucid-emacs.help
> "Jamie" == Jamie Zawinski <jwz@lucid.com> writes:

>
> o  I couldn't figure how to switch between screens (from the keyboard)
>    and have lucid raise the new screen to the top of the window stack.
>    In epoch I use C-z o and C-z p.

  Jamie> The M-o command switches focus to another screen.  It does this
  Jamie> by sending a TAKE_FOCUS message to your window manager.
  Jamie> Whether this causes the window to be raised is up to your
  Jamie> window manager; clients which second-guess the window manager
  Jamie> by raising the window themselves in such sitations are not
  Jamie> ICCCM compliant.

Most window managers do not raise windows when they get WM_TAKE_FOCUS
unless auto-raise is set. Unfortunately I dislike auto-raise because
windows raise as I move the pointer across them.

Setting the variable auto-raise-screen has similar effect - when the
pointer crosses any lucid windows they raise.

With epoch I have my desired behavior: If I move the pointer across
screens, they do *not* autoraise; however, if I move to another screen
using the keyboard, that screen does rise to the top.

This might seem a small point, but I find auto-raise so irritating, but
when I move to another screen with the keyboard I always want to see
that screen.

Is there some way (maybe undocumented?) that I could arrange for this
behavior?


Will lucid support a shared minibuffer at some time?

Thanks,
	--- John.

ps. M-x set-cursor-color didn't seem to work, and I couldn't find much
documentatin on extents/styles/X Resources, etc.
set-screen-background didn't work either - I needed to use
set-face-background.
Newsgroups: alt.lucid-emacs.help,comp.mail.elm
From: stuarth@argo.csis.dit.csiro.au (Stuart Hungerford)
Subject: Advice wanted on using Lucid Emacs as elm editor...
Organization: CSIRO Division of Information Technology
Date: Thu, 8 Oct 1992 05:57:10 GMT

Is anybody out there using Lucid Emacs as their editor in the Elm mailer?
I've got elm and lemacs talking to each other but it seems that I always get
the last message I've composed back in the editor when I want to do a new 
message.  Also -- it doesn't seem to be "quoting" the received message when
I reply.

This all works with two different editors, so I must be doing something wrong 
in the elm/lemacs setup.

Any advice much appreciated...

Stu

/-----------------------------------------------------------------------------\
| Stuart Hungerford | Internet : stuarth@csis.dit.csiro.au                    |
| CSIRO DIT         | Voice    : +61-6-2750941                                |
| Australia         | Fax      : +61-6-2571052                                |
\-----------------------------------------------------------------------------/
  RWFM? TFRM, TFUM, OTFGSM?
  (Read Which Flaming Manual? The Flaming Reference Manual, The Flaming User
   Manual Or The Flaming Getting Started Manual?)
                                                -- Michael Swaine

x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Mon, 12 Oct 1992 23:34:31 EDT
Date: Mon, 12 Oct 1992 20:35:03 PDT
From: devin%scylla@lucid.com (Matthieu Devin)
Subject: Re: epoch and lucid
	<9210130156.AA01934@saxon.Eng.Sun.COM>
Newsgroups: alt.lucid-emacs.help
You can raise a screen by calling the function raise-screen from elisp. 

     raise-screen: (screen)
       -- a built-in function.
     Make the window of SCREEN be the uppermost one (fully visible).
From: bjdunlop@shamash.cdc.com (Bruce Dunlop)
Newsgroups: alt.lucid-emacs.help
Subject: execute-extended-command problem
Date: 16 Oct 92 12:17:15 GMT
Distribution: usa
Organization: Control Data, Arden Hills, MN


I previously posted about a problem with delete-rectangle and cut-rectangle, to
which I didn't get any replies.  I have done some further experimenting, and
have found the real problem.  It is not with the rectangle commands.

The real problem is that I cannot execute ANY extended command if there is
marked text.  If I mark some text, then type ESC-x, then type ANY character,
I get an arg range error.

Please let me know if this works or doesn't work for you.

Jim Dahlberg
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Thu, 15 Oct 1992 14:28:31 EDT
Date: Thu, 15 Oct 1992 12:24:29 EDT
From: paquette%fatman.crim.ca@lucid.com (Marc Paquette)
Subject: Help with dired on SGI Indigo version of lemacs
Newsgroups: alt.lucid-emacs.help
You said:

> Having successfully built lemacs-19.3 for my SGI Indigo (after some
> stupidity on my part -- thanks to those who helped me out), I now have
> another problem, this time with Dired.
> 
> Dired fails to load, with the error message (approx):
>    Symbol's function definition is void: baud-rate
> 

Dired should work out of the box.  Check that you don't mess up
with the load-path in your .emacs: if ever you modify the
load-path, you're probably better to append things to it instead
of prepending paths.

If Dired is still not working after you checked your load-path,
then do the following before calling Dired (in your .emacs for
example): 

      (defun baud-rate () baud-rate)	; symbole 'baud-rate is now a variable 

The you should fly...

Marc Paquette              |Centre de recherche informatique de Montreal (CRIM)
Conseiller Technique, UN*X | 3744 rue Jean-Brillant, bureau 500
paquette@crim.ca           | Montreal (Quebec) Canada H3T 1P1
Tel : (514) 340-5758       | Fax   : (514) 340-5777
From: ucosmo@mcl.ucsb.edu (Boris Burtin)
Newsgroups: alt.lucid-emacs.help
Subject: Linking problem during compile
Date: 7 Oct 92 22:16:55 GMT

I can't seem to get ld to find the X libraries on my Sun Sparcstation.  
They are located in /usr/lib, so I don't see why there should be a 
problem.  I've tried setting LD_LIBRARY_PATH and running ldconfig, but
it doesn't help.  Here's the output I get from build-install.  I'd app-
reciate any help I could get!

---

ld   -e __start -Bstatic    -L. -L./lwlib -o temacs crt0.o dispnew.o screen.o scroll.o xdisp.o window.o  events.o event-alloc.o event-stream.o  term.o cm.o xterm.o xfns.o xselect.o xutils.o event-Xt.o menubar.o play.o libsst.o  emacs.o keyboard.o macros.o keymap.o sysdep.o  buffer.o filelock.o insdel.o marker.o  minibuf.o fileio.o dired.o filemode.o  cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o  alloc.o data.o doc.o editfns.o callint.o  eval.o floatfns.o fns.o print.o lread.o  abbrev.o sy



ntax.o font_lock.o unexec.o mocklisp.o bytecode.o  process.o callproc.o environ.o  doprnt.o extents.o faces.o elhash.o hash.o tparam.o lastfile.o  ScreenWidget.o ColumnWidget.o EmacsShell.o sunOS-fix.o strcmp.o strcpy.o  -L/usr/demo/SOUND -laudio    ./lwlib/liblw.a  -lXaw -lXext -lXt -lXmu -lX11   -ltermcap  -lg  -lm -lc
ld: -lXaw: No such file or directory
*** Error code 4
make: Fatal error: Command failed for target `temacs'
Current working directory /usr/local/junk/lemacs-19.3/src
*** Error code 1
make: Fatal error: Command failed for target `doall'
exit 1

--
     - Boris
(cosmo@cs.ucsb.edu)
From: tfb@aisb.ed.ac.uk (Tim Bradshaw)
Newsgroups: alt.lucid-emacs.help
Subject: Very long lines
Date: 9 Oct 92 06:17:55 GMT
Organization: Not

I often have to edit files which have very long lines -- up to about
1M all on one line.  it takes v18 about 1sec to go from one end of
these files to the other, and lemacs over 20 (by guesswork: I don't
have clocks available which measure time in units less than minutes).
Is there a good reason it is this slow?  It also seems to do pretty
badly on real binary files for the same reason I suspect.  It makes it
really difficult to patch kernels.

--tim
Newsgroups: alt.lucid-emacs.help
From: rouquett@Aig.Jpl.Nasa.Gov (Nicolas Rouquette)
Subject: comint
Reply-To: rouquett@aig.jpl.nasa.gov
Organization: NASA/Jet Propulsion Laboratory
Date: Fri, 16 Oct 1992 23:32:03 GMT

When using gdb or ilisp modes, the commands related to the inferior
process usually split the current window in two and in one of the
windows shows the buffer of the inferior process. For gdb this
happens with M-x compile and in ilisp with eval-defun-lisp for example.

With lemacs, this window-splitting behavior is unecessary when the
buffer to be displayed is mapped on a window visible in any screen.
What could I do to prevent the window-splitting behavior when unecessary?

 -- 
----------Nicolas Rouquette----------rouquett@aig.jpl.nasa.gov
    Artificial Intelligence Group
      Jet Propulsion Laboratory
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Thu, 15 Oct 1992 09:52:53 EDT
Date: Thu, 15 Oct 1992 01:55:44 PDT
X-Windows: Flawed beyond belief.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: Mail auto-save files?
Newsgroups: alt.lucid-emacs.help
In message <GRUNWALD.92Oct14204449@mumble.cs.colorado.edu> Dirk Grunwald wrote:
>
> Where I go, I leave a trail of auto-save files from sending mail.
> They're embarrsing me because I leave them in other peoples
> directories.

You can put all of your autosave files in one place if you use a package 
like sk's auto-save.el (in the lemacs .../lisp/packages/ directory.)

> I like having auto-save of mail I'm sending (mainly 'cause lucid just
> dumped on me), but why should they exist when I'm done sending mail?

You may only *think* you're done sending mail.  The `mail' command has been
changed to create a new send-mail buffer each time it is invoked instead of
selecting an old buffer if it exists.  So possibly you're accidentally
letting multiple send-mail buffers pile up.  When you kill a mail buffer (or
send the message) the corresponding auto-save file is deleted.  But if you
exit emacs with unsent mail buffers present, the auto-save files are not
deleted (which I think is the right thing.)

	-- Jamie
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Thu, 8 Oct 1992 02:59:58 EDT
From: danny@ipc1.amil.co.il (Danny Bar-Dov)
Date: Thu, 8 Oct 1992 08:58:28 +0000
	<1992Oct1.081408.10642@daimi.aau.dk>
X-Mailer: Z-Mail (2.1b.27 9/21/92)
Subject: Re: fresh xemacs dies in _start
Newsgroups: alt.lucid-emacs.help
On Oct 1,  8:14am, Christian Lynbech wrote:
> Subject: Re: fresh xemacs dies in _start
> I'm no expert on the inner magic's of loading and linking, but you may want to
> ensure yourself that you are using statically linking rather than dynamic. It
> says in some of the makefiles, that one should always use static linking when
> dumping emacs.
> 
> It would be nice though, if dynamic linking was possible. lemacs is, even by
> modern standards, very big.
There's no real need to dump emacs. It runs very well as an undumed emacs.
You lose of course the pre-loaded .el files but if you use a fast machine, and
if you do not have the habit of starting emacs for each file - but keeping one open
all the time, then you can say CANNOT_DUMP in the config file and use dynamic
libraries.  As a matter of fact, if you're short on memory on a multiuser machine
it might be better than to use a dumped emacs.
This knowledge is from experience. I used undumped emacs working with shared
libraries and it works very good. (that is not less than a dumped emacs).


> 
> 
> ------------------------------------------------------------------------------
> Christian Lynbech
> 
> DAIMI						office: R0.32   phone: 5034
> University of Aarhus,DK-Denmark                 email: lynbech@daimi.aau.dk
> ------------------------------------------------------------------------------
> 			  EMACS, The One True Editor                       
> 
> 
> Hit the philistines three times over the head with the Elisp reference manual.
> 
>                                         - petonic@hal.com (Michael A. Petonic)
> 
>-- End of excerpt from Christian Lynbech


x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Wed, 14 Oct 1992 09:20:42 EDT
Date: Tue, 13 Oct 1992 19:22:54 EDT
From: iansmith@cc.gatech.edu (Ian Smith)
Subject: screen-menubar
Reply-To: iansmith@cc.gatech.edu (Ian Smith)
X-Vi: NOT!
X-Mailer: VM 5.32L [Lucid Emacs 19.3]
Newsgroups: alt.lucid-emacs.help
what's up with this? From the NEWS file:
 

------------------------------
screen-menubar (&optional screen)

Returns the menubar description list of the given screen,
defaulting to the current screen.

------------------------------

It doesn't work on my copy.... It would be nice to see if I had already
inserted something in the menubar before I go trying to do it again...

ian


-----
Enjoy the polyrhythmic ritual/assault experience of Crash Worship.
ian smith, multimedia computing group, georgia tech, iansmith@cc.gatech.edu 
Newsgroups: alt.lucid-emacs.help
From: carney@rocky.rational.com (Mike Carney)
Subject: Minibuffer
Organization: Rational, Santa Clara, CA
Distribution: alt
Date: Mon, 12 Oct 1992 20:07:43 GMT


Is it possible to have each screen in lemacs have a minibuffer of its
own, with its own history? On my sun4 I have my 'again' key bound to
'repeat-complex-command'. It would be nice to have each screen know
what its last command was.

Also, has anyone out there had any success using the pending-delete
package with the font-lock package.

And lastly, is there any way to set up lemacs so that everytime a new
buffer is introduced a new screen is created? For instance, when I
execute 'M-x compile' the screen that I invoked this from is split,
with the compile messages output to the bottom half. It would be nice
if instead, the compile messages had a screen of their own, and when
the next-error function is called, it would first see if the file in
which the error occurs is currently being displayed in some other
screen, and switch to that one, or create a new screen with the file,
and switch there. Is this making any sense?

Anyway, answers to any of the above questions can be posted to news or
mailed directly to me. Thanks in advance :-).
--
____________________________________________________

    Michael D. Carney              \v/
    carney@rational.com           _<=>_                           
                                 /..[* ] 
    "Remember...          --===]o/[=[**]  
     no matter where you          /_\_*/
     go, there you are" -B.B      [] [] 
__________________________________d]_[b_____________


x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Thu, 15 Oct 1992 21:57:30 EDT
Date: Wed, 14 Oct 1992 17:30:46 EDT
From: jlf@sunpix.East.Sun.COM (John L. Furlani)
Subject: Lucid Emacs Patch for Solaris 2
Mailed-From: GNU Emacs or Epoch (19.3.13 Lucid)
Content-Length: 38887
Newsgroups: alt.lucid-emacs.help
From: rjc@cogsci.ed.ac.uk (Richard Caley)
Newsgroups: alt.lucid-emacs.help
Subject: Re: epoch and lucid
Date: 16 Oct 92 11:47:00 GMT
Organization: Human Communication Research Center
In-reply-to: John.Cooper@Eng.Sun.COM's message of 13 Oct 92 01:56:53 GMT

In article <9210130156.AA01934@saxon.Eng.Sun.COM>, Frame By Frame (fbf) writes:

fbf> Most window managers do not raise windows when they get WM_TAKE_FOCUS
fbf> unless auto-raise is set. 

[Pedantic point: Unless I am totally confused, WMs don't _get_
 WM_TAKE_FOCUS, they send it. WMs get enter notifies and maybe focus-in
 events].

I don't think there is a reasonable way to get the WM to do what you
want since it involves deciding whether a window getting focus is just
getting it becauuse the mouse happens to move over it, or because you
really want it to have the focus. A WM could be made to raise any
focused window which doesn't have the cursor in it, which would
probably be equivalent. Or perhaps `raise on focus if the cursor is
not moving'? 

Either is a bit hacky, I think the client (ie lemacs) should do the
raising since it has more information. 

I don't think a client which raises it's window is non-ICCCM
complient (so long as it is a simple raise, not relative to anything).
The WM is, of course, free to ignore the request.

--
rjc@cogsci.ed.ac.uk			_O_
					 |<
Newsgroups: alt.lucid-emacs.help
From: carney@rocky.rational.com (Mike Carney)
Subject: font-lock and pending-del
Organization: Rational, Santa Clara, CA
Distribution: alt
Date: Fri, 16 Oct 1992 17:46:58 GMT


I was having some problems running these two packages together, but
I've solved them, and thought that this might be useful to others.
The problem was that if font-lock mode was on, when you highlighted a
section of text, and started typing something else (which should
replace the highlighted text with pending-del loaded) would leave the
first character that you type highlighted, and pending-del would just
continue to replace that character with every subsequent character.

Well, enough babbling (I'm starting to sound like Stockdale! :-)

Here's what you need to change in  font-lock.el to fix the problem:

Add one link in the function font-lock-after-change-function
;; ...

(defun font-lock-after-change-function (beg end old-len)
  ;; called when any modification is made to buffer text.
  (save-excursion
    (goto-char beg)
    (if (or (> old-len 0)		; Deletions mean the cache is invalid.
	    (= (preceding-char) ?\n)	; Insertions at bol/bob mean that the
	    (bobp))			; bol cache might be invalid.
	(buffer-syntactic-context-flush-cache))
    (goto-char end)
    (end-of-line)
    (setq end (point))
    (goto-char beg)
    (beginning-of-line)
    (setq beg (point))
    (font-lock-unfontify-region beg end)
    (font-lock-fontify-region beg (1+ end))
    (font-lock-hack-keywords beg end)
    (zmacs-deactivate-region)		; Add this line in, and
					; pending-del will work
					; properly.
))

Hope this helps.

Now, has anyone figured out a patch to fix the problems with font-lock
mode and replace-regexp, replace-string, or any other search and
replace function? I think I know what's going on, but don't know how
to fix it. I think the problem is that during each replace, font-lock
mode takes over and uses re-search-forward (in the function
font-lock-hack-keywords), and this screws up the replace operations.
Does anyone know how to fix this?

Thanks in advance.
--
 __________________________________________
|                         ______+          |
|   Michael D. Carney    <  M   |  \+/     |
|   carney@rational.com  <___C__| _<=>_    |                      
|                               0/ .[\ ]   |
|   "Remember...                \/[.[\\]   |
|    no matter where you        | /_\_\/   |
|    go, there you are" -B.B    | [] []    |
|_______________________________|_d]_[b____|



x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Tue, 13 Oct 1992 02:37:36 EDT
Date: Mon, 12 Oct 1992 23:37:38 PDT
X-Windows: Live the nightmare.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: epoch and lucid
	<9210130156.AA01934@saxon.Eng.Sun.COM>
Newsgroups: alt.lucid-emacs.help
In message <9210130156.AA01934@saxon.Eng.Sun.COM> Frame By Frame wrote:
>
> With epoch I have my desired behavior: If I move the pointer across
> screens, they do *not* autoraise; however, if I move to another screen
> using the keyboard, that screen does rise to the top.
> 
> This might seem a small point, but I find auto-raise so irritating, but
> when I move to another screen with the keyboard I always want to see
> that screen.

I suppose it would make sense for this to be an option of the
other-window-any-screen command.

> Is there some way (maybe undocumented?) that I could arrange for this
> behavior?

It's a small matter of programming :-)

> Will lucid support a shared minibuffer at some time?

There are lots of things ahead of it on the list, but if someone gets it
working, I'd be happy to install the patches.  It kind of worked at one
time, in the distant past.  We disabled it because it tended to make
emacs crash a lot in redisplay and we didn't have time to screw around 
with it.

> ps. M-x set-cursor-color didn't seem to work, and I couldn't find much
> documentatin on extents/styles/X Resources, etc.

If you have 19.3, the emacs manual contains documentation on faces and
extents.  There's some stuff on X resources in the NEWS file; this will
make it into the manual eventually.

> set-screen-background didn't work either - I needed to use
> set-face-background.

the set-screen-background function probably shouldn't exist any more (or
should just set the background of the default face.)  Many of the screen-
manipulation functions don't really work.

	-- Jamie
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Thu, 8 Oct 1992 02:50:30 EDT
From: danny@ipc1.amil.co.il (Danny Bar-Dov)
Date: Thu, 8 Oct 1992 08:48:54 +0000
X-Mailer: Z-Mail (2.1b.27 9/21/92)
Subject: Re: at.lucid.emacs.help
Newsgroups: alt.lucid-emacs.help