I am opening a new mail thread, otherwise it will be mixed with the TAChart topic in the archives.

I'll look further into it. A few things:
- GetHighlighterAttriAtRowColEx may not be the best idea. It can be quite useful to be able to click on words in comments to. (Which works at current). GetHighlighterAttriAtRowColEx could be used to identify numbers.
- The highlighter is overall not the best solution to find linkable text. Because even a valid bit of code, may be unresolvable to codetools.

If using the Highlighter, I would propose to check for text/words that can definitely be excluded. (Numbers, certain keywords).

Another way would be to ask codetools them self.
Similar like SynEdit calls SourceEditor, which calls SourceNoteBook and then MainIDE.OnSrcNoteBookClickLink line 2952 in ide/main.pp ( see also line 1778: SourceNotebook.OnClickLink := @OnSrcNoteBookClickLink; )

Best Regards
Martin

Indeed, I missed that.

Now _that_ is what I wanted to hear when I started the original thread ;-) Good idea, I attached a new version of patch to the http://bugs.freepascal.org/view.php?id=12785.

I should note that I was horrified by the amount of "glue" code needed to route an event through main form, source notebook, source editor and SynEdit.

An embedded and charset-unspecified text was scrubbed... Name: not available
Url: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20081212/d6bc0fe9/attachment.pl

Oh, hierarchy is good in itself -- it is not what I am ranting about. (Although I'd say that main.pp, at 15000 lines, is in dire need of further splitting).

However, to add another event to SynEdit, I had to add two useless events and two useless event handlers, totally containing more code then the original event
-- simply to marshal the call through the hierarchy (see patch in the issue for details).
This is IMHO not optimal design ;-)

I haven't seen the patch? Can you check you really attached it.

As for the events... There is probably (I haven't seen the code) another way: Pass the callback through to synedit. IDE gives a callback to SourceNotebook. But that does not mean that SourceNotebook has to be the one who calls it. It can just pass the Method-Reference to SourcEditor, which passes it to SynEdit.
Source Notebook still needs to keep a copy, as it may open further SourceEditors.

Martin

Martin Friebe wrote

I haven't seen the patch? Can you check you really attached it.

Sorry, attached now.
It is a pity Mantis does not allow to attach a patch and add a note within a single operation.

Yes, this would be slightly better way. Since I am not familiar with this part of code,
I just implemented it the same way other similar calls work.

Op vrijdag 12-12-2008 om 21:14 uur [tijdzone +1000], schreef Alexander Klenin:

On Fri, Dec 12, 2008 at 20:38, Martin Friebe wrote: > I haven't seen the patch? Can you check you really attached it. Sorry, attached now.

Nope, still no attachment. Maybe that it's too big. There's a limit of the filesize of attachments on this list.

Joost.

Joost van der Sluis wrote

Nope, still no attachment. Maybe that it's too big. There's a limit of the filesize of attachments on this list.

I meant attached to an issue: http://bugs.freepascal.org/view.php?id=12785 Anyway, I'll attach it to this message too, just in case ;-)

Interesting information. Where would I have to start implementing multiple source editors (notebooks)?

DoDi

Thanks for the patch, looks good to me.

A few things:
- Originally you had the condition "NewX1NewX2 " moved into IsLinkable. Now it is omitted?
May be right, because codetools may (or may not) return false for those. Yet it means an unnecessary call to code tools.
- You probably accidentally included changes to the lfm file of source-editor?

(I can both fix them in the current patch, no issue)

- The unlucky bit is that your patch gets affected by a known bug. if you got a string with multibyte utf8 chars (like german umlauts) then anythink behind the umlauts is not linkable.

This is already the case now (SynEdit does currently not follow valid links, behind umlauts), so you patch isn't wrong. The issue is, I can not test it, until I fixed the umlauts. I will see, if I can look at this during the weekend.

- And last not least (not a stopper, but would be nice), the current solution does call Codetools each time you move the mouse. It may be possible for UpdateControlMouse to cache the boundaries of the current linkable word, and trust this cache instead of calling codetools from CalculateCtrlMouseLink again?

Best Regards
Martin

I am sorry, please ignore the above. It works absolutely perfect with umlauts, as well as with real-tab chars.

Hi Alexander,

Mattias did apply your patch (since I am restricted to the synedit folder). If you feel like doing the optimization, it will always be welcome, but is no must.

Martin Friebe wrote

Thanks for the patch, looks good to me.

...

I agree.

- You probably accidentally included changes to the lfm file of source-editor?

Not quite so. The lfm change I included was, IIUC, done by IDE automatically simply because I opened and saved SourceEditor unit. This happens often for me, usually since lfm format changed slightly since the last time anybody touched the lfm in question. I see three ways to deal with this:

1) Include such changes in commits, since they will inevitably show up later.
2) Ignore them, and let them pile up, and then either 2a) Include them all in bulk when some essential changes to the lfm is needed 2b) Periodically (and automatically, if possible) open and re-save all lfm's and commit the result.

I do not know what the policy in Lazarus is [judging by my previous policy questions,
there is probably no policy ;-)]. So I opted for (1).

I see that you already committed some fix. FWIW, I tested with Russian characters in comments -- it works for me.

Good idea, I was concerned with the speed too, but testing showed it to be ok (maybe my PC is too fast).
So for now I filed an issue http://bugs.freepascal.org/view.php?id=12790

IMHO the first consideration would be that if you have multiply windows, or split windows allowing more than one source viewed; you must also take care what happens if 2 views, display the same source. Of course restrictions could be put in place to prevent this, but in the end, I guess it wil be wanted, and will have to be done. therefore:

1) Allow 2 SynEdits to be able to share a textbuffer.

Then depends, if you display them in one window, or multiply windows. (in the later you need to add managment for the extra windows)

2) you have to find where the actual visual TNoteBook component (with the tabs) is created (either main-ide or SourceNotebook). To clarify SourceNotebook is not a visible component.It is a class that controls the (visible) TNoteBook

3) Make SourceNotebook able to have more than one TNotebook in it's control.

4) Fix all the code using this (things like find active editor, find active notebook-page....

This is only a brief overview, I havent looked through all requirement yet.

Best Regards
Martin

I'm interested in independent windows, so that the full (multi-monitor) desktop can have a row of edit windows.

you must also take care what happens if 2 views, display the same source. Of course restrictions could be put in place to prevent this, but in the end, I guess it wil be wanted, and will have to be done.

In the first step I'd restrict one file to one view. Every view will need an associated code explorer, which also must be managed - that's why I'm also interested in docking the explorer windows to the views, as I'm used from Delphi.

[...]

This is only a brief overview, I havent looked through all requirement yet.

Thanks, it will be a lengthy way, as expected ;-)

DoDi