Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Accept special commands without trailing semicolons even in multi-line mode#1545

Merged
rolandwalker merged 1 commit intomainfrom
RW/accept-special-commands-without-trailing-semicolon
Feb 14, 2026
Merged

Accept special commands without trailing semicolons even in multi-line mode#1545
rolandwalker merged 1 commit intomainfrom
RW/accept-special-commands-without-trailing-semicolon

Conversation

@rolandwalker
Copy link
Contributor

Description

"exit" was always an exception to the multi-line trailing semicolon rule. At minimum, "help" should likewise be an exception.

This makes all special commands exceptions to the multi-line trailing semicolon requirement, on the theory of consistency, because special commands starting with backslash have also always been exceptions.

Tests seem difficult. We'd want to do a "behave" test using an alternate configuration.

Checklist

  • I added this contribution to the changelog.md file.
  • I added my name to the AUTHORS file (or it's already there).
  • To lint and format the code, I ran
    uv run ruff check && uv run ruff format && uv run mypy --install-types .

even in multi-line mode.

"exit" was always an exception to the multi-line trailing semicolon
rule.  At minimum, "help" should likewise be an exception.

This makes all special commands exceptions to the multi-line trailing
semicolon requirement, on the theory of consistency, because special
commands starting with backslash have also always been exceptions.
@rolandwalker rolandwalker self-assigned this Feb 13, 2026
# Exit doesn't need semi-column`
(text == "exit")
# non-backslashed special commands such as "exit" or "help" don't need semicolon
first_word in SPECIAL_COMMANDS
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since first_word seems to come in as-is (could be mixed case), I'd either change this first one to .upper() or just combine the two cases and have it be something like first_word.lower() in (key.lower() for key in SPECIAL_COMMANDS.keys())` to cover both cases maybe.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm failing to understand the suggestion. By the time we get here, the words are only the textual forms, because the backslash forms were handled above. So we should only need to account for accepting eg EXIT like exit. If this is wrong we can follow up.

Copy link
Contributor

@scottnemes scottnemes Feb 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not wrong, I just think you could get rid of the first condition. You're currently checking if the as-is value is in special commands, and then you check if the lowercase version is in special commands. So you really only need to check the lowercase value as that will cover both situations (user gives EXIT or exit), or ExiT, or whatever).

Copy link
Contributor

@scottnemes scottnemes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving as-is, left a comment if for potential update if desired.

@rolandwalker rolandwalker merged commit 25926ca into main Feb 14, 2026
8 checks passed
@rolandwalker rolandwalker deleted the RW/accept-special-commands-without-trailing-semicolon branch February 14, 2026 10:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants