Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Avoid automatic bracket pairing inside comments and strings

Cerrado
  • ¿Algo no está bien?
#307 2 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@Jonathas2127 ya está trabajando en esto.

Desde el 14/10/2026.

  • #308 de @Jonathas2127 — abierto

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
160
Forks
64
Merge medio
1 d 11 h
PR fusionados (30 d)
132

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de sysprog21/codetrial

Todos los issues de sysprog21/codetrial

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.