luxmiranda/herms

:stew::fork_and_knife: A command-line manager for delicious kitchen recipes

Herm's

HeRM's: a Haskell-based Recipe Manager (yes, food recipes) for the command line.

Table of Contents

• Herm's
  • Features
    • What's new
    • Supported languages
  • Contributing
  • Installation
    • Manually cloning and installing from source with Stack
    • Via Hackage and Cabal
    • Manually with Cabal
    • Manually with Nix
  • Usage
    • Command-line interface
    • Configuring Herm's and managing recipe files

Features

• Add recipes! :)
• Look at recipes! :D
• Edit recipes! :DD
• Serving size adjustment! :DDD
• Remove recipes :(
• View metric recipes in imperial units and vice-versa
• Import and export recipes as JSON or YAML
• Generate shopping lists
• Keep track of recipes with tags
• Set default unit systems, serving sizes, language, and recipe (see the section on configuration)

What's new:

Version v2.0 is out! This is the first release for which pre-built binaries are available to download on Github. There were many, many great changes in 2.0, so thanks to everyone for the contributions!

See the changelog for more details.

Supported languages

• català
• English
• Español
• français
• Pirate (English)
• português

Contributing

Herms is very actively maintained and welcomes new contributions, whether in code, issues, documentation, translations, or feature suggestions!

Please see Contributing.md for more information.

Installation

At the moment, Herm's can only be installed via stack or cabal, but standalone binaries are in the works!

If you're interested developing/hacking Herm's instead of just using it, see Contributing.md instead.

Via Stack

stack update
stack install herms

Manually cloning and installing from source with Stack

git clone https://github.com/LuxMiranda/herms
cd herms
stack update
stack install

Via Hackage and Cabal

Note: Your mileage may vary with dependency resolution

cabal update
cabal install herms

Manually with Cabal

git clone https://github.com/JackKiefer/herms
cd herms
cabal update
cabal install

Manually with Nix

See ./nix/README.md.

Usage

Command-line interface

Herm's has a command-line interface!

Below is the exhaustive list of all commands and their functionalities. Take a gander!

Usage: herms [-v|--version] COMMAND
  HeRM's: a Haskell-based Recipe Manager. Type "herms --help" for options

  Available options:
    -h,--help                Show this help text
    -v,--version             Show version

    Available commands:
      list                     list recipes
      view                     view the particular recipes
      add                      add a new recipe (interactively)
      edit                     edit a recipe
      import                   import a recipe file
      export                   export recipes to stdout
      remove                   remove the particular recipes
      shopping                 generate a shopping list for given recipes
      datadir                  show locations of recipe and config files
      find                     find all matching strings within recipe book
                               (supports extended regex)

Configuring Herm's and managing recipe files

Herm's stores files in the following locations:

• The configuration file, config.hs in the XDG configuration directory, typically ~/.config/herms on most Linux systems

• The recipes file, recipes.yaml in the XDG data directory, typically ~/.local/share/herms on most Linux systems

To see where these are stored on your system, run herms datadir.

config.hs is a pseudo-Haskell-source-code file with several options for configuring the behaviour of Herm's. It currently supports the following options:

• defaultUnit : The default unit system to show recipes in. Options: Imperial, Metric, None. Setting to None will simply show recipes in whatever unit system they're stored in.
• defaultServingSize : Default serving size to calculate when showing recipes. Can be any non-negative integer; set to 0 for no default. This can be useful when you're always cooking for the same number of people!
• recipesFile : The recipes file to use. This option currently supports relative (but not absolute) location, as well; if your data directory is ~/herms/data, for example, and you want a recipe file in your home directory called ~/GrandmasHugeCookbook.yaml, set this option to "../../GrandmasHugeCookbook.yaml".
• language : Human language to use. See above supported languages.

---

In honor of Logan, Utah's greatest Breakfast & Brunch.

herms's Issues

Don't require all fields in YAML recipes

YAML is a nice, human-readable and writable format for storing recipes. However, our current implementation can be a bit verbose. Often, I'll specify a recipe and most attributes fields will just be set to the empty string "". I think we should make some of these fields optional if possible, and default to an empty string. In particular, I'm thinking of:

• Ingredient
  • unit
  • attribute
• Recipe
  • description
  • tags (default to the empty list)
  • servingSize

I think that the way to do this would be to use the :.? operator from Data.Yaml, changing something like

instance Yaml.FromJSON Ingredient where
  parseJSON = Yaml.withObject "Ingredient" $ \o -> Ingredient
    <$> (readFrac  <$> o .: Text.pack "quantity")
    <*> (parseUnit <$> o .: Text.pack "unit")
    <*> (o .: Text.pack "name")
    <*> (o .: Text.pack "attribute")

into something like:

instance Yaml.FromJSON Ingredient where
  parseJSON = Yaml.withObject "Ingredient" $ \o -> Ingredient
    <$> (readFrac <$> o .:? Text.pack "quantity")
    <*> (parseUnit . fromMaybe "" <$> o .:? Text.pack "unit")
    <*> (o .: Text.pack "name")
    <*> (fromMaybe "" <$> o .:? Text.pack "attribute")

(NOTE: I didn't actually typecheck the code above).

Current NixOS build is broken (both nix build and nixified stack)

Running NixOS 19.09 everything up to date since I started typing this, and the nix method outputs:

δ nix build -f .
builder for '/nix/store/2f0yxxnlhmp8psq2vgg09y8fx0rh4nkx-herms-1.9.0.4.drv' failed with exit code 1; last 10 log lines:
  version (src/Lang/Strings.hs:140)
  versionShort (src/Lang/Strings.hs:141)
  versionDesc (src/Lang/Strings.hs:142)
  progDesc (src/Lang/Strings.hs:148)
  unsupportedFormat (src/Lang/Strings.hs:149)
  supportedFormats (src/Lang/Strings.hs:150)
 0% (  0 /  2) in 'Lang.Spanish'
Missing documentation for:
  Module header
  spanish (src/Lang/Spanish.hs:5)
[0 built (1 failed), 0.0 MiB DL]  error: build of '/nix/store/2f0yxxnlhmp8psq2vgg09y8fx0rh4nkx-herms-1.9.0.4.drv' failed

While stack cannot find ghc843.

I don't know if this is beginner friendly (seems like it: bump allowed versions, see if they work, get going), because I'd like to have a go at this, but I'm not sure if it will actually be the best possible outcome.

E: GFM not reddit markdown

Installing from cabal fails "vty-5.15.1 failed during the building phase."

After cloning the repo and running cabal install -j. I'm installing on fedora 27.

[user@desktop herms]$ cabal install -j
Resolving dependencies...
Configuring vty-5.15.1...
Building vty-5.15.1...
Failed to install vty-5.15.1
Build log ( /home/user/.cabal/logs/vty-5.15.1.log ):
cabal: Entering directory '/tmp/cabal-tmp-2428/vty-5.15.1'
Configuring vty-5.15.1...
Building vty-5.15.1...
Preprocessing library vty-5.15.1...
[ 1 of 35] Compiling Graphics.Vty.Input.Events ( src/Graphics/Vty/Input/Events.hs, dist/build/Graphics/Vty/Input/Events.o )
[ 2 of 35] Compiling Graphics.Vty.Input.Terminfo.ANSIVT ( src/Graphics/Vty/Input/Terminfo/ANSIVT.hs, dist/build/Graphics/Vty/Input/Terminfo/ANSIVT.o )
[ 3 of 35] Compiling Graphics.Vty.Input.Terminfo ( src/Graphics/Vty/Input/Terminfo.hs, dist/build/Graphics/Vty/Input/Terminfo.o )
[ 4 of 35] Compiling Graphics.Vty.Input.Classify.Types ( src/Graphics/Vty/Input/Classify/Types.hs, dist/build/Graphics/Vty/Input/Classify/Types.o )
[ 5 of 35] Compiling Graphics.Vty.Input.Paste ( src/Graphics/Vty/Input/Paste.hs, dist/build/Graphics/Vty/Input/Paste.o )
[ 6 of 35] Compiling Graphics.Vty.Input.Classify.Parse ( src/Graphics/Vty/Input/Classify/Parse.hs, dist/build/Graphics/Vty/Input/Classify/Parse.o )
[ 7 of 35] Compiling Graphics.Vty.Input.Mouse ( src/Graphics/Vty/Input/Mouse.hs, dist/build/Graphics/Vty/Input/Mouse.o )
[ 8 of 35] Compiling Graphics.Vty.Input.Classify ( src/Graphics/Vty/Input/Classify.hs, dist/build/Graphics/Vty/Input/Classify.o )
[ 9 of 35] Compiling Graphics.Vty.Error ( src/Graphics/Vty/Error.hs, dist/build/Graphics/Vty/Error.o )
[10 of 35] Compiling Graphics.Vty.Config ( src/Graphics/Vty/Config.hs, dist/build/Graphics/Vty/Config.o )
[11 of 35] Compiling Graphics.Vty.Input.Loop ( src/Graphics/Vty/Input/Loop.hs, dist/build/Graphics/Vty/Input/Loop.o )
cabal: Leaving directory '/tmp/cabal-tmp-2428/vty-5.15.1'
cabal: Error: some packages failed to install:
brick-0.19 depends on vty-5.15.1 which failed to install.
herms-1.8.1.2 depends on vty-5.15.1 which failed to install.
vty-5.15.1 failed during the building phase. The exception was:
ExitFailure (-11)

Feature: What can I make with what I already have?

This is a follow-up to #62, which will implement tracking of a "pantry", a set of ingredients that the user already owns. After that is implemented, it should be easy to find out what recipes the user already has all the ingredients for.

Search through recipes given a keyword

I'm thinking of something similar to grep but that searches instead through recipes. For now, just search through what showRecipe would typically display, we can get fancier later!

The interaction might look something like this:

$ herms --search "seaweed"

4. Spicy Tempeh Sushi: * 4 sheets nori seaweed
4. Spicy Tempeh Sushi: (3) Place the rise on the seaweed sheet
7. Seaweed and Hummus Platter: | Seaweed and Hummus Platter | 
7. Seaweed and Hummus Platter: * Packaged seaweed sheets
7. Seaweed and Hummus Platter: (5) Put the seaweed on the platter
11. Goldfish Cracker Feast: (3) Place the sour straws in wavy patterns along the plate to emulate the look of seaweed

You can see here that the recipe index and recipe name are given followed by the relevant line of text that has been found. Sometimes it finds the word in the title, sometimes in the ingredients, sometimes in the directions. It just needs to be a simple "I found the string you're looking for on this line!"

Tips:

• Take inspiration from grep. Bold/color the output in a similar fashion.
• Study the showRecipe function and all of its many facets

Good luck! Throw questions this way if you have any :)

"One step at a time" mode for recipe viewing

My coworker Dave told me the other day about how he really just needs to focus on the current step of a recipe since he's not the greatest cook and quite liable to screw things a bit and end up with a baguette in the saucepan.

Let's help out Dave.

Add a flag for the herms view command to specify that you only want to have one direction at a time displayed. Have the user press enter to continue to the next step. The program should not exit until each direction has been stepped through.

Tips:

• Look at how serving size flag management is done to see how to manage the input
• Study the view function to see how recipes are displayed
• We'll probably want to use a separate function for this feature

Generate a shopping list given several recipes

Given several recipes and a serving size, generate an alphabetized list of ingredients that are required for those recipes. Maybe do this through a command similar to:
herms shopfor "Tacos" "Pad Thai" -s2
Which would give a shopping list for feeding two people a meal of Tacos and a meal of Pad Thai. Leveraging existing framework, one could also easily support selection through the recipe's index.
Also maybe come up with a better name than "shopfor" since "list" is already taken...

Tips:

• Leverage existing functions for parsing recipe names and serving size
• Don't worry about synonyms (e.g., scallions and green onions). We'll do something about that later down the line.
• Send the output to the terminal (nicely formatted, of course)

Failing Travis builds

It seems that a new version of the Brick library breaks our CI builds: https://travis-ci.org/JackKiefer/herms

`nix build` fails

Hi! Thanks for this awesome project.

When I try to follow the Nix build instructions I see:

nixos :: ~/projects/herms ‹master› » cd nix
nixos :: projects/herms/nix ‹master› » nix build -f .
builder for '/nix/store/lhdsfm5hhxh40h2a095g0hvnq5c5kgf2-herms-1.9.0.4.drv' failed with exit code 1; last 10 log lines:
    die', called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:950:20 in Cabal-2.4.0.1:Distribution.Simple.Configure
    configureFinalizedPackage, called at libraries/Cabal/Cabal/Distribution/Simple/Configure.hs:460:12 in Cabal-2.4.0.1:Distribution.Simple.Configure
    configure, called at libraries/Cabal/Cabal/Distribution/Simple.hs:596:20 in Cabal-2.4.0.1:Distribution.Simple
    confHook, called at libraries/Cabal/Cabal/Distribution/Simple/UserHooks.hs:67:5 in Cabal-2.4.0.1:Distribution.Simple.UserHooks
    configureAction, called at libraries/Cabal/Cabal/Distribution/Simple.hs:178:19 in Cabal-2.4.0.1:Distribution.Simple
    defaultMainHelper, called at libraries/Cabal/Cabal/Distribution/Simple.hs:115:27 in Cabal-2.4.0.1:Distribution.Simple
    defaultMain, called at Setup.hs:2:8 in main:Main
  Setup: Encountered missing dependencies:
  vty ==5.26.*
[2 built (1 failed), 137 copied (511.3 MiB), 75.1 MiB DL]
error: build of '/nix/store/lhdsfm5hhxh40h2a095g0hvnq5c5kgf2-herms-1.9.0.4.drv' failed

I'm on NixOS 20.03

nixos :: projects/herms/nix ‹master*› » cat /etc/os-release
NAME=NixOS
ID=nixos
VERSION="20.03.1812.14dd961b8d5 (Markhor)"
VERSION_CODENAME=markhor
VERSION_ID="20.03.1812.14dd961b8d5"
PRETTY_NAME="NixOS 20.03 (Markhor)"
LOGO="nix-snowflake"
HOME_URL="https://nixos.org/"
DOCUMENTATION_URL="https://nixos.org/learn.html"
SUPPORT_URL="https://nixos.org/community.html"
BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"

I was able to work around this by loosening the version bounds on vty:

nixos :: ~/projects/herms ‹mhuesch/build-normal*› » git --no-pager diff master herms.cabal                         129 ↵
diff --git a/herms.cabal b/herms.cabal
index 3abd7d5..bb7a6a3 100644
--- a/herms.cabal
+++ b/herms.cabal
@@ -116,7 +116,7 @@ executable herms
                      , mtl >=2.2.1 && <2.3
                      , optparse-applicative >=0.14 && <0.16
                      , text-zipper >=0.10 && <0.11
-                     , vty >=5.26 && <5.27
+                     , vty >=5.25 && <5.27
                      , yaml >=0.10 && <0.12

 test-suite herms-test
nixos :: ~/projects/herms ‹mhuesch/build-normal*› » cd nix                                                         130 ↵
nixos :: projects/herms/nix ‹mhuesch/build-normal*› » nix build -f .
[1 built, 0.0 MiB DL]

Feature: Vulgar unicode fractions

e.g. http://unicodefractions.com/

This would be a rewrite of showFrac (maybe readFrac too!)

Investigate using the units library

This library could eliminate much unit conversion machinery: https://github.com/goldfirere/units

Spruce up how recipes are listed

At the moment, the output for herms list is rather boring. Spice it up a bit (spice.. heheh) by showing some of the other things about the recipe. Show its index, name, first few words of the description, and the associated tags. Format it nicely. Maybe give it a cute ASCII frame.

Include a flag that one can set to list the recipes how they are now. This would be useful for someone, say, writing a bash script that interacts with Herm's.

Tips:

• Study the list function
• You may find the sepFlags function useful for flag handling

Switch command-line argument handling over to use optparse-applicative

We've got kind of a terrible system at the moment for argument handling. Let's use a nice library!

• https://hackage.haskell.org/package/optparse-applicative

herms: Prelude.read: no parse on WSL

I tried herms out on Windows subsystem for Linux (WSL).

I tried adding a recipe by herms add. At the end I received this message

herms: Prelude.read: no parse

I checked that my new recipe is not saved because herms view does not show this recipe.

Could this be due to WSL or bad input (PEBCAK)?

Feature: Track which recipes ingredients appeared in when creating shopping list

This is a bit tricky now that we combine ingredients. But I occasionally find myself wondering (when generating shopping lists): "Which recipe needed this?" or "Did I get everything for X recipe? Or did I input it wrong, and I actually got Y ingredient for Z recipe instead?".

It would be great if shopping lists included provenance information for ingredients, combining provenances as quantities are combined.

Autocomplete for Herms

Hello everyone,

I've written a bash script that autocompletes herms commands. It also autocompletes saved recipes if the previous command is one of - edit, remove or view. My problem is that this script needs to be sourced when herms is being installed. Is there a way to do this, for example in herms.cabal or travis.yml? I can submit a pull request once I figure out how to do this.

Thanks!

Source code formatting with Ormolu

Source code formatting is a nice way to keep style consistent across many authors, especially when contributors might not be familiar with the predominant styles of formatting, line breaks, etc. in Haskell codebases. We should format our source code and enforce the formatting in CI!

More improvement ideas

Wow! We've been getting so many new contributions thanks to Hacktoberfest. That's awesome!

When I first started Herm's there was a huge list of features that I thought would be cool to have. Now, we've nearly implemented all of them! 👏

Once we finish up this unit conversion business, I really feel comfortable making the first real "release" of Herm's to distribute throughout package repositories to share this labor of love that we've created.

In the meantime, though, post any ideas that you might have for additional improvements or features in this thread. See Contributing.md for the current list to make sure it hasn't already been thought of! :)

Document the release process

Now that we have releases (#67), it would be great to document the process of cutting a new release so we never have malformed releases. At a minimum, this should include:

1. Moving the "Unreleased" notes in the changelog to a section titled with the new version number
2. Bumping the versions in the CLI and Cabal files
3. Copy major changes to the "What's New" section of the README
4. Create a new git tag with git tag -a "vX.Y.Z" -m "", and push with git push --tags

Nutritional Information

Add optional caloric / nutritional information. Thoughts:

• Include ability to log calories, fat, carbs, and protein (any others?)
• Where should nutritional information be displayed? (list/view)
• Should calculate correctly with servings on view -s and when serving size is stipulated in add

Build with GHC 8.8, 8.10

We should make sure everything still works with GHC 8.8 and 8.10. This will probably require some updates to the version bounds in the Cabal file.

Test with GHC 8.4.3, GHC 8.6.1

Our tests are a few versions behind: https://www.haskell.org/ghc/

Export recipes

Herms has an import command, but no export! This should be relatively easy, it could be printed to stdout.

Import recipe file

Add an option to import a recipes.herms file to the current installation's recipe book. It ought to look something like this:
herms import {filename}
This would more or less involve reading the given file and appending its contents to the herms installation's recipe book.

Some tips:

• See the getRecipeBook function in herms.hs to see how the file is read in
• Note how functions such as remove and list are handled via the dispatch function

List recipes only with certain tag(s)

Specify an option with herms list to only list recipes that have the tags passed in as arguments. For example, typing herms list --tags frugal pasta would only list your inexpensive pasta recipes.

Tips:

• Study how flags are handled
• Study the list function

Let me know if you have questions! :)

Feature idea: Import and export to common recipe formats

Managing recipes on your computer has not been invented here.
As a user I'd like to import common recipe formats (maybe export as a separate ticket?).

The most common formats are

• Mealmaster (commonly referred as "MM Format")
• Rezkonv_{German, Google Translate} (commonly referred as "RK Format")
• CookMaster (commonly referred as "CM Format")
  (the first link has a proper spec, while the other two links are very vague)

Converters between these formats are commonly available. For example see http://recipetools.sourceforge.net/joomla3/index.php/cb2cb

Import/export recipes as JSON

Every language has a library to handle JSON so storing the recipes in the JSON format would make moving recipes to and from other programs much simpler.

Change datadir

Is there a way to change the datadir? I'm building Herms with Nix, and the datadir is a path in the Nix store:

/nix/store/n8ql2a3x0j0ciq05lnsn3pvlm5m8f7sa-herms-1.9.0.1-data/share/ghc-8.2.2/x86_64-linux-ghc-8.2.2/herms-1.9.0.1/

which is read-only. Can I change this setting with a command line flag or environment variable?

If not, consider this a feature request, one that I'd be willing to implement (pointers appreciated!).

Allow Vim directional keys (h, j, k, l) in the "Add a Recipe" menu

Currently, you can use Ctrl + the standard directional keys to move around the "Add a Recipe" menu. In the spirit of a true Vim disciple, I tried also allowing the option of Ctrl + (h, j, k, l), but Brick was being weird about it and wouldn't allow you to use some of the directions for some reason.

Your quest is to implement this capability!

• All of the code for the "Add a Recipe" menu is in src/AddCLI.hs
• The library that lets us have this menu is called Brick. If you're new to the library, check out this helpful introduction as well as the hackage documentation. It ain't as scary as it looks.
• You are required to use Vim when making edits to the code for this feature (just kidding)

Note Spanish translation in the README

We now have a Spanish translation (#81). We should note this in the README!

Recipe saving is broken

In the current master, saving a recipe results in writing a standard haskell show representation of the recipe to the yaml file.

When converting a recipe to a different unit system, add an option to save the recipe to file in that unit system

Currently, we can only view recipes in another unit system (e.g., herms view 2 --convert metric shows a recipe in metric units). Take this a step further and add an option to actually modify and save the recipe to be in that unit system.

It might look something like this:

herms view 2 --saveas metric

Or some other clever name for the flag.

Tips:

• Herm's handles flags using a library called optparse-applicative
• Check out src/UnitConversions.hs to see how unit conversions are handled
• All of the IO is relegated to app/herms.hs.

View a recipe in another unit system

Howdy folks! Yeah, I actually say "howdy folks" in real life because I'm from the western United States. Other silly things we say out here include "add 3/4 cup of water" and "mix in 1/8 teaspoons cinnamon." This is no good if your measuring cups are in milliliters!

Add a flag to specify viewing a recipe in a different unit system. Make a new file in src called UnitConversions.hs or something clever like that that contains functions to convert quantities in one unit to another. Start out with just the following units:

• 1 tsp <=> 5 mL
• 1 Tbsp <=> 15 mL
• 1 cup <=> 250 mL
• 1 oz <=> 28 g

We can add on more from there, but that should cover the basics for now.

Tips:

• Familiarize yourself with the Recipe data type
• Take a look at the showRecipe function
• Study how flags are handled

Allow failures on CI build with GHC 8.0.2

Unfortunately, the recent Brick update makes our CI build a bit brittle. I think it'd be fine to allow failures on GHC 8.0

https://travis-ci.org/JackKiefer/herms/jobs/440724513

Miscellaneous Tasks

No issues catch your eye? Check out https://github.com/JackKiefer/herms/blob/master/Contributing.md for other feature ideas

Feature: Express dependencies between steps of the recipe

I often cook with others. It's hard to decide on the fly who should take on which steps of a recipe, especially since some steps have dependencies on others (e.g. you have to chop the garlic before you can put it in the pan). It would be nice to have a clear picture (maybe even a vizualization??) of what the dependencies are and how to minimize the cooking time.

Allow integer quantities for ingredients

We currently use readFrac to read quantities from recipes stored in JSON/YAML:

instance Yaml.FromJSON Ingredient where
  parseJSON = Yaml.withObject "Ingredient" $ \o -> Ingredient
    <$> (readFrac <$> o .: Text.pack "quantity")
-- snip
readFrac :: String -> Ratio Int
readFrac = -- snip

readFrac requires a string as input, so users must ensure that the quantity field parses as a string, either by unnecessarily adding a denominator, e.g.

    - quantity: 1/1

or by quoting the value:

    quantity: '1'

I think it would be nice to support JSON/YAML integers directly (in addition to fractions), so users could just write:

    quantity: 1

which is more like what I would do in a plain text file.

Feature: Subtract already-owned ingredients from shopping list

This would be a two-part enhancement. Please correct me if any of my observations are mistaken.

It seems to me that shop simply concatenates the list of ingredients of the desired recipes. In the case that I'm making two recipes, each of which calls for limes, it seems that I'll get two lines in the output, each with different quantities of limes. So enhancement (1) would be to smartly combine the ingredients with identical, or better, inter-convertible units.

Once this is done, herms could also take in a list (from a file?) of ingredients the user already has, and remove them from the shopping list (or reduce the quantity in the list by the relevant amount).

I would be very happy to implement this!

Add Hacktoberfest to repo topics

Apparently we need to do this to get Hacktoberfest contributors! Can you help out @LuxMiranda? I don't have admin rights to the repo.

Add the option to specify serving size in the "add" menu

Herm's by default assumes that each recipe is for one serving, but sometimes you might be trying to copy over a recipe thats written by default for multiple servings. Add a box to specify the recipe's serving size in the "add" menu so that Herm's will do the math for you! Still, however, store the recipe as a single serving. So, you'll need to make sure that each quantity gets divided by the user-specified serving size for storage.

Add vertical space between ingredient fields

Currently there is no space at all vertically between ingredient fields, so if you e.g. wrote out "tablespoon", it could end up like
1 tablespoosoy sauce

Inserting a space between fields would make it like this
1 tablespoo soy sauce

So you'd know that the word was cut off, and you don't read "tablespoosoy".

Make `SORT_ORDER` to be a switcher

For the moment if you want to get the recipes grouped by tag you need to input

herms list  -s tags   OR   herms list -s default

The problem is that by default the ordering is default, so I don't see any sense in having option with -s default. Also writing tags or default by hands not really user-friendly (I couldn't manage to find out this magic words without going deeper into the code sources).

What I suggest is to have a switch so it will turn on grouping by tags like this

herms list --sort

Also short -s is not the best choice because there is already s for servings, I thing it could make users confused..

But all of this is just my opinion as a person who used herms. I just want to help in making this tool even better! ✨

Releases

The CHANGELOG lists several versions, but there are no releases on Github nor tags in Git. These are good ways to release binaries to users.

Ultimately, such binaries and source tarballs should be built in Travis. That might be a good feature request to haskell-ci.

Separate strings out to a different file

When we're starting to have folks translate herms, it will be easiest to have a separate file where all of the strings that are shown to the user are stored. That way, different files can be loaded for different languages.

Tips:

• Put the file into the data/ directory.
• Go ahead and just set the filename as a global constant similar to recipes.herms. We'll deal with loading other files later when we implement configuration :)

Feature: Specify required equipment in recipes and config

Some recipes require or are easier with a piece of specialized equipment, such as a food processor, blender, or hand mixer. We should allow recipes to say what they require, and allow users to specify in the configuration what equipment they have.

When viewing a recipe, we should leave out equipment by default, but warn if the recipe requires something the user doesn't have.

Like units, we should probably have a list/enumeration of recognized equipment (common stuff like a blender) but allow for unknown equipment to be specified.

Convert oven temperatures in recipe directions between Fahrenheit and Celsius

This should be an interesting one!
We now have the ability to convert ingredient measurements between imperial and metric. Now, let's take this a step further and add the ability to convert between Fahrenheit and Celsius for oven temperatures inside of recipes' directions!

This might be a little more involved as it will require parsing through the directions for a phrase like 400°F or 400 degrees Fahrenheit and converting it to 204°C when showing the recipe. Luckily, things like this are pretty straightforward in Haskell, so the hardest part will be familiarizing yourself with the current codebase to get a feel for how to handle things!

Tips:

• Herm's uses a library called optparse-applicative for flag handling
• Check out src/UnitConversions.hs to get a feel for how conversions are handled
• showRecipe is ultimately the function that gets called to handle these sorts of things

Add these features to recipe listing

Things look great with recipe listing! Let's see if we can take it even further.

Add terminal colors and bolded output to make listed recipes easier to read. While you're at it, maybe throw some colors in recipe display too...

Add a flag to generate just a simple list of recipe names without numbers, descriptions, or tags. This would be useful if there is, say, a bash script that interacts with Herm's in some way.

Tips:

• Study the list function
• Check out System.Console.ANSI

Linting and formatting

The following tools, integrated into the Travis build, can lead to significant gains in code quality:

• hindent
• hlint
• GHC-Options: -Werror with selective warnings turned on

What do you think about enabling a few of these? Stylistic checks shouldn't be enabled in all builds, but having them on in CI can be pretty beneficial.

See also https://taylor.fausak.me/2014/03/04/haskeleton-a-haskell-project-skeleton/#code-quality

Crash on empty serving size

When serving size is empty and you exit the interface, the application crashes while parsing the recipe. Better to just default to 1 than to lose any changes to the recipe imo.

Installation guide

It would be helpful to describe installation process