1. 05 12月, 2021 3 次提交
  2. 04 12月, 2021 1 次提交
  3. 26 11月, 2021 1 次提交
  4. 25 11月, 2021 1 次提交
  5. 20 11月, 2021 4 次提交
    • B
      Update ycmd · 4e10490c
      Ben Jackson 提交于
      4e10490c
    • B
      arm64 macs are supported · e269e411
      Ben Jackson 提交于
      e269e411
    • B
      Merge pull request #3972 from puremourning/update-submodule-upstream · 3d051fe5
      Ben Jackson 提交于
      Update ycmd
      3d051fe5
    • B
      Update ycmd · 5516e02a
      Ben Jackson 提交于
      Key changes that affected the tests:
       - clang 13 changed a few things, such as it's doc output and now it
         returns a set of symbols for an empty symbol search
       - new jdt.ls produces a new suggestion for Test from some internal jdk
         library on some jdk versions. annoying, pointless and probably buggy,
         but that's unfortunately the state of jdt.ls these days
       - newer vims have added values to the return from prop_list. Instead of
         asserting the dicts are equal, we use a permissions has_entries type
         check.
       - new jdt.ls uses spaces sometimes instead of tabs sometimes
      
      Also updated the docs to mention the actual libclang/clangd version
      that's required, as we know people do use their own.
      5516e02a
  6. 16 11月, 2021 2 次提交
  7. 13 11月, 2021 4 次提交
    • M
      Merge pull request #3953 from bstaletic/erratic-cursor · 2badfc08
      mergify[bot] 提交于
      [RFC] Do not call complete() if the cursor changed position since the completion request
      2badfc08
    • B
      Do not call complete() if the cursor changed position since the completion request · 425ce128
      Boris Staletic 提交于
      This can happen if there's another async plugin that can change cursor
      position, like matchup. In that case, it's a race condition between YCM
      completing correctly and the plugin movin the cursor some place else.
      
      The workaround here is to make sure the cursor position at request is
      the same as cursor position at `complete()` time. As a result:
      
      1. Erratic cursor movement won't mess up the buffer content and get in
         the way of typing.
      2. Occasionally, YCM won't call `complete()` in a situation where a user
         might expect it to, but that's a direct consequence of `1`.
      3. YCM will have spuroius "identifier complete" actions which means that
         "half" of a word might end up in identifier completer's database and
         subsequently suggested as a candidate. This is only temporary and the
         whole thing is eventually-consistent.
      425ce128
    • M
      Merge pull request #3969 from bstaletic/diags-large-file · 16ff59a0
      mergify[bot] 提交于
      [READY] Move ycm_state.UpdateMatches() to s:OnBufferEnter()
      16ff59a0
    • B
      Move ycm_state.UpdateMatches() to s:OnBufferEnter() · 14952ac8
      Boris Staletic 提交于
      This change does away with s:UpdateMatches(), for the sake of
      performance in large files.
      
      Previously, we would still try to update diagnostics in large files,
      which would result in YCM calling a vim API for every line in that large
      file.
      
      The obvious solution - just call `s:AllowedToCompleteInCurrentBuffer()`
      in `s:UpdateMatches()` - doesn't work, because it make
      `s:OnBufferEnter()` return early as well, because
      `s:VisitedBufferRequiresReparse() == false`. That makes
      `s:OnBufferEnter()` skip the rest of the setup of completion.
      
      Yes, this means that vimscript API for getting the text properties is
      very inefficient.
      14952ac8
  8. 06 11月, 2021 1 次提交
  9. 05 11月, 2021 4 次提交
  10. 31 10月, 2021 2 次提交
    • M
      Merge pull request #3965 from bstaletic/correct-clamp · 46937cf9
      mergify[bot] 提交于
      [READY] Do not assume current buffer in vimsupport.LineAndColumnNumbersClamped()
      46937cf9
    • B
      Do not assume current buffer in vimsupport.LineAndColumnNumbersClamped() · 9f3eebdb
      Boris Staletic 提交于
      Before the big diagnostics refactor, we only served diagnostics for the
      current buffer. That allowed `vimsupport.LineAndColumnNumbersClamped()`
      to assume `vim.current.buffer` was always correct.
      
      That is no longer the case - we were clamping offsets to, potentially,
      the contents of a wrong buffer. More specifically, if
      
      1. Current buffer is not the same buffer we are updating diagnostics
         for.
      2. Current buffer does not have line number of the target buffer
         diagnostics.
      
      Then we end up wrongfully "moving" the line of the diagnostic. On top of
      that, if the target buffer's "moved" line is shorter than the start column of
      the diagnostic, then we're still out of bounds.
      9f3eebdb
  11. 29 10月, 2021 3 次提交
    • M
      Merge pull request #3952 from bstaletic/no-path-highlight · b9925795
      mergify[bot] 提交于
      [READY] Make diagnostic highlighting in buffers without filepath work
      b9925795
    • B
      Make diagnostic highlighting in buffers without filepath work · e643d356
      Boris Staletic 提交于
      Currently this is the only thing that doesn't work for this kind of
      files.
      
      Because we don't have a file path, we use `$PWD/$BUFNR` as file path in
      requests. This mostly works, but for diagnostics it means we can't find
      the file corresponding to the diagnostics we have received. See
      vimsupport.py line 187 for reference.
      
      This PR introduces some heuristics to make those work in most cases:
      
      1. If the filepath we get from diags has a corresponding buffer number
         already, just use that. This covers already open files.
      2. If the filepath doesn't exist on the local storage, and the tail of
         the path is a numeric string, we assume the weird path came from
         `$PWD/$BUFNR` magic.
      3. Else we fall back to the current behaviour - either the path is an
         actual file path, or is not numeric. Either way, creating a new
         buffer seems reasonable.
      
      Note that this fails under the following circumstances:
      
      1. User has a file called `1` in the working directory.
      2. User opens vim without any arguments.
      3. YCM sends `OnBufferVisit` with `$PWD/1`.
      4. ycmd responds with some diagnostics.
      5. YCM mistakes `$PWD/1` (the buffer's fake path) with the actual file
         in the project.
      
      A more robust solution could be something like a global mapping from
      random strings to buffer numbers and using those generated strings as
      file paths. I just didn't think it would be worth the effort.
      
      Honestly, not sure if even this is worth the effort, but hey... there
      was clearly an intention to keep this category of files working.
      e643d356
    • M
      Merge pull request #3951 from bstaletic/loclist-stack · 78883ec9
      mergify[bot] 提交于
      [READY] Use location list stack, instead of trampling on existing ones
      78883ec9
  12. 28 10月, 2021 2 次提交
  13. 20 10月, 2021 1 次提交
  14. 19 10月, 2021 1 次提交
  15. 16 10月, 2021 2 次提交
  16. 14 10月, 2021 3 次提交
    • M
      Merge pull request #3920 from bstaletic/diag-interface · 347bbf73
      mergify[bot] 提交于
      [READY] Refactor diagnostic interface
      347bbf73
    • B
      Use text properties for diagnostic highlight · 777830bd
      Boris Staletic 提交于
      Text properties have a number of benefits:
      
      1. Not regex based, so should be faster on really big files.
      2. Highlights move with text, instead of being pinned to line/column.
      777830bd
    • B
      Use sign_* functions to manage signs · f2fee854
      Boris Staletic 提交于
      These functions are much easier to work with than the old :sign command.
      
      For starters, there's no need to parse the output.
      Other improvements include:
      
      1. Not caring about the sign ID, since we only deal with the ycm_signs
         group.
      2. Since the return values of these functions is structured, we don't
         need the DIagnosticSign named tuple.
      3. Ability to place/unplace all signs with a signle call, which should
         make diagnostic_interface more efficient.
      f2fee854
  17. 19 9月, 2021 2 次提交
  18. 14 9月, 2021 2 次提交
  19. 05 8月, 2021 1 次提交