@guy038 said in Columns++ version 1.3: All Unicode, all the time:

Note that the \p{Hex_Digit} regex is erroneous ! The right one is \p{xdigit}, at least, within Columns++

What’s going on there is that I followed the structure of Boost::regex character classes:

Character Classes that are Always Supported

Character classes that are supported by Unicode Regular Expressions

which are mainly the POSIX character classes plus Unicode General Categories interpreted as character classes. Also, note that in Boost::regex, character classes and character properties are the same thing. I didn’t make any attempt to change that. I believe this is different both from Unicode regular expressions and from PCRE.

(I did add a couple new character classes unique to Columns++: [:defined:] and [:invalid:], and aliases \i, \o and \y for [:invalid:], [:ASCII:] and [:defined:]. Also, Columns++ does not support [:Cs:]/[:Surrogate:] since Unicode in Scintilla can only be UTF-8, which cannot contain surrogates — though it can contain invalid byte sequences which appear to encode surrogates, as in WTF-8; Scintilla treats these as invalid UTF-8 bytes, and so does Columns++.)

Hex_Digit isn’t one of the Boost::regex character classes, and I never defined it. Defining it to be equivalent to xdigit would be trivial; re-defining xdigit to include non-ASCII characters is a bit more complicated:

I’ve found out a small anomaly concerning hexadecimal characters :

If I use the native Notepad++ search to match any hexadecimal character, with the regex [[:xdigit:]], against my Total_Chars.txt file, it returns 44 matches

If I use the Columns++ search to match any hexadecimal character, with the regex [[:xdigit:]], against my Total_Chars.txt file, it returns 22 matches

I suppose that the N++ answer is the right one. Indeed, in the https://www.unicode.org/reports/tr18/#Compatibility_Properties article , ( Annexe C about UNICODE REGULAR EXPRESSIONS ), it is said :

Hex_Digit contains 0-9 A-F fullwidth and halfwidth, upper and lowercase

Yes, it would seem the standard is to include those non-ASCII characters as hex digits. Further, the comments at your link under lower and upper are troublesome, as Columns++ treats them as aliases for Ll and Lu. Word and word boundaries are probably faulty as well.

I followed the Boost::regex principle that to extend the traditional POSIX mappings, the only Unicode property that is used to determine membership in a character class is the General Category.

I hard-coded (that is, they are written explicitly rather than being derived from Unicode tables) the POSIX mappings for ASCII characters, since that’s the only place they are really well-defined; plus there is a hard-coded exception for the non-ASCII character U+0085, the Next Line control character, because it should be part of \v, which is implemented in Boost::regex as [[:v:]]. I don’t see any reason [[:xdigit:]] can’t be extended with similar hard-coded logic; I just didn’t know until now that I should do it.

The other parts, though: whatever they are saying is supposed to be included in [:lower:] and [:upper:] besides letters, and whatever they are talking about in regard to word characters and boundaries… that might be problematic. I have a condensed set of tables built from a few Unicode files, instead of trying to import the ghastly large and complex ICU. Those tables include the General Category, but if that is not enough to determine membership in a character class… reorganizing them to include whatever additional information I need (it’s not yet clear to me what that will be) is not likely to be simple.

Thank you for your observation. Indeed, there are flaws. It is not yet clear to me if and how it will be practical to address them, though I can probably fix the [:xdigit:] behavior without much difficulty.

@Javier-Utrilla said in show the current zoom:

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

@Ivo-Krab said in Support for Plugins Admin & NppPluginList:

but modifying the C:\Program Files\Notepad++\plugins is understandably blocked without admin access.

Would it not be possible to allow (as a config choice) to install them in %APPDATA%\Notepad++ instead

The problem is that plugins in Notepad++ can do anything Notepad++ itself could do. They are C++ programs operating in the same security context as Notepad++ itself. From a security standpoint, allowing plugins in a directory that can be modified without admin access would be equivalent to allowing access to Program Files without admin access.

As I recall, that was allowed at one time, and this is why it was removed. Security-sensitive organizations determined that they could not install Notepad++ at all unless they could stop users from installing their own plugins. The developer decided it was better to remove the capacity entirely than to try to implement a switch of some kind.

The work-around, if you can run programs that are not installed in Program Files, is to use a portable copy of Notepad++. If you are not allowed to do that, then logically you would be forbidden to run Notepad++ plugins in a directory you control, since it would grant you exactly the same access.

@D-Kirkpatrick ,

I know the “Shortcuts” XML is the file to edit and that there is also a copy of that in %appdata% but so far I cannot put in my changes.

v8.9 still works with all my saved Run menu commands in %AppData%\Notepad++\shortcuts.xml, and I can still edit that file following the standard instructions for editing a Notepad++ config file found in the user manual

If you look at the shortcuts.xml file’s properties in Windows Explorer, do you have write permission to the file (you should, and you need it)

If that’s not it, you’ll have to say the exact steps you are using that aren’t working (and share your ?-menu’s Debug Info), otherwise it’s really hard for us to guess what’s going wrong for you.

I’d also like to add in MS Edge

No need: View > View Current File in > Edge has existed for years.

@xMRi

As far as I know, no. Npp explicitly checks this and throws an exception if no function is defined. So I would say, use an “About” menu item.

Updated linter++ to v1.0.2

This has mostly been concerned with changes to the dockable window with the results:

You can click on a column header to sort by that column You can drag the column headers to reorder the columns You can configure the font used for display

There’ve also been a few other minor improvements/fixes - see the Changes.md file

Downloadable from https://github.com/ThosRTanner/notepad-pp-linter/releases if you can’t wait for the plugin list to be updated.

@donho said in v8.8.9 and ConfigUpdater plugin:

@PeterJones

It’s already fixed in the GitHub, but I didn’t make the plugin list cutoff deadline.

Are you talking about it?
https://github.com/notepad-plus-plus/nppPluginList/pull/999

It’s in the current PluginList in RC normally.

I ran:

Plugins > ConfigUpdater > Reset Validators Plugins > ConfigUpdater > Update Config Files

The open tab with ConfigUpdater.log no longer shows any errors

@h-jangra

It could be, yes, because I downloaded it and ran setup_arm64.bat in a normal cmd shell, and it worked.
But it could also be due to how you originally set up Rust. I also played around with this a bit, but couldn’t reproduce your problem.
I had MSVC installed via the Visual Studio installer, and then I installed the Rust toolchain. Some weeks later I add the arm extensions for VS and added the target to Rust, and it works for me.

@Ekopalypse I tried simple plugin now using go. It did worked, let see if I can improve. If its good then I should make template for it.

@h-jangra

I doubt that you can implement this in Scintilla in a reasonable way, but the other idea of having a preview is there, and there are at least two plugins, here and here that can give you some ideas.

after a look at jn-npp-plugin on github it seems Win32 API is not available in win x64 and i didn’t find other way to use openfiledialog…
i am looking at python plugin now .

thanks for your help

The following code supports PythonScript 3.0.23 as well as earlier versions of PythonScript 3.x.

#------------------------------------------------------------------------ # If the character specified in the current selection is a white space, # then prompt the user to enter the alignment character (or characters), # using this character as the initial default. #------------------------------------------------------------------------ default_align_char = ',' from enum import Enum class PaddingSide(Enum): LEFT = 0 RIGHT = 1 def align_selected_text(max_align_char_count = None, padding_side = PaddingSide.LEFT): """Insert padding into the lines in the selection, as needed, to align up to max_align_char_count instances of a specific character or string of characters The default is to align all instances of the specific character. At present, the alignment character is taken as the character at the top of the current selection. You can uncomment some code below to change this policy to instead take the alignment character from within the selection at whichever end has the cursor. Either way, if that character is white space, the user is prompted to type the character (or characters). If you really wish to align on a white space character, you can just click OK at the prompt. When prompted to type the alignment character, the user may enter a sequence of characters, e.g., "-->", in which case the alignment is on the instances of that entire character sequence. For example, if the user enters "-->" at the prompt, then instances of the "-" character get aligned only if they're followed immediately by the characters "->", while instances of, say, "-1" and "- " remain unaltered. If there is no current selection, then aligns all lines in the editor. If there is a current selection, then aligns only the lines that are at least partially included in the selection, and the selection is changed to the entire block of newly-padded lines. Parameters ---------- max_align_char_count : positive integer, optional The maximum number of instances to align of the specific character. For example, set to 1 to align only the first instance of the character on each line. The default is to align all instances of the specific character. """ from Npp import editor #---------------------------------------------------------------------------- # For the alignment character, take the character just inside the bounds of # the selection block (at either the start or the end, as determined below). #---------------------------------------------------------------------------- editor.targetFromSelection() selected_text = editor.getTargetText() # Use this code to get the align_char unconditionally from the start # of the selection. align_char = selected_text[0] # Optionally use this code to get the align_char from within the selection # at whichever end has the cursor. # (startByte, endByte) = editor.getUserCharSelection() # if startByte == editor.getCurrentPos(): # align_char = selected_text[0] # else: # align_char = selected_text[-1] # If the character from the selection seems implausible as the # align_char, then prompt the user for it. if align_char.isspace(): from Npp import notepad global default_align_char align_char = notepad.prompt('Align character:', 'Enter Alignment Character', default_align_char) if align_char is not None: default_align_char = align_char #---------------------------------------------------------------------------- #%% Get the lines of text within the selected alignment block #---------------------------------------------------------------------------- (startLine, endLine) = editor.getUserLineSelection() startPos = editor.positionFromLine(startLine) endPos = editor.getLineEndPosition(endLine) text_lines = editor.getTextRangeFull(startPos, endPos).splitlines(True) #---------------------------------------------------------------------------- # Remember whether there is a user-selected block, so we can restore a # corresponding selection after aligning the text. #---------------------------------------------------------------------------- restore_selection = editor.getSelectionStart() != editor.getSelectionEnd() #---------------------------------------------------------------------------- # Align all instances of align_char within the lines of text #---------------------------------------------------------------------------- if align_char is not None: # Enable the following to save the align_char, however it was determined, # to be the default_align_char when prompting for it next time. # default_align_char = align_char padding_side_offset = padding_side.value * len(align_char) if max_align_char_count is None: align_char_count = max(line.count(align_char) for line in text_lines) else: align_char_count = max_align_char_count start = 0 for instance in range(align_char_count): # Set the target column using the index of the align_char, ignoring # immediately preceding space, or the length of the line tgt_char_col = max(len(line[:line.find(align_char, start)].rstrip()) for line in text_lines) for (idx,line) in enumerate(text_lines): align_char_col = line.find(align_char, start) if align_char_col >= 0: text_lines[idx] = line[:align_char_col+padding_side_offset].rstrip().ljust(tgt_char_col) \ + line[align_char_col+padding_side_offset:] start = tgt_char_col + len(align_char) editor.setTarget(startPos, endPos) editor.replaceTarget(''.join(text_lines)) if restore_selection: startPos = editor.positionFromLine(startLine) endPos = editor.getLineEndPosition(endLine) editor.setSelectionStart(startPos) editor.setSelectionEnd(endPos) if __name__ == '__main__': align_selected_text()