anil.recoil.org
+61
-2
CLAUDE.md
+61
-2
CLAUDE.md
···Then examine the HTML docs built for that module. You will see that there are module references with __ in them, e.g. "Jmap__.Jmap_email_types.Email_address.t" which indicate that the module is being accessed directly instead of via the module aliases defined.-Avoid redundant module nesting. When a file is named after a module (e.g., `jmap_identity.mli`), there's no need to have a matching nested module inside the file (e.g., `module Identity : sig...`). Instead, define types and functions directly at the top level of the file. Also, ensure that submodule main types are always named `t`, not named after the module (e.g., use `Create.t` not `Create.create`).
···Then examine the HTML docs built for that module. You will see that there are module references with __ in them, e.g. "Jmap__.Jmap_email_types.Email_address.t" which indicate that the module is being accessed directly instead of via the module aliases defined.+When adding OCaml documentation comments, be careful about ambiguous documentation comments. If you see errors like:+This usually means there isn't enough whitespace between the documentation comment and the code element it's documenting. Always:+3. When documenting record fields or variant constructors, place the comment after the field with at least one space+If in doubt, add more whitespace lines than needed - you can always clean this up later with `dune build @fmt` to get ocamlformat to sort out the whitespace properly.+IMPORTANT: For all modules, use a nested module structure with a canonical `type t` inside each submodule. This approach ensures consistent type naming and logical grouping of related functionality.+1. Top-level files should define their main types directly (e.g., `jmap_identity.mli` should define identity-related types at the top level).+2. Related operations or specialized subtypes should be defined in nested modules within the file:+5. When a file is named after a concept (e.g., `jmap_identity.mli`), there's no need to have a matching nested module inside the file (e.g., `module Identity : sig...`), as the file itself represents that namespace.+This structured approach promotes encapsulation, consistent type naming, and clearer organization of related functionality.
+194
-5
jmap-email/jmap_email.mli
+194
-5
jmap-email/jmap_email.mli
············
···+val color_flags : [`Red | `Orange | `Yellow | `Green | `Blue | `Purple | `Gray] -> string list···+val set_color_flags : Types.Email.t -> red:bool -> orange:bool -> yellow:bool -> Types.Email.t······
+154
-3
jmap-email/jmap_email_types.mli
+154
-3
jmap-email/jmap_email_types.mli
······
···+(* Apple Mail and other vendor extension keywords from draft-ietf-mailmaint-messageflag-mailboxattribute *)···
+4
jmap-email/jmap_mailbox.mli
+4
jmap-email/jmap_mailbox.mli
···+| Snoozed (** Messages snoozed for later notification/reappearance, from draft-ietf-mailmaint-messageflag-mailboxattribute *)+| Scheduled (** Messages scheduled for sending at a later time, from draft-ietf-mailmaint-messageflag-mailboxattribute *)+| Memos (** Messages containing memos or notes, from draft-ietf-mailmaint-messageflag-mailboxattribute *)
+84
-6
jmap-email/jmap_search_snippet.mli
+84
-6
jmap-email/jmap_search_snippet.mli
···
···
+116
jmap-email/jmap_thread.mli
+116
jmap-email/jmap_thread.mli
···
···