Notepad++ v8.4.9 Release

Mark Olson

@Ann-Witbrock
before:

use Edit->Blank Operations->TAB to SPACE

after:

Ann Witbrock

@Alan-Kilborn I’m sorry you are not making yourself at all clear.

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.

Alan Kilborn

@Ann-Witbrock said in Notepad++ v8.4.9 Release:

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).

Ann Witbrock

@Alan-Kilborn It’s OK I see it now, I was attempting setting the language in the main panel rather than the tab settings panel. I’m sorry. I’ve been using other editors more recently and missed the labelling. It’s really quite obvious ONCE YOU SEE IT!
And it does resolve my problem, indeed.

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.

Coises

@Ann-Witbrock said in Notepad++ v8.4.9 Release:

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?

rdipardo

@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

(*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'.

Coises

@rdipardo said in Notepad++ v8.4.9 Release:

@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.

Alan Kilborn

@Coises said in Notepad++ v8.4.9 Release:

…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?

PeterJones

@Coises,

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.

Coises

@Alan-Kilborn said in Notepad++ v8.4.9 Release:

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.

PeterJones

@Coises said in Notepad++ v8.4.9 Release:

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.)

Coises

@PeterJones Thanks, Peter. I seem to be a little slow in the uptake on this one. I appreciate your help and clarification.

rdipardo

@Coises, @Alan-Kilborn, @PeterJones

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.