Option for auto closing comments#75053
Closed
sergeyvfx wants to merge 4 commits into
Closed
Conversation
Has same strategies as autoClosingBrackets and autoClosingQuotes. This commit does not have any functional changes, just a preparation for an actual logic.
|
|
The tricky part comparing to those existing flags is that their
behavior is defined by a single character, which is how
_isAutoClosingOpenCharType() works. The comments, on another hand,
can consists of multiple characters and they do not fit existing
auto-closing filtering.
To avoid duplication of tokenizing, the decision on whether to place
closing comment or not is based on the electric action which now stored
corresponding token which generated new text.
This allows to filter electric actions in cursor type operations.
Similar to opening/closing pairs the opening/closing comment blocks
are stores in a character map.
Could be a bit overkill, but could as well be more flexible in case
language configuration supports multiple opening/closing comment
blocks (not sure if it is already supported, but in Pascal it is
possible to use { and (* for block comments).
P.S. There might be a trick to fit this logic into existing
isAutoClosing functionality. It does perform tokenization at certain
conditions, but the early output checks and checks for auto-closing
pairs would need to be changed somehow. And is still needed to know
whether typing sequencer is a quote, comment or a brace.
Probably, can check if it's a quote or a brace and consider a
comment otherwise, but seems a bit weak.
sergeyvfx
force-pushed
the
wip_auto_closing_comments
branch
from
June 8, 2019 13:09
430bf79 to
b8b402f
Compare
rebornix
added
editor-autoclosing
alexdima
self-requested a review
November 16, 2022 13:36
Member
|
Continued in #192335 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is an implementation of feature requested in #1966.
The option itself was added in a complete inspiration of
autoClosingBracesandautoClosingQuotesand it's in a separate commit to ease review of actual feature implementation.Not entirely happy with the logic implementation, but there is already quite convoluted interaction between checks in
_isAutoClosingOpenCharTypeand_typeInterceptorElectricChar.Wend with a way which minimizes amount of changes between those two.
The biggest challenge fitting this new functionality into existing
_isAutoClosing*functions is that they are currently designed to work with a single character pairs. While it's possible to make them aware of multi-character ones, it is still seems changes to_typeInterceptorElectricChar()are needed. And this is where some entanglement begins.Really looking forward having feedback from a core developers to find solution which fits design in a best possible way.