[Oberon] all in one git tree

[Guy]

I've been following the conversation on this very interesting subject.
Being a heavy user of git and other *marvelous* source code management
tools for the last 35 years, I can't count the number of times these
tools saved my ass of inserted bugs in code that the change history
management of those tools helped me find the issues... but I'm
digressing...

I have (very) stupid questions: Why is Oberon OS is allowing the use of
non-plain text source code entry? What is the benefit? Would it be
better to have ASCII (or UTF-8 or whatever) files that would simplify
so much the interaction with other systems? If it is for code
embellishment on screen and printout, what about implementing these
features in tools at the OS level, as every other system do?

An Happy New Year to all of you!!

Guy



On Thu, 2020-12-31 at 01:02 +0100, Liam Proven wrote:
> On Wed, 30 Dec 2020 at 19:50, Till Oliver Knoll
> <till.oliver.knoll at gmail.com> wrote:
> > > Am 26.12.20 um 12:21 schrieb Liam Proven:
> > > 
> > > It manages source code. Nothing else.
> > 
> > At least as far as github.com is concerned, this is not quite true
> > anymore ;)
> 
> OK, fair!
> 
> > Github has grown to be a platform with many, MANY more features
> > which go way beyond a nice "web GUI wrapper around git". Just to
> > mention a few (over which I just "stumbled" recently myself):
> > * Web hosting of "project web pages" (which coincidentally are
> > managed/updated via a specific git branch containing all the HTML
> > respectively markdown files): https://pages.github.com/
> 
> Yes -- a friend of mine uses this to host his personal blog, for
> free.
> 
> > * "Continuous Integration", with the possibility to define own
> > "actions" ranging from simple "code checking" to building
> > executables / containers / whatnot: 
> > https://docs.github.com/en/free-pro-team@latest/actions/guides/about-continuous-integration
> 
> Yes, we use that in $DAYJOB.
> 
> The amusing thing is: a tonne of work enabled Travis to generate PDFs
> and HTML and so on from Docbook, AsciiDoc and more. Which are then
> discarded.
> 
> And the feedback we get is extensive, but the feedback most of us
> _use_  is "it worked" or "it didn't work" as the model the CI tool
> uses to build stuff is so far away from the files on my disk that
> mostly I understand nothing useful from the failures, other than that
> there was a failure.
> 
> But I am a tech writer using tools for programmers. :-(
> 
> > * Per project Wikis, issue trackers, project pages, ...: 
> > https://docs.github.com/en/free-pro-team@latest/github/building-a-strong-community/about-wikis
> > 
> > And probably way more.
> > 
> > And yes, git has become the de facto industry standard for source
> > repositories - so no point in complaining about it ;)
> 
> Also fair!
> 
> > But this mandatory XKCD summarises it indeed perfectly:
> > 
> >   https://xkcd.com/1597/
> > 
> > 
> > ;)
> 
> Absolutely right.
>