() type displayed as ) about package.elm-lang.org HOT 15 CLOSED

This is weird. The cause is almost certainly in this file, but I wasn't able to figure it out yet. Are you able to take a look?

from package.elm-lang.org.

I'd love to but I can't get the package built. I'll open a thread on the list for visibility.

Also, I found Keyboard.keysDown as Signal Set KeyCode) which means it's dropping open parens not related to the unit type.

from package.elm-lang.org.

Oh, that's an intriguing hint! Can you record the exact typos you find by editing the initial issue? Collecting the exact text in one place will help us see patterns.

from package.elm-lang.org.

!!! I think I got it. I added some code to drop qualifiers, but I think it is too naive and will group the parens with the qualifier. I think that's what's happening in the Signal Set KeyCode) example at least. I don't see how it explains the unit case though.

I bet this code explains part of things. Can you try that out just in a small file and feed it strings to see what it does? May not be necessary to build everything!

from package.elm-lang.org.

That reproduces the problem for Keyboard.keysDown but not Signal (). It will also turn Set.Set Time.Time into Time (except there's a words upstream).

One option is to uses regexes:

dropQualifier : String -> String
dropQualifier token =
  let qualifiers = Regex.regex "[A-Za-z1-9_]*[.]"
  in Regex.replace Regex.All qualifiers (always "") token

I dug through the parser code and I think I figured out what matches valid module names. Also "\." is rejected as a regex so to match the dot I had to put it in angle brackets. The regex even handles crazy but valid types like Time.Time -> Graphics.Element.Element without any string splitting.

The string splitting solution is a bit involved - I've inlined the String.words here -

dropQualifier : String -> String
dropQualifier tipe =
  String.words tipe
  |> List.map (String.split ".")
  |> List.map (\tokens ->
    case tokens of
      [] -> ""
      [x] -> x
      x::xs -> if String.startsWith "(" x
               then String.cons '(' (last xs |> Maybe.withDefault "")
               else last xs |> Maybe.withDefault "")
  |> String.join " "

I'm happy to PR whichever one you like but I prefer the regex, especially if you can be more certain I'm not leaving modules behind.

from package.elm-lang.org.

Nice, I like the regex one better too, can you do a PR for that?

One thing to think about is that module names can be any unicode, so it may make sense to use something like this but that actually does not exist in JS :( The other thing is that because you are in a string, you need to double escape things: \n is a newline in a string, whereas \\n is going to show up to the user as \n. For some reason the JS stuff needs it as \\. I think.

from package.elm-lang.org.

Have you confirmed this fixes the issue?

from package.elm-lang.org.

Oh, oops! Yes, it's live on the site too!

from package.elm-lang.org.

Okay, I see that Keyboard.keysDown is fixed but all the unit types are still broken.

from package.elm-lang.org.

The error is server-side. If you look at the JSON file being sent when loading a docs page, unit types are already missing the open paren. Example with Task.Task x ).

from package.elm-lang.org.

If you run elm-make --docs whatever.json on your code, does that output have the issue? Or is this something I introduced when migrating the old docs to new docs?

from package.elm-lang.org.

If the migration introduced it, the fastest / best fix may be to find type fields with an uneven number of parens and fix them by hand.

from package.elm-lang.org.

Running the docs locally produces the correct output. As confirmation, we see the issue in core (Mouse.clicks) even though it hasn't been updated recently. But I'm not sure the migration is at fault either, since I also see the issue on libraries uploaded today.

I dug through the server and it seems to just serve the json file. Can you have a look at the actual file on disk (like the example in my last post) and see if the problem is there?

Also, reopen the issue?

from package.elm-lang.org.

Okay, I think I went and fixed all the old things. Can you confirm that these things are gone?

If it is true that "elm-make --docs" is working okay then we should be done. If not, we have narrowed things down a bit!

from package.elm-lang.org.

Yup, looks like things are fixed and the new docs generator is working. Thanks!

from package.elm-lang.org.