[abelhafi]

Prior to this commit, word wrap could only be configured globally or per MIME type under Tools/Options/Editor/Formatting. Consequently, setting different word wrap settings for two individual files of the same MIME type was not supported.

This commit adds a new "Word Wrap" checkbox action to the View menu to toggle word wrap for the active editor instance. The action is disabled when word wrap cannot be applied to the current context and comes assigned with the ALT-Z keyboard shortcut, which can be reconfigured via Tools/Options/Keymap.

Closes #9550

---

^Add meaningful description above

Click to collapse/expand PR instructions

By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -

• are all your own work, and you have the right to contribute them.
• are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).

LLMs, Commit messages and PR description:

• Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.
• LLM assisted commits should be attributed with an Assisted-by: MODEL_NAME MODEL_VERSION line appended to the commit message.
  • Please mention coding assistance in the PR description too (eg. by adding the same Assisted-by line from above)
  • Please describe the changes in your own words - we'd like to know you understand the changes being made!

If you're a first time contributor, see the Contributing guidelines for more information.

If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.

PR approval and merge checklist:

1. Was this PR correctly labeled, did the right tests run? When did they run?
2. Is this PR squashed?
3. Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
4. Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?

If this PR targets the delivery branch: don't merge. (full wiki article)

[Chris2011]

Nice, thx. I thought to add a toggle to the editor toolbar. What was you reason for the view menu entry?

[abelhafi]

Hello, I’ve added the action to the View menu, following the pattern seen in other applications like Notepad++ and VS Code. Also because I prefer to keep the editor clean. Greetings.

[Chris2011]

@abelhafi don't forget to add someone as a reviewer :)

[matthiasblaesing]

I'll have a look at this. @abelhafi there is no need for constant rebases. If CI would be enabled each forced push would trigger a rebuild and NB is already straining the resources. When review is done, depending on complexity of the PR and intermittend fixes, a final rebase might be necessary or be advisable.

[matthiasblaesing]

@abelhafi thank you for working on this. The implementation looks clean with the drawbacks that are mention in the documentation.

Let me suggest a slight different approach:

Wrapping is not a boolean, so why not expose the three possible values directly. I did not look to deeply into the implementation, but where there is currently a checkbox menuitem, this could be a submenu with the three options that could be directly switched. The keystroke could invoke a "Toggle Wrap" that cycles through wrapping modes "Off" -> "After words" -> "Anywhere". That way there does not need to be a compromise, in worst case toggle has to be invoked 2 times more to reach the original state again.

[matthiasblaesing]

This makes sense to me, if we assume that we don't want to introduce new dependencies/API. But looking at LineWrapType, the values encoded there are already API as they are used at multiple places and persitence. So from my POV, given that fromSettingValue already exists, I suggest to introduce getSettingValue to return that value. Drop the local definitions and deal with LineWrapType where possible.