Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Avoid automatic bracket pairing inside comments and strings

Aperta
  • Qualcosa non va?
#307 2 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Jonathas2127 ci sta già lavorando.

Dal 14/10/2026.

  • #308 di @Jonathas2127 — aperta

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

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.

Lingua principale
Rust
Stelle
160
Fork
64
Merge medio
1g 10h
PR unite (30g)
116

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di sysprog21/codetrial

Tutte le issue di sysprog21/codetrial

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.