HDTenEightyP/NetNews huggingface dataset:
In message <9208252317.AA08280@pts4.pts.mot.com> Bob Weiner wrote:
   >
   > 1.  An operator that returns a list of the extents in a buffer.

   You can use map-extents for this, and if you get in the habit of using
   map-extents instead of building a list and iterating over it, your code
   will generate less garbage.

Ok.  Why does map-extents always return nil, rather than a list of results
of the function application, as is common for map operators?  If this
was done to minimize unused return values, a flag that would return
the list would be handy so that the programmer still has control without
having to assemble the list himself.

   >     It would be nice to be able to filter this list when making the
   >     call so that it returned only those extents using a specified
   >     set of faces.

   In 19.2 there is no way to get the face of an extent, but there will be
   in 19.3.

   > 2.  get-face-<attribute> functions, e.g. get-face-color.
   >     To match the set-face functions presently available, so one
   >     doesn't have to parse the face data structure.

   It's in there; (apropos "^face-") or see prim/faces.el.

Got it.

   > 3.  A way to delete all extents in a buffer.
   >     A way to delete all extents with a set attributes in a buffer.
   >     A way to delete all extents with a particular set of faces in a buffer.

   These would be good utilities to have.  They can all be implemented in
   terms of map-extents.

   > Which is just to say that the Epoch zone/style API seems more mature.

   No surprise there, I guess :-)  We put a lot more work into the substrate
   needed to implement extents/faces than the API; Energize doesn't need an
   emacs-lisp interface to them at all; and until about two weeks before 19.1
   was released, there wasn't one.  So the paint's still a little wet.

   > An easy way to get Lucid Emacs there is just to compare how simply the
   > zone/style functions in Epoch can be done using extent/face operators
   > in Lucid Emacs and to plug any holes found.  This should be a much
   > more efficient process than trying to figure out from scratch what
   > operators Lucid Emacs should have.

   Agreed; that's why I'm glad you're porting Hyperbole!

I just hope the real V19 doesn't have another incompatible API.

Bob


Newsgroups: alt.lucid-emacs.help
From: Dave Mason <dmason@plg.uwaterloo.ca>
Subject: ``Wrong argument type:'' errors - in GNUS and elsewhere
Organization: University of Waterloo
Date: Fri, 4 Sep 1992 17:20:41 GMT

 I have just started using lucid-emacs (after using Epoch off & on for a
long while).  I am quite impressed.  It all seems nicely done.

I have seen several examples of Wrong argument type: errors.  The two most
repeatable ones:
 1) if you click button1 on a mode line, you get: windowp, nil
 2) in some newsgroups in GNUS, I get: syntax-table-p, nil
(as it happens, it's in alt.sex.  I have a couple of marked articles
followed by some deleted articles (possibly followed by unread ones).  If I
do "C-U " and answer a smaller number than the number following the marked
articles, then everything works fine.  If it has to scan back it gets
problems.)

I think I also saw another one somewhere, but I don't remember where.

	../Dave
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Tue, 25 Aug 1992 14:36:53 EDT
From: chan@jpmorgan.com (Milo A. Chan)
Subject: Got temacs.purify to work
Date: Tue, 25 Aug 1992 14:35:17 EDT
X-Mailer: ELM [version 2.3(JPM) PL11]
Newsgroups: alt.lucid-emacs.help
From: dmason@plg.uwaterloo.ca (Dave Mason)
Subject: Re: ``Wrong argument type:'' errors - in GNUS and elsewhere
Originator: root@plg.uwaterloo.ca
Organization: University of Waterloo
Date: Fri, 4 Sep 1992 17:42:42 GMT

 The comment that I meant to say is that both of the cases I mentioned were
cases of predicate functions.  How can a predicate function be passed a
wrong argument type?

 It just happened in another group, which has many deleted articles,
followed by a single unread article.  Therefore "C-U 1RET" even failed.

I fired up emacs, read the article, so now all the articles in the newsgroup
are read/deleted.  Then I restarted gnus in lemacs and jumped to the group
and tried "C-U 1RET" - still the same problem.  Here is that article in its
entirety:
------------
Newsgroups: uw.general
From: vhtodd@watcgl.uwaterloo.ca (Val (Todd) Hay)
Subject: Earn $10.00 doing a Psychology Experiment
Organization: Computer Graphics Laboratory, University of Waterloo, Ontario, Canada
Distribution: uw
Date: Fri, 4 Sep 1992 12:01:36 GMT

Earn $10.00 for completing a tactile
(touch sensation -- fingers) experiment.

It takes an hour.

We need right-handed male subjects.

If interested write back to me at this
account.

Val
------------
Nothing exciting looking in that.

Interestingly, more articles have arrived in alt.sex and I can no longer
reproduce the problem!  (Although more had arrived earlier and the problem
was still there.)  And uw.general still has the problem.

	../Dave
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Thu, 27 Aug 1992 12:05:31 EDT
From: chan@jpmorgan.com (Milo A. Chan)
Subject: Re: lemacs on AIX 3.2
Date: Thu, 27 Aug 1992 12:05:13 EDT
X-Mailer: ELM [version 2.3(JPM) PL11]
Newsgroups: alt.lucid-emacs.help
ccvr__MERCIER_Claude writes:
|I got the executable xemacs making the same changes that anybody else
|who tried but when I start it with "xemacs" it open a clear window which
|does not display anything or takes any input, I can sit in front of it
|half an hour and nothing happen. If I start it with "xemacs file"
|then it core dump. 
|I tried to dbx it in both cases and got the following:
|
|case 1: 
|(after I interrupt  with ^C)
|
|interrupt in unnamed block $b667 at line 455 in file "gmalloc.c"
|  455             i = _heapinfo[i].free.prev;
|
|
|result of where:
|
|unnamed block $b667, line 455 in "gmalloc.c"
|__free(ptr = "C-x C-f"), line 455 in "gmalloc.c"
|gmalloc.free(ptr = "C-x C-f"), line 591 in "gmalloc.c"
|free_widget_value(wv = 0x202051d8), line 129 in "menubar.c"

[...core trace deleted...]

It's interesting to note that this is the same place where the purify'd
version of temacs I have been working with dumps core.  Two different
hardware and software platforms, different compilers, different debuggers,
with and without purify.  Different stack frames, though.  Is there any
connection?  Or am I just confusing myself?

|
|In the second case (call with a file)
|
|
|it does not core dump if I run it under dbx but does otherwise.

I get the same behavior running purified temacs, gcc-1.40, sparc SunOS4.1.2,
gdb-4.6.



-- 
Milo Chan,  Fixed Income Market Strategies,  J.P. Morgan Securities, Inc.
email:   chan_milo@jpmorgan.com    ...or...   chan@fractl.tn.cornell.edu
phone:   212.648.4483              ...or...          212.648.4486 (sec'y)
Newsgroups: alt.lucid-emacs.help
From: jwz@lucid.COM (Jamie Zawinski)
Subject: Re: retained state from byte compile
Organization: WU Mail/News Gateway
Date: Thu, 27 Aug 1992 20:00:44 GMT

In message <LYSTAD.92Aug27120852@m2.dseg.ti.com> Garr Lystad wrote:
>
> I wrote a little advise macro when I first started using Epoch.  
> One of my files advises an lemacs function (call it x) and the advice
> calls a function I define in the same file (call this function of mine
> y).  If I do not load or evaluate any part of the file, but I do byte
> compile it, the advice on x remains and I get an error because y is
> undefined.  That shouldn't really be, should it?

It sounds to me like your adviser is a macro, and it is doing its work
in the macroexpander function rather than in the emitted code.  This is
a no-no.  It worked with the old byte compiler because it simply didn't
compile top-level calls to macros.

	-- Jamie
From: bob@almeria.inria.fr (Renaud Marlet)
Newsgroups: alt.lucid-emacs.help
Subject: Re: electric font lock mode
Date: 1 Sep 92 13:13:53 GMT
Organization: INRIA, Sophia-Antipolis (Fr)

You might also take a look at "decor" available via anonymous ftp to
babar.inria.fr (138.96.24.21) in pub/emacs. See the README file.

Renaud
Newsgroups: alt.lucid-emacs.help
From: grunwald@mumble.cs.colorado.edu (Dirk Grunwald)
Subject: Re: Mouse enhancements for buffer-menu mode
Reply-To: grunwald@foobar.cs.colorado.edu
Organization: University of Colorado at Boulder
Date: 2 Sep 92 12:26:28


>>>>> On Wed, 2 Sep 1992 11:47:45 EDT, weiner@pts.mot.com (Bob Weiner) said:


BW> Garr Lystad <lystad@m2.dseg.ti.com> wrote:
GL> I give up!  With something like Hyperbole apropos would do no good.
GL> The location moused determines what happens within a single mode.
GL> Even the basic ideas of what is useful on the mouse is different.
GL> In the case of mouse commands I will keep my bindings to myself in the
GL> future.  I've been using Zmacs for 9 years and I guess I'm just too
GL> old a dog to learn more new tricks than necessary.  

BW> I must have lost the thread here.  Could you clarify what you are
BW> saying here (especially the first and third lines)?  I can't
BW> respond because I and I suspect others don't know what you mean.
--

I think he's saying you can't tell what the mouse buttons are going to
do before you do something.
Newsgroups: alt.lucid-emacs.help
From: adatta@cadillac.siemens.COM (Amitava Datta)
Subject: Addition to the mailing list.
Organization: WU Mail/News Gateway
Date: Tue, 1 Sep 1992 19:21:25 GMT


Please add me to the mailing list. Thank you.

Amitava Datta (adatta@siemens.com)
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Fri, 28 Aug 1992 09:40:30 EDT
Date: Thu, 27 Aug 1992 13:30:17 PDT
X-Windows: Warn your friends about it.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: Mouse enhancements for buffer-menu mode
	<LYSTAD.92Aug27090446@m2.dseg.ti.com>
Newsgroups: alt.lucid-emacs.help
We have been trying to stay consistent with the following guidelines:

	button1 moves point
	button2 "selects" or "opens"
	button3 pops up a menu of all your choices

It would be good if others could try to be consistent with this as well,
because otherwise nobody will ever know what their mouse is likely to do
from one mode to another.

	-- Jamie
From: c23mts@kocrsv01.delcoelect.com (Mike Scheidler)
Newsgroups: alt.lucid-emacs.help
Subject: Mouse enhancements for buffer-menu mode
Date: 26 Aug 92 16:58:53 GMT
Reply-To: c23mts@kocrsv01.delcoelect.com
Organization: Delco Electronics Corp.
Originator: c23mts@kocrsw12


Here are a couple of mouse-based functions I use with buffer menu mode.
They're not elegant or complicated, but they make my life a little easier.

I have these new functions mapped to buttons 2 and 3, keeping the default
mapping for button 1.  This lets me switch to the buffer menu window with a
click of button 1 whenever I want to do other buffer menu operations.

Clicking button 2 on a buffer menu line will switch to that buffer, closing
all other windows on that screen.  (This is just like pressing '1' on the
line).  Clicking button 3 in a similar manner will cause the selected buffer
to come up in a new screen and switch focus there.


(defun Buffer-mouse-1-window (event)
  "Switch to buffer in 1 window using mouse."
  (interactive "@e")
  (select-window (event-window event))
  (mouse-set-point event)
  (switch-to-buffer (Buffer-menu-buffer t))
  (bury-buffer (other-buffer))
  (delete-other-windows))

(defun Buffer-mouse-new-screen (event)
  "Switch to buffer in a new screen using mouse."
  (interactive "@e")
  (select-window (event-window event))
  (mouse-set-point event)
  (select-screen (new-screen))
  (switch-to-buffer (Buffer-menu-buffer t)))
 
(define-key Buffer-menu-mode-map 'button2 'Buffer-mouse-1-window)
(define-key Buffer-menu-mode-map 'button3 'Buffer-mouse-new-screen)

-- 
 Mike Scheidler                    INTERNET:  c23mts@kocrsv01.delcoelect.com
 Software Technology               UUCP:      deaes!c23mts
 Delco Electronics Corporation     PHONE:     (317) 451-0642
 Kokomo, IN 46904                  GMNET:     8-322-0642
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Tue, 25 Aug 1992 19:18:38 EDT
Date: Tue, 25 Aug 1992 19:17:05 EDT
From: ex594bw@pts.mot.com (Bob Weiner)
Subject: Will the next version of Lucid Emacs have the following?
Newsgroups: alt.lucid-emacs.help
1.  An operator that returns a list of the extents in a buffer.
    It would be nice to be able to filter this list when making the
    call so that it returned only those extents using a specified
    set of faces.

2.  get-face-<attribute> functions, e.g. get-face-color.
    To match the set-face functions presently available, so one
    doesn't have to parse the face data structure.

3.  A way to delete all extents in a buffer.
    A way to delete all extents with a set attributes in a buffer.
    A way to delete all extents with a particular set of faces in a buffer.

If not, I would suggest that all of these could prove very useful
and should not be difficult to implement.

My experience so far in building Hyperbole support for Lucid Emacs
(which I have done and will release on this mail list and the
hyperbole list after a short personal testing period), is that it is a
good bit more difficult than producing the same support for Epoch.
Which is just to say that the Epoch zone/style API seems more mature.
An easy way to get Lucid Emacs there is just to compare how simply the
zone/style functions in Epoch can be done using extent/face operators
in Lucid Emacs and to plug any holes found.  This should be a much
more efficient process than trying to figure out from scratch what
operators Lucid Emacs should have.

Bob

x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Thu, 27 Aug 1992 20:35:54 EDT
Date: Thu, 27 Aug 1992 20:29:28 EDT
From: weiner@pts.mot.com (Bob Weiner)
Subject: How can I make a variable screen-local?
Reply-To: bob_weiner@pts.mot.com
Newsgroups: alt.lucid-emacs.help
It would be useful to make screen-title-format have a different value
for different screens.  I can't find a 'make-screen-local-variable' or
any such function, though.

Is there a way to do it?
Newsgroups: alt.lucid-emacs.help
From: lystad@m2.dseg.ti.com (Garr Lystad)
Subject: point-to-register
Organization: TI DSEG, Spring Creek, Plano, Tx.
Reply-To: Garr Lystad <lystad@m2.dseg.ti.com>
Distribution: alt
Date: Thu, 27 Aug 1992 16:27:17 GMT


The bug mentioned earlier that manifests itself as a problem with
point-to-register not returning the cursor from the minibuffer seems
to be a problem with interactive.  I ran a little test:

(defun xx (char)
  (interactive "cPrompt")
  (message "complete") )

(define-key global-map '(hyper z) 'xx)

The cursor stayed in the minibuffer.

I don't have the time or knowledge to fix the C code, but I have
made the following changes to fix point-to-register.

(defun set-register (char value)
  "Set contents of Emacs register named CHAR to VALUE.
Returns VALUE."
  ;;Next line doesn't fix problem, but change %c to %s and it does, 
  ;; but then the message is more or less useless. gsl 8-27-92
  (message "Point to register: %c" char)
  ;;Next line returns the cursor to the buffer where it belongs. gsl 8-27-92
  (switch-to-buffer (marker-buffer (point-marker))) 
  (let ((aelt (assq char register-alist)))
    (if aelt
	(setcdr aelt value)
      (setq aelt (cons char value))
      (setq register-alist (cons aelt register-alist)))
    value))

Obviously, such switch-to-buffer lines may need to be added to other
(interactive "c...") fuctions to make them work until we have a real
fix.  A lot of them already do something that gets the cursor back to
the buffer where it belongs, however.

  --  Garr
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Tue, 1 Sep 1992 00:52:02 EDT
Date: Mon, 31 Aug 1992 21:50:25 PDT
X-Windows: The joke that kills.
From: jwz@lucid.com (Jamie Zawinski)
Subject: electric font lock mode
Newsgroups: alt.lucid-emacs.help
jody@shell.com writes:
|
|Here's what I did to get emacs 18.58 running with purify and X11R5 on
|Suns.  The changes should be simular for lemacs:

[...diffs deleted...]

|Jody Winston		jody@shell.com
|..!{sun,psuvax1,bcm,rice,decwrl,cs.utexas.edu}!shell!jody
|Consultant to:
|Shell Development Company, Bellaire Research Center
|P.O. Box 481, Room 4205, Houston, TX 77001	(Voice: 713 245-7574)

I tried your changes, Jody, but I got the same results (as related by my last
post with the core trace).  

Has anyone succeeded in running lemacs with purify?

-- 
Milo Chan,  Fixed Income Market Strategies,  J.P. Morgan Securities, Inc.
email:   chan_milo@jpmorgan.com    ...or...   chan@fractl.tn.cornell.edu
phone:   212.648.4483              ...or...          212.648.4486 (sec'y)
Newsgroups: alt.lucid-emacs.help
From: kemmer@netcom.com (Todd Kemmerling)
Subject: Re: Will the next version of Lucid Emacs have the following?
Date: Wed, 26 Aug 92 16:48:31 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 


x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Wed, 2 Sep 1992 14:57:42 EDT
Date: Wed, 2 Sep 1992 11:55:57 PDT
X-Windows: Complex nonsolutions to simple nonproblems.
From: jwz@lucid.com (Jamie Zawinski)
Subject: Re: Mouse enhancements for buffer-menu mode
	<GRUNWALD.92Sep2122628@mumble.cs.colorado.edu>
Newsgroups: alt.lucid-emacs.help
In message <GRUNWALD.92Sep2122628@mumble.cs.colorado.edu> Dirk Grunwald wrote:
>
> I think he's saying you can't tell what the mouse buttons are going to
> do before you do something.

Another way to implement context-sensitive mouse clicks would be to attach
keymaps to extents or faces.  Instead of having a mouse button bound to a
function which did some kind of context-sensitive dispatching, this
dispatching could be encoded in the keymap structure.  When something like
hyperbole saw something that looked like a pathname, it would put that text in
a face which had a particular set of pathname-specific bindings.  Something
that looked like a network address would have a different set of bindings.

If faces had keymaps, then this would let you have different *key* bindings
depending on the position of the cursor, as well as attaching different mouse
bindings to different buffer positions.

	-- Jamie
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Wed, 2 Sep 1992 12:10:34 EDT
Date: Wed, 2 Sep 1992 12:04:19 EDT
From: weiner@pts.mot.com (Bob Weiner)
Subject: Re: Patch to fix Hyperbole smart key handler bug under Lucid Emacs.
Newsgroups: alt.lucid-emacs.help
I seemed to be having trouble with mail last week, several
   indications of bounced mail led me to resend my request twice. In
   any case, I got no response and still have been unable to install
   hyperbole with lemacs patches under lemacs 19.1.

   I have several questions:

   Do all hyperbole files need recompilation?

No just the ones that have change and were included in source
form only.

   There was a byte
   compiler issue early on with hyperbole and lemacs, is it
   resolved?

I haven't noticed any problem.  Again, if you want to point
something out, be very explicit about it so everyone knows
precisely what you are talking about, e.g. you don't explain
what the problem was.

   If all the hyperbole files should be recompiled, what
   is the best strategy for doing so? 

You could move files you don't use out of the directory and
then byte compile the directory if you ever have a need.

   Do I need to setq something to
   indicate the lack of epoch or wais?

No, during runtime Hyperbole should take care of this, but
there is no specific byte compile procedure which checks whether
or not something should be compiled under this version of emacs.

   In the hyperbole tar file on wilma.cs.brown.edu there is a shar
   file in the tarfile called BUT-COMPILE.shar, does it need to be
   applied before/after the lemacs hyperbole patch?

I don't recall what it is.  I would say no.

Bob
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Tue, 25 Aug 1992 14:02:56 EDT
From: chan@jpmorgan.com (Milo A. Chan)
Subject: Re: purify & lemacs
Date: Tue, 25 Aug 1992 14:01:19 EDT
X-Mailer: ELM [version 2.3(JPM) PL11]
Newsgroups: alt.lucid-emacs.help
From the Purify User's Guide:

"What Purify Does
 ----------------

Purify intercepts every memory access by inserting instructions into your
executable before every load and store.  Purify detects memory corruption
when it happens.  The origin of the problem is immediately and precisely
identified, by line number in the source code, making error correction quick
and easy.

Purify detects the following errors and pinpoints their origins:

    o	Reading or writing memory beyond the bounds of an array.
    o	Reading or writing freed memory.
    o	Freeing memory multiple times.
    o	Reading and using uninitialized memory.
    o	Reading or writing through null pointers.
    o	Memory leaks.


Purify finds these errors in the entire program  including third party
libraries which are linked with your code.  Because purify uncovers memory
access errors and memory leaks in all of the code used by a program, you can
change and improve your code with less fear of interducing new,
hard-to-detect errors."


The most basic usage of purify requires no code changes, just relink and run.


(I am not affiliated in any way with Pure Software Inc.)


-- 
Milo Chan,  Fixed Income Market Strategies,  J.P. Morgan Securities, Inc.
email:   chan_milo@jpmorgan.com    ...or...   chan@fractl.tn.cornell.edu
phone:   212.648.4483              ...or...          212.648.4486 (sec'y)
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Wed, 2 Sep 1992 15:17:04 EDT
Date: Wed, 2 Sep 1992 15:17:37 EDT
From: ex594bw@pts.mot.com (Bob Weiner)
Subject: Re: Mouse enhancements for buffer-menu mode
Reply-To: bob_weiner@pts.mot.com
Newsgroups: alt.lucid-emacs.help
> 
> >>>>> On Wed, 2 Sep 1992 11:47:45 EDT, weiner@pts.mot.com (Bob Weiner) said:
> 
> 
> BW> Garr Lystad <lystad@m2.dseg.ti.com> wrote:
> GL> I give up!  With something like Hyperbole apropos would do no good.
> GL> The location moused determines what happens within a single mode.
> GL> Even the basic ideas of what is useful on the mouse is different.
> GL> In the case of mouse commands I will keep my bindings to myself in the
> GL> future.  I've been using Zmacs for 9 years and I guess I'm just too
> GL> old a dog to learn more new tricks than necessary.  
> 
> BW> I must have lost the thread here.  Could you clarify what you are
> BW> saying here (especially the first and third lines)?  I can't
> BW> respond because I and I suspect others don't know what you mean.
> --
> 
> I think he's saying you can't tell what the mouse buttons are going to
> do before you do something.
> 

If so, then the Hyperbole manual explains that being able to tell
what a entity will do before you use it is important to the Hyperbole
design.  With the mouse keys, one simply depresses the smart key you
plan to use over the entity you want, and then while still holding
the first key, press the other smart key.  Then you can release them as you
like.

What you'll see is a description of what will happen at that location
when you click the first key.  It's quite easy to use once you try it.

Search for 'mouse' in the index should get you the appropriate information.

Bob
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Fri, 4 Sep 1992 15:19:06 EDT
Date: Fri, 4 Sep 1992 21:17:31 +0200
From: h.b.furuseth%usit.uio.no@lucid.com
Subject: Re: tags-query-replace
Newsgroups: alt.lucid-emacs.help
From: irvine@ntmtv.UUCP (Chuck Irvine)
Subject: How Download Lucid Emacs
Organization: Northern Telecom Inc, Mountain View, CA
Date: Fri, 4 Sep 1992 17:48:50 GMT

I was recently made aware of some pretty nice enhancements Lucid has done
to GNU Emacs. The really nice part, I was told, is that is it's available
free! Could someone please provide me with the information on how to get
access to it? Much thanks.

Chuck Irvine
x-gateway: rodan.UU.NET from help-lucid-emacs to alt.lucid-emacs.help; Thu, 27 Aug 1992 20:16:19 EDT
Date: Thu, 27 Aug 1992 20:08:26 EDT
From: weiner@pts.mot.com (Bob Weiner)
Subject: Re: Mouse enhancements for buffer-menu mode
Reply-To: bob_weiner@pts.mot.com
Newsgroups: alt.lucid-emacs.help