The greatest code editor feature of all time

[Michael]

The other thing I miss in most editors is proper block selection with mouse.
1. Double click selects word.
2. Triple click selects line
And then if you keep the mouse button pressed, dragging it will select more in same mode (by word or by line)

And simple shift+arrow keys selection (left/right - by letter, up/down per line)

This makes editing much faster and user friendly.

[Thorham]

Originally Posted by Michael

CloneWB - since otherwise it will not start properly on all machines with different monitor setups.

Yeah, that's a good idea. The user can change that later.

Originally Posted by Michael

GUI - yes, visual prefs, everything set to nice square aspect.

Visualprefs seems to be a bunch of hacks. Not all software is going to work completely properly with it. Diro5 is an example. Probably nothing you can do about it.

Originally Posted by Michael

On public screen it does not care about pens locked by other progs, and only allows to make a choice from first 16 (ECS legacy limit?) Should be all 256.

Forgot to check. Will check later today.

Originally Posted by Michael

Editing/changing the background colour is a pain. Unless a global option is hiding somewhere.

Selecting the background pen is done through the FACT system. This system allows changing the color and appearance of all characters, and some extra things like the background color. There's currently no option for changing this and it has to be changed in a script file.

The way it's set up is supposed to be part of a theming system I was going to do, but I haven't started working on it yet.

What do you want the background color to be? I can change it for you.

Originally Posted by Michael

The other thing I miss in most editors is proper block selection with mouse.

Can be added easily.

Originally Posted by Michael

1. Double click selects word.

It should already do that.

Originally Posted by Michael

2. Triple click selects line

Can be added easily.

Originally Posted by Michael

And then if you keep the mouse button pressed, dragging it will select more in same mode (by word or by line)

I'll see what I can do.

Originally Posted by Michael

And simple shift+arrow keys selection (left/right - by letter, up/down per line)

Is alt+arrows to keep shift+arrows movement, which is standard in Amiga editors. This may be a little rough around the edges.

[Michael]

"Visualprefs seems to be a bunch of hacks. Not all software is going to work completely properly with it. Diro5 is an example. Probably nothing you can do about it."

Not that bad actually, it's part of the newer os and once properly configured works very well and trouble free. It also allows to spot progs that were coded wrong or avoided the os guide lines and simply used permanent values instead of asking the os to supply them the variables (like sizeable gui elements).

Looking at the source Slider.c has all the needed bits to get it done and conform to v39+. Currently it assumes default values of v37.

The same is true for requesters, an easy solution is to add an extra 4 pixels to the windows height dimension, will work for 99.9 of cases, but better to get the proper window border dimension and take them into account.

The default background needs to be 0 (grey). And it should be easier to change, at least more vivid BOLD comment and mini doc about it would be good for easier finding and changing it when someone needs it to be done. And as I understood it's not that simple, since all the key words also need to change background colour, unless a global background can be used, and if it is not set for the key word, then use the special per key word defined background colour That way you can get away with changing background colour n one place only.

As for the ALT+SHIFT+CTRL keys, we can keep the legacy, yes it's a bit different to other os's but not critical.

eg. in win - CTRL+arrows - move cursor word by word and SHIFT+arrows marks.

And forgot, mouse click and drag should select text immediately, otherwise it's a pain.

TextEditor.mcc has more or less correct settings for keyboard and mouse,
only current version has a selection bug, it does not keep the selected item selected if you change direction.

[Thorham]

Originally Posted by Michael

Looking at the source Slider.c has all the needed bits to get it done and conform to v39+. Currently it assumes default values of v37.

The same is true for requesters, an easy solution is to add an extra 4 pixels to the windows height dimension, will work for 99.9 of cases, but better to get the proper window border dimension and take them into account.

I'll take a look.

Originally Posted by Michael

The default background needs to be 0 (grey).

It must absolutely NOT be gray. Most Amiga text editors use this horrible gray background. Never understood why. White background with black letters is MUCH better. The default FACT is, of course, gray. I just didn't include an option to select it.

Anyway, why is this gray so important? It's horrible!

Originally Posted by Michael

And it should be easier to change, at least more vivid BOLD comment

You can change that yourself. Menu -> Options -> Mode settings -> Edit styles. This changes the settings per mode. Changing the settings for C won't change the settings for Lua, for example.

Originally Posted by Michael

and mini doc about it would be good for easier finding and changing it when someone needs it to be done.

Yeah, that's a good idea.

Originally Posted by Michael

And as I understood it's not that simple, since all the key words also need to change background colour, unless a global background can be used, and if it is not set for the key word, then use the special per key word defined background colour That way you can get away with changing background colour n one place only.

Yes, everything has to change, but that's not so hard. It's a bit of code, but it's easy enough.

Although there needs to be a system for selecting color themes, I must ask again, why this drab gray?

Originally Posted by Michael

And forgot, mouse click and drag should select text immediately, otherwise it's a pain.

Yeah, shouldn't be hard.

[Leffmann]

Another detail I like in Sublime Text: smart highlighting of escape sequences inside string literals.

Originally Posted by Thorham

They're not mutually exclusive, but only having the ability to execute dos scripts and commands is certainly too limited.

I think it's the other way around. Being able to call external tools allows you to do pretty much everything, while having an ARexx port does not.

If your IDE is not scriptable, and you only have an ARexx port, then how would you go about automating your build process?

[Thorham]

Originally Posted by Leffmann

I think it's the other way around. Being able to call external tools allows you to do pretty much everything, while having an ARexx port does not.

If your IDE is not scriptable, and you only have an ARexx port, then how would you go about automating your build process?

My point is that only having the ability to call external programs is limiting, because now you have to have the right tools, or you have to write them.

Also having a full ARexx port, and a full script language makes things much easier. FrexxEd has all this. In fact, you use it's ARexx port and it's ability to call external programs through it's script language FPL (which is basically just C). This allows you to do just about anything by simply writing some scripts. If something would become too slow, you still have to use an external tool or write some code.

[Michael]

Grey, it's my favourite colour (joke).
Actually it' not a bad choice and depends on what shade it is and how your monitor works.
You can also tint it a bit in blue or green or yellow, will look very nice. (eg EAB theme )

Historically, it was the second best choice. Know what was number 1 ?
Yes, the 1.3 kickstart theme. White text on blue.
Black text on grey (OS2+) is the second best choice for eye strain, and there was a huge doc on this on wiki regarding ergonomics and health issues. Wonder why ms-dos used white on black, one of the worst combination and for health and safety reason would have been blocked by authorities.
Nevertheless even on ms-dos all major tools and text editors had white text on blue and black on grey as second option.

And finally, using the zero colour background should be the fastest mode for most editors.

Personally, having a white background brings too much light, and with 1 pxl thin fonts on a high res screen is almost unreadable (without antialising which makes the font thicker then it really is).
again, your asm settings are a very good example of a good setup with vivid colours and low impact on the eyes.

[Blueberry]

Back to original topic...

1. True smooth scroll. This is probably the feature I have been missing most across all editors.

When scrolling because of arrow up/down held down, scroll a uniform number of pixels on every vblank, so you can actually read the text while scrolling. An open question is what to do if the key repeat rate does not correspond to a whole number of pixels per vblank. Probably the scroll speed should be rounded up, so the cursor gradually tends towards the middle of the screen.

2. Move line up/down.

Shuffling lines around is something I do all the time when coding assembly. The Amiga+d / Amiga+f combination in AsmPro is a bit cumbersome for this. It should be simply (some combination of modifiers)+up/down to swap the current line with the one above/below it. The cursor moves with the line.

If a block is marked, move the whole block (and keep it marked).

[Thorham]

Originally Posted by Blueberry

Back to original topic...

Yes, that's not a bad idea. I'll contiunue my communications with Micheal through PM.

[Photon]

Yes, it was becoming a FrexxEd configuration thread.

Originally Posted by Blueberry

1. True smooth scroll. This is probably the feature I have been missing most across all editors.

Smooth scrolling is already in. I will try to time it for minimal tearing when scrolling upwards - double-buffering would rule it out for A500 use, both performance-wise and chipmem-wasting wise. Anything above 640x512 4 colors requires a huge amount of CPU power or a graphics card with a faster blitter.

Only on graphics cards will you be able to get smooth scrolling with a 60Hz display, and that's even more niched than requiring a really fast CPU.

Originally Posted by Blueberry

2. Move line up/down.

If a block is marked, move the whole block (and keep it marked).

This type of real-time updating is actually very tricky to make with any kind of performance.

And when editing, often you want to remove a commented line in the middle and move 3 lines from there and 2 other lines from 5 lines down and then paste it. I'm looking at a way to cut lines to history and then paste the history.

[Blueberry]

Originally Posted by Photon

Smooth scrolling is already in. I will try to time it for minimal tearing when scrolling upwards - double-buffering would rule it out for A500 use, both performance-wise and chipmem-wasting wise. Anything above 640x512 4 colors requires a huge amount of CPU power or a graphics card with a faster blitter.

Remember that in interlaced modes, you only have to copy half the scanlines each frame. If the scroll speed is an odd number of interlaced lines, this is tricky to do single buffered, though. Better round up to an even speed, then.

This way, the blitter should be able to keep up with 640x512 4 colors, though indeed not much more than that.

Originally Posted by Photon

Only on graphics cards will you be able to get smooth scrolling with a 60Hz display, and that's even more niched than requiring a really fast CPU.

You are forgetting about all of us emulator wussies.

Though, to be honest, it would be ideal to run this in A500 emulation mode. Hence, no graphics card.

Originally Posted by Photon

And when editing, often you want to remove a commented line in the middle and move 3 lines from there and 2 other lines from 5 lines down and then paste it. I'm looking at a way to cut lines to history and then paste the history.

True, but I still find it more convenient and efficient to move things around directly rather than going via a clipboard.

[Michael]

Most of the points raised for FrexxED are related to most editors too and need to be taken into account when a new editor is designed, so that the shortcomings of predecessors are overcome and not repeated again and again.

[Thorham]

So... how's it coming along?

[Yesideez]

Not sure if it's been mentioned already but being able to highlight text and TAB or SHIFT+TAB to indent and remove indents from the selected text.

Also to have custom tab stops and to choose whether to use real tabs or spaces.

Would also like to know if this is still in progress

[Photon]

Originally Posted by Yesideez

Not sure if it's been mentioned already but being able to highlight text and TAB or SHIFT+TAB to indent and remove indents from the selected text.

Also to have custom tab stops and to choose whether to use real tabs or spaces.

Would also like to know if this is still in progress

This is in AsmTwo, implemented as first tab stop at 8, following indentations as spaces, but you can keep comments at even 8 stops.

See release notes for the full list of editor features.

Been meaning to continue on this or any coding really, but the general coding at home allergy seems unstoppable. I fucking hate it. :/

[Foul]

Will try to explain with my poor english..and my little asm experience

Very often, just after compiling your source, you've got an error.
It would be cool, after pressing "ESC" to return to the editor, that the cursor will be placed on this "error"
No need to search the faulty line..

[Schoenfeld]

Please pardon if I drop in a bomb by asking for a feature I know from the Turbo Pascal IDE: If I place the cursor on a keyword and press CTRL-F1, it opens a window with a text reader, and it shows the Help chapter about that key word.

Translated to the Amiga, it would be "CTRL-HELP" and "Open Multiview with the guide linked in the syntax-highlighting config file, at the node that's about the keyword".

I'm probably not the only one who has too little experience in programming whatever language to not require frequent lookups in help files. These lookups should be fast in order to lower the frustration potential.

Jens

[Locutus]

You can have exactly that on Emacs using the AmigaOS autodocs.

[Schoenfeld]

Thing is: I'd like to have it a little smaller-footprint than Emacs. In relation to AmigaOS, Emacs is an OS on it's own, and yes, you can surely build a full IDE with it. My idea is to extend a little on the idea of Syntax Highlighting and re-use that code: If there is a help chapter for a (highlighted) key word, I'd like to open it with a single key stroke, mouse button or whatever other quick action.

Jens

[Thorham]

Originally Posted by Schoenfeld

I'm probably not the only one who has too little experience in programming whatever language to not require frequent lookups in help files.

All programmers need documentation. It's completely essential to programming, and the easier this works the better.