[Openmcl-devel] IDE directions

[Hamilton Link]

> Now, we know something that NSLayoutManager does not know, in that we 
> are using a fixed width font. It seems likely that this will always be 
> the case, as working with variable fonts in a programming editor is 
> evil, so I've been looking for a way to explain that to the layout 
> manager  so that it will simply shift all the glyphs on a line over 
> one and do the insertion.

We also should know when line-wrapping is turned on or not. It might be 
easier to at first only enable your feature when wrapping is off, 
dunno. Neat hack though, hope you figure out how you did it.

On Aug 28, 2004, at 7:16 PM, alex crain wrote:

> I've been working on the IDE and digging through the hemlock code and 
> I'm getting ready to do some actual coding. With that in mind, I want 
> to get a consensus on some design decisions.
>
For stuff that won't fit in the mode line (long arglists, most apropos, 
help, etc.) I think #3 gets my vote. I'd say let the existing code 
that's in place to handle this sort of thing handle it, but rebind 
*terminal-io* to your special stream that pipes out to your #3 window. 
Then code that normally prints to the command line window will be 
slurped off to your window and won't have to change in the back end 
(you know, assuming it can be set up that way in a reasonable fashion).

h

> In an effort to improve my familiarity with the code I've been working 
> on the command processor and I'm implementing the Random Typeout 
> streams so that thing like help and error messages have a place to go.
>
> There are a couple of ways to approach this. These streams are 
> typically transient messages that show the results of certain commands 
> like ^H-a (help apropos). Emacs handles it by splitting the window and 
> putting the data into a buffer, for example.
>
> Sometimes the data can be quite long, like when describing a mode with 
> all the key bindings, so putting the text in some kind of scrolled 
> window make sense.
>
> With that in mind, there are a few options:
> 1) use modal transient popups for these messages. The upside is that 
> you get one message per popup and the popups are tied to a specific 
> window. The windows don't need to be popups, they could easily be 
> window shades like the current error messages. The downside is that 
> you would have to close the message window before going back to work 
> but they could be easily closable, like with a modal button tied to 
> the return key.
>
> 2) Use non-modal popups. This means that you could leave the messages 
> up for reference but if you were editing multiple files it might 
> clutter things up a bit.
>
> 3) Use a common typeout window for everything. I'm thinking that when 
> you booted up the IDE, a typeout window would be created and perhaps 
> hidden with a toggle under the "Window" menu. When you do something 
> that causes typeout, the typeout window would be raised and display 
> the message.
>
> I'm leaning towards #3. Does anybody love/hate this idea?
>
> :alex
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>