[vwnc] 'Undo' don't work properly.

Going further with what Karsten wrote.

The code highlighter indicates many errors even before the
user attempts to compile the code. By adding the error message
to the error emphasis more information can be provided to
the user as a tool tip. Furthermore, if the highlighter detects
what would be a fatal error, i.e. syntax error, the "Accept"
command could be disabled.

Terry
 
===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Jan 22, 2010, at 12:59 AM, Karsten wrote:


Yes, it's definitely something that needs to be fixed/improved.

--
Travis Griggs
Objologist
"Every institution finally perishes by an excess of its own first  
principle." - Lord Acton



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I agree with the general sentiments and suggestions. I don't want  
anyone thinking that the code editing experience is the way it is,  
because I actually prefer it that way. I'd love an xcode like editing  
experience. As well as ideas pulled from other places. I don't like  
the in place error messages. I don't like the text editor not having  
an undo stack. As always, it's time and resources and priority, and  
all that good stuff, that I know all of you experience to some degrees  
in your own projects. One of the frustrations with the biannual  
discussion of the text editor, is that it is about 3 months out of  
phase with the biannual lookandfeel/widget discussion. Both worthy of  
lots of attention.

Two more thoughts...

1) It's been interesting for me to sit both sides of the fence. Just  
because there's a readily available goodie out there that seems to  
solve the problem, doesn't mean there's a "just toss it in" solution.  
While there's an opportunity for this to be in part due to a "not  
invented here" mindset, it's not entirely. Having modified VW tools  
for nearly 20 years now, there's a difference between doing a loadable  
add on version and an integrated version. It changes the way you do  
it. I still write addons which I put in the OR; I do them differently  
than when I'm making an integrated change. The Prerequisite work done  
for 7.7 is a good example. I wrote and maintained the original  
NewPrerequisiteEngine add on. When we "integrated" it in 7.7, what we  
finished with was very different in many ways (and similar in some  
other ways). I think I've seen at least one Undo add on mentioned  
here. I'll try to look at it, and see if it couldn't be integrated in  
some fashion, ASAP. I appreciate the reminders.

2) ExtraEmphasis. We could do a lot with ExtraEmphasis. I think I can  
speak somewhat authoritatively about it. But in it's current  
incarnation it has some ugly edge cases that make it tricky. As an add  
on, it necessarily does very little in the actual display area. It  
uses a set of existing APIs to basically "trick out" the display  
engine as best it can. One of the things that it can't really do  
though, is delineate between a group of characters that are emphasized  
with a single emphasis as a group, and a set of characters that are  
all emphasized individually with a like emphasis. To integrate it, I  
need to sit down and get friendly with the text display parts  
(DisplayScanner and friends). I'd also like an emphasis language, that  
while backwards compatible with the current use of symbols, enabled  
and encouraged real objects to be used for text styling. I don't want  
to play games with associations anymore (e.g. #backColor -> ColorValue  
red).

--
Travis Griggs
Objologist
"I did not have time to write you a short program, so I wrote you a  
long one instead."

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Please look at the HighlightingStyles package.  It starts the kind of idea transformation you identified.  (It includes various extensions to Object, UndefinedObject, and Array for nice behavior.)  Styles internally use the same symbol/association hacks that we've all grown to love and hate, but it could be converted to actual emphasis objects (say, something like a class approach such as BoldEmphasis, ItalicEmphasis, ColorEmphasis, etc.).  These could be applied where emphasis is needed.  The font queries could defer to the actual object [instance] similar to the announcement behavior.

Styles are used for all the various highlighters.  I also override all the color settings in the RB with styles and the grid color in UIPainter.  I'm gradually finding every place VW uses a fixed color assignment and slowly converting those to use user-editable styles.

Compatibility would be interesting, I admit, where everyone tests for #bold or something.  You'd like to convert #bold to BoldEmphasis, but that may be something you have to do at the last minute.  The key is to distinguish the set of possible emphases, or what you can change the visual appearance, and markers that identify something about the text.  Styles let me do both, and being able to have a "CustomEmphasis" (which I can subclass) would certainly make the hyper-highlighting for variables, selectors, and blocks cleaner.  (I also dislike the association mess.)

Cheers!
 
Tom Hawker
--------------------------
Senior Framework Developer
--------------------------
Home +1 (408) 274-4128
Office +1 (408) 576-6591
Mobile +1 (408) 835-3643
 
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Travis Griggs
Sent: Friday, January 22, 2010 11:18 AM
To: VWNC List
Subject: Re: [vwnc] 'Undo' don't work properly.

[snipped]

... I'd also like an emphasis language, that  
while backwards compatible with the current use of symbols, enabled  
and encouraged real objects to be used for text styling. I don't want  
to play games with associations anymore (e.g. #backColor -> ColorValue  
red).

--
Travis Griggs
Objologist
"I did not have time to write you a short program, so I wrote you a  
long one instead."

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

IMPORTANT NOTICE
Email from OOCL is confidential and may be legally privileged.  If it is not
intended for you, please delete it immediately unread.  The internet
cannot guarantee that this communication is free of viruses, interception
or interference and anyone who communicates with us by email is taken
to accept the risks in doing so.  Without limitation, OOCL and its affiliates
accept no liability whatsoever and howsoever arising in connection with
the use of this email.  Under no circumstances shall this email constitute
a binding agreement to carry or for provision of carriage services by OOCL,
which is subject to the availability of carrier's equipment and vessels and
the terms and conditions of OOCL's standard bill of lading which is also
available at http://www.oocl.com.

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Am 22.01.2010 um 21:42 schrieb <[hidden email]>:

> I also dislike the association mess.

Agreed, however, much to the same degree I dislike abusing classes for  
things they are not intended for. The ease of adding classes doesn't  
justify their inflationary use.

The huge Exception class tree, for instance, always seemed suspect to  
me, as I feel inheritance is abused for building a simple inclusion  
relationship among otherwise almost identically behaving objects  
(99.9% of Execption subclasses do not implement any significant  
behavior). Admittedly it's convenient to maintain the hierarchy in the  
browser and reference class names directly in the source code.  
Instance-based hierarchies require extra tools for maintenance and an  
API for referencing.

Whatever, I doubt the various emphases (bold, italic, light) are  
"Behavior" that would need or benefit from subclassing. The latter are  
font family attributes anyway, rather than text emphases.

Symbols aren't too bad, provided the context they are used in is well-
defined and focussed. Think of the various character encodings, XML  
tags, or locales. Symbolic references make objects more portable and  
robust, as they can be handled by images that lack support for all  
their features.

There will probably never be true support for typography and real text  
styles that deserve the name. Therefore, a careful overhaul of the API  
and mechanics behind it should be sufficient. Everything else beyond  
that would be overdone.

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc