The reason for the error were the text preprocessor added to deal with
tabs was created to process entire files, not just lines or words. In
that context it cleaned trailing new lines if any existed but in the new
role that's not only unwanted but erroneous.
### Problem description
After that was fixed the console started to add two empty lines between
each output line. When splitting a string using new lines you need to
not add a new line to the last line created. Even if the text ends in an
end line, the split screen code is set to not discard empty lines.
### Implementation description
The fixes are straightforward.
I have implemented a fix that makes the scrollbars behave like they do
in VScode. Vertically you can scroll past the end of the file until only
the last line can be seen at the top. The horizontal bar behaves as if
every line was the same length which is the length of the longest line
in the file. Not only this creates a better user experience, but it also
fixes the annoying flicker that occurs when scrolling through large
files. Also, I have switched all the old draw calls to render text to
regular TextUnformatted calls which adds extra stability to the
resulting display.
To implement the behavior I added a dummy widget with the desired
dimensions.
This time it may be for good.
### Implementation description
As requested I added the preprocessing functionality into the pattern
editor. I had to duplicate a few functions and update the c++ library to
version 20. but now I can make sure the pattern editor doesn't see a tab
again. I also removed the preprocessor from where it was before because
it is not needed anymore. The changes were tested using a file that used
tabs for all its white space. The file was pasted into the pattern
editor and imported as well. I both cases no crashes occurred and the
files had no tabs on them.
### Problem description
This PR implements the feature request described in #1995, that
describes a problem with the `Paste` vs `Paste all` commands. Users
could be thrown off by having `Ctrl+V` act as a simple "Paste over
selection", whereas it's generally accepted as a "Paste all".
### Implementation description
<!-- Explain what you did to correct the problem -->
This PR introduces a new setting, called "Paste behaviour" (under the
"Hex Editor" category).
This setting has three values:
- `Paste over selection`: the current implementation for ImHex. Pastes
only over the selection region, in this case pasting only one byte;
- `Paste everything`: allows ImHex's `Paste` to behave like a `Paste
all` when selecting one-byte regions;
- `Ask me next time`: prompts the user for a choice of behaviour
(default value).
*Note: as users generally use `Paste all` when selecting one-byte
regions, calling `Paste` when selecting over two or more bytes is not
affected by this change, and will still behave like the usual `Paste`
command.*
When selecting a one-byte region, and calling the Paste command, users
that have not defined a preferred behaviour in the settings will be
prompted to choose one, using a brand new popup. The popup also allows
the user to cancel, which will not change the settings' value, and will
cancel the paste action altogether.
### Screenshots
The new popup:
The new setting:
### Additional things
I'm not very good with long descriptions, so I'm open to any suggestions
regarding the text that is included in the popup!
I do think however that we should keep a hint indicating that `Paste
all` is always an option, which could solve the issue altogether for
very new users.
---------
Signed-off-by: BioTheWolff <47079795+BioTheWolff@users.noreply.github.com>
Co-authored-by: Nik <werwolv98@gmail.com>
<!--
Please provide as much information as possible about what your PR aims
to do.
PRs with no description will most likely be closed until more
information is provided.
If you're planing on changing fundamental behaviour or add big new
features, please open a GitHub Issue first before starting to work on
it.
If it's not something big and you still want to contact us about it,
feel free to do so !
-->
### Problem description
<!-- Describe the bug that you fixed/feature request that you
implemented, or link to an existing issue describing it -->
### Implementation description
<!-- Explain what you did to correct the problem -->
### Screenshots
<!-- If your change is visual, take a screenshot showing it. Ideally,
make before/after sceenshots -->
### Additional things
<!-- Anything else you would like to say -->
### Problem description
As described in issue #1841, there was a duplicate on the `Chinese
(Simplified)` translation.
After closer inspection, this came from an i18n file (Script loader,
specifically) having a bad ISO code (`zh_CN` instead of the expected
`zh-CN`).
This also caused a big impact on end users, as loading the latter
(`zh_CN`) would cause the whole UI to be displayed in English (the
fallback language), and only the script loader being translated into
Chinese.
### Implementation description
Fixed the i18n code in the Script loader file.
### Additional things
Closes issue #1841
Signed-off-by: BioTheWolff <47079795+BioTheWolff@users.noreply.github.com>
### Problem description
Long error messages were forcing the width of the window to span the
entire screen.
### Implementation description
The fix was sending the long message to the log and outputting a short
message to the 3d visualizer window.
---------
Co-authored-by: WerWolv <werwolv98@gmail.com>
### Problem description
As suggested in #1904, ImHex could benefit from having the capability of
pasting text directly into the editor.
This also complements the "Copy as... ASCII string" capability already
implemented in the software.
### Implementation description
A new shortcut called `Paste all as string` (to resemble the naming of
the `ASCII string` copy option) now allows to paste plaintext directly.
This shortcut is mapped to the `CTRL + ALT + SHIFT + V` keybind.
Internally, a new flag called `asPlainText` has been added to the
`pasteBytes` function, to minimise code changes and streamline code
readability.
The buffer is a simple type cast of the clipboard, without any
modification applied, which is then handed to the provider's `write`
function.
### Screenshots
The new shortcut is visible in the menu, just below the other paste
options:
---------
Signed-off-by: BioTheWolff <47079795+BioTheWolff@users.noreply.github.com>
Fix crash on UNDO/REDO shortcut press when in "title screen"
### Problem description
ImHex crashes when (by default CTRL + Z/Y) undo/redo is pressed when on
"title"/"starting" screen (no file open, tested on Windows release build
and Linux [WSL] from-source build).
This is due to the shortcut's callback being called even if the
`provider` is `nullptr`. (see `createEditMenu` function).
Theoretically, this is prevented by the `enabledCallback` function
passsed to `addMenuItem`. In this case, though,
`addMenuItem` correctly propagates `enabledCallback` to menu item
creation but does not pass `enabledCallback` to
shortcut creation. Thus, when handling shortcuts, `enabledCallback` is
not used at all and the shortcut's callback
can be called in contradiction with its preconditions. (specified by
`enabledCallback`)
### Implementation description
The implementation wraps the callback in a check that decides whether
the shortcut is enabled or not.
(see changed files)
```c++
auto callbackIfEnabled = [enabledCallback, function]{ if (enabledCallback()) { function(); } };
```
This function is then passed along instead of the `function` (shortcut's
callback).
Alternatively, we can check for `nullptr` in the callback directly. This
would require modification of `createEditMenu`'s contents.
(I did not choose this implementation because I do not think it
addresses the root of the issue).
### Screenshots
None
### Additional things
I'm not sure how big of a deal it is but I am unsure whether I can
capture (`[enabledCallback, function]`) by reference or not.
