Hi,
It seems Lazarus’ source editor still doesn’t support font ligatures. I’d love to use them in Lazarus to increase the code readability as I’ve used them in many other code editors (using other languages too).  Some popular fonts for that are Fira Code and JetBrains Mono. I’ve tried both of them with Lazarus editor but the ligatures don’t work.

Is there any plan to support font ligatures in the near future? Or is there any special setting to enable it? Thank you.
Best regards,
~Bee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201002/87bc41b2/attachment.html>

Are they strictly monospaced?

Are the chars IimXW and @ all the same width? (@ often is wider)

If any of those chars returns a different width, the SynEdit enforces the width, by calling ExTextOut with an "ETO" array. And that leads to each char painted on its own.

You can find the function "NeedETO" and set it to hardcoded False. That will prevent the enforcements (except in right to left scripts). But it will have side effects. SynEdit will place the caret, as if every char was exactly n pixel wide.
And if text color changes, the text is continued according to the calculated width. So if you select/deselect text, it will start moving a few pixel.

To get all this really working, SynEdit would need to use an entirely different Text API. It would need to know the width of each char, as it is drawn in context. (That is measuring a char of its own is no help, because the char may change width depending on the chars next to it.)

Pada Jumat, 2 Oktober 2020 20.20.09 WIB, Martin Frb via lazarus menulis:

Are they strictly monospaced?

AFAIK they are as long as you use monospaced font such as Fira Code or JetBrains Mono.

You can find the function "NeedETO" and set it to hardcoded False. That will prevent the enforcements (except in right to left scripts).

Where can I find that function? Is it within Lazarus IDE code or in SynEdit code?Pascal code is always written left to right, isn’t it?

But it will have side effects. SynEdit will place the caret, as if every char was exactly n pixel wide.

It shouldn’t be a problem with monospaced font, I suppose. I will try it and see what happen. Thank you.
Best regards,
~Bee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201002/c04a15a8/attachment.html>

Is there something that needs to be enabled to get ligatures working on Windows? I'm using Microsoft's Cascadia Code for example in VS 2019 where ligatures work correctly, but in Lazarus nothing happens. The ligatures have the same widths as the equal N characters (so the ligature for has the same width as both characters together).

Regards,
Sven

Sven Barth wrote

Is there something that needs to be enabled to get ligatures working on Windows?

You need to use one of APIs which support it (afair, DrawTextW?) and output whole ligature, not char-by-char.

If you use the following to output on a plain canvas

procedure TForm1.FormPaint(Sender: TObject);
var
   r: TRect;
   s: String;
begin
   r.Top := 0;
   r.Left := 0;
   r.Bottom := 50;
   r.Right := 50;
   s := 'abcdef';
   LCLIntf.ExtUTF8Out(Canvas.Handle, 10, 10, ETO_OPAQUE+ETO_CLIPPED, @r,
@s[1], 5, nil)
end;

Do you get the ligature?

SynEdit currently uses ExtTextOutW
I don't know if that is good enough. Nor how different it is compared to DrawTextW.

If replaced, the new function must be supported by all widgetsets.

Also, what ever function is used must currently support an "ETO" array. That is for each char outputted, a width in Pixel can be given. That is for example needed
- to enforce same width for Arabic text chars
- unicode chars of ambiguous width
- for fonts that are not strictly monospaced

It's not very simple. see file
https://github.com/Alexey-T/ATSynEdit/blob/master/atsynedit/atsynedit_canvasproc.pas and search for "ligatures" in all places. Unit has special code for win32.

Do you get the ligature? --

Actually might be easier than thought....

- If indeed the DX array is still applicable with the glyphs....
- And if that is supported on all widgetsets...
- And as long as the font does still behave monospaced ...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201003/8667a95d/attachment.html>

If it does work, would you please submit it as a patch for the next release? At least, add a note that the font ligatures feature only supports monospaced fonts and only works on Windows. It's better than nothing. Thank you.
–Mr Bee

Pada Sabtu, 3 Oktober 2020 22.37.58 WIB, Martin Frb via lazarus menulis:

On 03/10/2020 16:34, Alexey Tor. via lazarus wrote:

It's not very simple. see file
https://github.com/Alexey-T/ATSynEdit/blob/master/atsynedit/atsynedit_canvasproc.pas and search for "ligatures" in all places. Unit has special code for win32.

Actually might be easier than thought....

|
|
|
| if GetCharacterPlacementW(DC, PWChar(Str), Length(Str), 0, @CharPlaceInfo, GCP_LIGATE) 0 then | |
| Result:= Windows.ExtTextOutW(DC, X, Y, ETO_CLIPPED or ETO_OPAQUE or ETO_GLYPH_INDEX, Rect, Pointer(Glyphs), Length(Glyphs), Dx) | |
| else |
|
| Result:= Windows.ExtTextOutW(DC, X, Y, ETO_CLIPPED or ETO_OPAQUE, Rect, PWChar(Str), Length(Str), Dx); | |

- If indeed the DX array is still applicable with the glyphs....
- And if that is supported on all widgetsets...
- And as long as the font does still behave monospaced ...

revision 63951

Windows only, compile with -dWINDOWS_LIGATURE
Tested with Cascadia.

If someone wants to add an option "show ligatures" ($IFDEF WINDOWS} to the IDE options (Editor > Display / like the anti aliasing option), then the feature can depend on that, and no longer needs the define.

Sven Barth wrote

 I'm using Microsoft's Cascadia Code

According to my tests (libre office) Cascadia Mono does not do ligatures, but normal Cascadia works.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201004/4fad7b3c/attachment.html>

04.10.2020 19:05, Martin Frb via lazarus пишет:

Lazarus hangs on start for me on Windows 7 when compiled with this define.

Lazarus 2.1.0 r63957 FPC 3.2.0 i386-win32-win32/win64. I use JetBrains Mono font.

Could you start with an empty project? To make sure its not content related?

Though the code changes do not have any loop.

You could run in gdb

gdb lazarus.exe

r

ctrl-c when it hangs

bt

05.10.2020 1:48, Martin Frb via lazarus пишет:

Tried with an empty project, nothing changed. Actually it does not hang, it segfaults. GDB output:

i:\FPC\lazarus>i:\FPC\lazarus_gdb_w32\bin\gdb.exe lazarus.old.exe GNU gdb (GDB) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "mingw32".
Type "show configuration" for configuration details. For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"... Reading symbols from lazarus.old.exe...done.
(gdb) r
Starting program: i:\FPC\lazarus\lazarus.old.exe
[New Thread 6324.0x994]
[New Thread 6324.0x1834]
[Thread 6324.0x1834 exited with code 0]
[New Thread 6324.0x1c78]

Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0x00000024 in ?? ()
#2 0x00ab95f6 in DRAWHILIGHTMARKUPTOKEN (ATOKENINFO=..., parentfp=0x13abf6e8)
at lazsyntextarea.pp:1741
#3 0x00ab8a8e in PAINTLINES (parentfp=0x13abf6e8) at lazsyntextarea.pp:1798 #4 0x00ab86f3 in TLAZSYNTEXTAREA__PAINTTEXTLINES (ACLIP=..., FIRSTLINE=0, LASTLINE=27, FIRSTCOL=1, LASTCOL=154, this=<error reading variable>) at lazsyntextarea.pp:1870
#5 0x00ab831c in TLAZSYNTEXTAREA__DOPAINT (ACANVAS=0x1a798798, ACLIP=..., this=<error reading variable>) at lazsyntextarea.pp:1489 #6 0x00ab00d0 in TLAZSYNSURFACE__PAINT (ACANVAS=0x1a798798, ACLIP=..., this=<error reading variable>) at syneditmiscclasses.pp:1308 #7 0x00ab6f82 in TLAZSYNSURFACEMANAGER__DOPAINT (ACANVAS=0x1a798798, ACLIP=..., this=<error reading variable>) at lazsyntextarea.pp:1134 #8 0x00ab00d0 in TLAZSYNSURFACE__PAINT (ACANVAS=0x1a798798, ACLIP=..., this=<error reading variable>) at syneditmiscclasses.pp:1308 #9 0x00c1c402 in TSOURCELAZSYNSURFACEMANAGER__DOPAINT (ACANVAS=0x1a798798, ACLIP=..., this=<error reading variable>) at sourcesyneditor.pas:1353 #10 0x00ab00d0 in TLAZSYNSURFACE__PAINT (ACANVAS=0x1a798798, ACLIP=..., this=<error reading variable>) at syneditmiscclasses.pp:1308 #11 0x0070603f in TCUSTOMSYNEDIT__PAINT (this=<error reading variable>) at synedit.pp:4221
#12 0x0057270d in TCUSTOMCONTROL__PAINTWINDOW (DC=469832019, this=<error reading variable>) at ./include/customcontrol.inc:123 ---Type <return> to continue, or q <return> to quit--- #13 0x0055ffa7 in TWINCONTROL__PAINTHANDLER (THEMESSAGE=..., this=<error reading variable>) at ./include/wincontrol.inc:4857 #14 0x00563427 in TWINCONTROL__WMPAINT (MSG=...,
this=<error reading variable>) at ./include/wincontrol.inc:6850 #15 0x00572630 in TCUSTOMCONTROL__WMPAINT (MESSAGE=..., this=<error reading variable>) at ./include/customcontrol.inc:103 #16 0x00410221 in SYSTEM$_$TOBJECT_$__$$_DISPATCH$formal () #17 0x00000001 in ?? ()
#18 0x0120f754 in VMT_$CONTROLS_$$_TCUSTOMCONTROL () #19 0x0120f2b8 in VMT_$CONTROLS_$$_TGRAPHICCONTROL$indirect () #20 0x005725f0 in TCUSTOMCONTROL__WSREGISTERCLASS (pvmt=0x13abfbf4) at ./include/customcontrol.inc:90
#21 0x0056100b in TWINCONTROL__WNDPROC (MESSAGE=..., this=<error reading variable>) at ./include/wincontrol.inc:5429 #22 0x0070d54f in TCUSTOMSYNEDIT__WNDPROC (MSG=..., this=<error reading variable>) at synedit.pp:6399
#23 0x0061ff2a in DELIVERMESSAGE (TARGET=0x1bdaf3a0, AMESSAGE=<error reading variable: Attempt to dereference a generic pointer.>
) at lclmessageglue.pas:112
#24 0x0054410f in TWINDOWPROCHELPER__SENDPAINTMESSAGE (CONTROLDC=0, this=...)
at ./win32/win32callback.inc:746
#25 0x00547922 in TWINDOWPROCHELPER__DOWINDOWPROC (this=...) at ./win32/win32callback.inc:2357
#26 0x005487a1 in WINDOWPROC (WINDOW=1312066, MSG=15, WPARAM=0, LPARAM=0) ---Type <return> to continue, or q <return> to quit--- at ./win32/win32callback.inc:2774
#27 0x76f1630a in gapfnScSendMessage () from C:\Windows\syswow64\user32.dll #28 0x00140542 in ?? ()
#29 0x76f17326 in USER32!GetDC () from C:\Windows\syswow64\user32.dll #30 0x00548750 in TWINDOWPROCHELPER__DOWINDOWPROC ( this=<error reading variable: Cannot access memory at address 0x0>) at ./win32/win32callback.inc:2745
#31 0x76f16df8 in USER32!GetThreadDesktop ()
from C:\Windows\syswow64\user32.dll
#32 0x00000000 in ?? ()
(gdb)

Ok, that is in the new code (inside the OS call...). So some param that it does not like..

Could you try in file syntextdrawer.pp
line 792
function TheFontStock.GetNeedETO: Boolean;
To ALWAYS return false.

Maybe it does not like to have a DX/ETO param.

Martin Frb via lazarus schrieb am So., 4.
Okt. 2020, 18:05:

Thank you! Will test when I find the time. :)

Yes, Cascadia Mono is without ligatures, Cascadia Code is with them.

Regards,
Sven

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201005/c300f82a/attachment-0001.html>

I installed the font myself. And it works on windows 10 and that works.

However I found one possible issue.

Please go to
SynTextDrawer.pp
line 1269
and replace the current
    Windows.ExtTextOutW(FDC, X, Y, fuOptions or ETO_GLYPH_INDEX, @ARect, Pointer(Glyphs), Length(Glyphs), EtoArray); with the following new
    Windows.ExtTextOutW(FDC, X, Y, fuOptions or ETO_GLYPH_INDEX, @ARect, Pointer(Glyphs), CharPlaceInfo.nGlyphs, EtoArray);

The other ...TextOut in the lines below that should be kept as they are.

I've tested it (with Cascadia Code) and while it shows the one or other ligature, Visual Studio shows more.

Take the following sequence:

-> => >= <= *** .. ... >< >> << >>> <<< == !=

Visual Studio shows all as ligatures except the first one and the symmetric difference (I think it doesn't have one)

Lazarus however only shows >=, <=,   and .. as ligatures and for the three points it displays them as ".. .", so the first two are presented by their ligature, but the third dot is done separately (unlike in Visual Studio).

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201005/d153e022/attachment.html>

I found that if I put them into a string or comment, then they do all ligate....
Equally if I switch off the Highlighter

Maybe the HL's tokenizer.
Could be the HL sees a - as one token, and has that printed individually.

So those tokens either need to be kept together (But pascal dictates the "-" as one token), or joined together again.
=> is one Pascal token
-> is not. The HL sees 2 tokens (never mind they make no sense in that order)

Currently also ligatures do get broken, if you extend the selection, and have half of it selected.
That requires a rewrite of some parts of the painting code (needs to get into my TODO queue...)

05.10.2020 18:36, Martin Frb via lazarus пишет:

This change does not help.

I also tried your suggestion to make function TheFontStock.GetNeedETO to always return false.

This did not make any difference too.

-> => >= <= *** .. ... >< >> << >>> <<< == != Visual Studio shows all as ligatures except the first one

It's trivial - synedit just doesn't TextOut such symbols in one block, ie it doesn't renders '->' as 2 chars but renders it as 2 chars - and >. Same for >>> and <<< etc.

Ok, I installed Win7 in a virtualbox, got Lazarus, installed the "JetBrains mono" font (just the regular, skipped all the light/italics....) and "JetBrains mono Variable".

No crash.
Ligatures work (well the subset as described in other mail)

Without any way of reproducing, there isn't much I can do.

----
Can you try to catch it in the debugger, and see what params are given to NewTextOut
in
#2  0x00ab95f6 in DRAWHILIGHTMARKUPTOKEN (ATOKENINFO=..., parentfp=0x13abf6e8)
    at lazsyntextarea.pp:1741

  fTextDrawer.NewTextOut(TxtLeft, rcToken.Top, TxtFlags, tok,
ATokenInfo.Tk.TokenStart, ATokenInfo.Tk.TokenLength, FEtoBuf);

Just a note

    if GetCharacterPlacementW(DC, PWChar(Str), Length(Str), 0, @CharPlaceInfo, GCP_LIGATE) 0 then
      Result:= Windows.ExtTextOutW(DC, X, Y, ETO_CLIPPED or ETO_OPAQUE or ETO_GLYPH_INDEX, Rect, Pointer(Glyphs), Length(Glyphs), Dx)

Should that be
  CharPlaceInfo.nGlyphs
instead of
  Length(Glyphs)
?

GetCharacterPlacementW may return up to (but therefore also less than)  Length(Glyphs) glyphs.
So ExtTextOutW should get the adjusted count?

I did add a couple of checks. Amended it for right to left languages (Arabic).

Arabic only works with certain fonts.
And Japanese Katakana seems not to work at all (or I have not found a supporting font, while without this feature it works with "Deja Vue" and others).

It appears that this API restricts Windows font substitution abilities. It might be that in order for all this to work, one has to use the newer "uniscribe" API.

I also kind of assume that in the current IFDEF code the use of the DX array (ETO) is wrong. But I could not produce any errors from that / And it only would happen if  NeedETO = True.

So for the moment, this stays highly experimental.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20201006/989be547/attachment.html>

06.10.2020 13:32, Martin Frb via lazarus пишет:

Can you add some debugln in a format convenient to you? This will simplify things, I think.

This is in the paint handler, and it is called for each token. So potentially very slow with debugln.

But since it is in startup, hopefully you wont have to many.

Apply this patch please

diff --git a/components/synedit/lazsyntextarea.pp
b/components/synedit/lazsyntextarea.pp
index 4c5a599c9b..163af24e6c 100644
--- a/components/synedit/lazsyntextarea.pp
+++ b/components/synedit/lazsyntextarea.pp
@@ -1737,6 +1737,7 @@ procedure TLazSynTextArea.PaintTextLines(AClip: TRect; FirstLine, LastLine,
     if rcToken.Right > nRightEdge + 1 then
       tok.Bottom := rcLine.Bottom;
     TxtLeft := ScreenColumnToXValue(ATokenInfo.PhysicalCharStart); // because for the first token, this can be middle of a char, and lead to wrong frame
+debugln('Calling NewTextOut L: %s rcT: %s tok: %s tkt: %s // %s // eto: %s', [dbgs(TxtLeft), dbgs(rcToken), dbgs(tok),
dbgMemRange(PByte(ATokenInfo.Tk.TokenStart), ATokenInfo.Tk.TokenLength), dbgs(ATokenInfo.Tk.TokenLength), dbgs(Length(FEtoBuf.EtoData)) ]);      fTextDrawer.NewTextOut(TxtLeft, rcToken.Top, TxtFlags, tok,        ATokenInfo.Tk.TokenStart, ATokenInfo.Tk.TokenLength, FEtoBuf);

diff --git a/components/synedit/syntextdrawer.pp
b/components/synedit/syntextdrawer.pp
index 834d442563..ddbb09f4df 100644
--- a/components/synedit/syntextdrawer.pp
+++ b/components/synedit/syntextdrawer.pp
@@ -1267,9 +1267,14 @@ procedure TheTextDrawer.NewTextOut(X, Y: Integer;
fuOptions: UINT;
      CharPlaceInfo.lpGlyphs:= @Glyphs[0];
      CharPlaceInfo.nGlyphs:= Length(Glyphs);
      Glyphs[0] := #0;
+debugln('BEFORE');
      if GetCharacterPlacementW(FDC, PWChar(W), Length(W), 0,
CharPlaceInfo, GCP_LIGATE or GCP_REORDER or GCP_GLYPHSHAPE) 0 then begin
+debugln('GOT PLACEMENT %s  / %s  / %s', [dbgs(length(Glyphs)),
dbgs(CharPlaceInfo.nGlyphs), dbgs() ]);
+if CharPlaceInfo.nGlyphs > 0 then begin
+debugln('GOT --- %s  / %s', [dbgs(length(Glyphs)),
dbgMemRange(CharPlaceInfo.lpGlyphs, 2*CharPlaceInfo.nGlyphs)]);
        Windows.ExtTextOutW(FDC, X, Y, fuOptions or ETO_GLYPH_INDEX,
@ARect, Pointer(Glyphs), CharPlaceInfo.nGlyphs, EtoArray);
        exit;
+end;
      end;
    end;
    {$ENDIF}

06.10.2020 16:23, Martin Frb via lazarus пишет:

With this patch applied Lazarus seems to crash on debugln in lazsyntextarea.pp. Just in case, I tried to remove this particular debugln, then it printed 'BEFORE' and nothing more.

i:\FPC\lazarus>lazarus --debug-output=.\dbgoutput.txt Hint: (lazarus) [TMainIDE.ParseCmdLineOptions]
PrimaryConfigPath="C:\Users\Maxim
\AppData\Local\lazarus"
Hint: (lazarus) [TMainIDE.ParseCmdLineOptions]
SecondaryConfigPath="i:\FPC\lazar
us"
Hint: (lazarus) [TMainIDE.LoadGlobalOptions]
Hint: (lazarus) LastCalled="I:\FPC\lazarus\lazarus.old.working.exe" Hint: (lazarus) CurPrgName="i:\FPC\lazarus\lazarus.exe" Hint: (lazarus)
AltPrgName="C:\Users\Maxim\AppData\Local\lazarus\bin\lazarus.exe "
Hint: (lazarus) [TBuildManager.SetBuildTarget] Old=i386-win32-win32 New=i386-win
32-win32 Changed: OS/CPU=True LCL=False
TApplication.HandleException: EAccessViolation
Access violation
Stack trace:
$00C12B2D DRAWHILIGHTMARKUPTOKEN, line 1740 of lazsyntextarea.pp $00C11C76 PAINTLINES, line 1799 of lazsyntextarea.pp $00C11847 PAINTTEXTLINES, line 1871 of lazsyntextarea.pp $00C113D8 DOPAINT, line 1489 of lazsyntextarea.pp $00C07EA0 PAINT, line 1308 of syneditmiscclasses.pp $00C0FDD2 DOPAINT, line 1134 of lazsyntextarea.pp $00C07EA0 PAINT, line 1308 of syneditmiscclasses.pp $00D9A022 DOPAINT, line 1353 of sourcesyneditor.pas $00C07EA0 PAINT, line 1308 of syneditmiscclasses.pp $0079ECCB PAINT, line 4221 of synedit.pp
$005B3471 PAINTWINDOW, line 123 of include/customcontrol.inc $0059BB7B PAINTHANDLER, line 4857 of include/wincontrol.inc $005A00A4 WMPAINT, line 6851 of include/wincontrol.inc $005B3330 WMPAINT, line 103 of include/customcontrol.inc $004103A1
$0059D0A7 WNDPROC, line 5429 of include/wincontrol.inc $007A6B0F WNDPROC, line 6399 of synedit.pp
FreeFormEditor: FormEditor1=TFormEditor
Hint: (lazarus) [TMainIDE.Destroy] B -> inherited Destroy... TMainIDE Hint: (lazarus) [TMainIDE.Destroy] END
Heap dump by heaptrc unit of i:\FPC\lazarus\lazarus.exe 6222427 memory blocks allocated : 556846869/572547168 6211889 memory blocks freed : 555436555/571105040 10538 unfreed memory blocks : 1410314
True heap size : 28114944 (128 used in System startup) True free heap : 25543392
Should be : 25661040
Call trace for block $1CEE6DD0 size 64
$00418EBF
$770034A1
$77003473
$76FB0133
$00C11C76 PAINTLINES, line 1799 of lazsyntextarea.pp $00C11847 PAINTTEXTLINES, line 1871 of lazsyntextarea.pp $00C113D8 DOPAINT, line 1489 of lazsyntextarea.pp $00C07EA0 PAINT, line 1308 of syneditmiscclasses.pp $00C0FDD2 DOPAINT, line 1134 of lazsyntextarea.pp $00C07EA0 PAINT, line 1308 of syneditmiscclasses.pp $00D9A022 DOPAINT, line 1353 of sourcesyneditor.pas $00C07EA0 PAINT, line 1308 of syneditmiscclasses.pp $0079ECCB PAINT, line 4221 of synedit.pp
$005B3471 PAINTWINDOW, line 123 of include/customcontrol.inc $0059BB7B PAINTHANDLER, line 4857 of include/wincontrol.inc $005A00A4 WMPAINT, line 6851 of include/wincontrol.inc Call trace for block $1C6FECD0 size 92

Sorry my fault, I thought I had all the nil checks.... Please replace that debugln with

debugln('Calling NewTextOut L: %s rcT: %s tok: %s tkt: %s // %s // eto: %s', [dbgs(TxtLeft), dbgs(rcToken), dbgs(tok),
dbgMemRange(PByte(ATokenInfo.Tk.TokenStart), ATokenInfo.Tk.TokenLength), dbgs(ATokenInfo.Tk.TokenLength), dbgs(FEtoBufnil) ]);

07.10.2020 14:23, Martin Frb via lazarus пишет:

I got the following output:

i:\FPC\lazarus>lazarus
Hint: (lazarus) [TMainIDE.ParseCmdLineOptions]
PrimaryConfigPath="C:\Users\Maxim
\AppData\Local\lazarus"
Hint: (lazarus) [TMainIDE.ParseCmdLineOptions]
SecondaryConfigPath="i:\FPC\lazar
us"
Hint: (lazarus) [TMainIDE.LoadGlobalOptions]
Hint: (lazarus) LastCalled="I:\FPC\lazarus\lazarus.old.working.exe" Hint: (lazarus) CurPrgName="i:\FPC\lazarus\lazarus.exe" Hint: (lazarus)
AltPrgName="C:\Users\Maxim\AppData\Local\lazarus\bin\lazarus.exe "
Hint: (lazarus) [TBuildManager.SetBuildTarget] Old=i386-win32-win32 New=i386-win
32-win32 Changed: OS/CPU=True LCL=False
Calling NewTextOut L: 71 rcT: l=71,t=36,r=85,b=54 tok: l=71,t=36,r=85,b=54 tkt:
2020 // 2 // eto: False
BEFORE

That output looks all ok.

I concluded from the output that you have a 32 bit IDE. So I checked => 32 bit IDE crashes for me too.
From the bit of debugging I have done, this may be a stack corruption. I had cases where the OS returned to NewTextOut (even though indicating that GetCharacterPlacementW failed), but NewTextOut crashed on exit. (either in its internal finally handler, or on actually returning to parent)

Interestingly on Win10 a 32bit IDE - while not crashing - does not display ligatures. The call to GetCharacterPlacementW returns failed.

Anyway, I squeezed this in, under the assumption it might be a quick solution.
So this will have to go back on the todo list.
If someone has any worthwhile idea what might cause the issue....

One more think
Lazarus build with 32bit 3.0.4 on win 7 does not crash. (But ligatures do not work either).

It might be dead simple (at least I hope)

{$IFDEF WINDOWS_LIGATURE}
function GetCharacterPlacementW(hdc: HDC; lpString: LPCWSTR; nCount,
nMaxExtend: Integer; var lpResults: GCP_RESULTSW; dwFlags: DWORD):
DWORD; stdcall; external 'gdi32' name 'GetCharacterPlacementW';
{$ENDIF}

Add stdcall.

At least on win10 that makes 32bit working. Not booting up win 7 again.

I took the declaration from the windows units in fpc => which has some wrongly typed params that I adjusted.
But it also does not have stdcall.

Yes, the stdcall fixes the crash for me on Windows 10 64bit & Lazarus IDE 32bit.

But the ligatures are not very promising. I get ':=' as ligature but
nothing else.

Ondrej

All winapi calls should have stdcall, at least the ones without are suspicious
(iirc for win64 we use the same calling convention so you might not notice)

Marc

Op 2020-10-09 om 04:33 schreef Martin Frb via lazarus:

Windows unit has {$calling stdcall} globally

Ondrej Pokorny wrote

But the ligatures are not very promising. I get ':=' as ligature but nothing else.

You probably will see more inside comments or strings, or if the highlighter is off.

In my tests, I did get in normal pascal source <= >= .. But not ... or =>

The latter are not a single token to the highlighter, so they get broken into text fragments.

Ah, that's true.

Ondrej

09.10.2020 5:33, Martin Frb via lazarus пишет:

Yes, my IDE is 32 bit. It works now correctly for me on Win7 too. Thanks!

Just as an update this breaks other scripts

     dbg.Arguments := 'a b c ä ö 😁 X あｓｆ';

Using Deja vue mono, normally all chars are shown (maybe with windows build in font substitution).

With the patch, the smiley and Japanese (including the 2 full-widths chars) are no longer shown.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20210313/137c76b9/attachment.html>