1. 17
  1.  

  2. 3

    Do you plan to move eggex parsing & translation into a separate library, for easy linking from other projects? (Or did you maybe already do that? I tried searching but didn’t seem to be able to find one easily.)

    1. 4

      I would like to, but realistically it won’t happen because I’m working on many other things now. I would probably copy the grammar into yacc to make a reference implementation:

      https://github.com/oilshell/oil/issues/491

      If anyone wants to do that we should chat about it on Zulip. It’s not a big language – yacc should be able to create a tree easily, and then printing it to ERE or PCRE is a “dumb” single-pass algorithm.

      edit: the other things I’m working on: http://www.oilshell.org/blog/2019/12/09.html#whats-next

      1. 1

        Ok, then if I decide I want it one day, I’ll contact you. Thanks!

        edit: Ah, I wondered why I missed the whats next list; now I see that’s because it is cunningly hidden in plain sight below a long and boring list of contributions ;)

    2. 2

      Do the examples work for y’all? When enter e.g. “pat = / [0-9]+ /” in osh pre10, it just barfs that “[ interactive ]:1: ‘pat’ not found”.

      1. 2

        Oh sorry you have to use bin/oil to do that. In bin/osh it’s var pat = / [0-9]+ /.

        That’s basically because foo = in shell means running a command foo with an argument = !

        I need to document that difference more.

        Also, the two syntax changes I mentioned aren’t in the 0.7.pre10 release – they’ll be in the next one. So if you want the latest you can get the dev build which takes 30 seconds on most machines.

        https://github.com/oilshell/oil/wiki/Contributing

        Thanks for trying it, and let me know if you have more problems!

        1. 1

          Makes sense, now that you tell me. Thanks a lot!

      2. 1

        Hey your site always views tiny on mobile. Might need to add something like this

        <meta name="viewport" content="width=device-width, initial-scale=1">
        

        I’m unfamiliar with this metalanguage

        https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form

        1. 1

          Hm I just tried that but it looks funny on my iPhone. Right now I just turn my phone horizontally and it’s readable. It doesn’t work well vertically I agree. If anyone has any other suggestions let me know.


          It is some variant of BNF because of the ::=, but I’ve never seen ... to mean a character range. The wikipedia page mentions [] as an extension but not ... .

          I guess the point is that Eggex should be readable enough for a specification (unlike Perl regex) and unambiguous enough for a computer program to execute (unlike the many variants of BNF).

          Also the wikipedia page uses <subpattern> where as Python’s spec just uses subpattern.

          1. 2
            • The meta tag is a good idea. It is dumb that we all have to insert, essentially, the same boilerplate into every website, but such is the internet.

            • Your body element has the .skinny tag, which has a hard width of 30em. You likely want to specify max-width: 30em, so that element automatically shrinks on narrower viewports (like a portrait phone).

            • Your <pre> blocks are also long. I’ve always struggled with styling long code blocks for mobile clients. There are some simple things you can do: pre { overflow: auto } will turn on scrollbars, and a smaller font helps too. But, I think, nothing beats rewrapping your source code, even though that might be a lot of work.

            (I’m a big fan of your blog. Also, I think we may both know someone in common [Sonke].)

            1. 3

              It is dumb that we all have to insert, essentially, the same boilerplate into every website, but such is the internet.

              It’s basically a shibboleth that means “yes, I understand there are displays narrower than 800 pixels”. It’s kind of a weird thing given that the Web was supposed to be device-independent from the beginning, but there was that awkward early-teen phase where “device independent” meant “this page looks OK at 800×600 and 1024×768”, which will live forever because the #1 rule of browser-maintenance is “don’t break the web”.

              1. 2

                Hm I added those changes here. It does make it bigger by default, at the cost of removing the left margin, which makes it hard to read IMO.

                http://www.oilshell.org/blog/2019/12/22-mobile.html

                It seems to be better by default but remove some flexibility. The way it is now I can make it look nice if I zoom the right way.

                I think one solution for the <pre> problem is to prefer a skinnier font? I’m not sure what that would be though.

                1. 1

                  I wish you luck on your responsive CSS journey. Iosevka is my skinny font of choice.