<p>In my 2D esolang, Trilangle, most instructions are a single character, which makes syntax highlighting trivial. However, the &quot;push&quot; instructions are two characters each, which complicates things.</p>
<p>Consider the following subprogram:</p>
<pre><code>   .   .
    . .
     &quot;
. . &gt; _ . . 
   .   .
  .     .
</code></pre>
<p>The two characters on the bottom (<code>&gt;_</code>) can have a different meaning depending on the direction that this is approached:</p>
<ul>
<li>If this is hit from the northeast, <code>&quot;&gt;</code> is a push instruction.</li>
<li>If this is hit from the northwest, <code>&quot;_</code> is a push instruction.</li>
<li>If this is hit from the west, southwest, or east, <code>&gt;</code> changes which direction the IP is moving (and <code>_</code> is a no-op).</li>
<li>If this is hit from the southeast, <code>_</code> changes the direction the IP is moving.</li>
</ul>
<p>2D languages with a &quot;string mode&quot;, such as <a href="https://en.wikipedia.org/wiki/Befunge" rel="noreferrer">Befunge</a>, have a similar problem. In fact, it's possible for <em>every</em> non-quote character in the program to be both an instruction and part of a string (<a href="https://codegolf.stackexchange.com/a/37210/106545">example</a>).</p>
<p>How can syntax highlighters for these languages determine what to color as string/character literals?</p>

<syntax-highlighting><esolang>
How could syntax highlighting work for 2D languages?
CC BY-SA 4.0
2023-07-21T17:30:20.007Z
An interesting 2D language in case you don't know it: https://in-thread.sonic-pi.net/t/using-orca-to-control-sonic-pi-with-osc/2381
coredump
<p>There are a few problems here.</p>
<p>First, <strong>parsing in a &quot;traditional&quot; language goes in only one direction, but in your language it can go in many directions</strong>. The well-trodden parsing theory (grammars, LL/LR, etc.) won't help you here.</p>
<p>Second, <strong>syntax highlighting your language isn't even possible if there are instructions which conditionally change the &quot;cursor&quot;</strong>, because that means an instruction can be interpreted multiple ways at runtime. And even if you restrict highlighting to instructions which can only be interpreted in one way, finding them all is equivalent to solving the Halting Problem.</p>
<hr />
<p>Nonetheless there are 2 approaches you could take:</p>
<ol>
<li><p><strong>Use <a href="https://www.di.ens.fr/%7Ecousot/AI/IntroAbsInt.html" rel="noreferrer">abstract interpretation</a></strong> to &quot;run&quot; your program, but instead of actually running and performing side-effects like printing, just color each instruction. The upside is that coloring will be accurate and you can give multi-meaning symbols a &quot;multi-meaning&quot; color. The downside is this is tricky and slow, and you won't be able to highlight everything because you'll need to guarantee a <a href="https://cs.stackexchange.com/questions/3466/fixed-point-what-does-it-mean-in-the-world-of-computer-science">fixpoint</a>.</p>
</li>
<li><p>Simply highlight all the symbols which <em>look</em> like instructions. For instance, if you see a <code>&quot;</code> next to a <code>&gt;</code>, treat it as such even though the <code>&quot;</code> or <code>&gt;</code> could be executed alone, or backwards. This is the <strong>Word Search</strong> problem (<a href="https://leetcode.com/problems/word-search/" rel="noreferrer">LeetCode</a>, <a href="https://stackoverflow.com/questions/26793846/fastest-algorithm-for-finding-a-word-on-a-word-search-grid">Stack Overflow answer</a>), in your case modified for a hexagonal grid. The upside is that this is easy and fast. The downside is that you're misleading users if the instruction isn't actually hit from the right direction, which may be more likely if your language/programs are small, because many times separate symbols will just coincidentally be together in the same way as an instruction.</p>
</li>
</ol>
<p>Both of these have major downsides. To address them:</p>
<ul>
<li><p>You could make it so there are <strong>no instructions which conditionally change the cursor</strong> (perhaps instead they conditionally turn the cursor &quot;on&quot; and &quot;off&quot; or change what actions are executed), so that all instructions are unambiguous.</p>
</li>
<li><p>You could make <strong>all symbols which are part of multi-symbol instructions, <em>only</em> part of multi-symbol instructions, and then disallow 2 multi-symbol instructions from sharing the same symbol</strong>. This would make it so each symbol can only be parsed as one type of instruction, or as a runtime error.</p>
</li>
</ul>
<p>But, since you're writing an esolang, IMO you really don't have to worry about accurate syntax highlighting or large-scale performance. You could just pick approach #1 or #2 and go with it :)</p>

CC BY-SA 4.0
2023-07-28T20:42:44.707Z
2023-07-28T20:42:44.707Z
tarzh
<p>I think your language needs a dedicated editor, or at least a mode or plugin that goes beyond just highlighting characters. You can have different perspective that highlights different directions (in Southwest view, you see the sequences of characters highlighted specially), and the programmer needs to switch from one view to another to see how the program is structured.</p>
<p>Maybe you can have a main view too: if you imagine each perspective as being a transparent layer, you can combine the different highlights in the main view, assuming this does not result in too much noise.</p>

CC BY-SA 4.0
2023-07-21T17:42:02.397Z
2023-07-21T17:42:02.397Z
coredump
CC BY-SA 4.0
2023-07-22T02:31:55.167Z
That points at the general problem I have with syntax highlighting: I don't actually care about the syntax. I want *semantic highlighting* instead. (No to mention that some popular "syntax" highlighters actually only do *lexical* highlighting.)
Jörg W Mittag
CC BY-SA 4.0
2023-07-22T03:01:12.033Z
@JörgWMittag yes exactly, there are more categories of expressions to highlight than just keyword/function
coredump
CC BY-SA 4.0
2023-07-22T06:03:27.370Z
It will definitely need a dedicated editor because traditional IDEs' concepts of implicit indentation for lines, bracket balancing, etc. will be complete nonsense. Even the assumption of typing left to right and then hitting return and going to the next line isn't necessarily very useful for editing such code.
Karl Knechtel
CC BY-SA 4.0
2023-07-22T12:52:54.743Z
@KarlKnechtel This is a very good point! I honestly have a better time editing Trilangle code in notepad.exe than a traditional code editor precisely because it doesn't do those things.
Bbrk24
# How could syntax highlighting work for 2D languages?
Posted by: username_0 on 2023-07-21
In my 2D esolang, Trilangle, most instructions are a single character, which makes syntax highlighting trivial. However, the "push" instructions are two characters each, which complicates things.
Consider the following subprogram:
   .   .
    . .
     "
. . > _ . . 
   .   .
  .     .

The two characters on the bottom (>_) can have a different meaning depending on the direction that this is approached:

If this is hit from the northeast, "> is a push instruction.
If this is hit from the northwest, "_ is a push instruction.
If this is hit from the west, southwest, or east, > changes which direction the IP is moving (and _ is a no-op).
If this is hit from the southeast, _ changes the direction the IP is moving.

2D languages with a "string mode", such as Befunge, have a similar problem. In fact, it's possible for every non-quote character in the program to be both an instruction and part of a string (example).
How can syntax highlighters for these languages determine what to color as string/character literals?
**Tags:** syntax-highlighting esolang
> **Comments:**
> **username_1**: An interesting 2D language in case you don't know it: https://in-thread.sonic-pi.net/t/using-orca-to-control-sonic-pi-with-osc/2381  
---
## 2 answers
### Answer by username_1 on 2023-07-21. Score: 7
I think your language needs a dedicated editor, or at least a mode or plugin that goes beyond just highlighting characters. You can have different perspective that highlights different directions (in Southwest view, you see the sequences of characters highlighted specially), and the programmer needs to switch from one view to another to see how the program is structured.

Maybe you can have a main view too: if you imagine each perspective as being a transparent layer, you can combine the different highlights in the main view, assuming this does not result in too much noise.
> **Comments:**
> **username_3** (2023-07-22): That points at the general problem I have with syntax highlighting: I don't actually care about the syntax. I want *semantic highlighting* instead. (No to mention that some popular "syntax" highlighters actually only do *lexical* highlighting.)  
> **username_1** (2023-07-22): @JörgWMittag yes exactly, there are more categories of expressions to highlight than just keyword/function  
> **username_4** (2023-07-22): It will definitely need a dedicated editor because traditional IDEs' concepts of implicit indentation for lines, bracket balancing, etc. will be complete nonsense. Even the assumption of typing left to right and then hitting return and going to the next line isn't necessarily very useful for editing such code.  
> **username_0** (2023-07-22): @KarlKnechtel This is a very good point! I honestly have a better time editing Trilangle code in notepad.exe than a traditional code editor precisely because it doesn't do those things.  
---
### Answer by username_2 on 2023-07-28. Score: 5
There are a few problems here.

First, **parsing in a "traditional" language goes in only one direction, but in your language it can go in many directions**. The well-trodden parsing theory (grammars, LL/LR, etc.) won't help you here.

Second, **syntax highlighting your language isn't even possible if there are instructions which conditionally change the "cursor"**, because that means an instruction can be interpreted multiple ways at runtime. And even if you restrict highlighting to instructions which can only be interpreted in one way, finding them all is equivalent to solving the Halting Problem.

---

Nonetheless there are 2 approaches you could take:

1. **Use [abstract interpretation](https://www.di.ens.fr/%7Ecousot/AI/IntroAbsInt.html)** to "run" your program, but instead of actually running and performing side-effects like printing, just color each instruction. The upside is that coloring will be accurate and you can give multi-meaning symbols a "multi-meaning" color. The downside is this is tricky and slow, and you won't be able to highlight everything because you'll need to guarantee a [fixpoint](https://cs.stackexchange.com/questions/3466/fixed-point-what-does-it-mean-in-the-world-of-computer-science).
2. Simply highlight all the symbols which *look* like instructions. For instance, if you see a `"` next to a `>`, treat it as such even though the `"` or `>` could be executed alone, or backwards. This is the **Word Search** problem ([LeetCode](https://leetcode.com/problems/word-search/), [Stack Overflow answer](https://stackoverflow.com/questions/26793846/fastest-algorithm-for-finding-a-word-on-a-word-search-grid)), in your case modified for a hexagonal grid. The upside is that this is easy and fast. The downside is that you're misleading users if the instruction isn't actually hit from the right direction, which may be more likely if your language/programs are small, because many times separate symbols will just coincidentally be together in the same way as an instruction.

Both of these have major downsides. To address them:

* You could make it so there are **no instructions which conditionally change the cursor** (perhaps instead they conditionally turn the cursor "on" and "off" or change what actions are executed), so that all instructions are unambiguous.
* You could make **all symbols which are part of multi-symbol instructions, *only* part of multi-symbol instructions, and then disallow 2 multi-symbol instructions from sharing the same symbol**. This would make it so each symbol can only be parsed as one type of instruction, or as a runtime error.

But, since you're writing an esolang, IMO you really don't have to worry about accurate syntax highlighting or large-scale performance. You could just pick approach #1 or #2 and go with it :)
---
