Article View: gnu.epoch.misc
Article #1087Re: Separate minibuffer in the Epoch/Lucid merge
From: Colin Smiley
Date: Thu, 25 Feb 1993 21:55
Date: Thu, 25 Feb 1993 21:55
59 lines
4025 bytes
4025 bytes
In article <9302250727.AA05013@epls01.sa.erisoft.se> Jan.Djarv@sa.erisoft.SE (Jan Djarv) writes: > Jamie mentioned to me that the separate minibuffer feature might go > away when the greate epoch/lucid merge occurs. I for one, and at > least some of my users would greatly prefer to keep a separate > minibuffer as an option. It is so handy to have one large minibuffer, > particularly when you have smallish windows (say 40 columns or so), > and want to do a find-file-other-screen. Please don't remove the separate minibuffer feature. I find it quite handy. If you have very long pathnames, and wan't to see the whole path, you just resize the minibuffer instead of the whole window. I've also got used to having the minibuffer at the top of my screen. My eyes automatically go there whenever I do something minibufferish. Switching to the old emacs style has become a real pain (when epoch isn't available, i.e no X). I find myself looking all over for the minibuffer until I realize where it is :-). Please, oh please keep the minibuffer! For me it is a major win over both Lucid Emacs and vanilla Emacs (hee). It seems I always have more than one screen up (thanks to gnuclient), and it is so much easier to deal with a centrally located *single* minibuffer (now if we could only put a scrollbar on it... :-) ). Also, since it seems the flame wars between Lucid Emacs and vanilla Emacs 19 are getting ready to start again, let me get my two cents into the fray now. There are two major things keeping me from using Lucid Emacs. 1) Lack of minibuffer support. 2) The innability to share elisp files as well as Epoch and vanilla Emacs do. I can only hope that the latter will change when Emacs 19 comes out. Now what about the former? As for the apparent bad blood between Lucid and RMS, I don't think it is making either side look any better than the other. I think it's bad because Emacs as a whole is what's going to end up getting hurt. From a strictly outsider/user point of view it appears that Lucid was hurrying things to get their product out, thus the apparent rushing of the emacs 19 development, and the lumping in of features that RMS was unsure of/didn't know about. By the same token, I don't think RMS wanted any one entity other than himself and the FSF to have too much design control over Emacs. Please (and I am going to sound like a politician or something by saying this), for the good of Emacs as a whole try to make some sort of compromise, huh? As for Epoch, I see it as a possible way to unify the two peacefully. Any thoughts? Colin -- ------------------------------------------------------------------------- Colin Smiley, Compaq Computer Corporation, Houston, Texas 77269-2000 e-mail: smiley@compaq.com Phone: (713) 378-8426 ------------------------------------------------------------------------- Disclaimer: Any opinions expressed here do not reflect the opinions of Compaq Computer Corp. They make computers. I make noise.
Technical Details
Message-ID:
<SMILEY.93Feb25155523@maharet.im.hou.compaq.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!stanford.edu!agate!howland.reston.ans.net!usc!cs.utexas.edu!wotan.compaq.com!twisto.eng.hou.compaq.com!ce1test.eng.hou.compaq.com!smileyReferences:
<9302250023.AA11945@curley.osf.org> <9302250727.AA05013@epls01.sa.erisoft.se>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fc7ee,eb824aff1801c135 X-Google-Attributes: gidfc7ee,public X-Google-ArrivalTime: 1993-02-25 13:55:23 PST Newsgroups: gnu.epoch.misc Path: arc1-ca.pugleaf.net!sparky!uunet!stanford.edu!agate!howland.reston.ans.net!usc!cs.utexas.edu!wotan.compaq.com!twisto.eng.hou.compaq.com!ce1test.eng.hou.compaq.com!smiley From: smiley@maharet.im.hou.compaq.com (Colin Smiley) Subject: Re: Separate minibuffer in the Epoch/Lucid merge Organization: Compaq Computer Corporation In-Reply-To: Jan.Djarv@sa.erisoft.SE's message of 25 Feb 1993 03:37:32 -0500 References: <9302250023.AA11945@curley.osf.org> <9302250727.AA05013@epls01.sa.erisoft.se> Nntp-Posting-Host: maharet.im.hou.compaq.com Message-ID: <SMILEY.93Feb25155523@maharet.im.hou.compaq.com> Distribution: gnu Sender: news@ce1test.eng.hou.compaq.com (Netnews Account) Date: Thu, 25 Feb 1993 21:55:23 GMT Lines: 60