Closes#1075
- All positions are dynamically calculated relative to the tab rectangle now (i.e. no hardcoded pixel values are used to position icons/text anymore)
- Match positioning of icons/text in active and inactive tabs (i.e. elements are not "jumping around" anymore upon selection)
Some specific fixes:
- Most issues with vertical TabBar are resolved now (it was basically unusable before, for example labels were cut)
- Darkened background of inactive tabs fills the whole tab now (fixes#1011)
- Close button is centered correctly now (fixes#1010)
When tab settings exists only for L_JS (the old settings) but if the
current document is L_JAVASCRIPT, tab settings for L_JS won't apply to
L_JAVASCRIPT document.
The fix is to use L_JS's tab settings for both L_JS and L_JAVASCRIPT
documents, and to synchronize the values of both type while user
modifies javascript tab settings.
Closes#1111
See https://github.com/notepad-plus-plus/notepad-plus-plus/pull/187/files
, see also comments added in the PR:
String returned by SCI_GETWORDCHARS from scintilla is not null terminated, so check for strlen in isWordChar() below on listChar is dangerous as strlen accesses data after the buffer until the first following null is found in memory
- seen with MS Application Verifier on x64 release
- expected to also happen on win32 x86 release
(Closes#1070)
When backups and session snapshots feature is enabled, batch
modification a big file could make Notepad++ crash. The solution is to
prevent from backing up modified file during the operation of batch
modification.
(Fixes#725)
Open a file of 3 bytes length with '\0' in the middle, only 1 character
shown in editor.
Such file is detected as UTF16 w/o BOM, that makes the wrong length
interpretation. Adding the "len mod 2 == 0" condition to enhance the
detection is the only solution I can find so far.
Closes#1054, Fixes#1002
The problem is if fread() is called multiple times, then
UnicodeConvertor->convert() is called multiple times, which causes
m_pNewBuf to point to the last read in chunk. Then after the entire file
was loaded, getEOLFormatForm(UnicodeConvertor.getNewBuf(), ...) was being
used which was only trying to detect the EOL mode from the last read in
chunk. If this last chunk started with \n then the file was detected as
Unix line endings. The file linked from issue #1002 happened to have just
the right situation where this occurred.
