Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Avoid automatic bracket pairing inside comments and strings

Offen
  • Stimmt etwas nicht?
#307 2 Kommentare 0 Reaktionen 1 zugewiesene Person Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@Jonathas2127 arbeitet bereits daran.

Seit 14.10.2026.

  • #308 von @Jonathas2127 — offen

Bewertung

Dieses Issue wurde noch nicht bewertet.

Beschreibung

Problem

Automatic bracket pairing currently inserts a closing bracket inside comments and string literals. In these contexts, an opening bracket may be ordinary text, so inserting an additional closer can interrupt typing.

This behavior was mentioned in #85, which also proposed the core pairing behavior and an optional toggle. Those features have since been addressed through #88, #165, and #252. This proposal focuses specifically on making automatic insertion aware of comments and strings.

Reproduction

With automatic bracket pairing enabled, select C++ in the interview editor.

In the examples below, | represents the caret and is not part of the code.

Line comment

Before typing (:

// note |

Actual result:

// note (|)

Expected result:

// note (|

String literal

Before typing (:

const char* s = "left| ";

Actual result:

const char* s = "left(|) ";

Expected result:

const char* s = "left(| ";

I also reproduced automatic pairing inside a multiline C++ block comment.

These behaviors were reproduced with Chromium against revision 59bde8f. I also inspected web/editor.js and its beforeinput integration at revision 8394d5489630f7ed989cd86835c57647bf7f2e44: the pairing path checks the following character but does not check whether the caret is inside a comment or string.

Proposed behavior

For a collapsed selection, typing (, [, or { inside a recognized comment or string should insert only the typed character.

Outside those contexts, the existing pairing behavior should remain unchanged, including the following-character restriction introduced by #165.

This proposal would preserve:

  • Wrapping selected text with brackets.
  • Typing over an existing closing bracket.
  • Deleting an empty pair with Backspace.
  • The Auto-close setting and its persistence.
  • Existing undo, paste, and IME behavior.

Tracking which closing brackets were automatically inserted is a separate concern and is outside this proposal.

Implementation approach

I propose checking the lexical context at the caret before attempting automatic pair insertion.

The editor already has language-aware tokenization for syntax highlighting and bracket matching. I would first investigate reusing that classification instead of introducing another independent parser.

The check should use the current editor contents and selected language. It also needs to handle partially typed code and caret positions at string or comment boundaries. If the context cannot be determined reliably, the initial implementation would preserve the existing behavior.

When pairing is suppressed, the handler should allow the browser's normal text insertion to proceed. This would avoid introducing a separate editing path for ordinary typing.

Validation

I would add focused helper tests and browser tests covering:

  • Ordinary code where automatic pairing should still occur.
  • Line and block comments where supported by the selected language.
  • Strings, including escaped quotes and supported multiline forms.
  • Caret positions immediately inside and outside comments and strings.
  • Switching languages without reusing stale context.
  • Selected-text wrapping and the Auto-close setting.
  • Undo behavior for both automatic pairing and ordinary insertion.

The browser tests would exercise actual typing in the editor. I would also run the repository's verification script and report any skipped checks.

Scope confirmation

I would like to implement this as a focused follow-up to #85. Does suppressing automatic insertion for collapsed selections inside comments and strings match the intended editor behavior?

Refs #85.

Vorherrschende Sprache
Rust
Sterne
160
Forks
64
Ø Merge
1 T. 10 Std.
Gemergte PRs (30 T.)
116

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus sysprog21/codetrial

Alle Issues in sysprog21/codetrial

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.