ram-ashwin@YALE.ARPA.UUCP (06/11/87)
> It doesn't bother you that the DM editor does not have word wrap, that > basic of text processing services? > > Nope, doesn't bother me a bit. That is what troff is for. Huh? We're talking about automatically going to a new line when you reach the end of a line (or some predefined right margin) while you're typing. Ain't seen a troff that does that yet. This is probably the single biggest annoyance in the DM editor (from the point of view of simple text entry). Well, one of the many single biggest annoyances anyway :-). I'd be happy to list some others -- no incremental search, repeat search gets screwed up if any other macros use search (e.g., delete word), window jumps around madly if you try to balance a paren that's off the current window region, can't undo undoes, filename completion, ... . (I count undoing undoes, filename completion, etc., as nice features even for "simple text entry" because even novices who are shown these features on Emacs like and use them.) I don't wish to flame; I only hope that Apollo does something about stuff like this (since I sure don't want to give up these wonderful machines). -- Ashwin.
ram-ashwin@YALE.ARPA (Ashwin Ram) (06/13/87)
> From: Giebelhaus@hi-multics.arpa > > I wouldn't mind if the DM had more functionality, but I don't want it to > be as slow as Emacs. I like having a quick and dirty editor and a high > power editor. I agree... I like fast editors too. Must a native Emacs be slow, however? What do people who've used ZMACS on the Symbolics machines feel about this? Does it feel sluggish to use? -- Ashwin.
nazgul@apollo.UUCP (06/14/87)
In article <8706122102.AA01290@yale-celed.arpa> ram-ashwin@YALE.ARPA (Ashwin Ram) writes: > > From: Giebelhaus@hi-multics.arpa > > > > I wouldn't mind if the DM had more functionality, but I don't want it to > > be as slow as Emacs. I like having a quick and dirty editor and a high > > power editor. > > I agree... I like fast editors too. Must a native Emacs be slow, however? > What do people who've used ZMACS on the Symbolics machines feel about this? > Does it feel sluggish to use? > > -- Ashwin. Well, once upon a time it wasn't, but the most recent versions certainly are. I have a friend who works on them and she complains that every release is slower (and incompatible with the last). At the lastest release they now have transcript pads with ZMACS commands working in them - and scrolling just got much slower. I don't think that an integrated EMACS *has* to be slow, but that's certainly my perception of Symbolics. (I would imagine that further discussion in this direction should not continue in this group. Aegis vs. Unix is bad enough, let's not start fighting about Symbolics as well. :-) -kee -- UUCP: {mit-erl,yale,uw-beaver}!apollo!nazgul ARPA: apollo!nazgul@eddie.mit.edu I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
ram-ashwin@YALE.ARPA (Ashwin Ram) (06/17/87)
> From: Robert Stanzel <rps@apollo.UUCP> > > I'd be happy to list some others -- no incremental search, repeat search gets > screwed up if any other macros use search (e.g., delete word), window jumps > around madly if you try to balance a paren that's off the current window > region, can't undo undoes, filename completion, ... . > > I agree with all your wishes. I've been pining for word wrap and a search > stack since I came here. > > For gosh sakes man, submit ucr's! Read crucr.hlp to see how to submit them > over the network -- you can't ask for more convenience. I agree that we users should submit UCRs. But UCRs are pretty complicated. Much of the information that they ask for (barring section 13 and perhaps 15) is unrelated to software bug reports. Why not work on the "apollo" mailing list gripes too? If I were filing a UCR, I'd write exactly the same thing in section 13 as I would if I were mailing to "apollo". Why is one any more of a bug report than the other? The point is that the more complicated you make the procedure, the less feedback you'll get. Most non-system-administrator-type users don't bother to fill out UCRs and things like that, though many will mail stuff to forums like this. (I'm not saying that they're right; I'm only making a comment about user psychology.) > Particularly, I wish > you'd submit a bug report for the "window jumps around madly if you try to > balance a paren that's off the current window region" bug -- I mentioned it > internally, and it was regarded as a wishlist-bug. Does submitting a UCR make the difference between a "wishlist-bug" and a real bug (whatever that is)? Are UCRs only for real bugs? What do we do with genuine wishlist-bugs then? The point is the same -- it's to Apollo's advantage to make the feedback procedure as simple as possible, and to work on bugs/wishes expressed through mailing lists as well as those filed "officially" through the UCR mechanism. > (Aside: I'm still a little > irked at you Yalies, because you bludgeoned us into doing paren balancing the > WRONG WAY! -- that is, not the Emacs way. I can't STAND it when I type a > right-paren on top of an existing balanced paren (either flavor) and it just > matches the paren rather than inserting a new one! I reported this as a bug > and I got back "this is the way Yale wants it"! Arghh! End miniflame :-) That's funny... I hacked my Emacs to do balancing the DM way (even though I was using Emacs much before the DM)! When I'm modifying already existing code, I find it useful to hit ")" on existing parens to check if they balance correctly (I don't want new ones inserted if they do). Of course, when the cursor bounces to the *right* when you hit BL on a *left* paren... that's a bug. Also, BL should insert a right paren with a "unbalanced" message even if it is unbalanced, rather than just error out. But this is a matter of taste -- the problem with the DM is that it isn't customizable (e.g., BL) or extensible (e.g., it is impossible to write a DM command that will intelligently "visit/find" a file (edit it if you can, read it if you don't have edit rights, create it if it doesn't exist, pop to it if it's already open)). > Regarding filename completion -- trivial to implement. I'd send it to you > if I had it packaged up right ... I suspect many people have various hacks (like your filename completion; also the history hacks that people posted recently) to do various neato things. Many of these would never be revealed if people didn't flame on the "apollo" mailing list but started submitting UCRs instead. BTW, if you ever get around to packaging it up right, do let me know. I'll trade it (:-)) with our keydefs (initially due to Eric Jones) to do repeat searches correctly even if other commands use search. -- Ashwin.
peterson@utah-cs.UUCP (John W Peterson) (06/18/87)
>> >>> I'd be happy to list some others -- no incremental search, repeat search >>> gets screwed up if any other macros use search (e.g., delete word), >>> window jumps around madly if you try to balance a paren that's off the >>> current window region, can't undo undoes, filename completion, ... . >> >> I agree with all your wishes. I've been pining for word wrap and a search >> stack since I came here. >> >> For gosh sakes man, submit ucr's! Read crucr.hlp to see how to submit them >> over the network -- you can't ask for more convenience. > > Does submitting a UCR make the difference between a "wishlist-bug" and a > real bug (whatever that is)? Are UCRs only for real bugs? What do we do > with genuine wishlist-bugs then? > After seeing this message, I dug through my file of UCR's. I sent a UCR complaining about several lossages in the DM (poor customizability, no extensibility, no right margin, cryptic interface, etc.) I sent it in April of 1985. I got a response of "...yeah, we'll look into that." Two years later all the deficiencies are still there. Moral: Use emacs and/or the X window system. ps - I don't know if it's the same thing, but I wrote a filename completion package for the shell (which Yale further modified). I'm pretty sure there's a copy on the ADUS tape, and I think it's also in the UCLA archive. pps - Although it's not real word wrap, I came up with the following hacks to fill paragraphs in the DM: kd f1 [,76];\ \;ed;en;tr ke kd f1s ed;es ' ' ke Press F1 to wrap a line that's too long, and press shift-F1 to join a line that's too short (you must be at the end of the short line). You can alternate between the two to quickly clean up a paragraph.
ram-ashwin@YALE.ARPA (Ashwin Ram) (06/19/87)
> From: peterson@cs.utah.edu (John W Peterson) > > I don't know if it's the same thing, but I wrote a filename completion > package for the shell (which Yale further modified). This is pretty useful, but it only works from a shell, not the DM command window (where it's needed to complete filenames for READ, EDIT, etc.) It should be pretty easy to generalize this using Robert Stanzel's CP -W trick, however. > Although it's not real word wrap, I came up with the following hacks > to fill paragraphs in the DM: DM_FORMAT does this (and other stuff like justify and center) and is even easier to use. It's in Scott Turner's UCLA archives. -- Ashwin.