Version 3.0 #408
Version 3.0 #408
Conversation
|
@clason The hover issue should be fixed now. The stress test project was very helpful 👍 |
|
Looking at the stress test project, it looks like there are some false positives concerning the static analysis as well. Those should be fixed too. |
|
Glad it's useful for something :) Can confirm that hover works here as well -- thanks! Yes, I noticed the false positives (or negatives?) as well, but put them on the back burner as merely cosmetic. I still see some, though; for example: \newenvironment{shortexample}{%
\begingroup\mdfsetup{nobreak=true}
\begin{example}%
E }{% ■ Unexpected "}"
E \end{example}\endgroup% ■ Missing "}" inserted
}(with the static analysis error inline). There are also some in inline asymptote code, but that's a different matter. |
|
@clason The workspace expansion issue should be fixed along with the "find all references" performance regression. Concerning the static analysis, I managed to reduce the number of false positives a bit. Most of them are now inside the asymptote code. In particular, |
|
@clason Did the completion regression with the wrong text edit occur in the mean time again or can it be marked as resolved? Besides that, I decided to reimplement building and forward search because some people likely rely on these features and I feel bad removing them without an alternative. All in all, I think this PR can be merged soon. |
|
I've been using this PR as my daily driver for a while and have not noticed this problem since then, so I'd consider it fixed. (And if not, it's random enough to merge anyway and I'll open an issue should it occur again.) The only thing that I've noticed in my testing is some differences in the (workspace) symbols, especially the styling. For example (from a newer version of the above arXiv project; left is master, right is this PR) (formatted item labels are always missing (theorem names are missing if they involve a LaTeX command) or (some section numbers are missing). There's also some whitespace difference in float captions (I believe an added space before and after the caption? The space before the caption is not consistent, though.) For some reason, the symbols for float break my client showing them (neovim with telescope.nvim) with this PR; not sure why that should be the case if they worked before... |
|
Oh, and I'm no longer seeing diagnostics from the Not that I miss them, exactly :p |
|
@clason The issues with the symbol formatting should be fixed now.
This was some regression caused by incorrect debouncing. The parsing events caused the build log diagnostics to be debounced but now it should be fixed.
Almost nobody misses overfull hboxes ;) |
Not completely; some symbols are still not showing the numbers -- but now it's different ones, so maybe a timing issue? (The other issues are indeed fixed.)
👍🏻
Indeed :) |
The label numbers are calculated synchronously so I don't think its a timing issue. Does it change over time? Can you take a look at the |
|
It is indeed a bit odd. It seems to be stable (not changing depending on which file of the project I open and trigger The issue is not quite consistent: some indeed don't have a (which looks like the old version parsed?); others do: Hmm, I can reproduce them in the old arXiv version as well. Maybe it's a problem with the platform (macOS Intel; texlive2021 fully updated)? Here's the full diff (master vs PR) for the output of 5d4
< style.tex|31 col 3| [thm] Example
865a865
> monotone.tex|63 col 1| [float] Figure 6.1: Illustration of \cref{ex:inner-outer-difference} with $\limsup_{n \to \infty} X_n=[0, 1]$ while $\liminf_{n \to \infty} X_n=\emptyset$.
988c988
< monotone.tex|741 col 9| [item] (iii)
---
> monotone.tex|741 col 9| [item] Item
1630c1630
< gap.tex|681 col 5| [equ] Equation (11.31)
---
> gap.tex|681 col 5| [equ] Equation
1634c1634
< gap.tex|712 col 1| [sec] 11.32 Duality gap realignment
---
> gap.tex|712 col 1| [sec] Duality gap realignment
2136c2136
< nlpdps.tex|224 col 1| [sec] 15.17 Convergence proof
---
> nlpdps.tex|224 col 1| [sec] Convergence proof
2680c2680
< setderiv.tex|898 col 9| [equ] Equation (20.12)
---
> setderiv.tex|898 col 9| [equ] Equation
2690c2690
< setderiv.tex|949 col 1| [float] Figure 20.3: Illustration of the different graphical derivatives and coderivatives of $\subdiff f$ for $f=\abs{\freevar}$. The dashed line is $\graph \subdiff f$. The dots indicate the base points $(x, y)$ where $D[\subdiff f](x|y)$ is calculated, and the thick arrows and filled-in areas the directions of $(\Delta x, \Delta y)$ (resp.~$(\Delta x, -\Delta y)$ for the coderivatives) relative to the base point. Observe that there is no graphical regularity at $(x, y)\in\{(0, -1), (0, 1)\}$. Everywhere else, $\subdiff f$ is graphically regular. Observe that cones in the last figures of each row are polar to the cones in the first and the second figures on the same row.
---
> setderiv.tex|949 col 1| [float] Figure 20.3: % Illustration of the different graphical derivatives and coderivatives of $\subdiff f$ for $f=\abs{\freevar}$. The dashed line is $\graph \subdiff f$. The dots indicate the base points $(x, y)$ where $D[\subdiff f](x|y)$ is calculated, and the thick arrows and filled-in areas the directions of $(\Delta x, \Delta y)$ (resp.~$(\Delta x, -\Delta y)$ for the coderivatives) relative to the base point. Observe that there is no graphical regularity at $(x, y)\in\{(0, -1), (0, 1)\}$. Everywhere else, $\subdiff f$ is graphically regular. Observe that cones in the last figures of each row are polar to the cones in the first and the second figures on the same row.
2779c2779
< graphical.tex|11 col 1| [sec] 22.1 Semi-differentiability
---
> graphical.tex|11 col 1| [sec] Semi-differentiability
2878c2878
< cofrechet.tex|64 col 5| [equ] Equation
---
> cofrechet.tex|64 col 5| [equ] Equation (23.3)
2943c2943
< gclarke.tex|6 col 1| [sec] 24.1 Strict differentiability
---
> gclarke.tex|6 col 1| [sec] Strict differentiability |
Hmm, that's very odd. I cannot reproduce any of these examples (except for
in the aux file. Does your aux file have the same entry or is there some difference? |
|
Are you sure you haven't mixed up the labels? I don't have that label in my (And the fact that it shows the number without label confused me, too.) But something is screwy with the equation One thing that may explain this is that line 712 of \begin{subequations}
\label{eq:gap:accel:setup}
\begin{equation}
\Happrox_{k+1}(u)
\defeq \Step_{k+1}(\subdiff \tilde G(\nextu)+\grad \tilde F(\thisu)+\Xi)
\end{equation}
...
\end{subequations}This is incorrectly picked up as a And the I've added two logs for |
Hmm, it looks like we have different versions of the same file.
That definitely explains it. Subequations was not recognized yet and the label rendering function attaches the label to the section instead.
That's an issue. The comma is confusing the parser because it cannot determine at the parsing stage whether these are two labels or just one label with a comma in its name. I have to think of a way to properly deal with this. |
Possible; I'm using the latest version (
👍🏻
Hmm. At least So I'd say the only remaining "regresssion" is cosmetic (master strips the |
| .unwrap() | ||
| .formatter_line_length | ||
| .map(|value| { | ||
| if value < 0 { |
There was a problem hiding this comment.
Yeah, the fix should be coming soon along with the newlines fix.
There was a problem hiding this comment.
(If the newline stripping was intentional, that's fine of course.)
There was a problem hiding this comment.
Hmm... Something is still weird. It uses the default value when I format first; if I undo and format again, it uses the correct value...
(This might be a client issue, though.)
There was a problem hiding this comment.
Yep, that seems to have done the trick, thank you! 👍🏻
(sorry for bugging you with all these small things... I'll shut up now ;))
There was a problem hiding this comment.
No problem, we fixed a lot of (smaller) bugs, now. I think, we can merge this now, can't we?
By the way, what do you think about this feature?
I was thinking about updating the indexing script in order to allow completion of key value options (mainly package imports and other commands that allow (x)keyval arguments. The parser is now capable of handling these, so I guess it makes sense to make some use of it. One could even go further and provide warnings using that information if you try to use some unknown key, for example.
There was a problem hiding this comment.
No problem, we fixed a lot of (smaller) bugs, now. I think, we can merge this now, can't we?
Yes, I think so, too!
By the way, what do you think about this feature?
I was thinking about updating the indexing script in order to allow completion of key value options (mainly package imports and other commands that allow(x)keyvalarguments. The parser is now capable of handling these, so I guess it makes sense to make some use of it. One could even go further and provide warnings using that information if you try to use some unknown key, for example.
Oh, that's an interesting idea! Yes, I can see how that could be useful. You'd add [ and , as a trigger character for completion, then (assuming the latter isn't already)? Is that something you'd be able to support generally, or do you have to add these explicitly as a json?
(If you really want to push the linting, you could also add type information to keys so you could show an error when passing a bool for an integer value...)
There was a problem hiding this comment.
Is that something you'd be able to support generally, or do you have to add these explicitly as a json?
This can be supported generically using the latex-completion-data script as a basis. We still have an (incomplete) Rust port around, which makes the script incremental and faster to execute. We can extend this script to detect commands like \define@key or \define@boolkey, which allows us to provide completion for them without hard-coding every single package (which is basically impossible).
This PR consists of a huge internal refactoring and a lot of bug fixes. As mentioned in #405, there are some breaking changes concerning mainly the options format and additional requests like building and forward search.
Closes #405.
Closes #365.
Closes #359.
Closes #339.
Closes #409.
Closes #386.
Closes #310.
Closes #413.
Closes #309.
Checklist for 3.0:
TextEdit