Commits on Nov 14, 2017
  1. Merge pull request #91 from andrewschleifer/master

    Shadowfiend committed Nov 14, 2017
    import help pages scraped from website
    This is everything that the Wayback Machine had from except two missing pages:
    open_line.html and tagstack.html
Commits on Oct 30, 2014
  1. Update sparkle commit.

    Shadowfiend committed Oct 30, 2014
  2. Project tweaks.

    Shadowfiend committed Oct 30, 2014
    Update various settings.
  3. Fix ViTextStorage references.

    Shadowfiend committed Oct 30, 2014
    Because NSTextView’s textStorage is now a property, we
    can’t override the accessor with one of return type
    ViTextStorage * without triggering a compiler warning.
    Instead, we provide viTextStorage, which provides access to
    the appropriate type, and call that when we need a true
    ViTextStorage instance.
Commits on Dec 9, 2013
Commits on Dec 7, 2013
  1. When searching for a view to move up/down/left/right to, recognize ru…

    Shadowfiend committed Dec 7, 2013
    …ler views.
    Before, hitting a ruler view would mean continuing to adjust in
    the given direction, which when moving up or down would
    mean continuing to look up or down for a valid text view. In
    those cases, we wouldn’t end up finding one, or we’d end up
    passing through the view immediately on top/bottom of the
    current one to one further up whose ruler wasn’t in the path of
    the caret point.
    Now, when we see a ruler view or one of its children, we look
    up the associated text view and select that.
  2. While searching for a view to move up/down/left/right to, adjust for …

    Shadowfiend committed Dec 7, 2013
    Before, if going in the indicated direction from the caret
    resulted in coordinates that were on a split view splitter, we
    would simply fall back on the old behavior of going to the first
    entry in the split in the given direction. We now adjust the
    coordinates either rightwards or downwards (depending on
    whether we’re looking for the next text view vertically or
    horizontally) so as to move off of the splitter.
  3. Search for text view until we run out of window in selectViewAtPositi…

    Shadowfiend committed Dec 7, 2013
    We start with an offset of 40 in the direction dictated by the
    provided position, and then increase in multiples of 40 until
    we are no longer over a view at all or we have found a
  4. Compute and constrain reference point with respect to scroll view.

    Shadowfiend committed Dec 7, 2013
    We now compute the reference point as a point in the scroll
    view containing the text view. Additionally, we constrain it to
    the scroll view’s bounds with some padding, so that if the caret
    is off the visible scroll area, we keep the value we’re working
    with within the scroll rectangle. That means we’ll never be able
    to switch windows outside of the visible area of the current
Commits on Dec 6, 2013
  1. Basic caret-based view left/right/up/down selection.

    Shadowfiend committed Dec 6, 2013
    Now, when we select a view left/right/up/down from another
    view, we check the caret in the view that we are moving with
    respect to and do some coordinate math to figure out the
    view that is left/right/up/down *of the caret*, rather than
    simply selecting the top element in the split that is in that
    A couple of issues currently:
     - If the caret is scrolled away, behavior is a little strange,
       because math is still done with respect to the caret
       position, even though it’s hidden.
     - There are some hardcoded numbers in there to jump over
       things like the gutter views and the split view hit areas.
     - If the caret is just right, the math to determine the text
       view in the appropriate direction will find a split view
       splitter instead and will fall back to the old behavior.
  2. Add viewWithTextView: to ViTabController.

    Shadowfiend committed Dec 6, 2013
    This method returns the ViDocumentView instance in the
    tab view corresponding to the given ViTextView, or nil if
    there is no such instance.
Commits on Dec 5, 2013
  1. Only mark the first character of a folded range with attachments.

    Shadowfiend committed Dec 5, 2013
    Before we were checking if the current fold was the same as
    the first fold, but that is also true if we go through a child fold
    and then back to the first fold in a later range. In those
    cases we don’t want to mark the first character in the current
    range with the attachment attribute.
    End result, we now just check if we’re closing this fold and
    the start of the current range is the start of the fold area.
    In that case, we mark it with the attachment attribute.
  2. Only try to find a parent fold to close if there is room to do so.

    Shadowfiend committed Dec 5, 2013
    Before, when closing a fold at a given location, we would
    push through parents even if the current fold’s depth was
    equal to the minimum close depth, which meant we could
    try to close folds above the minimum depth. We no longer
    do that.
    This only happened when folds had the same start location
    as their parents and we were closing one of the child folds.
  3. Ensure minCloseDepth doesn't go negative in closeFold:inRange:levels:.

    Shadowfiend committed Dec 5, 2013
    When minCloseDepth goes negative, it actually goes way
    positive, breaking the fold close. We do this by seeing if the
    min close depth would become negative, and limiting it to
    1 in those cases.
  4. Recursively update childrens' depth when updating a fold's depth.

    Shadowfiend committed Dec 5, 2013
    Before, when adding a fold to a parent, we would only
    update the new child’s depth. We now overlapd setDepth: to
    then recursively apply this depth change to the fold’s
    children, if any.
Commits on Dec 4, 2013
  1. Fix openFoldAtLocation:* to correctly find the topmost closed fold.

    Shadowfiend committed Dec 4, 2013
    Before we were finding the bottommost closed fold instead.
  2. Fix comment in closeFoldAtLocation: to reflect what it's actually doing.

    Shadowfiend committed Dec 4, 2013
    We find the *bottommost* open fold with the same start as
    the fold at the location, not the topmost one.
  3. closestCommonParent fold now checks if its arguments are parents of e…

    Shadowfiend committed Dec 4, 2013
    …ach other.
    We were running into an issue where if the first fold was a
    parent of the second, and they both shared another parent,
    you would get the other shared parent, the first fold’s parent,
    as the result.
    Now, if the first fold is parent of the second, it is returned,
    and if the second is parent of the first, it is returned, and if
    not then we search for the nearest common parent as we
    did before.
  4. Only mark the start of a closed fold when opening its immediate parent.

    Shadowfiend committed Dec 4, 2013
    We were marking the start of a closed fold with the folded
    attachment if we had opened any parent, which means if
    we had folds closed three levels deep and we opened the
    top level, we’d see a marker both for the second and third
    level closed folds. This fixes that issue.
  5. openFold:inRange:levels: always gets the right start fold.

    Shadowfiend committed Dec 4, 2013
    If folds had identical starts to their parents, we would pass
    the deepest fold at a given location to
    openFold:inRange:levels:. We now properly pass the
    topmost fold that meets the requirements (open fold if
    closing, closed fold if opening).
  6. Always mark a fold as open if we're removing the folded attribute.

    Shadowfiend committed Dec 4, 2013
    This means we may do it more than once per fold, but folds
    that start in the same place as parents need us to always
    mark them open.
  7. Add attribute to ViFold to track if it has the same start as its parent.

    Shadowfiend committed Dec 4, 2013
    We’ll be using this for some slightly-more-complicated logic
    we need to do in cases where we’re opening/closing folds
    with identical starts.