If you've ever wanted to be able to use multi-line strings in FPC...

[gues1]

Now open the same file with an editor that is configured to use tabs instead of spaces and add a new line and see how this thing is burning
Not everyone uses the same editor and not everyone configures their editor the same. Also if the editor changes the indentation of untouched lines it completely breaks any source control, so I doubt Delphi is doing that (can't verify tho).
It's not hard to imagine a project with 1 person using tabs and the others using spaces, I've worked with such projects. The language should not break down for this.
In my example above the first line uses 2 spaces and the second one uses 2 tabs. FPC treats them as the same indentation, even though the latter should be twice the indentation.

In Delphi, like I said, every TABS becames spaces (default 1 tab = 2 spaces). If the unit came from external editor too.

Of course if the external editor had different space rappresentation to "tab" this is a problem.
But until now I didn't had any problems 'cause when I work with a sharing project one of the thing that I impose is the "syntax" used for code (idents, formattings, general var name, etc ...).

Normally if I work with other Delphi devs we works with the same parameters, and if I works with other "language" teams it's no meaning about my code formatting.

So, I don't see nothing so bad ... but your exceptions are true.

[Warfley]

In Delphi, like I said, every TABS becames spaces (default 1 tab = 2 spaces). If the unit came from external editor too.

I just downloaded Delphi to test, and as Expected, it doesn't do that. I mean thats obvious because even if Embarcadero is really bad at designing their language in a way thats not horrible, their compiler and editor is quite decent. But alas tested it anyway.

What I did to replicate, I created a new empty Delphi project. Then I opend the file with VSCode where I switched to Tabs for indentation and created the following code:

Code: Pascal  [Select][+][-]

1. begin
2.         WriteLn('''
3.                 Line 1
4.                 Line 2
5.                 Line 3
6.                 ''');
7. end.

Now I opend with Delphi and Added a new line 4:

Code: Pascal  [Select][+][-]

1. begin
2.         WriteLn('''
3.                 Line 1
4.                 Line 2
5.                 Line 3
6.    Line 4
7.                 ''');
8. end.

As you can see Delphi did not touch the other lines, still Tabs there. But what Delphi does, is throw an error when you mix tabs and spaces for indentation.
So at least they solved the issue.

Also some notes, In delphi you can configure your Editor to use tabs instead of spaces, as you can with pretty much any Editor. So you can even have two Delphi editors using both Delphi and still run into these issues.
Also while recognizing this as an error, the error message is hilariously unspecific "inconsistent input character", which I feel could be improved upon.

[gues1]

You are right.

Sometimes it works ... beacause LSP may be will crash .. but when you compile there were an error.
If I start again the IDE, the errors about tabs are present.

I previous responded (now deleted) with the things OK, but that was not right.

I never found these "tabs" errors in the IDE, may be 'cause I always worked with people that work with the IDE too.
I'll search in QP for this anomaly and create one if it doesn't exist.

[Thaddy]

The bug with the backticks inside a block opened with normal ticks is fixed.
The syntax is now accepted and does not crash the compiler anymore.
Thanks Michael!
Example with backticks in ascii art:

Code: Pascal  [Select][+][-]

1. {$ifdef fpc}{$mode delphi}{$endif}{$H+}
2. var
3.   s:String;
4. begin
5. s:=
6. '''
7.  ____  _       _            ____                     _
8. | __ )| | __ _(_)___  ___  |  _ \ __ _ ___  ___ __ _| |
9. |  _ \| |/ _` | / __|/ _ \ | |_) / _` / __|/ __/ _` | |
10. | |_) | | (_| | \__ \  __/ |  __/ (_| \__ \ (_| (_| | |
11. |____/|_|\__,_|_|___/\___| |_|   \__,_|___/\___\__,_|_|
12. '''
13. ;
14. writeln(s);
15. readln;
16. end.
17.  

[d2010]

I hope  I do not spam.,
You can add Ascii'Art direcly in Tstringlist.
You found at Line-48.
I attach here ascii.txt as zip. I try only a few
preparations over ascii.art.txt

Code: Pascal  [Select][+][-]

1. procedure Tform1.DoIteratorEachFilezip3Stream(Sender: TObject; var AStream:TStream;  AItem: TFullZipFileEntry);
2. Var lena,addc:integer; Astr:string; kRegionBatFile:char;
3.    Asho:AnsiSTring;
4.    nth,cnt:integer;
5.  begin
6.  
7.     AStream.Position:=0;
8.     lena:=length(AdCharFmt1c);
9.     if (lena<01) then lena:=01;
10.     inc(cntDoIteratorEachFilezip3Stream);
11.     Astr:='';
12.     addc:=000;
13.     astr:=lowercase(Aitem.ArchiveFileName);
14.     Asho:=extractfileext(astr);
15.     if (asho='.bat') then kRegionBatFile:='b' else kRegionBatFile:='a';
16.    Case kRegionBatFile of
17. 'a':   with Tstringlist.Create do
18.         Begin
19.           LoadFromStream(Astream);
20.           Add(''); Add('');
21.           Add(''); Add('');
22.           Add(''); Add('');
23.           Add(''); Add('');
24.           inc(CancelFeedBack[#13],08);
25.           inc(CancelFeedBack[#10],08);
26.           PFeedWizRes3[PsizeWizInc3].y13:=CancelFeedBack[#13];
27.           PFeedWizRes3[PsizeWizInc3].x10:=CancelFeedBack[#10];
28.           Astr:=GetText;
29.           Addc:=Astream.Size;
30.           Free;
31.           AdCharFmt1c:=AdCharFmt1c+Astr;
32.           for nth:=01 to length(Astr) do inc(CancelFeedBack[astr[nth]]);
33.           lena:=PsizeWizRes3[PsizeWizInc3-1];
34.           Asho:=copy(AdCharFmt1c,lena,255);
35.           lena:=length(AdCharFmt1c)*sizeof(char);
36.           PsizeWizRes3[PsizeWizInc3]:=lena+001;
37.         end;
38. 'b': with TStringList.create do
39.       Begin
40.         Addc:=Astream.Size;
41.         LoadFromStream(Astream);
42.         insert(0,Aitem.ArchiveFileName);
43.         insert(0,'#region');
44.         insert(0,'');
45.         Add('%batmeter='+Aitem.ArchiveFileName);
46.         Add('#endregion');
47.         inc(cntBatmeter.x);
48.         Add('');
49.         Add(';; ,');
50.         Add(';;/,`\');
51.         Add(';;` | \____\\');
52.         Add(';; _(      ) \');
53.         Add(';; \-\~~~_|\  \');
54.         Add(';;    \ `   \  `');
55.         Add(';;    `     `');
56.         Asho:=GetText;
57.         Free;
58.         AdCharFmt2c:=AdCharFmt2c+Asho;
59.       End;
60.   end;
61.     if (addc>03) then  Case kRegionBatFile of
62. 'b':inc(cntlbop.x);
63. 'a': Begin inc(cntlbop.x);;inc(PsizeWizInc3);End
64.        else dec(cntlbop.y);
65.        End;
66.   " Eu multumesc tie ArsenieBoca tie!Doamne milueste-ne"
67.    Astream.free;
68.    setlength(astr,15);
69.    if (length(asho)>2) then setlength(aSho,003);
70. End;
71.  

I see, TstringList support big-ascii-art.txt as very well,
Using concat(s) or  multiple(s) concat are good , but in same cases, the  multiple(s) concat ,, leaks the buffer.
Best Regads..

[Thaddy]

That's not the point. (but it is not spam)
The point is you can write it as a multiline string.
You are doing it the "old" way, which is perfectly fine.
I Just demo'd the "new" way.

I might add that not everybody is quite happy with this feature, including me, but Delphi has it.
In your case it would save a heck of a lot of add's....

Code: Pascal  [Select][+][-]

1. {$ifdef fpc}{$mode delphi}{$endif}{$H+}
2. {$if fpc_fullversion <30301}{$error won't work in lower versions}{$endif}
3. uses classes;
4. var
5.   s:string;
6. begin
7.   s:=
8. '''
9.   ,
10.  /,`\
11.  ` | \____\\
12.   _(      ) \
13.   \-\~~~_|\  \
14.      \ `   \  `   `     `
15. '''
16. ;
17.  writeln(s);
18. end.

Never mind the syntax highlight.... It works and less typing.
And yes, you can add that string to a TStringlist and it will still work... with one add.

Code: Pascal  [Select][+][-]

1. {$ifdef fpc}{$mode delphi}{$endif}{$H+}
2. {$if fpc_fullversion <30301}{$error won't work in lower versions}{$endif}
3.  
4. uses classes;
5. var
6.   s:string;
7. begin
8.   s:=
9. '''
10.   ,
11.  /,`\
12.  ` | \____\\
13.   _(      ) \
14.   \-\~~~_|\  \
15.      \ `   \  `   `     `
16. '''
17. ;
18.  with TStringlist.create do
19.  try
20.    add(s);
21.    writeln(text);
22.  finally
23.    free;
24.  end;
25.  readln;  
26. end.

Maybe the last example is a better way to explain it.

Of course this feature is more for the likes of html, xml, json and sql.

Anyway, it is one add instead of many....

Thanks to Akira and Michael for implementing it.

[Warfley]

I never found these "tabs" errors in the IDE, may be 'cause I always worked with people that work with the IDE too.
I'll search in QP for this anomaly and create one if it doesn't exist.

Yeah I guess that with Pascal most people will use Delphi or Lazarus with the default configuration (2 spaces), I encountered things like this mostly with C where people were using all kinds of different editors

[PascalDragon]

In my example above the first line uses 2 spaces and the second one uses 2 tabs. FPC treats them as the same indentation, even though the latter should be twice the indentation.

It would not make sense for the compiler to treat a tab as a specific number of spaces, because a user might have a different setting. There could even be units from different authors with different settings. So it would be best if FPC would complain just like Delphi does as you discovered. Maybe report a bug, please?

[creaothceann]

Maybe the tab width could be specified via a command-line option to the compiler? The default could be OS-specific; for example Notepad.exe on Windows 11 uses a width of 8.

[Thaddy]

There are some options by means of directives. I will add these later, because I did not test all of them yet.
Meanwhile Michael also fixed a really contrived cornercase that I found.

Code: Pascal  [Select][+][-]

1. {$modeswitch multilinestrings}
2. begin
3.   writeln(
4.   '''
5.  `
6.  '''
7.   );
8. end.
9.  

Any additional char made this compile, but the above did not. Now it does compile correctly.

[PascalDragon]

Maybe the tab width could be specified via a command-line option to the compiler? The default could be OS-specific; for example Notepad.exe on Windows 11 uses a width of 8.

And then you forget that in some invocation and suddenly you have errors. No, thank you. Something like this should not influence compilation.

[Akira1364]

Hey guys. I've been looking back over some recent posts. Couple things I wanted to note:
- I wrote the entire (working) implementation of this functionality LONG before Delphi had multiline strings, basically trying to make it as user friendly as possible in direct response to a bunch of skepticism that was present on the development mailing list at that time (e.g. that's why there's super precise and helpful unterminated multiline string error reporting, that's why the TrimCount compiler directive exists, etc.)
- I originally intended to update it to optionally support the (different, wholly unrelated, later) way that Delphi implemented multiline strings, but Michael VC got around to doing it himself and merging the patch first (which is great, I'm happy to see non-Pas2JS-FPC finally have this).
- All of that said, I guess just keep in mind this functionality was not originally trying to be like Delphi at all because Delphi didn't actually have it then. Were my patch merged several years ago it's somewhat likely that Embarcadero would have just mimiced it directly, but since it wasn't, they just did their own thing with different syntax.

[Akira1364]

Also, there is a bug: backticks crash the compiler, but should be perfectly legal:

Code: Pascal  [Select][+][-]

1. {$modeswitch multilinestrings}
2. begin
3. writeln('''
4.          `
5.         ''');
6. end.

That seems a remnant from Akira's original proposal/patch, which used backticks.
Not very smart because backticks are firmly in the 1..127 range and the compiler can already handle #39 (tick) properly.
No need to escape more.
The bug is in the scanner.

My original patch (again which predates Delphi's multiline strings) ONLY used backticks and absolutely didn't crash lol. I haven't looked too in depth at the exact way that Michael VC updated the code but as far as I can tell he didn't really change it much, the overwhelming majority is literally my original code from the last time I updated it with no changes whatsoever, 99% of what he did was just specifically adding things to make the Delphi-style-syntax also work. I assume that at this current time it works both ways, though, that is, any bugs that resulted from the update have probably been fixed since you left this comment. Just wanted to point that out again, NOTHING about this feature had anything to do with Delphi when originally implemented.

[Thaddy]

Michael v.C. already fixed everything that is reported, so it is no longer relevant.
He fixed everything in the same week, months ago.
In the delphi syntax mode it is compatible to the last detail, meaning a byte wise comparison renders the same data. Right data is not trimmed.
Only left side beatifying is allowed because that does not affect content.