### Problem description
The bug can be reproduced as follows:
1) Using Ctrl-F do a search for a term that occurs several times in the
file. and press F3 to visit them.
2) Go back to the fop of the file and insert 3 blank lines.
3) Pressing F3 once or many times will not find the term entered above.
### Implementation description
The reason for this bug is that the positions of the matches are not
being reset when changes can potentially move them.
The fix consists on resetting the search locations when changing the
contents of the file and redoing the search after the changes are made.
The bug was specially problematic when doing replace because the
replacement position would be identified as a match. This PR fixes
replace as well.
---------
Co-authored-by: Nik <werwolv98@gmail.com>
This is a simple fix for a simple issue. Just check if the last char in
the selection is a double quote and if it is, make the selection one
char shorter.
---------
Co-authored-by: Nik <werwolv98@gmail.com>
### Problem description
Currently when errors are found the entire line where the error occurred
is highlighted and one has to look at the error message in order to find
where the error is located on the line. With this PR the line will no
longer be highlighted and the location of the error will be marked with
an red waved line under the error location. Hovering over the text where
the error occurred produces an error overlay so if several errors occur
on the same line they can all be seen separately.
### Implementation description
The definition of error marker was switched to include column and size
as well as line and message like before.
This change required changing the way view pattern editor draws the
error markers because the errors themselves don't have size information.
Also, a new errorHoverBoxes type was defined to help in the detection of
the floating error messages when error is hovered.
Note that the underwave code depends on having a monospaced. If font is
not monospaced the underwaved text can be short/long or displaced.
### Screenshots
### Problem description
There are some recent issues about Mac keys not configured properly for
the pattern editor. This PR moves all the shortcuts to the shortcut
manager, so they can be edited at will. Even if the key is not
identified correctly it should be possible to use preferred keys for any
action.
---------
Co-authored-by: Nik <werwolv98@gmail.com>
other separate, but closely related fixes are:
- fix: The previous fix also solved the (unreported) bug of being unable
to select utf-8 works by double-clicking.
- fix: The move to next/previous word (Ctr-arrow) behaved differently
depending on the direction. I made both the move left/right functions
share a much simpler algorithm and rewrote the find start/end of word
functions share the same code structure.
### Problem description
The code was using the byte index of the match into the utf-8 string to
store the match locations, but the code that sets the selection uses the
char index into the utf-8 string instead. Another problem was that the
search uses the byte index to determine if it needs to find more
matches.
### Implementation description
Both problems were solved by introducing two functions to switch from
coordinates in units of bytes to coordinates in units of chars and vice
versa.
Co-authored-by: Nik <werwolv98@gmail.com>
### Problem description
When this feature was implemented the text editor handled all the
keyboard input so the blink reset function could be called in one place
for all the key presses. Now that shortcuts are done in the shortcut
manager we need to reset the blink state inside all the functions that
can affect cursor movement.
### Implementation description
Every function that moves the cursor now calls the blink state reset
function at the very start. There may be more functions that need this
that haven't been merged but git should show merging conflicts so it
should be easy to deal with.
This PR updates the nativefiledialog submodule and uses its new feature
to set the ImHex main window as the parent of the dialog window. This
ensures that the dialog stays on top of the main window. This is
currently supported by NFDe on Windows, macOS, and Linux/X11.
Linux/Wayland behaves as it did previously due to limitations in NFDe.
Note that macOS file dialogs have already been parented properly as NFDe
previously used the key window (the window currently receiving keyboard
events) on macOS. However, it's probably better to do the correct thing
and pass the main window to NFDe even on macOS.
### Problem description
The file dialog go behind the main window if the main window is clicked
while the file dialog is open.
### Implementation description
Update nativefiledialog and pass the `GLFWwindow*` of the main window to
the library function.
### Screenshots
Before:
https://github.com/WerWolv/ImHex/assets/6948096/589c3401-702a-4b0a-99ed-02d3e4d9080e
After:
https://github.com/WerWolv/ImHex/assets/6948096/8fef4900-eedc-48d5-8a4e-7bd81e37e3c0
### Additional things
I have tested this on Windows and Linux/X11, but did not test this on
macOS. It would be ideal if someone can help with this. (But as far as
NFDe is concerned, macOS `NSWindow*` handles have been tested (with
SDL2) and works.)
Co-authored-by: Nik <werwolv98@gmail.com>
### Problem description
By default, the cursor's blinking cycle is independent from user
actions, which feels unconventional while editing pattern code. This
change ensures that the blinking cycle is reset, and the cursor is made
visible every time the editor receives a keyboard event like character
entry, or arrow navigation.
### Implementation description
I moved the hard-coded blink timing numbers to their dedicated static
constant fields since now they are referenced from multiple different
places.
I added the function `void ResetCursorBlinkTime()` to `TextEditor.cpp`
that will reset the blink cycle to `currentMillis() -
sCursorBlinkOnTime`, ensuring that the cursor is visible. This function
is called for every keyboard and mouse click event.
### Screenshots
Before:
https://github.com/WerWolv/ImHex/assets/45818400/668c6802-79a3-450b-80d3-d6abf2ce27be
After:
https://github.com/WerWolv/ImHex/assets/45818400/ee7f60e0-a75f-416d-b86d-8d12b5cdadf2
---------
Co-authored-by: Nik <werwolv98@gmail.com>
Fixed console error messages using doc comment syntax highlights. Fixed
results of find not updating when march case was toggled. Fixed syntax
highlights of nested ifdefs. Fixed editor cursor blinks if OS focus goes
to another window. Fixed Highlights of "\\\"" was incorrectly handled.
---------
Co-authored-by: Nik <werwolv98@gmail.com>
### Problem description
WASM build does not support copy/paste beyond the application. Meaning,
there's no practical way of sending text back and forth across the
application border.
There are lengthy threads why this is a technical challenge in
WASM/Browser world, e.g:
- https://github.com/pthom/hello_imgui/issues/3
- https://github.com/emscripten-core/emscripten/pull/19510
### Implementation description
Implements a workaround solution as Header only C++ library, as proposed
and implemented at:
https://github.com/Armchair-Software/emscripten-browser-clipboard
Maybe there are cleaner ways of achieving the functionality. Definitely
would like to have some discussion around this. 👀ℹ️ The proposed PR "works for me" on Windows, using CTRL-C/V shortcuts
to copy text from and to the application. On MacOS the system shortcut
to Paste is different from what ImHex has defined. This results in
system Paste shortcut of command-V triggering the browser callback to
synchronise the application clipboard, but no actual Paste takes place
within ImHex.
If there would be a clean way to trigger the paste command, that would
be wonderful (or get the context and references to write the data to the
cursor, but I was unable to find a clean solution). The only proposed
solutions in the referenced threads were about triggering paste event
internally via Key events. This seemed wonky 🙃 , so is not currently
implemented. At the moment the paste on MacOS is command+V followed by
control+V.
### Additional things
This is definitely a stopgap solution before the ImGui and Emscripten
take a more proper solution in enabling Copy/Paste outside the
application borders. However, I feel like this is a must have capability
to make the WASM build more useful, not just for trying out ImHex.
Cheers! 🍻
---------
Co-authored-by: Nik <werwolv98@gmail.com>
