rost_gen VS rustfmt

This week, I released version 1.0.1 of rost_gen, a simple static site generator built using rust. I had kind of forgotten about versions for a while, but the project had advanced enough for a v1 release. Since I had used rust, the appropriate place for a release was crates.io.

This week, I added some automated testing to my static site generator project, rost_gen. As the project is built using rust, it was quite easy to get started as I did not need to use any additional frameworks.

This week, I added a formatter and linter to rost_gen (a static site generator) to improve the readability of the code and fix common issues automatically. I chose to use rustfmt for the formatter and rust-clippy for the linter.

This week, I was tasked with adding another feature to my static site generator rost_gen based on Docusaurus features. Docusaurus is a great static site generator that has a lot of features. It provides a starting template, and even a command to deploy to github pages. After some deliberation, I decided it would be best to add support for parsing links to other pages (internal and external). If implemented properly, it would allow me to easily add additional inline markdown features such as bold, italic, etc. I broke down the feature into several parts and created issues for them:

For this week in my course in open-source development, I was tasked with refactoring my ssg project (rost_gen). A simple and though potentially time-consuming task.

My rost_gen ssg project also received a PR about adding config file parsing. After reviewing the changes, I decided to test it locally by setting up a tracking branch using git. This was fairly simple to do, and I can't believe I did not try this before. Since I have not added any automated tests, I previously did this by looking at the code. However, as more features get added, it is not possible to check if the code will work as you think. By using a local tracking branch, I was able to easily test the changes and find some formatting issues by using VS code's auto formatting. I requested the author to resolve these and merged the PR by merging the branch into the master branch.

For week 4 of my course in open-source development, I was tasked with adding two more features to my ssg project rost_gen. However, I was supposed to work on both at the same time on different branches and merge those branches into the main branch once both implementations were complete. Normally, I would use pull requests and not merge directly into the main branch.

For this week in my course on open-source development, we were tasked to pick another ssg (static site generator) project and add support for markdown (.md) files and at least one markdown feature. Someone reached out to me about adding markdown support to my ssg (rost_gen) and created an issue for it.

The first step I did was I added an issue to Eakam's repository so that they knows what I'm doing with their code For this Lab 2, I'm going to implement the code that allows user covert a md file into a html file. Also, I would like add a feature that be able to change the header syntax (#) in an MD file into the

This is a project that I created as part of my course in open-source development. Rost_gen is a basic static site generator made using Rust that generates html files from text files.

The author provides very surface-level criticism of two Rust tools, but they don't look into why those choices were made.

With about five minutes of my time, I found out:

wrap_comments was introduced in 2019 [0]. There are bugs in the implementation (it breaks Markdown tables), so the option hasn't been marked as stable. Progress on the issue has been spotty.

--no-merge-sources is not trivial to re-implement [1]. The author has already explained why the flag no longer works -- Cargo integrated the command, but not all of the flags. This commit [2] explains why this functionality was removed in the first place.

Rust is open source, so the author of this blog post could improve the state of the software they care about by championing these issues. The --no-merge-sources error message even encourages you to open an issue, presumably so that the authors of Cargo can gauge the importance of certain flags/features.

You could even do something much simpler, like adding a comment to the related issues mentioning that you ran into these rough edges and that it made your life a little worse, or with a workaround that you found.

Alternatively, you can continue to write about how much free software sucks.

[0]: https://github.com/rust-lang/rustfmt/issues/3347

[1]: https://github.com/rust-lang/cargo/pull/10344

[2]: https://github.com/rust-lang/cargo/commit/3842d8e6f20067f716...

The new style still supports single line let-else, and there is a configuration parameter to make it be on one line also for longer lines.

It seems there is an issue about this dating all the way back from 2018 but yet it still hasn't been fixed.

However since 4179 recent versions should merge configuration files. Not sure what the details / specifics are but if just ignoring the file entirely is not good enough you might give it its own directory and rustfmt.toml file and see if that works.

Could this be be #3863 - Gives up on chains if any line is too long? It might not be, because I can't see a specific "line" that's too long to format, but there's more detail about the exact problem in the issue.

Rustfmt is a tool that formats Rust code in compliance with style guidelines. Its name precisely reflects its purpose. To install rustfmt, you can run rustup component add rustfmt. Once installed, you can execute cargo fmt to format Rust code in your workspace. If you require further information, you can visit rustfmt’s GitHub repository.

code must be formatted with rustfmt.

Yes, some cases are not yet supported (https://github.com/rust-lang/rustfmt/issues/4914).

Just FYI, the let-else suggestions will only work until rustfmt settles on a format for it. So you may be surprised when this happens and it suddenly changes.