Future plans

[pyscripter]

The next two areas I am planning to work on are #26 and #27.

a) Unicode fixes (#26)

I plan to use DirectWrite for rendering text but also measurement and cursor positioning. See here for an explanation of the reasons.

It will be a major rewrite. The painting code, PaintTextLines, is about 1000 lines long. I would expect that code to become much simpler. Gone will be the weird stuff such as ExpandAtWideGlyphs.

The downside is that Direct2D and DirectWrite are not available on Windows XP. I could keep the GDI stuff and switch to DirectWrite only when it is available. But I do not want to do that. It will defeat the purpose of simplifying the code base and it would be hard to maintain. @MShark67 @JaFi-cz. Do you think XP compatibility is important?

b) Multi-cursor, multi-selection support (#27)

Some initial work has been done and it is available in the "multicursor" branch. But it still needs quite a bit of work.

[JaFi-cz]

Form me, Windows XP support is still important.
When I publish test with new Delphi, where lowest Windows limit was set above Windows XP, I got lot of complains.
I understand, it's additional work for you to maintain both version of code, but Windows XP are still alive.

[pyscripter]

VS code for instance does not support Win XP.

[JaFi-cz]

So why are you asking if you are decided? ;-)

[pyscripter]

Good question.

What I have decided is that if I were to work on #26 I would not keep both GDI and DirectWrite in the code base. The changes I have in mind are almost like writing Synedit from scratch and I just could not handle the complexity of keeping GDI and adding the DirectWrite. Having both in, would also defeat part of the motivation, which is to simplify the code base. In the early days of SynEdit there were tens, even hundreds of contributors. Maybe that was part of the problem, but the code became almost unmaintainable.

What I have not decided is whether it is worth doing it. You and Mark are the only developers that contribute to this project with features, support, bug fixing, testing etc. Your help would be crucial. If you were to tell me that "if you drop XP I am out and I will stick to the current version", I would just not bother.

[JaFi-cz]

You asked about WinXP support. I told you my opinion. If you leave support of WinXP, it doesn't change my mind to contribute and use current SynEdit version. I will publish last version with Windows XP support and next version will be without it.
But if I would choose of new GDI handling or multicursot, I would vote for multicursor. There will be lot of work to tune it up.

[pyscripter]

I agree that multi-cursor multi-selection is more useful. But it makes sense to deal with the lower level stuff first. For example the Track changes bar was much easier to implement after the redesigned gutter and the new undo system.

[pyscripter]

By the way Marry Christmas to everyone.

[pyscripter]

One more question regarding multi-caret and multi-selection (please see https://wiki.freepascal.org/ATSynEdit#Multi-carets to get the idea. VS-code works similarly).

If similar functionality is implemented in SynEdit, does one still need the different selection modes (column and line)?

[JaFi-cz]

I never used Line mode. I don't see usage for it, cause it can be easily done with standard selection. But column mode is still useful. Maybe pasting become obsolete, but column mode will always used for copy or delete. I personally use it often when I work with sets of data in text files.
I see another usage of column mode - e.g. UpperCase/LowerCase column of data. Multiedit mode isn't able to replace it.
In my editor I have sort based on selected column implemented. But this can be handled by the other way.

[pyscripter]

Multiedit mode isn't able to replace it

Why is that? Have you read in the link how copy and past works?
For example in VS Code

Add cursors at the beginning of the lines and select lower

type upper

Select Upper

Apply Upper case command.

Note that VS code does not support column mode.

[JaFi-cz]

OK, Won't be there any performance problems to work with thousands lines at once?

[pyscripter]

Well you have a point. VS Code has a limit of 10000 cursors. But it gets very slow when say you type with more than 3-4000 cursors. Selecting text with 10000 cursors is quite fast though.
Similarly with Cuda text.
I wonder whether the feature can be implemented more efficiently in SynEdit. Will see.

[MShark67]

XP Support is only slightly important to me as I haven't had that issue pop up lately. Of course, it's often that when something is removed that you find out someone really needs it lol. I definitely approve of code simplification. I've only used multi-cursor editing a few times, but it's definitely a cool feature. One thing I'd like to see is a multi-line selection option that didn't highlight all the way to the right edge of the screen, but really it's a very minor point. The recent improvements have all been stellar and much appreciated!

[MShark67]

It's definitely a "wish list" item for me, but I can understand keeping with a standard (although it seems like some of my usability suggestions have been met with "that's how vscode does it", so maybe changing to be more standard isn't such a bad thing...)

[JaFi-cz]

I met this request once only, but for my opinion it isn't important if line is highlighted to the end of window or end of line.
Highlight to end of line can be confusing for empty lines, cause you won't see if line is selected there

[MShark67]

JaFi, that's a good point. I checked out VSCode and it appears they do the end of line selection as if there was a hidden char there. I wonder if it's for that reason. I've had someone complain about the full line selects as it hides what whitespace is there, so there are pros and cons both ways I think.

[pyscripter]

What should we do with this? Switch, make it optional or keep it as is?

[MShark67]

I'd vote for either an option or to just make it the new standard (but I totally understand keeping it "as is" as well.) I do like the way VSCode does it, I noticed they've moved the behavior to outlook as well.

[pyscripter]

Finished and committed the painting code.
Sample output:

Chinese properly spaced, surrogate pairs and color emojis

Bidirectional text properly selected.

[pyscripter]

Another option is turn off anti-aliasing while drawing indentation lines. This is what it looks like with color clGray.

Quite close to what we have today. And should be much faster.
And Aliased straight lines with LightGray color

[MShark67]

The performance of the new bitmap version is very good, no longer an issue at all. I notice that the lines overlap slightly causing a darker dot between lines. I don't see it in your screen shots so maybe you've already fixed it or it's more pronounced on large font sizes. I can (kind of) fix it by reducing the bitmap height (or the draw rectangle) by one pixel. Here's a screenshot that shows it with a huge font just to make it clear:

[JaFi-cz]

Version of gudes without antialiassing looks much better. Thank you.
Can you make font antialliasing optional please? Some of my users require it.

[pyscripter]

Can you make font antialliasing optional please? Some of my users require it.

Now there is the FontQuality property, which also affects the DWrite stuff. Let me finish everything and then we can think about what rendering options are needed.

Dotted or straight lines? I think I like better the aliased straight lines with the appropriate choice of color. Maybe this could also be an option.

[JaFi-cz]

Dotted or straight lines? I think I like better the aliased straight lines with the appropriate choice of color. Maybe this could also be an option.

Straight lines without aliasing looks good. I would prefer speed than dotted lines.

[pyscripter]

Discussion moved to a new topic #141