kenjis1 has quit [Remote host closed the connection]
drakonis has joined #nixos-dev
lovesegfault has quit [Quit: WeeChat 2.7]
lovesegfault has joined #nixos-dev
ris has quit [Ping timeout: 252 seconds]
das_j has quit [Remote host closed the connection]
Scriptkiddi has quit [Remote host closed the connection]
Scriptkiddi has joined #nixos-dev
das_j has joined #nixos-dev
drakonis has quit [Ping timeout: 268 seconds]
drakonis1 has joined #nixos-dev
drakonis1 has quit [Client Quit]
drakonis1 has joined #nixos-dev
justanotheruser has quit [Ping timeout: 258 seconds]
justanotheruser has joined #nixos-dev
lovesegfault has quit [Ping timeout: 252 seconds]
lopsided98 has quit [Quit: Disconnected]
justanotheruser has quit [Ping timeout: 258 seconds]
lopsided98 has joined #nixos-dev
justanotheruser has joined #nixos-dev
lovesegfault has joined #nixos-dev
drakonis1 has quit [Quit: WeeChat 2.7]
orivej has joined #nixos-dev
orivej has quit [Ping timeout: 258 seconds]
lovesegfault has quit [Quit: WeeChat 2.7]
<MichaelRaskin>
ryantm: I think a PR/issue can also be blocked by an issue?
<MichaelRaskin>
Also, this is exactly the case where not having an actual issue tracking system is annoying (if it was a reference blocked-by: it would be easy to ask whether the blocker has been resolved)
ixxie has joined #nixos-dev
orivej has joined #nixos-dev
ris has joined #nixos-dev
orivej has quit [Ping timeout: 268 seconds]
kenjis has joined #nixos-dev
Synthetica has joined #nixos-dev
__monty__ has joined #nixos-dev
__monty__ has joined #nixos-dev
__monty__ has quit [Changing host]
kenjis has quit [Remote host closed the connection]
kenjis has joined #nixos-dev
kenjis has quit [Remote host closed the connection]
kenjis has quit [Remote host closed the connection]
kenjis has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
FRidh has joined #nixos-dev
<aanderse>
is the idea that we support upgrading from ancient (2-3+ years old) versions of nixos directly to current stable, or that users should have to upgrade from version now-4 to now-3 to now-2 to now-1 to now?
<ryantm>
MichaelRaskin: How about "2.status: blocked by PR/issue" ?
<MichaelRaskin>
aanderse: I think in practice people might be required to build multiple intermediate versions of Nix…
<aanderse>
MichaelRaskin: if you're running a server with loads of state that probably seems like a smart idea
<MichaelRaskin>
ryantm: yes, I think this wording is the shortest which is still clear. My point about having actual issue tracker still stands, but it is also out of scope
<MichaelRaskin>
aanderse: I have no idea what is the current PostgreSQL upgrade story in NixOS
<aanderse>
MichaelRaskin: i'm considering special "migration" scripts which were put in place (forever ago) and probably shouldn't be there anymore. after 5+ versions is it fair to just drop them assuming people will have upgraded to one of the previous 5 versions of nixos first.
<ryantm>
Alright, I'm going to add that label.
<FRidh>
ryantm: seems useful to me
kenjis has quit [Quit: Leaving.]
kenjis has joined #nixos-dev
kenjis has quit [Remote host closed the connection]
kenjis has joined #nixos-dev
drakonis1 has joined #nixos-dev
kenjis has quit [Remote host closed the connection]
tilpner_ has joined #nixos-dev
kenjis has joined #nixos-dev
tilpner has quit [Ping timeout: 240 seconds]
<infinisil>
aanderse: Ideally nothing would prevent people from doing such big upgrades
<infinisil>
I think the only thing in the way is the nix version
<infinisil>
as of now
<infinisil>
And that should be fixable
<infinisil>
The problem is that current nixpkgs is only evaluatable with not ancient nix versions
<aanderse>
infinisil: yeah, i suppose so. unfortunately that makes it more of a challenge in keeping legacy stuff around, though
<infinisil>
So we'll have to have some iterative bootstrapping thing where we "get latest nixpkgs version that evaluates with the users current nix, build nix from that, find the next nixpkgs the user can build"
<infinisil>
As long as we keep such a path open, it should be fine
<infinisil>
Oh!
<infinisil>
Idea: A linked list of nixpkgs versions!
tilpner_ is now known as tilpner
<infinisil>
Every nixpkgs contains a lib.bootstrapNixpkgs = "<commit hash of a nixpkgs that contains the lowest required nix version to evaluate current nixpkgs>"
<infinisil>
Then to evaluate a nixpkgs version, we can first check whether the nix we have can evaluate it, otherwise look at bootstrapNixpkgs and first build nix from that, and so on
<MichaelRaskin>
I think lib is exactly where the new stuff might end up?
<MichaelRaskin>
Maybe better to just have /bootstrap_revision file?
kenjis has quit [Remote host closed the connection]
kenjis has joined #nixos-dev
<MichaelRaskin>
(I guess location should be discussed a bit)
Synthetica has quit [Quit: Connection closed for inactivity]
NinjaTrappeur has quit [Quit: WeeChat 2.7]
NinjaTrappeur has joined #nixos-dev
<infinisil>
MichaelRaskin: Ah yeah, just a file sounds better
orivej has joined #nixos-dev
ixxie has quit [Ping timeout: 265 seconds]
ixxie has joined #nixos-dev
<infinisil>
Another problem is how to make it compatible with older nixpkgs versions
<MichaelRaskin>
infinisil: you cannot fully solve the problem retroactively
<MichaelRaskin>
Old nixos-rebuild lacks the necessary knowledge whatever you do
<infinisil>
Hm true..
<infinisil>
So maybe we'll just not worry about that and only focus on the future
<MichaelRaskin>
I guess we could make the Nix version check print the oldest commit which is not completely broken and has a new enough Nix version
<MichaelRaskin>
This might be useful for some users, I guess
<infinisil>
That sounds like a good compromise
<MichaelRaskin>
Actually, it is a complicated question whether nixos-rebuild _should_ try to follow this reference
<MichaelRaskin>
After all, a couple of years worth of release notes might require a configuration.nix change
<infinisil>
I think that's a separate issue
<infinisil>
We just need to get it to evaluate at all with the most recent nixpkgs version
<infinisil>
Then people can fix their potentially now-broken config
<MichaelRaskin>
Yes, but people might want to switch to intermediate versions anyway
<MichaelRaskin>
Just because these migrations were actually tested
<infinisil>
MichaelRaskin: Will also be possible by just not using the latest nixpkgs version
<MichaelRaskin>
Anyway, we need to print the complaints correctly, if only because Nixpkgs use is not the same as NixOS use
<infinisil>
Hm, we could maybe get rid of the --fast flag of nixos-rebuild and make it the default
<infinisil>
I think that might have been introduced to prevent such nix migration issues, but I don't think it really works
<infinisil>
(well, it's only useful if you can't evaluate your system with your nix version, but pkgs.nix works)
<infinisil>
But that shouldn't really happen with minver.nix
<MichaelRaskin>
I think it is for the cases where the modules system updates require new stuff, but Nix — being a relatively simple derivation — can be built with the old Nix
<infinisil>
MichaelRaskin: I think minver.nix should be increased for that as well. It's in lib too
<infinisil>
And the module system is in lib
<infinisil>
Okay but first, I need to finish writing this damn documentation format RFC!
<MichaelRaskin>
Ahaha
<infinisil>
Maybe I should just push the current draft, I mainly just need some good overviews of the different formats now
<infinisil>
I'll just do that, anything is better than forgetting this for another week
<niksnut>
I can't wait for another round of bikeshedding over documentation formats
kenjis has quit [Remote host closed the connection]
kenjis has joined #nixos-dev
<infinisil>
niksnut: This RFC won't be about which one is the best, only about the process for determining the format
<{^_^}>
rfcs#64 (by Infinisil, 32 seconds ago, open): [RFC 0064] New Documentation Format
<MichaelRaskin>
infinisil: if the RFC needs to gain a usable description of the formats, it doesn't matter what the RFC is about, but the discussion will be bikeshedding about formats
<infinisil>
MichaelRaskin: I don't want people to make remarks like "but this one is better than this because bla bla". This RFC is just for "How good is format X at this?". But yes we need to agree on this which I guess can involve some discussions
<infinisil>
But generally it's much less controversial than which format is the best
<MichaelRaskin>
I will not be surprised at all when a discussion about which considerations are missed but important starts
<__monty__>
A poll? I see you haven't learned of Brexit? : >
<MichaelRaskin>
Maybe learned too much? A properly botched and manipulated poll brings you to the position of leadership!
<MichaelRaskin>
I think the first phrase of the RFC PR description is already enough to start a bikeshedding
<infinisil>
Come on, don't always be so negative
<infinisil>
Let's just see where this goes
<drakonis1>
finally, time for some excitement
<drakonis1>
__monty__: debian systemd polls :V
<drakonis1>
infinisil: rendered rfc
<drakonis1>
broken
<infinisil>
drakonis1: Oh thanks, fixed now
<infinisil>
niksnut: -.-
<infinisil>
Don't start the bikeshedding already please
<infinisil>
If you have another format you'd prefer, feel free to suggest it, otherwise feel free to write a short objective overview for docbook
drakonis2 has joined #nixos-dev
drakonis1 has quit [Ping timeout: 248 seconds]
kenjis has quit [Remote host closed the connection]
<MichaelRaskin>
infinisil: Told you so. No really, you write a phrase that postulates an existing consensus, it is likely false at its full weight, what did you expect.
<infinisil>
MichaelRaskin: What is false?
<MichaelRaskin>
You say «the community wants», we have more or less two ways to establish that as a truth
<MichaelRaskin>
Either an accepted RFC or unanimous assent
<infinisil>
MichaelRaskin: Other than niksnut, I don't know anybody who wants to stay with docbook. See also https://discourse.nixos.org/t/documentation-format/4650 where nobody mentions they want to stay with docbook. I think this can certainly be considered pretty much the whole community
<infinisil>
I guess I can change it to "almost the whole community wants ..."
<MichaelRaskin>
You should just go with existential instead of universal quantifier and say that a lot of active community members would prefer to move away from Docbook
<__monty__>
While I agree with fridh that exactly what documentation would be covered should be in the RFC I hope they're not implying projects might choose different formats? That sounds like a strictly worse situation than the status quo?
drakonis2 has quit [Quit: WeeChat 2.7]
<gchristensen>
MichaelRaskin isn't debating it, just pointing out that making conclusive statements about the entire community is a bold move :P
<infinisil>
__monty__: Yeah I'd want all of nix, nixpkgs and nixos to use decide on a single format
<infinisil>
Also for being able to join/interlink them
<infinisil>
MichaelRaskin: gchristensen: Alright I changed it
<MichaelRaskin>
I do think that a good pandoc setup would do us more good than a unified migration (and could be done with a lot less opportunities for pushback)
<LnL>
getting the opinion from people that have worked on the docs the most is probably also more valuable then those that complain about the format
<samueldr>
LnL++
<{^_^}>
LnL's karma got increased to 17
<gchristensen>
LnL++
<{^_^}>
LnL's karma got increased to 18
<MichaelRaskin>
And do not forget to include Wiki people
<samueldr>
mediawiki format is not a contender here for a good documentation format :)
<MichaelRaskin>
Isn't it currently a majority of Nix* documentation?
<samueldr>
I wouldn't think so, nixpkgs and nixos manuals are quite beefy
<samueldr>
they may very well have a fair fight here
<MichaelRaskin>
Well, it depends on how you count the option list, I guess
<samueldr>
what the nixos wiki does have is a greater variety of shallower topics I think
<samueldr>
with some extra-deep parts
<MichaelRaskin>
I would say it is effectively written in plain text
<samueldr>
not counting the options list
<samueldr>
that would be cheating :)
<samueldr>
MichaelRaskin: I'm saying that as a wiki person
<MichaelRaskin>
Well, it _is_ documentation…
<MichaelRaskin>
And probably its existence ensures that no side has majority
<samueldr>
yeah, right, and it technically is docbook :)
<MichaelRaskin>
Do we have any tags there?
<MichaelRaskin>
I mean, in the actual practice
<MichaelRaskin>
I mean, ever
<samueldr>
hm?
<samueldr>
it's mediawiki, there are categories, which I think work in a taggly way
<samueldr>
but are not strictly speaking tags
<MichaelRaskin>
No, I mean in the option list
<samueldr>
ah!
<samueldr>
yes there are!
<samueldr>
docbook tags yes
<__monty__>
MichaelRaskin: While I'd consider pandoc as the build tool a good idea in theory. Given that all the documentation is still written in a single format, just as a way to provide easy migration to yet another different format in the future. In practice its too limited imo. Its reST support is more or less lamentable for instance.
<samueldr>
for the html view of the options list, there is docbook to html conversion being made in-situ in the JS bits
<MichaelRaskin>
Well, it depends on the demand for reST support
<__monty__>
MichaelRaskin: No, what I'm trying to say is pandoc really only supports markdown. And a markdown subset of various other formats...
<__monty__>
So pushing for pandoc would really come down to pushing for markdown and only markdown.
<MichaelRaskin>
Ah, it's that limited
<__monty__>
It doesn't have to be of course. But would require significant development effort for each format you want fully supported.
<infinisil>
Yeah I also don't find pandoc optimal
<infinisil>
pandoc seems more like something you'd want to use for one-time conversion from one to another format
<__monty__>
Hmm, I disagree. Pandoc's the greatest thing since sliced bread. It just comes with caveats.
<MichaelRaskin>
Wait, how is it good enough even for one-time conversion if it misses too many things?
<__monty__>
It's excellent for conversion *from* markdown. : )
<__monty__>
Also latex and docx for example.
<__monty__>
I currently use it with reST, Just have to take into account the features that aren't supported. Custom directives for example.
<infinisil>
Not included in the RFC yet: If markdown is chosen, how do we decide on which markdown to choose
<gchristensen>
that is indeed a danger of markdown
<__monty__>
Does sphinx support markdown? It's the reST tool afaik?
<infinisil>
Yeah..
<infinisil>
__monty__: It supports both apparently
<infinisil>
But I believe most use reST with it
<__monty__>
gchristensen's requirement focus a lot on the maintainer side of the docs imo. That's what's brought us to this, people don't like *authoring* in docbook.
<jtojnar>
Adding my voice for Docbook English like words are easier to remember than random combinations colons, periods, backticks and brackets
<MichaelRaskin>
Should there be any specific plan for options documentation conversion?
<gchristensen>
jtojnar: that is definitely a perk
<gchristensen>
I feel like that perk goes away if it takes 0.5s to try one and then the other
<jtojnar>
Indeed, but that should be fixable
<gchristensen>
what should be fixable?
<jtojnar>
Tooling
<gchristensen>
ah
<infinisil>
jtojnar: On the other hand, people need to first learn which words to use
<infinisil>
jtojnar: Quick: What's the docbook words for a man page entry?
<jtojnar>
That would be the same for adoc / rest
<__monty__>
And english and translated documentation doesn't mix.
<infinisil>
For me at least, I was never able to remember docbook words and syntax and stuff, which is why I put it here:
<infinisil>
,xml
<{^_^}>
Nix XML docbook cheatsheet: <link xlink:href="https://example.com"/> <citerefentry><refentrytitle>man</refentrytitle><manvolnum>1</manvolnum></citerefentry> <programlisting>let some = "program"; in some</programlisting> <literal>true</literal> <option>users</option> < = < > = > Simple docbook reference: https://docbook.rocks/
<jtojnar>
I just copy paste the less commonly used ones, but I believe reentry?
<jtojnar>
REFENTRY
<infinisil>
Well almost lol
<jtojnar>
autocomplete lol
<__monty__>
jtojnar: Then looking up a table of formatting syntax doesn't actually sound like more work?
<__monty__>
And you internalise it almost as quickly. Every dev knows the common markdown symbols, no?
<MichaelRaskin>
You mean backticks, right?
<MichaelRaskin>
Because I have no idea about the rest
<infinisil>
gchristensen: How was jing a problem in the xml build process?
<infinisil>
Wondering about that
<MichaelRaskin>
I guess backticks collapsing literal/variable/path into the same thing can be billed both as a plus and as a minus
<__monty__>
You don't know *emphasis*, **strong** emphasis and [links](http://url)?
<gchristensen>
jing is a MUCH nicer XML processer than xmllint or whatever. it gives mucd more reasonable errors. however, the dependence upon openjdk and the resulting closure size was too much.
<infinisil>
gchristensen: What was the problem with the bigger closure size? People complaining?
<jtojnar>
I just saw the various link syntaxes in rest and gave up (though Docbook also is not as uniform as I would like)
<MichaelRaskin>
What even _is_ strong emphasis?? I know <b> and <i>
<gchristensen>
it was a blocker and was not merged
<gchristensen>
small closure size, as much as you don't want it to be, is a definite requirement
<MichaelRaskin>
I think _ does something in markdown, and I have no idea what exactly
<__monty__>
MichaelRaskin: That's for the tool/project setup to decide.
<__monty__>
Underscores are just an alternative to * afaik? And it's for situations where one is less convenient.
<gchristensen>
back in a while
<MichaelRaskin>
Oh, there are all the completely crazy space rules
<infinisil>
**monty**: _ also have a different meaning in different formats I believe
<infinisil>
s/have/has
<__monty__>
Different markdown formats?
<MichaelRaskin>
Link syntax is busted in all minimalistic markups, HTML a href is the gold standard
<infinisil>
__monty__: In asciidoc and rst and such I think
<__monty__>
infinisil: Well all the symbols mean different things in unrelated formats, I don't see the problem?
<infinisil>
Yeah in asciidoc it's _italic_ and *bold*
<infinisil>
Just something to keep in mind, because most people are used to markdown
<infinisil>
I kind of think markdown is also a no-go because it's so html focused
<infinisil>
s/a no-go/not optimal
<__monty__>
The problem with markdown is the proliferation of formats. You'd end up with nix-documentation-flavored markdown.
<infinisil>
Hehe
<MichaelRaskin>
Not supported by any preexisting tooling, I guess?
<jtojnar>
can we gather a list of features we want?
<infinisil>
gchristensen: Why do we have pandoc is the build process now though, which is much worse than 300MB?
<infinisil>
jtojnar: Check the RFC, we're collecting requirements there
<__monty__>
That's not out of the question though, imo. reST would also not serve well as-is but with the right custom directives etc. I could see it as a nice way to write docs.
<infinisil>
(and discussing them)
<FRidh>
__monty__: I indeed meant that say nix could have a different format because it's different people contributing to it. And, if I understand LnL correctly, I also value the opinion more of those that actually contribute (docs) to the respective project.
<FRidh>
I don't think anybody likes it if suddenly others decide what you should code or write in.
<__monty__>
FRidh: But that's a catch-22. Some people don't contribute because docbook's too burdensome for them.
<MichaelRaskin>
So you need to ask the wiki people?
<__monty__>
If only the people that are happy with the status quo get to have a say then of course nothing ever changes.
<FRidh>
yea I've heard that excuse before. You know, Python docs have been in markdown since I wrote them and they've hardly seen changes. In fact, I recall a PR where one did not want to write docs because those docs were supposedly in docbook
<FRidh>
yes, it's a burden to write in a language you're not familiar with or just don't like...but regardless of the choice, we end up with that
<__monty__>
FRidh: The impression that all the docs are in docbook is clearly enough to scare people away *even* if technically those docs aren't in docbook at all.
<FRidh>
__monty__: a significant part of the nixpkgs docs are in markdown. If one has never actually bothered to look at the source, should they be taken serious then?
<LnL>
yeah that's kind of my point
<infinisil>
I did write idris docs only because there already were some in markdown
<__monty__>
Imo they should. Any pair of eyes that hasn't looked at your docs just because they erroneously think it's in a particular format is a potential contributor lost.
<LnL>
sure there might be a few more people that will contribute with another format, but I'm not convinced it will be a large percentage
<__monty__>
Seriously, if people loathe docbook enough to not even bother looking at the source for the docs, maybe it's not the best format to keep most of them in?
<LnL>
I personally don't have a problem with docbook, but the current tooling isn't great
<__monty__>
Documentation's already not a popular thing to contribute to, I don't see a need for extra hurdles.
<infinisil>
Agree with __monty__
<LnL>
sure if tooling was the main argument here I would agree a lot more
<__monty__>
I know that even in my very minor contribution(s? I think it was singular) docbook did *not* inspire me to look further for sections that could be improved.
<FRidh>
Originally I wanted to write the Pytohn docs in rest, because that's what I was familiar for. I absolutely did not like docbook. There was already some markdown docs (haskell) so as a trade-off I went for markdown, even though it's worse IMO. Now, I am more leaning to converting it to docbook, because there's hardly any contributors to it, and I could add proper in-document references
<__monty__>
Maybe having a format that's nice for authoring *and* maintaining isn't possible? Then a tool like pandoc so submissions can be in markdown or whatever but maintained in docbook would be a cool solution. But it'd require significant effort to make the conversions back and forth lossless afaics.
<infinisil>
__monty__: Our current docs are really outdated. And I think such a solution would make this ever worse
<infinisil>
s/ever/even
<__monty__>
Being able to write in your personal favorite format would make documentation worse?
<infinisil>
Well we'd have more docs, but less people willing to update them when they become outdated
<infinisil>
I'd think
<__monty__>
Why? I'm talking about converting the file you wanna work on from docbook to "my favorite format", working on it and then converting back for submission, by the contributor or by dedicated docs maintainers.
<infinisil>
Oh I see
<infinisil>
I understood to only do the "favorite format -> docbook" step
<infinisil>
__monty__: Problem with that is that we lose information in the conversion and end up with only features supported by the intersection of all formats
<MichaelRaskin>
I have a feeling that Docbook in that scheme is not the same docbook as we are using now
<__monty__>
Note that I'm also saying that doesn't come for free. But if maintainers and authors can't agree on a single format I don't think there's a better-case solution.
<infinisil>
E.g. manpage entries in docbook would be converted to `man(1)` in markdown, then to <literal> back in docbook
<__monty__>
infinisil: Not with custom filters. Which is the effort I'm alluding to.
<infinisil>
Hm I see
<infinisil>
Ultimately I think we're better off by just deciding on a single format and using that. All other tech projects can do that too
<MichaelRaskin>
I wonder if there is a way to make literal/variable distinction easy in Markdown
<__monty__>
MichaelRaskin: It would be plenty easy in nix-documentation-flavored markdown : >
<MichaelRaskin>
It will never be plenty easy
<MichaelRaskin>
Because you need to remember the dstinction exists
<MichaelRaskin>
And Markdown primes you not to
orivej has quit [Ping timeout: 265 seconds]
FRidh has quit [Quit: Konversation terminated!]
<__monty__>
But you get to add whatever syntax you want in the nix-documentation-flavored markdown.
justanotheruser has quit [Ping timeout: 260 seconds]
<gchristensen>
infinisil: w.r.t. pandoc, it isn't in the build closure for nixos
<gchristensen>
just like jing is used in docs for nixpkgs, but not nixos
orivej has joined #nixos-dev
<MichaelRaskin>
__monty__: I am not sure how long would it take to get rendering support from GitHub
<__monty__>
Is that a requirement?
<gchristensen>
that is a great question ;)
<__monty__>
Because that limits the options, especially for markdown flavors.
<MichaelRaskin>
So, we do not get to bikeshed about which Markdown flavours to include?
<__monty__>
Nope, only gfm and subsets, like standard markdown.
<infinisil>
asciidoc renders really nicely in github
<drakonis1>
infinisil: localize text for multiple languages
<drakonis1>
its pretty much required for maximizing reach
<infinisil>
I'm not sure we're at the point where we can keep docs in multiple languages up-to-date when we can't even do it in english
<gchristensen>
we're not
<gchristensen>
but we have the tools to do it if we chose to
<infinisil>
gchristensen: So you actually meant spoken languages and not doc format conversion?
<gchristensen>
yeah, I'll clarify
<infinisil>
Cool
<gchristensen>
I'll also clarify what I mean by "requirement"
<infinisil>
I think some of your points there are more nice-to-have's and not requirements
<infinisil>
s/and not/than
<drakonis1>
i'll ring up some people for translation when we're past the hurdle of having docs
<infinisil>
gchristensen: Regarding the point about spotting errors, do you mean like to have editors that can automatically highlight errors?
<gchristensen>
I don't mind
<gchristensen>
like if it takes editor integration and that does it, sure. if it is a live-reloading rendering of what you're authoring and it takes 0.5s to re-render, that works too
<gchristensen>
btw I think it is a new crowd here from last time I said so -- r13y.com is building regularly again, and the latest nixos-unstable's channel has 1537 out of 1561 (98.46%) paths reproducing
<drakonis1>
very nice.
<infinisil>
Ah so it's less about spotting it in the code, and more about getting quick error feedback in any way
<gchristensen>
right, it is a statement about UX
<infinisil>
Maybe I'd rewrite that as "fast feedback loop" or so to be clearer
<gchristensen>
I'd like to leave it as-is for now, actually
<infinisil>
Hm, "trivially being able to spot errors [in source code]" (which is my understanding) doesn't sound like something any format can fulfil
<gchristensen>
well, that isn't what I wrote :P
<infinisil>
Sorry, quote correction: "errors [..] are trivial to spot" (my understanding: [in source code])
<gchristensen>
"during authoring"?
<infinisil>
Hm, that seems so obvious to be omittable to me
<gchristensen>
eh
<gchristensen>
okay
<infinisil>
Anyways, these are just my thoughts on this
<infinisil>
Though I guess it's important to come to a consensus for requirements too
orivej has quit [Ping timeout: 268 seconds]
drakonis1 has quit [Read error: Connection reset by peer]