notepad.getFiles() should only return REAL tab file data

[sasumner]

notepad.getFiles() will often return a "new _" file (where _ is a number) even though I can see no "new _" files in my set of N++ editor tabs. Can this be changed to only show real tab files that the user can see?

Are you talking about the hidden view issue only or did you discover that you get newX files reported
in active view as well? Basically are you looking for something like this

if notepad.isSingleView():
    view = notepad.getCurrentView()
    print '\n'.join([x[0] for x in notepad.getFiles() if x[3] == view])

[sasumner]

TBH I just did a quick test to refresh my memory (noticed this a long time ago) because someone else asked me about it yesterday. Thus I only noticed an orphan "new" file in the hidden secondary view in the data returned from the function. Sure the snippet of code makes sense, but it seems like getFiles() could just not return a "new" file I can't see...or is that unreasonable?

No, absolutely valid just wanted to make sure that you haven't discovered a new situation
where npp returns files which, from users point of view, aren't there.

[sasumner]

Just a side note that N++'s own "Doc Switcher" aka "Document List Panel" also exhibits this same behavior and puts a "new 1" file in its list. The proper place to address this is extremely likely to be in Notepad++ itself (with NPPM_GETNBOPENFILES), but...

This is an npp issue as the list of files, which is used by PS, is returned by npp but the hack would be,
better I hope is, minimal to get the desired behavior.

[chcg]

@ClaudiaFrank If the hack doesn't break anything else seems reasonable. Anyhow we should find the root cause in N++ I think. Is the issue happening with latest N++ 7.5.8?

[sasumner]

Is the issue happening with latest N++ 7.5.8?

Yes.

[chcg]

@sasumner Thanks.

indeed the N++ behaviour here is strange:

Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:30:26) [MSC v.1500 64 bit (AMD64)]
Initialisation took 1000ms
Ready.
>>> notepad.getFiles()
[('new 1', 1604584428672L, 0, 0), ('new 1', 1604586989344L, 0, 1)]
>>> notepad.getFiles() 
[('new 1', 1604584428672L, 0, 0), ('new 3', 1604622409456L, 1, 0), ('new 1', 1604586989344L, 0, 1)]

Starting with a new instance of N++. Creating a new file the is 'new 3' instead of 'new 2'. The internal document counting seems to be 'interesting'.

[sasumner]

@chcg The more I think about it the more the correction belongs to Notepad++...but sort of back to the constant problem: would we ever see that change implemented there...of course, maybe a change in PS could be a sort of "double-check" on N++'s return data, and if just happened to find an error it could correct it. :)

Propose the following changes to https://github.com/bruderstein/PythonScript/blob/master/PythonScript/src/NotepadPlusWrapper.cpp#L278

boost::python::list NotepadPlusWrapper::getFiles()
{
	idx_t count;
	intptr_t bufferID;

	boost::python::list files;

	int view = 0;
	bool onlyOneView = isSingleView();
	if (onlyOneView) { view = getCurrentView(); }
	int view_end = onlyOneView ? view : 1;
			
	for(view; view <= view_end; view++)

results in

>>> notepad.getFiles()  # only one file open
[('new 1', 42924784, 0, 0)]

>>> notepad.getFiles() # second file open
[('new 1', 42924784, 0, 0), ('new 3', 63345072, 1, 0)]

>>> notepad.getFiles() # second file moved to second view
[('new 1', 42924784, 0, 0), ('new 3', 63345072, 0, 1)]

>>> notepad.getFiles() # first file closed
[('new 3', 63345072, 0, 1)]