MakeupLiveFormat - Website to highlight elixir code

Recently, I wanted an easy way to highlight elixir code, and I wanted to use @tmbb’s excellent Makeup library to do so, but it was annoying to get some nice visual output so I decided to create a Phoenix LiveView-powered website to help others with the same issue. Simply paste in your elixir code into the text box and it will immediately be highlighted:

Try it out here: https://makeup-live-format.herokuapp.com/

GitHub: GitHub - axelson/makeup_live_format: Application to that highlights elixir code using the makeup library

12 Likes

I tried it and thee is a bit annoying bug with double newlines (only in rendered) which appear on any input (even if I just press space at end of default input). Can you please fix it?

Hmmm, I’m not able to reproduce that, what browser are you using?

Vivaldi - Chromium-based

EDIT: Looks like my browser handles white-space style in different way than yours.

For me all values except initial, normal and nowrap adds extra newline-like CSS behaviour. Also initial, normal, nowrap and pre-line have CSS behaviour which looks like it remove spaces at start of line.

Hmmm, so what type of styling would you need to get the same behavior that other browsers have?

Sorry, I just found it’s not that. I have compared a default HTML with generated one and see extra span with class err - no idea why.

This is how it looks like by default:

<pre class="highlight"><code><span class="kd">defmodule</span><span class="w"> </span><span class="nc">ExampleModule</span><span class="w">
  </span><span class="kd">def</span><span class="w"> </span><span class="nf">hello</span><span class="w"> </span><span class="k" data-group-id="6243670888-1">do</span><span class="w">
    </span><span class="nc">IO</span><span class="o">.</span><span class="n">puts</span><span class="p" data-group-id="6243670888-2">(</span><span class="s">"Hello World"</span><span class="p" data-group-id="6243670888-2">)</span><span class="w">
  </span><span class="k" data-group-id="6243670888-1">end</span><span class="w">
</span><span class="k">end</span><span class="w">
</span></code></pre>

and here it’s how I cut and paste exactly same code:

<pre class="highlight"><code><span class="kd">defmodule</span><span class="w"> </span><span class="nc">ExampleModule</span><span class="err">
</span><span class="w">
  </span><span class="kd">def</span><span class="w"> </span><span class="nf">hello</span><span class="w"> </span><span class="k" data-group-id="5326747296-1">do</span><span class="err">
</span><span class="w">
    </span><span class="nc">IO</span><span class="o">.</span><span class="n">puts</span><span class="p" data-group-id="5326747296-2">(</span><span class="s">"Hello World"</span><span class="p" data-group-id="5326747296-2">)</span><span class="err">
</span><span class="w">
  </span><span class="k" data-group-id="5326747296-1">end</span><span class="err">
</span><span class="w">
</span><span class="k">end</span><span class="err">
</span><span class="w">
</span></code></pre>

Those span contains one newline character. When I remove that extra span, it’s contents or just set display to none then the code looks as expected.

Ok, I found why that extra span is generated! I suggest you to inspect text which comes from socket. :077:

This is default inspected:

“defmodule ExampleModule\n def hello do\n IO.puts("Hello World")\n end\nend\n”

And here is the one from socket:

“defmodule ExampleModule\r\n def hello do\r\n IO.puts("Hello World")\r\n end\r\nend\r\n”

1 Like

Nasty…

This is not a Bug in this application. It actually exposes a bug in the Elixir lexer, which is that the \r character from windows line endings isn’t matched by the lexer. When used on windows, Elixir seems to conver \n\r into \n, but when used somewhere else it doesn’t. The problem is probably that @Eiji (and me) are sending strings from Windows which are parsed with Elixir running on a Unix system. That way, the \r character is flagged as an error (which generates the extra span tags - very annoying).

The fix seems pretty obvious, the problem is that I’m not sure on how to test it in a portable way.

Pretty funny, but I’m not even using Windows. I’m on openSUSE Tumbleweed. Did something strange happen in Linux world last time? :077:

$ uname -a
Linux install 5.3.12-2-default #1 SMP Thu Nov 21 07:21:43 UTC 2019 (a6f6081) x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/os-release 
NAME="openSUSE Tumbleweed"
# VERSION="20191231"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20191231"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20191231"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
LOGO="distributor-logo"

$ cat /proc/version
Linux version 5.3.12-2-default (geeko@buildhost) (gcc version 9.2.1 20190903 [gcc-9-branch revision 275330] (SUSE Linux)) #1 SMP Thu Nov 21 07:21:43 UTC 2019 (a6f6081)

@axelson I have send 3 small pull requests. One of them is a simple fix to replace that newlines.

@axelson I just wanted to say that I wholeheartedly approve of this demo xD I’ve meant to write something like it for a while, but I never made the time for it.

I wonder if there could be a way for the user to tag code as “looking wrong”, which would cause an email to be sent somewhere (or maybe a bot that creates a GitHub issue in the lexer’s repo?) I can see this being abused though… Maybe if it were protected by a captcha?

3 Likes

Even though you’re using linux, it seems like your browser is sending windows-style strings through the websocket… Is that some kind of web standard in which JS treats all strings as being windows-style? I have to look into it

I’m not sure such a fix would be a good idea. I think the Elixir lexer should be handing this input correctly, that is, it should recognize the \n\r sequence as whitespace. Unless there is something in the Elixir “standard” that says that the compiler is not meant to accept strings with windows-style endings… Is there?

My browser is somehow sending \r\n instead of \n\r. Maybe only my case is not handled properly by lexer?

My PR is just a temporary fix and would fix bug (by workaround) much faster + it could be reverted any time.

It’s not “maybe”. I’ve just checked and the lexer doesn’t handle this case properly (if Elixir is meant to support these line endings).

To be clear, it is \r\n (as emitted by Windows) and Elixir’s parser does handle it. \n\r would not be handled.

2 Likes

FWIW, the same change would be necessary in Erlang’s Makeup parser. :smiley:

I’m glad that you like it! Not sure I’ll get to a “looks wrong” button/form but that is interesting. Perhaps instead of an email it could just create a DB record.

Thanks for the PR’s and the investigation, I’ll take a look at them soon!

FYI, I merged the PR’s (including the \r\n patch). Thanks @Eiji!

1 Like

Thanks @axelson, really nice project! I love how easy it is to generate the beautiful Makeup output in realtime with LiveView!

One thing, at the moment for each single change the whole textarea value is sent to the back-end and the whole highlighted code sent back to the front-end. Maybe adding some debouncing would help?

1 Like

Hi @alvises, thanks for the kind words! De-bouncing is a good idea so I’ve added it in https://github.com/axelson/makeup_live_format/pull/10
Also if anyone is curious what a PR that updates a LiveView project from 0.4.1 to 0.11.1 they can look at: https://github.com/axelson/makeup_live_format/pull/8 along with https://github.com/axelson/makeup_live_format/pull/9 (since I missed a breaking change the first time)

As a side-note I wish there was a way to for phx-throttle to work similarly to lodash’s throttle with leading=true and trailing=true: https://lodash.com/docs/4.17.15#throttle but that should really be a separate forum topic.

2 Likes