Let me attempt to summarize, hopefully for someone’s benefit, what we know so far:

Problem 1: cryptic language identifiers in the Tab Settings list box

Cause: the window procedure that fills Tab Settings uses an instance of this Lang structure, which has a _langName member, filled by the name= attribute of langs.xml, which is identical to the Lexilla language identifier so that N++ can send it, unmodified, directly to Scintilla when creating the lexer (convenient for the developer, less so for end users).

Potential Solution: There is already a ScintillaEditView::_langNameInfoArray type with a more readable _shortName member. The approriate _shortName could be looked up using the enumerated _langID which every Lang instance already has; or else the Lang type can be refactored to store it’s own pretty name.

Problem 2: the first item, “[Default]”, is always selected in the Tab Settings listbox

Cause: the window procedure that fills Tab Settings does this on purpose by always passing a 0 index to the dialog window.

Potential Solution: the window procedure that sets the preference dialog needs access to an instance ScintillaEditView, which can look up the active lexer by calling getCurrentBuffer()->getCurrentLang(), then setting the index of the selected item appropriately.

Sound like fun? Well, that’s Win32 GUI programming in C++ for you.

I don’t yet fully understand why (and why the numbers of items in the two lists are different,

They aren’t as different as you imply. 89 of the 91 entries from the table are also in the Tab Settings box. The two entries that are missing are “ext” and “udf”. “udf” is the User Defined Language File, and since tab settings for the UDL are not implemented, that’s why it doesn’t show up in the Tab Settings box. And “ext” is a dummy/placeholder, with no lexer associated (“null” is the final column), so it makes sense that it’s ignored.

Looking at the default langs.xml, there are 89 entries. The name="..." of each of those 89 entries matches up with the _langName from the table and matches up with the order in the Tab Settings list. So Tab Settings gets its order and contents from langs.xml. And the two languages name="udf" and name="ext" were intentionally left out, as they do not use traditional language lexers.

which means it’s not a one-to-one correspondence, which means these are more than just two different ways of naming the same thing.

I believe your conclusion is incorrect, based on the data I provided.

What is named in the tabs list,

answered

and how is the active one determined… by the active language alone,

Yes. The _langName from the source-code table maps to the name="..." from langs.xml, providing the 1:1 linkage from the entries in langs.xml and the entries in the table (it’s only 1:1 in one direction, because of the extra items in the table).

or is there another complication… or a completely different pathway?). I’ll have to find some time to spend crawling through Notepad++ code before (possibly) I’ll feel like I know what’s happening.

It took me about 15 minutes to write up this further explanation for you, and didn’t take any crawling in any source code that I or someone else hadn’t already linked for you, except for langs.xml (which hardly counts as source code). (I had the flash to look in langs.xml when I was trying to figure out why Tab Settings wasn’t in 100% alphabetical order.)

I don’t see any problem with this; are you going to make it a real feature request?

When and if I feel like I actually understand what is going on there, so the request will make sense (and, hopefully, I can follow up right away with a pull request to implement it). @rdipardo and @PeterJones clarified how the lists get to be as they are, but I don’t yet fully understand why (and why the numbers of items in the two lists are different, which means it’s not a one-to-one correspondence, which means these are more than just two different ways of naming the same thing. What is named in the tabs list, and how is the active one determined… by the active language alone, or is there another complication… or a completely different pathway?). I’ll have to find some time to spend crawling through Notepad++ code before (possibly) I’ll feel like I know what’s happening.

I see that languages in the Language Menu box appear to match up with the languages that are, in fact, on the Language menu … but are the languages in the Tab Settings in fact the same languages, just using different identifiers?

The names in the Language menu are the text from Notepad_plus.rc

The table in ScintillaEditView.cpp shows the _langName and _shortName and _longName values that Notepad++ uses elsewhere. The _langName corresponds to the name that’s found inside lexer source code and in the Settings > Preferences > Language > Tab Settings box, the _shortName is what shows up in the Language menu and in Settings > Preferences > Language > Language Menu’s Available items and Disabled items boxes, and the _longName is what shows up as the file-type language name in the status bar.

though for some reason I can’t guess, they’re in some apparently random order

The Preferences’ Language Menu box is “sorted” in the same order from the ScintillaEditView.cpp table (which, as the comment in .cpp file says, "the order of lang type (enum LangType) must be respected – where the enum LangType order is defined in Notepad_plus_msgs.h), and the preferenceDlg.cpp code that was linked above just iterates through that table in order, which is why it’s that order rather than being sorted alphabetically; the Preferences’ is sorted alphabetically by _langName (except “searchResult” goes at the end for the Tab Settings); the order in the Language Menu is set by the order in the Notepad_plus.rc file.

…otherwise situations like @Ann-Witbrock encountered seem inevitable.

My first thought was putting some static text in the Tab Settings groupbox that says “[Default] setting is in effect unless overridden by setting for specific language”. My second thought was that that is pointless because that’s pretty much the definition of “default”.

best to highlight the entry that’s actually in control of the current document

I don’t see any problem with this; are you going to make it a real feature request?

@Coises said in Notepad/+/+ v8/.4/.9 Release:

Side note: Is there a reason the language names there aren’t the same as the ones in the Language Menu list just to the left (e.g., C++ in the Language Menu, but cpp in the Tab Settings?

The latter is populated by simply iterating Lexilla’s module identifiers (*1): https://github.com/notepad-plus-plus/notepad-plus-plus/blob/7e6c4b3c6bb08ccd9da4ef09c3361ea16f0409bb/PowerEditor/src/WinControls/Preference/preferenceDlg.cpp#L2884-L2887

Forgive me, but I’m now more confused than I thought I was before. I see that languages in the Language Menu box appear to match up with the languages that are, in fact, on the Language menu (though for some reason I can’t guess, they’re in some apparently random order), but are the languages in the Tab Settings in fact the same languages, just using different identifiers? I can’t make out from the code you linked and the code above it what, if anything, is the connection between the two. (Hmmm… I count 88 entries in the Language Menu box and 85 in the Tab Settings box, so I guess they can’t be quite the same… but nothing in the documentation clarifies to me what is the connection.)

All this even more makes me think it really would be best to highlight the entry that’s actually in control of the current document; otherwise situations like @Ann-Witbrock encountered seem inevitable.

Side note: Is there a reason the language names there aren’t the same as the ones in the Language Menu list just to the left (e.g., C++ in the Language Menu, but cpp in the Tab Settings?

The latter is populated by simply iterating Lexilla’s module identifiers (*1): https://github.com/notepad-plus-plus/notepad-plus-plus/blob/7e6c4b3c6bb08ccd9da4ef09c3361ea16f0409bb/PowerEditor/src/WinControls/Preference/preferenceDlg.cpp#L2884-L2887

(*1)

$ git clone https://github.com/ScintillaOrg/lexilla.git
$ cd lexilla/examples/CheckLexilla
$ CFLAGS=-Wno-deprecated-declarations make check
gcc -I ../../include  -Wno-deprecated-declarations CheckLexilla.c   -o CheckLexilla.exe
./CheckLexilla.exe
Opened ../../bin/lexilla.dll -> 00007ff9c2350000.
There are 132 lexers.
a68k abaqus ada apdl as asciidoc asm asn1 asy au3 ave avs baan bash batch bib blitzbasic bullant caml cil clarion clarionnocase cmake COBOL coffeescript conf cpp cppnocase csound css d dataflex diff DMAP DMIS ecl edifact eiffel eiffelkw erlang errorlist escript f77 flagship forth fortran freebasic fsharp gap gdscript gui4cli haskell hollywood hypertext ihex indent inno json julia kix kvirc latex lisp literatehaskell lot lout lua magiksf makefile markdown matlab maxima metapost mmixal modula mssql mysql nim nimrod nncrontab nsis null octave opal oscript pascal powerbasic perl phpscript PL/M po pov powerpro powershell abl props ps purebasic python r raku rebol registry ruby rust sas scriptol smalltalk SML sorcins specman spice sql srec stata fcST TACL tads3 TAL tcl tcmd tehex tex txt2tags vb vbscript verilog vhdl visualprolog x12 xml yaml
Lexer factory 4 -> 00007ff9c236fe30.
Created cpp lexer -> 0000016796a00000.
Lexer name 3 -> cpp.
Property names ''.
Name space 'lexilla'.

To avoid confusion, it might be useful to have it obey the default when no language is set.

I’m pretty sure Notepad++ does that, but it sets “language” automatically based on the file extension. Normally that’s a good thing, but…

Does it seem to anyone else that when you open Settings… | Preferences | Language, the language selector in the Tab Settings box ought to start off with the language currently applied to the active file highlighted? I’m fairly sure at least some of the ones I see that are not set to Use default value — like python and yaml — were not set that way by me. I’m not sure it would even occur to me, if I were editing a *.yaml file (if that is what triggers yaml) that it was a language and not just an unknown file extension (which it is to me). So I might be thrashing about the same way, wondering why my settings weren’t effective.

Side note: Is there a reason the language names there aren’t the same as the ones in the Language Menu list just to the left (e.g., C++ in the Language Menu, but cpp in the Tab Settings?

To avoid confusion, it might be useful to have it obey the default when no language is set.

I’ve tried out the edit menu settings as well now (thanks Mark for pointing me in the right direction) and although it’s a little confusing it seems to be quite useful :-) This actually would have saved me all the trouble if I’d noticed in advance and changed all the tabs to spaces as normal.

Hopefully this discussion will help others if they come across this. Thanks.

I’m sorry you are not making yourself at all clear.

I think I’m pretty clear, if you’d just read and provide what I’m asking for.
You are probably referring to Mark’s posting, which isn’t going to help you solve the root of your problem (which is, what you get [spaces or tab character] when you press the Tab key).

I see in the thread below that there is a new, additional place to set this. I had not noticed this in the menu. Perhaps the word Blank is not so obvious if you aren’t expecting it.

I’ll try again with that setting. Not sure how that should interact with the global setting.

including fully setting Python as you pointed out

How come you aren’t showing this to us here, in a screenshot, like I asked?

The label “Disabled items” was a bit confusing

Disabled items has nothing to do with what we’re discussing.

Show us your setting like this, with python in view and selected:

The same behaviour is still present in 8.5.2 (see detailed progression of test), including fully setting Python as you pointed out, thanks :-)
(The label “Disabled items” was a bit confusing there, and it’s been a while since I used this editor often so I misinterpreted the highlight).

I think we can probably conclude this is also true for other languages, but it’s vital for Python.

turning everything into spaces (not desirable)

Did you know that the recommended standard for Python is to use spaces for indentation and NOT tab characters?

the editor does not respect the setting preference flag for converting tabs to spaces.

You aren’t showing the setting for Python in your screenshot. Scroll the listbox in the Tab Settings groupbox down to where the python item is shown and make it active, and then post THAT screenshot. Only then will we know what the setting for Python files is.

When inserting a tab in an existing Python file, the editor does not respect the setting preference flag for converting tabs to spaces. That is, it always uses spaces whether “Replace by space” is checked or unchecked.
The line with 3 columns in the image has just had a tab inserted.

Obviously this is dreadful for Python. It means that misalignment of new code can only be corrected by turning everything into spaces (not desirable) via unindent/indent of blocks.

NB it works ok for a new file (prior to save).

I will install the latest version to see if it is better and update here as appropriate.

This issue seems to be present since 8.4.7 already, 8.4.6 is the last version that launches fine.

Could you help us to identify the problem please:
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/13074#issuecomment-1445398398

This was noted HERE as well.
Perhaps the SUPPORTED_SYSTEM.md file is in need of updating.

“The procedure entry point CoGetApartmentType could not be located in the dynamic link library ole32.dll.”

This issue seems to be present since 8.4.7 already, 8.4.6 is the last version that launches fine.

I did some tests and, indeed, the use of DirectWrite insrease rendering of characters !

I verified that, if the DirectWrite option is not checked, the four Unicode characters, provided by @register-noname, are properly displayed ONLY IF the current line contains a character with codepoint over the BMP, so with codepoint above FFFF !

Compare these two screen-shoots below :

WITHOUT Direct Write

And :

WITH Direct Write

Note, particularly, the differences in lines 1 , 2 , 15 and 16 ;-))

Best Regards,

guy038

🞂 ◷ ◴ ◵ ◶ - clock
◷ ◴ ◵ ◶ - clock

It appears that you want DirectWrite enabled; see Settings > Preferences > MISC. As the Preferences dialog says, turning it on “may improve rendering special characters”.

I confirmed in v8.4.9 with my settings, DirectWrite off will have display problems like you showed, whereas DirectWrite on will show all the characters correctly:

But the same has been true for many versions, not just v8.4.9, so this really should have been a separate topic, since it’s not specific to v8.4.9.

@donho: BTW, we frequently get questions here that are solved by DirectWrite being on. Is there a reason that we cannot have that setting enabled by default – that way, new users will just see Notepad++ work great with Unicode characters, rather than having to come complain about poor Unicode behavior and then be told that they need to change a setting. Let me know if you want me to create an issue.