> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4924?src=pr&el=h1) Report > Merging [#4924](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4924?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/63e529a2bd25f73822bcea037c83b4001b5aa800?src=pr&el=desc) will **increase** coverage by `<.01%`. > The diff coverage is `86.32%`.
> # [Codecov](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4924?src=pr&el=h1) Report > Merging [#4924](https://codecov.io/gh/rubberduck-vba/Rubberduck/pull/4924?src=pr&el=desc) into [next](https://codecov.io/gh/rubberduck-vba/Rubberduck/commit/63e529a2bd25f73822bcea037c83b4001b5aa800?src=pr&el=desc) will **increase** coverage by `<.01%`. > The diff coverage is `86.32%`.
I still get loads of Consider renaming 'Sheetxx' inspections. I can't rename these because the sheets are dropped & recreated on every execution.
@Vogel612 I'm getting my head wrapped around git. That's my first step...
TBH, I know everyone appreciates my sarcastically given title as head of QA, but I really do feel like all I do is complain about stuff. I get that finding the bugs is important, but I do want to do my share of fixing them, too.
@FreeMan OK, I could rename them, but next time I run the code, the warnings will come right back...
@Vogel612 I wanted to remove a file that was removed in a directory. I used git rm . -r and that wasn't the correct command. That removed everything that had already been pushed to my repo.
I have commits that I want to keep that need to be pushed. Is the correct way to stash them and pull from my repo?
and now that I've stumbled & bumbled my way into the VBE API to export/import modules, I'm a certified expert in finding my way around docs to figure out how to change worksheet code names!
My branch and origin/master have somehow diverged.
$ git status
On branch master
Your branch and 'origin/master' have diverged,
and have 6 and 3 different commits each, respectively.
(use "git pull" to merge the remote branch into yours)
nothing to commit, working tree clean
$ git pull
fatal: refusing to merge unrelated histories
when you try to merge (and pull always includes a merge), git searches for the "merge base" between the commits you merge by going back through history
> **Rubberduck version information** Version 2.4.1.4666 OS: Microsoft Windows NT 10.0.15063.0, x64 Host Product: Microsoft Office 2016 x64 Host Version: 16.0.4822.1000 Host Executable: EXCEL.EXE
**Description** Adding `'@Ignore ImplicitByRefModifier` to a function declaration does not work if there is a line continuation (`_`) in the declaration.
**To Reproduce** Steps to reproduce the behavior: 1. Write a function declaration with an implicit `ByRef` 2. Edit in a line continuatio
mkay. I guess best option for me to then is clone my gh repo and manually move over the directories to that new one. Push to repo and see what happens.
> Yea, I assume that's because a part of the logic for ignore annotations may fall back to checking the annotation based on the module's lines as retrieved from the VBE, which only respects physical lines, not logical lines...
@M.Doerner Very interesting to hear that. Contrast to the LSP approach, which (iiuc) sends keystrokes across to the server, which can then choose when to send updates. Typically, it would wait for a certain dwell time (for example to wait for the user to stop typing), then request a build.
If we were ever to do out-of-process, we should [consider/do] this.
Not that Liskov doesn't rock, ofc :-)
tl;dr - the server keeps an in-memory representation of the source code, independent from how it is represented on disk. It then uses that to service requests for symbols, documentation, locations...
oh btw 'server' in this context just means 'another process', not an actual bit of iron.
I would point out that if we have our custom code pane, there would be no reason to not just export the attribute pass files (for VBA project) and just work with them directly and import into the VBE lazily.
hopefully importing is much quicker than exporting.
@Vogel612 You seem to be saying that even if we had a custom code pane where we work with the exported file directly, this still wouldn't fly?
I figured that with the custom code pane in control, we can just work with the exported file directly, cut out the code pane pass altogether, and simply import changes on-demand.
@this if we want to be able to correctly deal with bracketed expressions, bracketed identifiers and the general quirks of the VBE, I think it's impractical
@Vogel612 Sorry if I'm being thick (not unusual...) The VBE is not a unicorn, therefore its special sauce must be replicable. Is the problem that too much of its operation is undocumented?
IIUC (unlikely), pretty-printing is a side-effect of the operation of the VBE. Hit enter, code gets compiled, which then gets round-tripped to the IDE.