Recent

Author Topic: SynEdit on Linux  (Read 617 times)

scasparz

  • New member
  • *
  • Posts: 38
SynEdit on Linux
« on: April 20, 2019, 07:51:12 pm »
Trying to make a small editor for personal use, employing the tSynEdit on Linux Mint 64 19.1, using Lazarus 2 64 and the latest fpc.

Have found a number of little bugs that would need some fixing. For example when the current line is the first or the last line of the screen and the user presses the up or the down arrow respectively, the cursor leaves traces, a kind of a ghost leftover as it advances either upwards or downwards. This issue appears only when gutter is not visible and can be replicated. I take it as a little nuisance. This issue only regards the Linux version, the windows 32 one seems to be OK in respect of it.

Another more serious issue comes when occasionally the screen gets messed, with the wrong lines appearing in place of others. User can tackle the issue by pressing either page up or down which repaints the screen correctly. Unlike the previous issue, I fail to replicate this given it occurs rarely.

Should I file these bugs? and if so what is the procedure? Where to look?

As a final thought, given the IDE SynEdit appears to work extremely well, I wonder how difficult it would be to derive the SynEdit VCL from this proven code base.



kind regards
s

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5515
    • wiki
Re: SynEdit on Linux
« Reply #1 on: April 20, 2019, 08:17:42 pm »
Yes please report. The bugtracker is linked in the menu on the left of this forum (it is currently being upgraded, so not available).

As for the cursor. Do you also compile on windows? Please try (and include in the report) what happens, if you apply the following setting to your SynEdit (after creation)
Code: Pascal  [Select]
  1. type
  2.   TSyn = class(TSynEdit)
  3.   public
  4.     property ScreenCaret;
  5.   end;
  6.  
  7.   TSyn(SynEdit1).ScreenCaret.ChangePainter(TSynEditScreenCaretPainterInternal);
  8.   TSynEditScreenCaretPainterInternal(TSyn(SynEdit1).ScreenCaret.Painter).Color := clRed;
  9.  


As for the issue with the wrong lines: You can report it. It will require more feedback though. And hopefully some useful info will emerge from it. Otherwise it is unlikely to be fixable.

Compile SynEdit with
Code: [Select]
-Sa -Criot -gt -gw -O-1
-dSynDebug
-dSynCaretDebug
-dSYNSCROLLDEBUG
-dSynTrimDebug
-dSynFoldDebug
-dSynCheckPaintLock
-dSynClipboardExceptions
-dAssertSynMemIndex
-dSynAssert
-dSynAssertFold

In your app, add the unit "LazLogger" to the uses (can be in any unit of your app.

Start your app with
--debug-log=path/yourlogfile.txt

And if the error happens (or any assert error), attach the log.

If no error happens, delete the log between runs. Otherwise it will have lots of extra lines....


You mean making the Lazarus version of SynEdit compile under Delphi? Needs a volunteer.
No idea how much work that will be.

Also I would suggest if anyone wants to do that, to fork it. We can't test every change we make. But a fork could test them before importing them.


Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5515
    • wiki
Re: SynEdit on Linux
« Reply #2 on: April 20, 2019, 10:00:06 pm »
For the caret issue, please test with trunk
Revision: 61028
Date: 20 April 2019 21:57:06
SynEdit, GTK2: fix ghost caret during scrolling

That should fix it. At least fixes it for me.

You can get a patch from
https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&root=lazarus&revision=61028

scasparz

  • New member
  • *
  • Posts: 38
Re: SynEdit on Linux
« Reply #3 on: April 21, 2019, 06:40:51 pm »
Hi Martin,

To begin with, many thanks for your superfast multiple responses.
Downloaded unit syneditpointclasses.pas from the trunk, kept a copy of the original and rebuild Lazarus with the Tools - Build Lazarus with profile: Normal IDE. Not sure if I could use the LazLogger as suggested though. Ran a quick test (just a form with the tSynEdit on it, plus a checkbox to turn gutter invisible and vice versa), now the caret behaves well. Looks like problem is solved. Thank you for this as well.

Two questions please:
  • Is there still a reason to file the caret issue as a bug on Mantis?
  • Is there any reason to revert to the previous (original) version of the syneditpointclasses.pas unit instead of keep using the new one (trunk)?

Now in regard to the second issue, I believe there is no reason to file for a bug until I manage to find a way to replicate the problem. Is this OK?

Finally, I believe (please correct me if wrong) the IDE text editor does not make use of the tSynEdit (palette) version, but it comes from a different code base. Had this been the case, do not have any clues as to how similar or different those two versions may be. I can understand there are multiple components on the synedit palette page that rely on the tSynEdit (palette version), which may not be compatible with the IDE version. However given the IDE version seems to work extremely well, I wonder if there is any reason to keep these two different code bases for what apparently is the same thing.
Had we been able to make use of the IDE version, it could help into making considerably more robust apps under any OS platform. Not to mention the IDE version has a far more rich command set by comparison. I really miss the old ^QP, have been using from the Turbo Pascal era. Anyway, in the end, perhaps having a smaller number of well-working components may be a better way to go. Am I wrong?




best regards
s
« Last Edit: April 21, 2019, 06:45:04 pm by scasparz »

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5515
    • wiki
Re: SynEdit on Linux
« Reply #4 on: April 21, 2019, 10:27:45 pm »
Downloaded unit syneditpointclasses.pas from the trunk, kept a copy of the original and rebuild Lazarus with the Tools - Build Lazarus with profile: Normal IDE. Not sure if I could use the LazLogger as suggested though. Ran a quick test (just a form with the tSynEdit on it, plus a checkbox to turn gutter invisible and vice versa), now the caret behaves well. Looks like problem is solved. Thank you for this as well.

Two questions please:
  • Is there still a reason to file the caret issue as a bug on Mantis?
  • Is there any reason to revert to the previous (original) version of the syneditpointclasses.pas unit instead of keep using the new one (trunk)?
No need to report on the bugtracker.

Did you just apply the changes in that revision? Or replaced the entire file. There may (or may not) have been other changes. If there are other changes, then depends on what else changed. 
(You can use diff to compare the download and the original)

Quote
Now in regard to the second issue, I believe there is no reason to file for a bug until I manage to find a way to replicate the problem. Is this OK?
Probably not. It is most unlikely that it would make any change.

Quote
Finally, I believe (please correct me if wrong) the IDE text editor does not make use of the tSynEdit (palette) version, but it comes from a different code base. Had this been the case, do not have any clues as to how similar or different those two versions may be. I can understand there are multiple components on the synedit palette page that rely on the tSynEdit (palette version), which may not be compatible with the IDE version. However given the IDE version seems to work extremely well, I wonder if there is any reason to keep these two different code bases for what apparently is the same thing.

The IDE uses the same SynEdit.

There are a few features (such as the topline hint) that were added for the IDE. Those feature are managed in a subclass in unit ide/SourceSynEditor.

There also is no lfm file for SynEdit in the IDE, instead SourceSynEditor also puts the various components (plugins from the palette) together.

The IDE also has features build around SynEdit (menus, page control, ...) those are in SourceEditor, and a few related units.

Quote
Had we been able to make use of the IDE version, it could help into making considerably more robust apps under any OS platform. Not to mention the IDE version has a far more rich command set by comparison. I really miss the old ^QP, have been using from the Turbo Pascal era. Anyway, in the end, perhaps having a smaller number of well-working components may be a better way to go. Am I wrong?
You can configure the key shortcuts for your own SynEdit. There is a property (something like KeyStrokes)

However some of the commands in the IDE (e.g. incremental search) are implemented in SourceEditor.
You can hook the OnCommand / OnUserCommand events... I have to check which one does what...



Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 5515
    • wiki
Re: SynEdit on Linux
« Reply #5 on: April 22, 2019, 11:17:19 am »
A few hints/notes.

Read http://wiki.lazarus.freepascal.org/SynEdit (and maybe http://wiki.lazarus.freepascal.org/Editor_Macros_PascalScript section on Caller)
If you change text from your code, read the related section.

With regards to the wrong lines paint issue:
- Make sure all of your BeginUpdate/EndUpdate blocks match.
- Never call Application.ProcessMessages (or anything that could trigger Paint) while in a BeginUpdate/EndUpdate block.

scasparz

  • New member
  • *
  • Posts: 38
Re: SynEdit on Linux
« Reply #6 on: April 22, 2019, 11:15:13 pm »
Many thanks again Martin, for directing me to the right track. Has been very kind of you. Much-much-much obliged. Will try to follow your directives closely.




kind regards
s