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.
I have asked a question to a friend in USA for which one should I use, here is his answer:
1. "Extended (\r, \n, \t, \x..., \0)"
2. "Extended (\n, \r, \t, \0, \x...)"
The ellipsis (three dots) means that the list does not show everything that could be shown.
If you mean that there are more items than what you can show, but you are listing just the most important ones, you want the second one.
The first one implies that you are following a certain order and that some items are not listed but that \0 is last, either in list order or importance. At least, that's what it looks like to me.
closes#1007, closes#919, closes#834
When backups are enabled, playing back a macro that takes a while can
corrupt a file (see the mentioned issues). I tested this with a ~100,000
line text file, ~3.3MB in size. Created a macro of Down5, Delete10. Played
this till the end of the file. Took about 20s to run so it had a few
backup cycles during it. Reproduced it fairly easily and never had it
happen after this adjustment.
* The Shebang detection is much improved:
- detect more languages
- not tied to any specific full path
- See https://en.wikipedia.org/wiki/Shebang_%28Unix%29 for more details about Shebang
* There is not need to have a space after <?php. Closes#1014
* Remove the closing > in the html doctype to support older
* versions of html as well
* The Shebang detection is much improved:
* detect more languages
* not tied to any specific full path
* There is not need to have a space after <?php
* Remove the closing `>` in the html doctype to
support older versions of html as well
