Notepad++ 7.8 Release

Zsolt Kántor

@patrickdrd said in Notepad++ 7.8 Release:

did you change the font in search dialog?
if so, is there an option I can change it back?

No, it was not changed. I suppose you can’t change it.

Alan Kilborn

@patrickdrd said in Notepad++ 7.8 Release:

did you change the font in search dialog?

See above, specifically: 10. Make Combobox font monospace in Find dialog.

if so, is there an option I can change it back?

No. Apparently it was decided that this is a good change for everyone.

tomasz1986

@patrickdrd said in Notepad++ 7.8 Release:

did you change the font in search dialog?
if so, is there an option I can change it back?

The new font looks smaller and very blurry in my system (Windows 7). As such, it is very difficult to read. It also uses serif fonts for Korean (and possibly all CJK languages), which are not suitable for small sizes.

Here are two screen shots.

old (crispy)

new (blurry)

Please consider adding customisation options, or at least an option to switch between the old and the new fonts.

tomasz1986

I am very sorry for two posts in a row, but I am no longer allowed to edit the previous one.

Just to clarify, my point is that Windows does not even ship with monospace fonts for languages like Korean. This makes it use a fallback font instead. The problem is that the default fallback for monospace fonts is the default serif font (called Batang), which looks blurry in small sizes. In the previous version of Notepad++, the default sans-serif font (Dotum) was used instead. That font stays crispy even in small sizes.

Even with 3rd party monospace Korean fonts installed, Windows will still use serif fonts in their place. Right now, I am able to manually set Notepad++ to use 3rd party monospace Korean fonts in the Style Configurator, but those settings do not seem to apply to the Find window.

cybermcm

Possible bug: I’m using npp as replacement for notepad on Windows (according to this page:
https://npp-user-manual.org/docs/other-resources/#notepad-replacement)

Worked with 7.7.1 portable, it is now broken (in 7.8 portable) if files have a space in its name.
E.g. file “xxx yyy.txt” -> double click -> npp shows xxx doesn’t exist, yyy.txt doesn’t exist -> file is opened after that along with desktop.ini which is opened every time

For now I’m reverting back to 7.7.1

Alan Kilborn

@cybermcm

Related to this, possibly, although you don’t appear to have multiple ? :

23. Fix command line issues where filenames have multiple white spaces in them.

cybermcm

@Alan-Kilborn no, just one white space. I just noticed that this is more severe. NPP openes all! other files in the same and in subfolders if one single file is opened. desktop.ini (from my posting above) was opened because it was the only other file on my desktop…
At least for me (or my current config) a no go

Alan Kilborn

@cybermcm

I guess maybe you want to make a bug report.

dokutoku

I felt sad that my plugin added to nppPluginList was not reflected in 7.8.

rinku singh

@dokutoku said in Notepad++ 7.8 Release:

nppPluginList was not reflected in 7.8.

Send a pull request for notepad++ plugin template(d language)

dokutoku

@gurikbal-singh

Do you mean this request?

https://github.com/notepad-plus-plus/nppPluginList/pull/140

rinku singh

@dokutoku
https://gitlab.com/dokutoku/rdmd-for-npp/issues/3
how we can exit from console (dub ATL+D in your plugin )? it close the npp

Zsolt Kántor

When syntax highlight is enabled (e.g. C source code) and you check the global override Enable global bold font style box for keywords and some other characters will be less thicker. Is this normal? Here are the screenshots:

not selected.png

Just check the case keyword, dots, semicolons, equal signs and curly brackets

It happens with most of the font types, and as far only if syntax highlight is enabled. Is this normal?

Bilbo47

“3. Add “No to all” and “Yes to all” options in Save dialog.”

Regression: The Yes/No/Cancel buttons used to have hotkeys so that single keystrokes could give a command on how to proceed. In 7.8, “Y” and “N” are ignored, while “Escape” still works. This is a showstopper for me; back to 7.7 for that basic usability feature. Also for standard usability, the new “All” buttons need to have their own hotkeys.

It appears the new “X to all” buttons are available only after the “Close All” command; in case of the “Close” command, they are greyed out. User interface principles say that buttons that are never available in certain circumstances should not even be visible in those circumstances. If “Close” and “Close All” are going to be two separate commands, then the corresponding dialog functionality/discoverability should also be different. If “X to all” is going to be not-available after “Close” then the “All” buttons should be not-visible after “Close”. Or, if “X to all” is going to be available after “Close” then “Close All” should not be a separate command. In short, the decision of all-versus-one should be made only once, or should be made available as often as possible. But showing that different functionality is available only if User backs up and starts over, that’s just maddening.

From experience, custom buttons can be added to the Windows-standard Common Dialogs instead of writing custom dialogs; it just takes some more subclassing and API work to do so.