🚀 go-pugleaf

I've been using emacs 19.8 for almost a whole day now.

Things I like, relative to epoch:
vanilla configuration and building is easier
scroll bars
binding X keys is easier, more intuitive
documentation on X things is better (at least in info)
mouse pop-up menus (control-mouse-1 pops up a "deck of cards" menu,
  from which you can do just about anything)

Things I don't like:
custom configuration and building is harder
apparently won't do mouse-drag hiliting
can't underscore regions on mono displays
  (but you can change the color or invert the region)
doesn't run on my Apollo (but I can fix that)
mouse use is less intuitive (but can be changed)

I also can't figure out how to get it to work the way I like to use epoch,
which is to have a single minibuffer, and each buffer in its own window.  I
think this can be done but I haven't figured it out yet.  It's got a
variable you can set to give each buffer its own window ("screen" in epoch
terminology, "frame" in emacs, "window" to X) but it doesn't really work
the way I want.

For now I'm going to stick with epoch.

There are apparently some political bugs with emacs as well.  For example,
the code to make emacs run on Apollo Domain/OS has been around for years,
but rms refuses to incorporate it in to emacs without getting signatures on
paperwork from the authors of the Apollo code.  I don't know the details,
but I do know that it was no problem at all getting the Apollo code into
epoch, and epoch runs right out of the box on an Apollo.  I say this not
because I think the Apollo code is so imporant, but because I suspect the
same political considerations might apply to other modifications that could
be just as important.

I'm very happy about the reported merging of epoch with lucid.  I'm familiar
with Leonard Zubkoff's work, and I think a combined epoch/lucid would be
much better (for my purposes) than emacs 19.

In article <CRAFFERT.93May24134516@nostril.lehman.com> craffert@nostril.lehman.com (Colin Owen Rafferty) writes:


   Hello-

   So now that emacs 19.7 has been released, what do we do?  Allegedly,
   it incorporates all of the extra stuff that epoch does.  Is this true?
   If so, when does epoch become obsolete?  If not, what seems to be the
   correct approach.

Well, the real emacs 19 does incorporate some of the features of
Epoch, but not all...  In particular, the x event handling support,
multiple fonts, incremental redisplay, etc of epoch are all NOT in
emacs 19 at this time (although they may be, in the future).  Epoch
is, as far as we're concerned, already obsoleted by Lucid emacs.
We're working on merging with Lucid Emacs because it has some features
(menu bars, widget/Xt base, key events, glyphs, etc) that make it
nicer than both epoch and emacs 19.  So, the next release of epoch
will essentially be the same as a release of lucid emacs, at which
point we'll probably be merging the names too, in some way.


   Can anyone out there who has been involved with development of 19.7
   give any advice as to what approach people may want to take in moving
   back to "real" emacs.

I'm afraid I cannot help you with this...  Lemacs/epoch will be
epoch-compatible, so there is nothing we need to do to address this.

Personally, my feeling on the matter is that epoch was a stopgap out
of necessity until the real emacs 19 appeared.  In the mean time the
emacs world has effectively bifurcated, into those who want emacss
that are stand-alone kitchen sinks with everything in the emacs (the
"real emacs 19 approach") and those who see that emacs has to play a
part in integrated environments in the future, and thus be, and
become, more widgety (the lucid emacs approach).  Since we built epoch
to fill our own research needs, we feel that we should persue things
in the direction most appropriate for us, which is integrated software
process support/collaboration support environments, and lucid emacs
makes more sense to us, so we're pushing our effort in that direction
for now.

Of course, we also would like to move nice features of epoch into the
real v19 too, and we hope to work with RMS on this in the future.
However, FSF have very stringent code input requirements, such as
every patch being motivated.  I applaud this, since they might well
have to maintain the resulting mess, but don't have the time or
resources to provide the epoch-isms to them at this degree of clarity
right now.

Personally, I dont have a strong negative image of one, and positive
image of the other; it's just that for the things that we do, the
Xt/widget direction, key events, menus, etc, makes much more sense.
In many respects, to me, lemacs is what we really should have done
with epoch in the first place.

So:  to all you happy epochers out there:  watch out for an epoch
5.0/lucid merge some time in late summer or early fall.  And if you
want to return to regular emacs, thank you for your support,
encouragement and bug fixes, and I hope that over time this
bifurcation will heal itself.

-- Simon Kaplan
--
Simon Kaplan					kaplan@cs.uiuc.edu 
Department of Computer Science			uiucdcs!kaplan@uunet.uu.net
University of Illinois at Urbana-Champaign	
1304 W. Springfield Ave				phone: +1 217 244 0392
Urbana Illinois 61801, USA			fax:   +1 217 333 3501

In article <1u2npd$atc@terminator.rs.itd.umich.edu> Jim.Rees@umich.edu writes:
>
> I also can't figure out how to get it to work the way I like to use epoch,
> which is to have a single minibuffer, and each buffer in its own window.  I
> think this can be done but I haven't figured it out yet.  It's got a
> variable you can set to give each buffer its own window ("screen" in epoch
> terminology, "frame" in emacs, "window" to X) but it doesn't really work
> the way I want.

	I couldn't figure this out either, and I posted this question
	to 'gnu.emacs.help' to no avail. I hope the epoch/lemacs merger
	will retain this functionality!! As near as I can tell, currently
	neither emacs-19 nor lucid emacs allows one to have a single 
	minibuffer which is shared by all screens/frames and resides in a 
	screen/frame of its own.

> For now I'm going to stick with epoch.

	I think I'll continue using epoch, and see what "lepoch" looks
	like this fall.


							Darrell Schiebel

>>>>> On 27 May 1993 15:36:44 EST,
>>>>> In message <DSCHIEB.93May27153644@muse.cv.nrao.edu>,
>>>>> dschieb@muse.cv.nrao.edu (Darrell Schiebel) wrote:

Darrell> As near as I can tell, currently neither emacs-19 nor lucid
Darrell> emacs allows one to have a single minibuffer which is shared
Darrell> by all screens/frames and resides in a screen/frame of its
Darrell> own.

emacs-19 can do this.

Try executing the following lisp with your original emacs window up:


(progn
  (let ((current-frame (selected-frame)))
        (setq default-minibuffer-frame
              (make-frame '((height . 1)
                            (width . 80)
                            (name . "minibuf")
                            (menu-bar-lines . 0)
                            (minibuffer . only))))
        (setq default-frame-alist
              (cons '(minibuffer . nil) default-frame-alist))
        (make-frame)
        (delete-frame current-frame)))

Or you could put something like the following in your .emacs to have
it happen automagically:

(setq minibuffer-frame-alist
      (append minibuffer-frame-alist
              (list '(minibuffer . only) '(name . "minibuf"))))

(setq initial-frame-alist '((minibuffer . nil)))

In article <DSCHIEB.93May27153644@muse.cv.nrao.edu> dschieb@muse.cv.nrao.edu (Darrell Schiebel) writes:
> In article <1u2npd$atc@terminator.rs.itd.umich.edu> Jim.Rees@umich.edu writes:
> >
> > I also can't figure out how to get it to work the way I like to use epoch,
> > which is to have a single minibuffer, and each buffer in its own window.  I
> > think this can be done but I haven't figured it out yet.  It's got a
> > variable you can set to give each buffer its own window ("screen" in epoch
> > terminology, "frame" in emacs, "window" to X) but it doesn't really work
> > the way I want.
>
>  I couldn't figure this out either, and I posted this question
>  to 'gnu.emacs.help' to no avail. I hope the epoch/lemacs merger
>  will retain this functionality!! As near as I can tell, currently
>  neither emacs-19 nor lucid emacs allows one to have a single 
>  minibuffer which is shared by all screens/frames and resides in a 
>  screen/frame of its own.

	Well, I was wrong, the 'make-frame'/'new-frame' commands give
	everything necessary to have a separate minibuffer, and it seems 
	to do it in a very nice way. I think something like the following
	works:

		(setq default-minibuffer-frame 
		    (new-frame 
		        '((width . 400) (height . 1) 
		          (minibuffer . only))))

	then after that the following will create a minibufferless
	frame: 

		(new-frame '((minibuffer . none)))

	At least this is close to what is required.

							Darrell Schiebel

SK> == Simon Kaplan <skaplan@imbuya.inria.fr>

 SK> Personally, my feeling on the matter is that epoch was a stopgap out
 SK> of necessity until the real emacs 19 appeared.  In the mean time the
 SK> emacs world has effectively bifurcated

Well, the two separate approaches you listed are very true, but it seems
more fragmented than that to me (at least right now).

At the moment there are emacs-18, epoch-4, lemacs-19 and emacs-19.  (We
only have emacs-18 and epoch-4 installed here.)  All four are incompatible
in at least some areas of elisp, though at least emacs-18 and epoch-4 can
share a hunk of elisp (which saves me a hunk of disk space).

The main problem (IMHO) is going to be having an emacs or set thereof that
can share an "environment" (all of those lovely things we toss in our
.emacs files) while still running on both X and tty interfaces (since I'm
not always at my workstation's console).  Right now, emacs-18 and epoch-4
fill that bill.  Hopefully, the future "lepoch-5" will either include a tty
emacs or be compatible enough with one that I can use it; otherwise, I may
wind up using emacs-19 merely to save myself the trouble of maintaining
(and using) two incompatible emacses.

 SK> So: to all you happy epochers out there: watch out for an epoch
 SK> 5.0/lucid merge some time in late summer or early fall.

I'll be waiting.  Keep the separate minibuffer! :)

 SK> And if you want to return to regular emacs, thank you for your
 SK> support, encouragement and bug fixes, and I hope that over time this
 SK> bifurcation will heal itself.

I hope so as well.  I am actually quite interested in the Lucid Emacs
approach, but simply don't have the disk space to devote to yet another
full-blown emacs installation right now.  As I said earlier, I'd rather not
return to "regular emacs" if I can get better X functionality from
"lepoch", but if I have to give up tty use, I may not be able to avoid it.

(Judging from the References: line, this is the third GNUS posting in a row
for this thread.  I sense a pattern here: "those who live within emacs". :)
--
� Christopher Davis � <ckd@kei.com> � <ckd@eff.org> � [CKD1] � MIME � RIPEM �
^ if these characters appear as the number 7 then you don't have ISO-8859-1 ^
^   or something between me and you stripped the high bit on this message.  ^

>>>>> On 27 May 1993 15:46:53 GMT, Jim.Rees@umich.edu said:

Jim.Rees> apparently won't do mouse-drag hiliting

It kind of can do that with transient-mark-mode, but not as nice as
e.g. Lucid. 

Jim.Rees> There are apparently some political bugs with emacs as well.
Jim.Rees> For example, the code to make emacs run on Apollo Domain/OS
Jim.Rees> has been around for years, but rms refuses to incorporate it
Jim.Rees> in to emacs without getting signatures on paperwork from the
Jim.Rees> authors of the Apollo code.

This is a `legal bug', RMS won't use other peoples code without their
written permission.  He has been burned on this issue before.

In article <ABRAHAM.93May28030600@loke.iesd.auc.dk>, abraham@research.att.com (Per Abrahamsen) writes:

  Jim.Rees> apparently won't do mouse-drag hiliting
  
  It kind of can do that with transient-mark-mode, but not as nice as
  e.g. Lucid. 

No, transient-mark-mode is just region hiliting, where the hilite appears on
mouse-up.  Mouse-drag hiliting is different, that's where the hilited area
follows the mouse as you drag.

>>>>> On 28 May 1993 17:16:58 GMT, Jim.Rees@umich.edu said:

Jim.Rees> No, transient-mark-mode is just region hiliting, where the
Jim.Rees> hilite appears on mouse-up.  Mouse-drag hiliting is
Jim.Rees> different, that's where the hilited area follows the mouse
Jim.Rees> as you drag.

What I ment was that you can select a region by draging the mouse, and
you can highlight the region.  I don't think Emacs 18 could do any of
those.  I agree that highlighting the region *while* dragging the
mouse it better, and that is why I said Emacs `sort of' supported it.

What *exactly* can epoch do which emacs19 cannot?  Here is a list,
please flag errors if emacs can do these things (with a dash of elisp)
or if there are epoch features you rely on that emacs19 can't support.
I think it comes down to more X awareness and some nice hooks.


EVENTS:
property-change
map
move
resize
client-message

X STUFF:
get/set property
intern atoms
conversions
(un)grab pointer
mouse pointer move/query
rebind keys
query tree
send client message

HOOKS:
create-screen-alist-hook
select-screen-hook
after-movement-function
after-update-hook
window-select-hook
set-window-buffer-hook

FONTS:
variable width fonts


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

Are you depressed because you finally get epoch working just the way
you want, and now you feel obliged to switch to emacs-19?  Are your
friends teasing you because your editor doesn't have scrollbars and
drop down menus?  Or perhaps you think that the emacs widgets are so
ugly that you don't want them on your nice color screen?

WS is a widget server designed for use with epoch, the X-aware
extension to emacs written by the good folks at UIUC.  WS provides a
drop down menu bar at the top of the epoch screen, and a single scroll
bar at the right edge of the screen.  The scroll bar moves the
currently selected window in the associated screen.  Menu commands are
normally executed in the context of the screen where you did the menu
selection.

WS is the Tk wish application extended with a new widget class (XENO).
Tk and its companion Tcl provide a flexible environment for Xwindows
widget handling.  New widgets such as panels, listboxes, etc. may be
built in Tk/Tcl and interfaced to epoch via WS.  


All comments are welcome, on any subject from algorithms to func names.


COPYRIGHT:

Almost none.  I ask that you credit me on this and derivative works.
Usage and distribution is unlimited.


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


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