something like U | Zoom +10

It’s fine…but why not make the abbreviated encoding MORE descriptive, and the zoom info LESS descriptive. E.g. (just my thinking): U8B |Z+10

# -*- coding: utf-8 -*-
from __future__ import print_function
from Npp import *

class ZoomInEncodingStatusBar(object):
    def __init__(self):
        editor.callback(self._on_zoom, [SCINTILLANOTIFICATION.ZOOM])
        editor.callback(self._on_updateui, [SCINTILLANOTIFICATION.UPDATEUI])
        notepad.callback(self._on_bufferactivated, [NOTIFICATION.BUFFERACTIVATED])
        notepad.callback(self._on_langchanged, [NOTIFICATION.LANGCHANGED])
        self.update()

    def _encoding_short(self):
        """
        Encoding abreviado:
        A   = ANSI
        U   = UTF-8
        UB  = UTF-8-BOM
        U2L = UCS-2 LE
        U2B = UCS-2 BE
        """
        try:
            e = int(notepad.getEncoding())
        except:
            return "?"

        enc_short = {
            0: "A",    # ANSI
            1: "UB",    # UTF-8-BOM
            2: "U2B",  # UCS-2 BE
            3: "U2L",  # UCS-2 LE
            4: "U",   # UTF-8
        }

        return enc_short.get(e, "?{}".format(e))

    def update(self):
        z = editor.getZoom()
        enc = self._encoding_short()
        txt = "{} | Zoom {:+}".format(enc, z)
        notepad.setStatusBar(STATUSBARSECTION.UNICODETYPE, txt)

    def _on_zoom(self, args): self.update()
    def _on_updateui(self, args): self.update()
    def _on_bufferactivated(self, args): self.update()
    def _on_langchanged(self, args): self.update()

# Forzar instancia nueva (importante)
zoom_enc_sb = ZoomInEncodingStatusBar()

you will that in the bottom bar where UTF-8 was located now it will show something like U | Zoom +10 .

It works for both views.
Hope it can help.

try to start a language-war with the proponents of Python

No saber-rattling detected…or intended with the following:

My history is Perl first, then Python – standalone, not PythonScript.
And both were for text processing type things; for other things I’ve always been a C/C++ person (mainly C).
The old command-line guy in me really liked Perl’s quirkiness, perhaps readers know what I mean … command.com’s interpreter really had/has a bunch of quirks.

However, as much as I liked Perl at the time, I found that if I “put it down” for a while, it was really hard to come back to it (due to ever-advancing age perhaps). With Python, I found it just sort of flows from the fingertips, so to say, and was easy to come back to after some time off. Aside from maintenance of some large scripts I wrote and still use, I haven’t done any new Perl in many years (perhaps a decade?).

I was rather pleased when I discovered Notepad++ and saw that its most popular scripting plugin was Python-based. (This might be the only sentence in the post that is on-topic).

But overall, I see no need for “language wars”.
I’m reminded of the quote from the Lord of the Rings (movies): “Go off and die in whatever manner most suits you” (or something like that).
In this case, “Go off and use whatever language most suits you, as long as it gets your job done”.

@mpheath said in show the current zoom:

I see here https://perl.fandom.com/wiki/TIMTOWTDI about “only one option for not equals operator”.

Ugh, that page does an awful job of describing the TIMTOWTDI philosophy – it makes it seem like it’s a petty reactionism to Python, but that philosophy was actually baked into Perl from the beginning, without any thought to Python (which was introduced a couple years after Perl was initially released). Given that it had two sentences about TIMTOWTDI, two sentences about how “unreadable” Perl is, and a whole paragraph describing Python as the antithesis, I get the feeling that the author of that article may have been a critic, not a fan, of Perl.

And I didn’t make either my original TIMTOWTDI comment, nor this response paragraph, to try to start a language-war with the proponents of Python. I personally use Perl more than I do Python (because PythonScript is my only use of Python, whereas I’ve been doing hobbiest projects in Perl since the 90s) – but it’s not because I think Perl is “better” than Python – they are different, and each have their pros and cons – it’s just that I’m more familiar and comfortable with Perl. I actually brought up TIMTOWTDI to say that I actually appreciate different perspectives and design choices in coding, and I usually learn something by seeing how someone else would approach a problem differently than I would.

I am sure there are others who would prefer Notepad++ to look like a cockpit of a 747 jumbo jet.

Such a statement always reminds me of this ISSUE, maybe because of this COMMENT from that issue. :-)

Apparently, I did not communicate very clearly, since you think that was what I was saying. Sorry.

My point about “clobbering” was the least important point in my message (and the point least supported by data)…

@Andi-Kiissel had only one name and yet was warned about clobbering. I tried for less as changing the name to _ was quite easy. Thanks for apologizing and clarifying your intentions.

I come from Perl’s TIMTOWTDI philosophy, so I very much encourage and appreciate different approaches. And I like your solution for avoiding the need for .hwnd – tracking the state, so you can tell which was changed and thus which to replicate to the other, is a great idea.

I see here https://perl.fandom.com/wiki/TIMTOWTDI about “only one option for not equals operator”. Well, Python 2 vs Python 3 compatiibility is usually more of a concern than the single != operator IMO.

I just wish PS3 would stop calling itself “alpha” and release to Plugins Admin, to make it easier for everyone to make that transition.

Absolutely. I cater for PS2 as it is the Plugin Admin default. The Plugin Admin could offer both versions to keep everyone happy. Python 2 is backwards for me as I started with early Python 3 and so I do minor hacks to make PS3 code work for the PS2 users.

@Alan-Kilborn said in show the current zoom:

But it is probably considered “extreme” to go to that length.

To be open minded about everything is to include the “extreme”. So thanks for the complement.

As for “show the current zoom”, I like the KISS concept. Too much stuff to view which can make you can miss what is important. I am sure there are others who would prefer Notepad++ to look like a cockpit of a 747 jumbo jet. I am usually busy doing something so viewing the zoom level is not a concern for me. Synchronizing zoom with 2 panes is a tedious task so I saw value with another script to choose from that might help.

I am posting a function so please do not clobber me for choosing a function.

Apparently, I did not communicate very clearly, since you think that was what I was saying. Sorry.

My point about “clobbering” was the least important point in my message (and the point least supported by data). It was meant more as an observational example of why one might wrap things in a class: but your reason (multiple functions) and Alan’s reason (templated code) are both better justifications for it than my <theThing>it’s not clobbering time</theThing> semi-reason. :-)

I come from Perl’s TIMTOWTDI philosophy, so I very much encourage and appreciate different approaches. And I like your solution for avoiding the need for .hwnd – tracking the state, so you can tell which was changed and thus which to replicate to the other, is a great idea.

and @Alan-Kilborn said,

I write exclusively in PS3 these days.

I just wish PS3 would stop calling itself “alpha” and release to Plugins Admin, to make it easier for everyone to make that transition.

I guess no names is the least to be clobbered.

But it is probably considered “extreme” to go to that length.
It isn’t a terrible thing to introduce one or two new names per script, if the names are reasonably unique (as mine tend to be).
Confession: My script directly above also introduces a user32 name. This is to support PythonScript v2, which, since I don’t use that, was a last minute add-on concession.

…and can be done without .hwnd so can be compatible with PythonScript 2 and PythonScript 3

I write exclusively in PS3 these days. Often I make the concession to publish a script so that it is compatible with both, but I don’t think in terms of “how do I make this the most efficient” in order to provide this support.

Probably, at some point, I will not bother to provide PS2 compatible code in scripts I publish.

Functions also can be suitable for this task as it is not that complex.

When I’m scripting, I don’t start out by judging: “Is this task complex enough to deserve a class wrapper?” or equivalently “Is this task simple enough to just be a function?”. As I have a script that generates a new script’s skeleton, I just go with it and everything gets a class.

I am posting a function so please do not clobber me for choosing a function.

Not clobbering, just commenting. :-)

Classes can have multiple methods which is why I consider that many users choose to use them. Functions also can be suitable for this task as it is not that complex. Functions can be as useful as classes and each has their role. So I am posting a function so please do not clobber me for choosing a function.

This function can sync the zoom levels and can be done without .hwnd so can be compatible with PythonScript 2 and PythonScript 3. Keeping track of the zoom levels and adjusting the levels is how it operates.

from Npp import editor, editor2, SCINTILLANOTIFICATION

def _():
    zoomLevels = [editor1.getZoom(), editor2.getZoom()]

    def zoomLevel(args):
        if editor1.getZoom() != zoomLevels[0]:
            level = editor1.getZoom()
            editor2.setZoom(level)
            zoomLevels[0] = level
        elif editor2.getZoom() != zoomLevels[1]:
            level = editor2.getZoom()
            editor1.setZoom(level)
            zoomLevels[1] = level

    return zoomLevel

editor.callback(_(), [SCINTILLANOTIFICATION.ZOOM])
del _

This is basically a nameless enclosure function as _ is usually treated as a temporary name. Enclosed to keep zoomLevels available to only the inner nested function zoomLevel. The _ name is deleted after registering the callback so the global namespace has no additional names. This code can be added to the startup script and that is what I would insert it as that is where I have tested it.

Your super-simple script assumes that the last tab you clicked in (editor) is the same editor you are zooming. But it is possible to click in View1 and zoom in View2, because it will zoom whichever tab the mouse pointer is hovering over when you use Ctrl+Scrollwheel, even if you haven’t clicked in that view

And because of that, Alan had to add some checks to see which view was actually being zoomed (not which has the last click), and that process is hampered by PythonScript 2 not including the .hwnd, whereas PythonScript 3 has the .hwnd already. (Update 3: … hence needing the ctypes and hwnd-grabber at the beginning)

And as we regulars often do, he wrapped it in a class, so that function and variable names in his script won’t clobber the function and variable names from other scripts.

Thus, as often happens: when you just try to “get it done”, it’s pretty simple and can be a few lines of code; but when you then try making it good enough for publishing, to cover edge cases, the code becomes more complicated. This Is The Way.

-—

Update 1: Yep, I just confirmed: when I ran your script, clicked in View1, and tried to scrollwheel-zoom while the mouse cursor was still over View1, it correctly zoomed both Views. But if I move the mouse cursor over view2 – without clicking, so view1 is still active – then when I try to scroll-zoom, view2 briefly shows up as zoomed, but then jumps back to no-zoom.

Update 2: Yep, when I instead run Alan’s, whether my scrollwheel-zoom is over view1 or view2, both views correctly scroll as expected

Here’s a script that will keep the zoom levels for both views the same.

These five rows in startup.py do the same thing for me:

def syncZoomLevel(args):
    level = editor.getZoom()
    editor1.setZoom(level)
    editor2.setZoom(level)
editor.callback(syncZoomLevel, [SCINTILLANOTIFICATION.ZOOM])

I was also considering the previously mentioned feature of allowing zoom to be synced between multiple tabs shown side-by-side. Side-by-side comparison views of multiple tabs is one scenario where I’d normally find myself wanting to “see” the zoom. I can usually sync up the zoom manually, but usually by overshooting the zoom in one of the tabs, then adjusting back to match the second tab.

Here’s a script that will keep the zoom levels for both views the same. I call the script ZoomLevelKeepBothViewsSynched.py.

# -*- coding: utf-8 -*-
from __future__ import print_function

#########################################
#
#  ZoomLevelKeepBothViewsSynched (ZLKBVS)
#
#########################################

# references:
#  https://community.notepad-plus-plus.org/topic/25844
#  for newbie info on PythonScripts, see https://community.notepad-plus-plus.org/topic/23039/faq-desk-how-to-install-and-run-a-script-in-pythonscript

#-------------------------------------------------------------------------------

from Npp import *

#-------------------------------------------------------------------------------

try:
    editor1.hwnd
except AttributeError:
    # running PS2
    import ctypes
    user32 = ctypes.WinDLL('user32')
    notepad.hwnd = user32.FindWindowW(u'Notepad++', None)
    editor1.hwnd = user32.FindWindowExW(notepad.hwnd, None, u'Scintilla', None)

assert editor1.hwnd

#-------------------------------------------------------------------------------

class ZLKBVS(object):

    def __init__(self):
        editor.callback(self.zoom_callback, [SCINTILLANOTIFICATION.ZOOM])
        self.zoom_callback( { 'hwndFrom' : editor } )

    def zoom_callback(self, args):
        if not notepad.isSingleView():
            other_editor = editor2 if args['hwndFrom'] == editor1.hwnd else editor1
            this_editor = editor2 if other_editor == editor1 else editor1
            other_editor.setZoom(this_editor.getZoom())

#-------------------------------------------------------------------------------

# to run via another file, e.g., (user) startup.py, put these lines (uncommented and unindented) in that file:
#  import ZoomLevelKeepBothViewsSynched
#  zlkbvs = ZoomLevelKeepBothViewsSynched.ZLKBVS()
# also note: need to make sure that "Initialisation" for "Python Script Configuration" is set to "ATSTARTUP" and not "LAZY".

if __name__ == '__main__':
    try:
        zlkbvs
    except NameError:
        zlkbvs = ZLKBVS()

you probably added it with the Customize Toolbar plugin

Oh lordy, you are correct. Sorry about that. I forgot that plugin came with toolbar buttons.

There are three zoom actions. There are only two zoom buttons on the default toolbar.

You can examine the Online User Manual’s list of all the toolbar buttons to confirm this

If you have a button on the toolbar for the restore-zoom, you probably added it with the Customize Toolbar plugin or another plugin.

there are currently two toolbar buttons dedicated to zoom

There are actually three buttons. Zoom in, zoom out, restore default zoom.

Another possibility would be to have a toolbar button that shows the current zoom then users can decide if they want to use it or not.

@mkupper said in show the current zoom:

However, for Notepad++ I have never need to know the zoom level as a number or percentage as I adjust the zoom until it looks good.

I was going to reply to @Snabel42 's comments with something like this.
The key takeaway: Knowing the zoom level number doesn’t do much for you, just adjust until the text looks “good” to you (whatever that means).

I was thinking the same thing. And I do agree that a lot of the time knowing the exact value probably is not necessary. Yet I somehow find myself wanting to see it. Maybe habit from it being such a common mechanism in many other applications I use?

I was also considering the previously mentioned feature of allowing zoom to be synced between multiple tabs shown side-by-side. Side-by-side comparison views of multiple tabs is one scenario where I’d normally find myself wanting to “see” the zoom. I can usually sync up the zoom manually, but usually by overshooting the zoom in one of the tabs, then adjusting back to match the second tab.

If syncing was a feature, I suppose seeing the actual zoom value/level would be needed even less. But then again seeing the zoom would perhaps let the user know if zoom-syncing was currently enabled or not for the two visible tabs.

However, for Notepad++ I have never need to know the zoom level as a number or percentage as I adjust the zoom until it looks good.

I was going to reply to @Snabel42 's comments with something like this.
The key takeaway: Knowing the zoom level number doesn’t do much for you, just adjust until the text looks “good” to you (whatever that means).

Here’s another point, when people are saying program X, Y and Z all have zoom in their status bar: I’d say that other programs use % values for this, and Notepad++ doesn’t provide a nice % value for the setting. So, if all the clamorers for this in the status bar get it, they’ll then start complaining that it isn’t showing a percentage.

OK, so just what are people zooming in/out for??
Do people not know how to set an appropriate (for them) font size?? And thus set-and-leave zoom level at zero? And thus, just forget about zoom level forevermore?

I zoom in, out, and reset several times a day. Sometimes I need to see the big picture and will zoom out. Other times I want to see a detail and so I zoom in. When dealing with code I like to be able to see the entire block or section I’m dealing with and will adjust the zoom as needed. I use both the mouse wheel and keyboard’s Ctrl+Num +-/ to zoom in/out/reset.

However, for Notepad++ I have never need to know the zoom level as a number or percentage as I adjust the zoom until it looks good.

Lately I have been troubleshooting a web site issue and have discovered that knowing the exact zoom level, or being able to set it to an exact number in Firefox is useful as I have been taking screen shots and then using them to show what has changed. 80% zoom happens to be the sweet spot.

However, I really don’t need to know that a number such as 80% is the sweet spot. For example, let’s say in Notepad++ I am taking advantage of page up/down to show different views or aspects of something. I flip up or down through the pages like a slide show. In that case there will be a zoom level that is the sweet spot for this particular file. All I’d do would be to add a note, Zoom +3 that reminds me that the desired sweet spot is achieved by resetting the zoom and then doing three up-ticks using Ctrl /+++.

• Different DPI and resolution on different monitors (application window currently being on different monitors
• Content of the current text (Source code vs long form text etc)
• My morning eyesight vs evening eye sight (mine changes due to tiredness)
• Whether I prefer wearing glasses or not (changes with eye straing, lighting conditions etc

I would personally much prefer zoom level being quickly visible in the status bar. rather than setting a font size and leaving it at that.

Regarding 228% screenshot: Way too much statusbar space wasted on a feature that is not very useful (IMO).

OK, so just what are people zooming in/out for??
Do people not know how to set an appropriate (for them) font size?? And thus set-and-leave zoom level at zero? And thus, just forget about zoom level forevermore?

I call the script ZoomLevelInZoomsViewMenuText.py:

# -*- coding: utf-8 -*-
from __future__ import print_function

#########################################
#
#  ZoomLevelInZoomsViewMenuText (ZLIZVMT)
#
#########################################

# references:
#  https://community.notepad-plus-plus.org/topic/25844/show-the-current-zoom
#  for newbie info on PythonScripts, see https://community.notepad-plus-plus.org/topic/23039/faq-desk-how-to-install-and-run-a-script-in-pythonscript

#-------------------------------------------------------------------------------

from Npp import *
import sys
from ctypes import ( addressof, byref, create_unicode_buffer, sizeof, Structure, WinDLL, )
from ctypes.wintypes import ( HBITMAP, HMENU, LPVOID, LPWSTR, UINT, )

#-------------------------------------------------------------------------------

python3 = True if sys.version_info.major == 3 else False

user32 = WinDLL('user32')

MIIM_ID = 2
MIIM_STRING = 64

class MENUITEMINFO(Structure):
    _fields_ = [
        ('cbSize', UINT),
        ('fMask',  UINT),
        ('fType',  UINT),
        ('fState',  UINT),
        ('wID',  UINT),
        ('hSubMenu',  HMENU),
        ('hbmpChecked',  HBITMAP),
        ('hbmpUnchecked', HBITMAP),
        ('dwItemData',  LPVOID),
        ('dwTypeData',  LPWSTR),
        ('cch',  UINT),
        ('hbmpItem',  HBITMAP),
    ]

#-------------------------------------------------------------------------------

class ZLIZVMT(object):

    def __init__(self):

        npp_main_menu = notepad.getMenuHandle(1)
        self.npp_view_menu = user32.GetSubMenu(npp_main_menu, 3)  # File=0, Edit=1, Search=2, View=3, etc. (assume these won't ever change)
        menu_items = user32.GetMenuItemCount(self.npp_view_menu)
        size_ub = 256
        ub = create_unicode_buffer(size_ub)
        self.mii = MENUITEMINFO()
        self.mii.cbSize = sizeof(self.mii)
        self.mii.fMask = MIIM_ID | MIIM_STRING
        self.mii.dwTypeData = addressof(ub)

        self.zoom_pos_on_parent_menu = None
        for pos in range(menu_items):
            self.mii.cch = size_ub
            user32.GetMenuItemInfoW(self.npp_view_menu, pos, True, byref(self.mii))
            if 'Zoom' in self.mii.dwTypeData:
                self.zoom_pos_on_parent_menu = pos
                break
        assert self.zoom_pos_on_parent_menu

        self.update_zooms_menu_text()  # put the current value in the menu item text

        editor.callback(self.zoom_callback, [SCINTILLANOTIFICATION.ZOOM])  # for when user switches zoom level
        notepad.callback(self.bufferactivated_callback, [NOTIFICATION.BUFFERACTIVATED])  # for when switching from view0 to view1 or vice versa

    def update_zooms_menu_text(self):
        text_to_set = 'Zoom (current level: {:+})'.format(editor.getZoom())
        self.mii.cch = len(text_to_set)
        self.mii.dwTypeData = text_to_set if python3 else unicode(text_to_set, 'utf-8')
        user32.SetMenuItemInfoW(self.npp_view_menu, self.zoom_pos_on_parent_menu, True, byref(self.mii))

    def zoom_callback(self, args): self.update_zooms_menu_text()

    def bufferactivated_callback(self, args):  self.update_zooms_menu_text()

#-------------------------------------------------------------------------------

# to run via another file, e.g., (user) startup.py, put these lines (uncommented and unindented) in that file:
#  import ZoomLevelInZoomsViewMenuText
#  zlizvmt = ZoomLevelInZoomsViewMenuText.ZLIZVMT()
# also note: need to make sure that "Initialisation" for "Python Script Configuration" is set to "ATSTARTUP" and not "LAZY".

if __name__ == '__main__':
    try:
        zlizvmt
    except NameError:
        zlizvmt = ZLIZVMT()

So, as mentioned in a previous post, you can quickly check the current zoom level by pressing Alt+v (to drop the View menu down) and then when you’re done, hit Esc to close the dropped menu.

I don’t strongly see a need for seeing the zoom level on the status bar. However, lots of tools – including the browsers that ArkadiuszMichalski had shown, or VS – do show it (some taking up more space than others), so I can see why some users have just grown to expect it to be always visible. If it were on the status bar, I’d vote for as small as possible (just enough room for up to 100% to show, no extra up/down controls); but if one of the alternatives were possible, I’d probably prefer any of those to taking up more SB space.

If it were doable, I like the thought of replacing the toolbar zoom buttons with a fancy zoom-control with display and + and - as part of a unified control – I especially like the firefox screenshot shown here (stolen from the issue). However, I have a feeling that’s harder to implement than a simple statusbar. But maybe as a compromise, if it’s easier, just change the zoom-toolbar tooltip to show the current zoom level when you hover over those icons, so you can know where it’s at before clicking to zoom in or out.

Changing the Zoom-menu-label is an interesting idea, though it might be surprising to users, since nothing else changes the menu text like that. I know some menu entries have the blue selection ball on the left, so I know icons go there; could there be icons for the -10 to +20 range (either numbers, or some fuel-gage-looking thing, or something), and just have the right icon selected for that menu entry? I don’t know whether that’s harder or easier or just “differenter” to implement.

But the more I think about it, the more I like @conky77’s idea of being able to sync the zoom between the two tabs – whether the scrolling is synced or not, any use case where I can think of wanting to zoom one View when two are visible, I cannot think of why I wouldn’t also want to zoom the second View at the same time. If that option existed, either as a toggle in the top-level View menu, or in the View > Zoom submenu, or even in the Preferences, I have a feeling I’d end up leaving it on all the time, just for the ease of zooming.

IMO, don’t waste the space to always show the zoom level.

I said this because most-everyone thinks it should be on the status bar.
I say, leave the status bar alone, it already has a lot of stuff on it – and the stuff there is “important”, much more so than a zoom-level that a user rarely changes.

OK, so what are some other options?

Well, there are currently two toolbar buttons dedicated to zoom – I forgot about that because why would anyone use them?: Ctrl+wheel does their functionality. Perhaps these two buttons could be replaced with a single control that would show the current zoom level (constantly) and also allow changing the value. One appeal of this is that no new screen space would be lost to something like this.

Another possibility would be to show the current zoom level on the View menu’s Zoom entry – instead of the text being Zoom >, it could be Zoom (current: +2) >. Sure, it isn’t constantly visible to a user this way, but it is only a single-keycombo press away.