#115 Color in the editor

At the moment we're using the educational "BlueJ"-IDE at school to program Java.
This IDE highlights code blocks.
I think that this would be very helpful to make the FMSLogo-Editor clearer and more modern.

In the attachment, you will find a small example of how this could look with FMSLogo, in comparison to BlueJ.

Bring even more color into the editor!
Set also a color for:

• new procedure names
• lists
• loops (for, forever, do.while, do.until)
• if, ifelse, iftrue, iffalse..

To make FMSLogo more user-friendly, you could also provide the option to change the colors...

Regards,
Jan Grabe

[DanielAjoy]

how hould you highlight this valid Logo code:

make "list [ifelse :a > :b [repeat 4 [print "hello]] [repeat 2 [print "bye]]]
DEFINE "abc list [a b] :list

[Anonymous]

Good question, Daniel. See my result in the attachment.

The thing is, when I spoke about the yellow and grey highlighting, I thought about the editor and forget to mention it. I don't think this highlighting would make much sense in the commander.
And my suggested highlighting also don't make much sense in a one-line MAKE instruction, I didn't thought about that as well when I created this request.
The colors I've chosen are also nearly random and I think I'm also not the right person to decide this. For an example, I chose green for strings, because many other languages/IDE's I know have green for strings.
When I created this request, I had the a bit unstructered and confusing Logo editor in my mind. Today I've the same words in my mind, because I don't think there are good ways/help to give your code a good structure and I think this is import to don't lose the track of your code.
Many times I've lost 10 minutes because I forgot a bracket. If Logo would be structurable like Java, this wouldn't be a problem. Logo should at least automatically insert the closing bracket, I think even this would help a lot.
And also the commander is really bad when talking about usability, as you cannot write multiple (visible) lines into the input box, and if you copy code into the editor, you will only see the last one and have to click on a very small button to go one line up. This should be resizable.

All in all, we should think about how to improve the usability of the UI, today other IDE's are much better in this point!

Jan

[DanielAjoy]

I noticed that you colored [a b] as if it was data. But [a b] could just as well be code, or both:

to a
print "apple
end

to b
print "banana
end

make "list [a b]
show lput "c :list
run :list

Here [a b] is code AND data.

[DanielAjoy]

And also the commander is really bad when talking about usability, as you cannot write multiple (visible) lines into the input box,

I don't have a problem with this. I guess I've learned not to expect to be able to do it :)

I guess the UCBLogo command area allows this multi-line editting a little better:

http://i.imgur.com/fnpIoED.gif

But you can't move up to edit the previous line.

And once you submit the whole command you can't access it through the history feature of FMSLogo (by pressing the UP arrow)

In FMSLogo I'm happy with currently being able to just paste multiline chunks of code from another place into the FMSLogo command line.

and if you copy code into the editor, you will only see the last one and have to click on a very small button to go one line up. This should be resizable.

I'm not sure what you are talking about here. What is the name of that button?

[David Costanzo]

and if you copy code into the editor, you will only see the last one and have to click on a very small button to go one line up. This should be resizable.

I'm not sure what you are talking about here. What is the name of that button?

Jan is referring to up/down buttons on the vertical scrollbars that appear when there's more than one line pasted into the commander.

[David Costanzo]

The problem with color is that people precieve color differently. About 8% of males have some kind of color blindness according to Wikipedia. I'd expect that the diagnosis of color blindness is lower in children, which are the main audience . My 7th grade science teacher told me that her teachers thought she was stupid because she couldn't see the letters and numbers that other kids could see. It would be very bad if FMSLogo set a child thinking they were too stupid to program because it used color inappropariately.

Another problem with color is that monitors are all different. On my monitor at work, contrast is hard to see and some internal web sites are nearly unusable because they have an white-on-orange scheme and the text is difficult to read. In the example.jpg, the yellow and light grey are hard to see on my home monitor. It would be bad if critical programming elements brackets became invisible.

The problem with letting a user override the color preferences is that some schools use a single "student" account and do not have assigned computers, so a newbie student who sits down at a computer that a power user had previously configured to suit their personal tastes may be disoriented because things that are usually blue are now red. Or worse, a mischevious student might make everything white, completely baffling a newbie student.

The problem with syntax color in Logo is that it's such a dynamic language that there's little that an editor can rely on. Even a fundamental primative like FORWARD can be re-defined to take a different number of inputs by the time a particular line is executed. The text within brackets might be instructions (as in the default IFELSE) or it might be a list of words (as in PRINT). This dynamic nature is what makes Logo Logo and removing it to make it easier to colorize would turn it into a bad Java.

Each of these problems has a mitigation, so I'm not saying that FMSLogo's editor shouldn't have more color, just that it should be done carefully. For example, its default color scheme should use color sparingly and have a 5:1 contrast ratio. Or when FMSLogo is installed, it can ask if it should disable configuration settings that persist across restart to mitigate issues when multiple users all use the same Windows account. And it could have a "Reset all options to default" option so that it's easier to fix a bad configuration than it is to create one (mitigating the mischevious student). Incidently, Jef Raskin, the father of the Mac UI, felt that end-user customization was only provided by lazy designers, as end-users are not design experts and most users will cause problems for themselves with too much customization. He argued that what users really want is a good UI, not to have to customize a bad one.

Another approach is FMSLogo's bad usability is to start with the problems and look for the best way to solve it, rather than starting with a solution. For example, losing 5 minutes to a missing bracket can be addressed in many ways. One is to change the language to automatically close all open brackets making code that was previously syntactically illegal into legal code. FMSLogo couldn't know where the programmer really wanted the close bracket in all cases (maybe the problem is even with the open bracket), but it might be able to guess based on some complex heurstics and do an okay job most of the time. Another solution is to colorize unmatched brackets and provide keyboard shortcuts for navigating between matching brackets (which is what it does now, although perhaps too subtly). Another is to improve the error reporting when FMSLogo finds an unmatched bracket, jumping to the open bracket, instead of jumping to the procedure's "TO" line. Another is to add code folding (a feature I always disable in my editors because I find it annoying). I'm sure there are others.

I think the multiline ability of the commander which you called "really bad usability" and Daniel Ajoy opened a bug on saying that it doesn't handle procedure definitions shows the value of not making small improvements. In previous versions of FMSLogo, only the first line would be pasted, which made it hard for me to quickly execute blocks of sample code or run code from my workshop's Web pages. In the wxWidgets version, I added multiline paste to the commander's input. This was intended to be a small improvement for one specific use case. If you hit enter, FMSLogo runs the line, so the only way to get multiple lines with with paste. I was concerned that dynamically resizing the input field to fit the pasted text would pinch space away from the history box and cause problems when the command font was large, but I added the vertical scrollbar so that you could at least see that there were multiple lines. Since you were only pasting code to execute that you had just copied from somewhere else, I didn't see a strong need to be able to view/edit pasted code. If you wanted to edit the code before running it, I thought you'd use the editor. I knew that any code which had "TO" would give a confusing error (this is architectually difficult to fix), but I thought it would be better overall. Maybe my small improvement made FMSLogo worse and I should have held off until I had the time to work out a solution that handled all cases (colorblind students, mischevious students, machines with a single account, etc.)

[DanielAjoy]

Since you were only pasting code to execute that you had just copied from somewhere else, I didn't see a strong need to be able to view/edit pasted code.

I agree with this.

If you wanted to edit the code before running it, I thought you'd use the editor.

That is what I do.

I knew that any code which had "TO" would give a confusing error (this is architectually difficult to fix)

Is this why pasting procedure definitions doesn't work?

[David Costanzo]

I knew that any code which had "TO" would give a confusing error (this is architectually difficult to fix)

Is this why pasting procedure definitions doesn't work?

Yes. As I recall, the commander has different behavior than LOAD and cannot process more than one line. To get multiline pastes to work, FMSLogo replaces all newlines with spaces before executing it. This strategy doesn't work for TO and .MACRO possibly for other constructs.

[DanielAjoy]

I see. I hadn't noticed the up/down buttons on the vertical scrollbars that appear when there's more than one line pasted into the commander.

I don't see it documented in the Help. That might be better for now as it is an experimental feature yet, I suppose.

Of the top of my head here is another way to handle pasting code into the Input box.

If the content is more than one line, the text is pasted directly into the Output/Command-Recall List Box, but highlighted/selected.

Also, a new associated new feature of the Output/Command-Recall List Box would be that whenever a group of lines are selected in the Output/Command-Recall List Box, and the Enter key is pressed all of them are run as if they were loaded. Then as the commands are executed correctly, they are repaste into the Output/Command-Recall List Box, until a command fails.

This way of doing things removes the possibility of editing multilines in the Input Box and the need for the up/down buttons on the vertical scrollbar.

Further down the line, if you feel that the ability of editing in immediate mode is important, you could allow to text to be altered in the Output/Command-Recall List Box.

Text could be then modified there, marked, and executed/loaded.