INI files 2.0
I agree, the feature set seems largely inspired by INI files. It seems in general there is a large demand for a more flexible (and less ugly) version of INI files.
The Eno notation language
21–30 of 33 posts
Re: The Eno notation language
#22Well, it doesn't look particularly intuitive, but it can't be worse than YAML.
Re: The Eno notation language
#23This looks like a cool project, but I don't know how I feel about the non-primitive type loaders. Date strings, email addresses, urls, colors, and lat-long are hard problems, and trying to handle them in the spec is a misstep. Leave the complex loaders out, strive to handle perfectly just the core list of primitives, and let devs write their own email or url parsers. (Who is asking for lat-long parsing?)
(Seriously, the email parser doesn't match most of the Examples [0] on the Wikipedia page about email validation. Don't use regex to validate unless you're gonna write `/.* @.*/`.)
Re: The Eno notation language
#24INI files 2.0
Wouldn't that be TOML?
Re: The Eno notation language
#25From a relatively short glance, I don't see any mention of what problem this is trying to solve. Data interchange? Storage? Consumption/production? I see some excitingly magical looking type "inference" happening though. That ruby code is sure that the value associated with Malaga is a lat/long pair is it? Not a temperature range, etc.? So, some very optimistic approach to types, no real way to validate content, and…
What you're seeing there is actually validation :), the lat/lng type is not magically inferred but instead explicitly requested by the code - if it were not valid it would generate a user-friendly, localized error message. Also the underlying document hierarchy that holds the data is validated. So on the contrary it is actually hard not to validate content in eno.
The quirky looking syntax you mention is probably familiar to you from YAML or paper forms ("Name: Joe"), and Markdown ("# Section"), likewise if you have two levels you use "## Subsection".
There's quite a few things that eno solves (there's only so much space on a frontpage, sorry), but if you want one of the more prominent ones: It's considerably hard to win over users without technical background to switch to secure, statically generated content solutions when the most prominent format works like this: http://yaml.org/spec/1.2/spec.html I've explained eno in 5mins to a non-technical intern who is now managing content at a client of mine and in months I haven't heard a single question about how eno works! User empowerment. <3
Re: The Eno notation language
#26This looks like a cool project, but I don't know how I feel about the non-primitive type loaders. Date strings, email addresses, urls, colors, and lat-long are hard problems, and trying to handle them in the spec is a misstep. Leave the complex loaders out, strive to handle perfectly just the core list of primitives, and let devs write their own email or url parsers. (Who is asking for lat-long parsing?) (Seriously,…
I fully agree with your assessment - eno allows arbitrary types, therefore if and to what extent non-primitive type loaders should be included as core functionality needs to be thoroughly considered and negotiated soon. I included non-primitive loaders (also the exotic lat/lng ;)) to (a) show that this is a possibility and (b) get hands-on insight how well this works in real world usage. (in short: I love it so far, but I'd love to hear other experiences!) It took months to get the whole ecosystem jump-started as a one man show, so that's why some loaders are ... pragmatically coded, you're of course right on that, although admittedly I had no idea the email spec was that complex, thanks for making me aware. ;)
Re: The Eno notation language
#27What non-indented markup languages gain by avoiding indentation, they lose in succinctness. What is the difference between a section, a list, and a field set? When would I use one instead of another? If your aim is data representation, why not go for JSON, Lua table-notation or S-expressions? These do not need different syntax for sections, lists or field sets, but have very clear syntax for a few primary data struct…
section vs. list in eno is like object vs. array in JSON - you need both.
eno has neither indentation nor closing tags of any sort, that means if you use a section to group some values, you need to start another section to end the previous one (no closing tags!), that's why there are fieldsets, which allow short groupings that automatically end with the next field/list/fieldset.
I share your opinion that a single syntax would be the ideal thing, but not having closing tags (which keeps the language simple and fast to write) required a trade-off in the language design to be made.
Why not JSON, Lua table-notation or S-expressions? Because the prime design goal was to achieve greatest possible simplicity and accessibility - almost anyone should be able to use it, no matter the background. If possible I would have wanted eno to be even more reduced and simple, but at some point you have to draw a line too, otherwise you end up with a toy, and then you won't ever get adoption by devs either. So this is why eno ... :) Thanks for your question!
Re: The Eno notation language
#28JAMD (just another Markdown)
Re: The Eno notation language
#29From a relatively short glance, I don't see any mention of what problem this is trying to solve. Data interchange? Storage? Consumption/production? I see some excitingly magical looking type "inference" happening though. That ruby code is sure that the value associated with Malaga is a lat/long pair is it? Not a temperature range, etc.? So, some very optimistic approach to types, no real way to validate content, and…
What you're seeing there is actually validation :), the lat/lng type is not magically inferred but instead explicitly requested by the code - if it were not valid it would generate a user-friendly, localized error message. Also the underlying document hierarchy that holds the data is validated. So on the contrary it is actually hard not to validate content in eno. The quirky looking syntax you mention is probably fam…
> What you're seeing there is actually validation :), the lat/lng type is not magically inferred but instead explicitly requested by the code - if it were not valid it would generate a user-friendly, localized error message. Also the underlying document hierarchy that holds the data is validated. So on the contrary it is actually hard not to validate content in eno.
Please make this clear on the website! I think it’s a clever idea.
Also, this has garnered some attention on Lobste.rs [1], if you’re interested to read the discussion there as well.
[1]: https://lobste.rs/s/jno6gb/eno_notation_language_libraries
Re: The Eno notation language
#30Earlier quoted context omitted.
Yes exactly - Hashes denote 'sections' in eno! In the language design phase this was heavily inspired by markdown, because of the already widely familiar concept of 'headings' - I collected feedback from users that (although they showed considerable anxiety given the prospect that they were to use text files to edit their content in the future instead of a fancy web interface) they found working with markdown (quote)…
This is a really cool project! I don't need quite the power of eno (yet!) in my CLI journaling app[1], but I similarly value the power of users being able to just easily read and write their own data. (I went with Markdown for the data store.) [1]: https://github.com/JacobEvelyn/friends
Thanks for the encouragement!
I like the philosophy of friends! (even though I too don't need quite the power of it (yet). ;))