Notepad++ v8.6 Release Candidate 2
-
Problem with multi-edit 0-width column selection visibility in N++ dark mode:
-
@xomx
Thank you for your heads up. Done in commit:
https://github.com/notepad-plus-plus/notepad-plus-plus/commit/2a90f1148782d23d0553e84bae83552b6944d6e7 -
@donho Thank you for the RC2 fix for the zero-width column delete of multi-byte UTF-8. I was able to confirm that RC2 works correctly for me.
I have not done a github report yet for how what I think you call multi-select works. I’m getting more used to some aspects of it and like it when it works. I’m also finding myself seeming to fight with Notepad++ v8.6 and needing to do Ctrl-Z undo when I don’t notice that the editor has switched to multi-select mode but my brain is on single-select mode. I use column mode a lot but have not yet nailed down a pattern to when my mind and Notepad++ v8.6 diverge… To use your Firefox analogy, I’m thinking ahead and don’t notice right away that I’m firing missiles out my rear.
-
If I change my style (Settings > Style Configurator … > Select theme), or just open the Select-theme-combobox, the current line background appears unreadable/black …
… until I restart Notepad++, then it’s again as it should be:
With 8.5 it wouldn’t display the current line background at all until restart (so it would at least still be readable).
-
@CennoxX pointed out the following HERE:
The way the v8.6 Release Candidate 2 of Notepad++ works when using ctrl+c without selection and then ctrl+v differs from Visual Studio Code. In VS Code the whole line will be added in the line above, in Notepad++ the line will be added on the cursor position. I’m probably biased because I’ve used VS Code’s copy function before, but I think VS Code’s behaviour is more useful.
IMO the paste point should be absolute; i.e., right where the caret is. But, I wanted to point this out in this RC thread in case there’s a lot of disagreement with me and a lot of agreement with @CennoxX
-
@CennoxX said in Notepad++ v8.6 Release Candidate 2:
With 8.5 it wouldn’t display the current line background at all until restart (so it would at least still be readable).
I suppose that you mean With 8.6.
I cannot reproduce it at all.
Could you provide the complete instructions to reproduce the issue steadily please? -
@mkupper said in Notepad++ v8.6 Release Candidate 2:
I’m also finding myself seeming to fight with Notepad++ v8.6 and needing to do Ctrl-Z undo when I don’t notice that the editor has switched to multi-select mode but my brain is on single-select mode. I use column mode a lot but have not yet nailed down a pattern to when my mind and Notepad++ v8.6 diverge…
To summarize the situation:
In Scintilla there are rectangular mode (column mode) and stream mode (for single or multi-selection), and multi-edit/select is stream mode.
Notepad++ bases on these 2 modes only in the current state of code to display on status bar. So in the future release, it’s better to be able to distinguish the multi-selection from single selection.Please create an issue and ping me, I will work on it.
-
@Alan-Kilborn said in Notepad++ v8.6 Release Candidate 2:
@CennoxX pointed out the following HERE:
The way the v8.6 Release Candidate 2 of Notepad++ works when using ctrl+c without selection and then ctrl+v differs from Visual Studio Code. In VS Code the whole line will be added in the line above, in Notepad++ the line will be added on the cursor position. I’m probably biased because I’ve used VS Code’s copy function before, but I think VS Code’s behaviour is more useful.
IMO the paste point should be absolute; i.e., right where the caret is. But, I wanted to point this out in this RC thread in case there’s a lot of disagreement with me and a lot of agreement with @CennoxX
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/14296#issuecomment-1823722799
-
D donho unpinned this topic on
-
@donho I have found it out, the black line is actually a bug in a plugin (CSVLint) in combination with the new version.
-
@CennoxX said in Notepad++ v8.6 Release Candidate 2:
the black line is actually a bug in a plugin (CSVLint) in combination with the new version.
I know this issue had happened before with CSVLint in combination with ComparePlus in particular (and AFAIK ComparePlus has actually solved this problem on their end), but does the black-line bug now happen even without ComparePlus installed?
Big if true. If this is indeed the case, someone should definitely raise an issue in CSVLint’s GitHub repo.
-
P PeterJones locked this topic on
