git.cworth.org Git - sup/blob - HACKING

   1 Running Sup locally
   2 -------------------
   3 Invoke it like this:
   4
   5 ruby -I lib -w bin/sup
   6
   7 Coding standards
   8 ----------------
   9
  10 - Don't wrap code unless it really benefits from it. The days of
  11   80-column displays are long over. But do wrap comments and other
  12   text at whatever Emacs meta-Q does.
  13 - Use as few parentheses as possible.
  14 - Use {} for one-liner blocks and do/end for multi-line blocks.
  15
  16 How messages are updated in the index
  17 -------------------------------------
  18
  19 Ferret doesn't have any concept of updating; to change message state
  20 it must be deleted then re-added to the index.
  21
  22 Thus there are a couple situations where we'll have a message to be
  23 "added", but it already exists in the index, and we need to decide
  24 which parts of which version to keep:
  25
  26 1. The user has changed the state of the message, e.g. read it or
  27    added a user label. In this case we want to use the state of the
  28    version in memory, but keep everything else on disk.
  29
  30    This is the behavior of Index#update_message
  31
  32 2. We've received a new copy of the message. Crucially, this can
  33    happen for two different reasons:
  34
  35    a. The message was sent to a mailing list to which the user is
  36       subscribed, and we're now getting that message back, possibly
  37       with altered content (subject mangling, signature adding, etc.)
  38
  39    b. The user has moved the message between sources. E.g. if the
  40       primary inbox has a quota, and other sources are on local,
  41       quota-less disk, the user may regularly move messages from the
  42       inbox to the sources on disk.
  43
  44    In both of these cases, the solution is to keep the state from the
  45    index, but use the new message contents.
  46
  47    This is the behavior of Index#update_or_add_message, which can be
  48    also be called for new message.
  49
  50