Remove duplicate numerical lines
I get nervous about
editor.getCharacterPointer()because of my lack of full understanding about multibyte character encodings (as stated previously, I’m an A-Z person). I suppose, though, in this case we are talking about, there could be no issues…
not sure I understand your concerns about this.
I assume it is only the pointer to the text buffer returned and pythonscript
plugin has the python buffer protocol implemented so it should be safe always.
But as written, I assume - don’t really know how it is implemented.
So to revisit this:
if all open files were missing EOL, it would save all files, but only fix the EOL on the active file
I just re-tested after disabling my more-complicated script, restarting N++, and then activating my script as posted above. I created 3 new named files and make sure each had only a single line of text (only a 1 showing in the line-number margin–thus NO line-ending at end-of-buffer, or anywhere in the buffer for that matter). I activated a different file from these 3 and pressed the Save All toolbar button. Checking all 3 files in turn I found that all had a line 2 in the line number margin and this were all appropriately affected by my callback script.
Not sure why you would see different behavior. I’m running PS 126.96.36.199 and N++ 7.2.2, which for the latter, I’m confident you are not… ;-)
I’m in the same position as @PeterJones - only the current active file
does get the eol added.
I guess I will stop posting scripts now…let others do the heavy lifting. :-)
…unless and until I move to a newer N++…
No, no, no … don’t do that … forget all about I wrote :-)
It never happened - everything is good - bright nice day
and bugs are just animals :-)
To continue with the hijack-tangent of this thread… :-)
hahahaha, i like … word of the day: hijack-tangent ;-D 👍
it’s really refreshing, it is different to other bbs’es where this kind of thought exchange is and has to be done via the bbs’ chat and pm systems, often leaving a sterile one post product at the end without any leads how the author(s) got there.
i think this can be very useful to new interested users to get a better grip of how much time you really need to think about a seemingly simple task and/or consult with others to get a good or perfected result within a short period of time.
and i guess no one could come up with a good and plausible reason to mind about this kind of hijacking anyways.
especially because the op is probably happy since yesterday and the rest is a nice brain storming, coding, testing and sharing.
aaaaand … my post (this one) was the real hijacking … lol
PeterJones last edited by PeterJones
I’m on 7.5.8 32-bit, with PythonScript 188.8.131.52…
And now @Scott-Sumner has actually given me a valid reason to downvote him, because if he stops posting PythonScript, it will be up to me… and I just don’t have the py-knowledge to keep up for long. :-)
valid reason to downvote
First labeled a “retard”, then spanked vigorously by Don Ho in perhaps an interesting overreaction…and now downvoted by Peter… I’m super unpopular. :-(
don’t worry, you’re not … i’m currently googling for a specific helping hack:
nodebb plugin hack that downvotes from specific users triggers a double upvote
(alternative: hack that there are two upvote buttons left and right of the counter for specific user accounts)
also don’t worry, i’m currently googling for a specific helping hack:
nodebb browser hack that specific users, who refuse to post scripts, are unable to close the np++ browser window ever again
(alternative: they can close it, but as soon as they do, the same page will pop up on their cellular phones)
PeterJones last edited by
I’m super unpopular
… says the one who has 70% higher reputation than anyone else in these forums. :-) Fortunately, downvotes can be transitory: 'Twas done as a joke, referring back to the time that the interface made it look like I had downvoted Scott. But my real downvotes are reserved for egregious behavior – posting spam in the forums, primarily – so I removed this one.
And yes, it does seem to have been rather rough in the forums recently: gang up on Scott this week; last week, I got so frustrated due to a certain conversation that I was within moments of deciding to not bother reading/posting here; and, I’m sure Don hasn’t had the best time, with all the problems that showed up in the transition to 7.6. Hopefully, it will mellow out again soon.
Anyway, I learned a lot through all the code examples and the experiments they prompted. Thanks all.
transition to 7.6. Hopefully, it will mellow out again soon.
i think i’m afraid not.
there have been new complaints that, now that all plugins reside at a single, all users accessible location inside %programdata% as the active posters wished, others that were silent before want it either in a different location or the way it was in 7.6 … or the way it was in 7.5.9 … or inside of %programfiles%
This is where real life and software development goes hand in hand - you can’t make everyone happy.
gurikbal singh last edited by
not sure what to do!?? What about the uploaded zip?
gurikbal singh last edited by
zip file has contain a plugin for you
this plugin can remove duplicate lines
Thank you very much for your effort but I wasn’t asking for one,
I offered a possible solution by using the pythonscript plugin
but maybe @rizla-kostas, the original poster, finds this useful.
Alan Kilborn last edited by
I was looking at the EOL at EOF thing and I liked the scripts presented in regards to same. However, after the script is in place…what if I WANT to create a file without the final EOL, a very occasional need maybe?
So I came up with this few lines of code that can be inserted into the scripts, which will prevent the script from doing anything if the Alt key is held while a save is being done.
import ctypes VK_MENU = VK_ALT = 0x12 if ctypes.windll.user32.GetKeyState(VK_ALT) & 0x8000: return
In practice this only works when Save or SaveAll is done via toolbar button. :)
Eko palypse last edited by Eko palypse
I did some tests concerning the performance and memory usage about calculating whether the last line contains an eol or not.
I opened a ~600MB file and run the following script
from Npp import editor import time start = time.time() lastLineContainsEOL = True if len(editor.getLine(editor.getLineCount()-1)) == 0 else False end = time.time() - start print 'getLine:', end start = time.time() lastLineContainsEOL = True if editor.getText()[-1] in '\n\r' else False end = time.time() - start print 'getText:', end start = time.time() lastLineContainsEOL = True if editor.getCharacterPointer()[-1] in '\n\r' else False end = time.time() - start print 'getCharacterPointer:', end
which resulted in
getLine: 0.000999927520752 getText: 2.94100022316 getCharacterPointer: 0.641000032425
then I did the same test while watching the performance monitor and saw that
editor.getText()[-1] allocated an additional 600 MB whereas editor.getCharacterPointer()[-1] didn’t.
So, currently it seems that len(editor.getLine(editor.getLineCount()-1)) == 0 is the fastest and best on resources
whereas getCharacterPointer might be a fast way to access the buffer as long as you know what you are looking for.
PeterJones last edited by
I have sent a private apology to @Scott-Sumner, but I thought I should also make a public apology: downvotes aren’t something to joke with (or about), and my initial response (after I had seen it bothered him) was still couched in humor (and probably not very funny, at that), when it should not have had any attempts at justification or humor. I have been sorry for my poor choices on that day since I saw his response, and I have been saddened as he has stayed away for the last two weeks. I wish I knew how to make it up to him, but saying that I’m sorry is all that I know to do.
I highly respect Scott, and value his contributions to this forum. I hope he will come back and participate again.