Random colorized code looks nice but isn't helpful

Help!
1

Hi,

I’m using: SWI-Prolog version 9.30 on a windows11 machine. I’m using mostly XPCE version 7.0.0 because the colored syntax helps me a bit during programming. But when my code gets longer it becomes more and more random colors (see below). Any idea where it comes from?

Screenshot 2025-10-09 131527
Screenshot 2025-10-09 131527512×768 50.2 KB

Viele Grüße

Siegfried

2

It looks like the colors are fine, but there is some offset issue that causes them to be at the wrong place. Can you share the file? Either attach here or send to bugs@swi-prolog.org?

3

Well here it is:stupid_expert_v00_00.pl (3.6 KB)

“Colors at the wrong place…” hm. I just loaded the file into Notepad++ to see it with different colorsyntax: And found two colons (originally comming from a commentline. But the where black over black. So I couldn’t see them (crazy).

I correct that and now the colors are fine do far. I would love to rant about Windows11, but most likely it’s a beginner’s mistake…

The program is more for me to study Prolog instead of helping the operation crew… The idea is that the script figures out which operation procedures are currently relevant 8regrding the current state of the machine) and it should give advice which procedures are used to reach another machine state.

I’m still not ready…

4

This is getting rather weird. I loaded this file into Linux. That shows fine, except that the encoding seems to be ISO Latin 1 and my system expects UTF-8, so some of the German stuff is shown a invalid character.

Then I loaded the file into the Windows 11 version. All shows up as expected. German characters as well as colours.

What could be different? It seems the transfer as attachment has not changed the file. At least it still has DOS line endings and ISO Latin 1 encoding.

Any ideas? Could someone else try?

5

In Windows 10/Edge browser, I have downloaded the file and opened it with Notepad++, which says ASCII encoding (extended ASCII), and Windows line endings, i.e. CRLF.

Then I have found at least one problem: there are several EOL comments, e.g. % --- Auflistung der Betriebszustände etc. with a sole CR at the end, which (by SWI-Prolog and in the SWI editor, not in Notepad++) is not a newline and eats the subsequent line of code: and it so happens that, at line 66 as seen in Notepad++, that is causing a syntax error proper.

In general, on Windows or else, I suggest setting up your code editor(s) to only use \n as a newline for all text files, i.e. irrespective of the programming language and even for the data files.

1 Like
6

There are many .pl files included in a swi-prolog installation - do they render correctly?

LF (Unix standard) or CRLF (Windows) signify a newline. I’d call it a bug if a text parser cannot handle a file containing a mix of the 2 standards, since it’s a simple parsing rule.

A lot of text editors will follow https://editorconfig.org/

Was there a particular text editor used to create this inconsistent-format file?

7

In general, CR/LF encoding should not matter for PceEmacs. It reads the file assuming DOS line endings (at least that is what it detects on my Windows 11). Then it is represented inside the editor as only \n. The highlighting code reads directly from the editor. If the input phase does not work you see the \r inside the editor. That is not the case.

There is sometimes an offset issue for the GUI tracer. That is because positions are computed from the file. Normally works well, but there some cases where it fails (forgot which; might be fixed).

In SWI-Prolog, I/O normalizes all text to Unicode with \n line endings.

8

I think the crazy coloring issue has been resolved with your help:

The *.pl files from the swi-prolog installation are displayed correctly.

I wrote my first Prolog files at home (Linux + nano) and continued working on them at work using Notepad++ on Windows and start writing code in swipl editor also…. Using different text editors caused inconsistencies, but this hadn’t caused me any problems in my other projects until now.

For now, I’ll stick with the swipl editor and install Prolog on Linux at home as well. I’ll also refrain from using ‘German stuff: umlauts, etc.’ for now. So far, it’s working and everything is nice and colorful – and in the right place.

Now I’m sure I’ll learn Prolog faster – thank you. :slightly_smiling_face:

9

Good. I’d like to know what is causing the trouble though. Ok, inconsistent NL/CR could be considered an invalid file, but nevertheless the file loads fine on my Windows 11 and, AFAIK, it should not have impact on the highlighting. Also non-ASCII should be fine and it does show up correctly on (again) my Windows-11.

As is, the only known (to me) problems are

  • Unicode code points > 0xffff on Windows. Prolog itself can handle these, but the graphics system (mostly) not. That problem is Windows specific as wchar_t is 16 bits on Windows (and 32 bits on all other platforms I’m aware of).
  • Unicode combining characters. That is, you can write many characters with diacritics as a single code point or two of them (the diacritic as combining character followed by the character to apply it to). This is currently not normalized and the editor is unaware that the two characters belong together and takes only the space of the non-combining character. This problem is cross platform.

One possible explanation is that your original file uses combining characters for the umlaut diacritics and that was changes somewhere during transfer? If you still have the broken file, could you zip it and send it as attachment to bugs@swi-prolog.org? Please include the exact length in bytes and, if you have it, a hash (MD5, SHA1, …), so I can be sure transfer did not change it.