[7824] in Athena Bugs
7.3 System Release Notes (24 Jul 91, 12:11)
daemon@ATHENA.MIT.EDU (ckclark@ATHENA.MIT.EDU)
Fri Jul 26 15:50:17 1991
From: ckclark@ATHENA.MIT.EDU
Date: Fri, 26 Jul 91 15:50:07 -0400
To: dryfoo@ATHENA.MIT.EDU
Cc: testers@MIT.EDU
In-Reply-To: dryfoo@ATHENA.MIT.EDU's message of Fri, 26 Jul 91 14:34:30 EDT <9107261834.AA19255@thelonious.MIT.EDU>
Reply-To: ckclark@MIT.EDU
>>>>> On Fri, 26 Jul 91 14:34:30 EDT, dryfoo@ATHENA.MIT.EDU said:
dryfoo> 1) Section 2.3 -- "The following is a list of files that are commonly
dryfoo> reference by absolute pathnames..."
dryfoo> The list includes /usr/athena/emacs, should it also
dryfoo> include emacsclient ?
(I *knew* it, Richard. I *told* you somenone point out the
inconsistency in having a compatibility symlink for emacs but not for
emacsclient!)
At the time we decided to provid a compatibility symlink for emacs, the
was only about two other programs which we said we needed symlinks for,
and the goal was to keep these to a minimum. Since then the philosophy
has changed so that it seems we provide symlinks from everywhere to
everywhere else. It would be foolish to think that adding one more for
emacsclient would hurt. The argument for not including it was, I quote,
``Anyone who references emacsclient created that reference themselves
and knows how to fix it.''
dryfoo> 3) 2.6 Emacs version 18.57, "Selection, cut, and paste works like x
dryfoo> term"
dryfoo> Not really:
dryfoo> -- Drag-Left-button doesn't seem to select
dryfoo> -- Selecting still doesn't hi-light ("Of course it doesn't
dryfoo> high-light," you reply, "Emacs never high-lights." But we've
dryfoo> never advertised "works like xterm" before.
Now that I think about it, you're right; it is wrong to say that, both
technically and intuitively. Perhaps nothing should be said about it at
all. It just "is". Or just take out the part about it being like
``xterm''. It's not, really. Not at all.
dryfoo> 4) 2.6 Emacs version 18.57, "Ctrl-Shift <middle-button> ... will bring
dryfoo> up help menus"
dryfoo> Doesn't seem to.
It may be that your window manager can override that if you have a
window manager function bound to that sequence. It works for me. (The
light bulbs work on *our* system :-) I'll look into it.
dryfoo> 8) New Emacs release (change not mentioned in notes) -- Under some
dryfoo> circumstances, fill-paragraph no longer removes extra spaces in
dryfoo> a line. I can't reproduce this regularly yet, but you might
dryfoo> keep your eye out for reports of this behavior.
Thanks for mentioning it. If you come up with an easily repeatable
example of the bug, please send me mail. I'll check to see if anyone
else has reported similar behavior to the FSF lists.
