[Openmcl-devel] openmcl 1.0 vs. GUI

[Hamilton Link]

No feedback IS feedback.  It means that people don't think it's good 
enough to bother with yet, and I know why I personally don't think it's 
worth bothering with yet, and I've said why before: speed.  Oh, and 
pretty often the last time I used it it was still throwing errors 
subtly suggesting I should Save Often.

I will download and try the latest version, but my criteria for an 
editor for lisp, in priority order, are:

1) keystroke response is faster than 50 wpm (= 300 cpm = 5cps -> at 
least a 5Hz response rate)

2) no warning messages, dead windows, or worrying about data loss
3) emacs keybindings
4) reasonable listener integration (eval, and the longer-term potential 
for eval-and-inspect, trace-this, who-calls, etc.)
5+) bells and whistles (sexp selection, syntax highlighting, etc.)

And in general I'd settle for #1, wait patiently for #2-3 and live a 
very long time without #4-6 (I use emacs without slime 99% of the time, 
and it's still better than using Hemlock).

I was using the editor on and off for several months (and consistently 
for maybe a month), and complained about the editor's speed and made 
some attempts at fixing it basically that entire time.  Then a few 
changes got made by several people that improved things to "nearly 
acceptable," except for indentation, which was (is?) still slow for 
nested forms.  Then I got sidetracked and the GUI wasn't worth fussing 
with while I put out other fires, so I reverted to emacs.

I guess my points are two-fold.  One is please put in the indentation 
fix unless you can assure me that using your other methods all buffer 
updates happen inside of 5Hz (and imho if you have to resort to the 
tricks you mention Hemlock's still doing something very wrong, my email 
client doesn't have any of those limitations and it's perfectly speedy, 
as is Fred and most every editor I've ever used other than Hemlock).  
The other is until the editor, backtrace, and listener (ranked 1/2/3) 
are solid and responsive I predict people will continue to use openmcl 
solely from the command line or via slime, along with emacs or vi.

So don't waste your time on the documentation manager etc. which came 
in tied for positions 6/7/8.  Figuring out where effort should be spent 
was the whole point of doing that survey.

Like I said I will resume using the GUI environment but until the top 
three things are solid the GUI is going to continue lose out to slime 
and you should interpret the near total silence of the potential user 
base as equivalent to feedback along those lines.

hamilton

On Aug 28, 2005, at 9:13 PM, alex crain wrote:

>
> On Aug 28, 2005, at 8:54 PM, Gary Byers wrote:
>>
>> One change that I'd made to the bleeding-edge version around the time
>> that you announced your version is to try to defer redisplay until
>> after a simple editing command completes.  (As the code is written,
>> redisplay is attempted after every buffer modification; that's clearly
>> wrong, and the change I introduced at least muffles that so that you
>> don't see a lot of hyterical redisplay when an editing command (like
>> indentation) makes a lot of individual buffer changes.)
>>
>> That (fairly simple) change does seem to improve usability quite a
>> bit.  To some degree, it's a bandaid on a deeper problem, and I have
>> some concerns about whether it'd be simpler and better to run
>> editor commands in the event thread.  We've discussed this a little,
>> and should probably discuss it more.
>
> I admit that I've been resisting this change and I'm not convinced that
> it's necessary. The current GUI does a couple of things to improve 
> performance:
>
> 1) 1 font per buffer - only color changes allowed, no bolding or 
> italics.
> 2) buffers a always aligned on line boundaries
> 3) changes are restricted to the current visible area
>
> There is still some horrible code that handles the syntax 
> highlighting, but otherwise
> it's pretty quick and this makes buffer changes pretty efficient. I'm 
> thinking that
> the text system should be able to keep up with Hemlock and Hemlock is 
> already
> pretty smart about buffer updates, since it was designed for slow 
> terminals.
>
> I could always be wrong, of course, but I would hate to introduce 
> jumpy text unnecessarily
> and I'm afraid that your change may have unintended side effect on 
> extended commands,
> like recursive edits or incremental searches.
>
> :alex
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>