Update README to include new codex format command.

[aloiscochard]

Also, you might like the fact that the last version of codex (0.2.0.0), will include as well the tags of the current project in the generated codex.tags.

That is why I removed the section about hasktags, as there is no need of using it directly.

[nh2]

This is cool, I just see one problem with it: In contrast to Emacs and Vim, Sublime isn't biased to one of the ctags formats - it just happens that the CTags plugin chose the Exuberant format. But any other day, another plugin could appear to support the Emacs format, that's why I'm not sure it's fair to call the CTags format the the sublime format.

[aloiscochard]

That is very good point @nh2.

I don't know much about the Sublime ecosystem to be honest, what I want is to make the life as easier as possible for anyone using one of the main editor.

I see it as "default" configuration, which should be overrides depending of the end-users need.

As today there is only one ctags plugin, I think that's pretty safe for now, of course that might change in future

[mantkiew]

I don't think it's fair to just remove hasktags part. It's an alternative, which some people may be using in the case codex is not available for whatever reason (e.g., codex pulls in a lot of dependencies compared to hasktags. Also, currently, I cannot install codex on windows codex-0.2.1.4 depends on curl-1.3.8 which failed to install.).

[nh2]

I don't think it's fair to just remove hasktags part. It's an alternative, which some people may be using in the case codex is not available for whatever reason

This is also a good point.

[aloiscochard]

(sorry for being slightly off-topic)

@mantkiew there is a branch with Windows support ready to rocks implemented by @bmjames (https://github.com/bmjames/codex/tree/windows-compat)

He basically replaced curl with wreq and a few other changes, it's shame I did not have yet dedicated time to release those changes, I hope that will happen very soon (I'll announce it on the cafe).