Love the makedown name, renaming..
As for a short name available in terminal, we can add alias m="makedown" as part of zsh completion script.
Both:
$ makedown deploy-to-production
and
$ m deploy-to-production --help will work
Aditionally we can generate html out of the, now `makedown.md`, right in the tool:
$ makedown --html makedown.html
or
$ m --pdf makedown.pdf
I appreciate the quickness in renaming a project (x.md wasn’t great), but you’re missing the main point that Make provides - building a project based upon changing input files (DAGs and all of that). Make files are great in that they are flexible and allow this type of usage (especially with .PHONY),
But without the “building” component to it, I found the name makedown confusing. Maybe that’s just me.
But I like the project overall. I’m still trying to get my head around the syntax, but it looks nice. I’m also not sure I’ll switch from keeping scripts like this in my $HOME/.local/bin directory, but I can see how this is an appealing way to work.
I use Makefiles all the time for dependency management, not necessarily for compiling code. For example, in a data analysis workflow, I’ll use a make file to manage the processing from ETL, extracting out whatever data I need, and finally, generating a figure. Whenever one step in the process is updated, the rest are automatically also run.
But now seriously.. the diagrams are working really well for simple examples, thank you so much for sharing this tool. I have bookmarked your page, my documentation is based on text files and often have to build these kind of diagrams too.
The example buttons took me a while to be found, but are good for syntax explanation. Thank you for making this available.
I won't mention telnet because you don't use it, but in CSV and similar data it is quite a trouble to normalize the data. So instead of 2 possibilities now we 3 to detect.
I don't get the CSV part. You can emit a new row after a line ending and on EOF with non-empty buffer. What's the tricky part or third option here? The crlf is never a part of the data.
Absolutely correct: You never had issues. Other people have built other software that does not use modern CSV libraries. They work just fine today and don't need to update, wouldn't even be possible for most cases in either case.
Please do consider that many software products will not change and they will still be actively used on production environments that you will never have interest about.
Well, GP proposed removing the idea of trailing newlines from standard *nix tools entirely, so I think it's fair to ask what shop is going to update their RHEL deployment to upgrade to a version of `cat` or `sed` that doesn't have trailing newlines but can't spend 5 minutes to handle a newline properly in their CSV parser? That doesn't make a lot of sense.
And it was pretty clear from the context of norir's comment that they were not talking about legacy software, they were talking about writing new projects/file formats that used newlines as a separator. Just because you want to shoehorn your legacy projects into this discussion doesn't mean that they fit.
