-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A few fixes for emacs mode indentation #12486
Conversation
Aligns to the same column if the previous line ends in a single '|' (but not a '||').
When indenting a non-blank line, stay at the same cursor position relative to the content after indenting.
This changes the indent to calculate positions relative to the enclosing block (or braced/parenthesized expression), rather than by an absolute nesting level within the whole file. This allows things like this to work: let x = match expr { Pattern => ... } With the old method, only one level of nesting would be added within the match braces, so "Pattern" would have ended up aligned with the match. The other change is that multiple parens/braces on the same line only increase the indent once. This is a very common case for passing closures/procs. The absolute nesting method would do this: spawn(proc() { // Indented out two indent levels... }) whereas the code in this commit does this: spawn(proc() { // Indented out only one level... })
@pnkfelix I think you are a little familiar with rust-mode? Can you review? |
@MicahChalmer can you squash that commit into the one that adds the test? |
I've added details in the description of each comment as to what it does, which I won't redundantly repeat here in the PR. They all relate to indentation in the emacs rust-mode. What I will note here is that this closes #8787. It addresses the last remaining case (not in the original issue description but in a comment), of indenting `match` statements. With the changes here, I believe every problem described in the issue description or comments of #8787 is addressed.
👯 |
hmm, some things are not working the way I would have expected. e.g. despite a comment saying "If we're at the beginning of the line (before or at the current indentation), jump with the indentation change. Otherwise ...", AFAICT we are not actually jumping when the cursor is at the beginning of the line. (At least not when the content on this line is properly aligned -- maybe its just muscle memory, but I expect the cursor to jump to the indentation column when I hit tab from the beginning of the line, regardless of whether the current content is already properly aligned or not.) I've been getting mixed results when attempting to narrow this down. (earlier I had thought that the problem might be an artifact of my use of a beta version of emacs, but now I'm seeing the same issue even with a release version of emacs.) I will try to investigate and file a proper bug. |
I think I know what the problem is. I'll file another PR to fix it. |
See #12835 |
minor: hide param inlay hint when argument is fn-like macro with similar name Closes rust-lang#12486
don't lint [`mixed_attributes_style`] when mixing docs and other attrs fixes: rust-lang#12435 fixes: rust-lang#12436 fixes: rust-lang#12530 --- changelog: don't lint [`mixed_attributes_style`] when mixing different kind of attrs; and move it to late pass;
don't lint [`mixed_attributes_style`] when mixing docs and other attrs fixes: rust-lang#12435 fixes: rust-lang#12436 fixes: rust-lang#12530 --- changelog: don't lint [`mixed_attributes_style`] when mixing different kind of attrs; and move it to late pass;
don't lint [`mixed_attributes_style`] when mixing docs and other attrs fixes: rust-lang#12435 fixes: rust-lang#12436 fixes: rust-lang#12530 --- changelog: don't lint [`mixed_attributes_style`] when mixing different kind of attrs; and move it to late pass;
I've added details in the description of each comment as to what it does, which I won't redundantly repeat here in the PR. They all relate to indentation in the emacs rust-mode.
What I will note here is that this closes #8787. It addresses the last remaining case (not in the original issue description but in a comment), of indenting
match
statements. With the changes here, I believe every problem described in the issue description or comments of #8787 is addressed.