[FORK] How to get Alt-0### codes to work for newlines and similar

M Andre Z Eckenrode

@guy038
@PeterJones
(…and all other interested parties)

For what it’s worth, I’m using NPP v8.8.3 32-bit installed under Windows 10 Pro, and I am able to enter all of the respective characters using the Alt+nnn codes mentioned here, EXCEPT that I don’t have HKEY_CURRENT_USER\Control Panel\Input Method > EnableHexNumpad set to 1.

Coises

@guy038 said in Notepad++ v8.8.4 Release Candidate:

Hello, @donho and all,

In the 8.8.3 and 8.8.4 releases, there’s a bug when you want to change any EOL characters into a LF character or into a CR character, using the process :

Hold down the Alt key

Type, either, on the numeric keypad, successively, on the 0, 1 and 0 keys OR on the 0, 1 and 3 keys

Release the Alt key

=> Nothing happens ??

However, if you click, for example, on the LF or CR zones of the Character Panel, it does modify the end of line as expected !

Note that it does not depends on the appearance of the EOL chars ( Default or Custom Color )

I did not verify with the 8.8.2 release, but I’m certain that results are OK till the 8.8.1 N++ version, included !

Can anyone confirm this bug ?

Best Regards,

guy038

BTW, it seems that any char from \x01 to \x1F is ignored and cannot be written with the process described above !

I can confirm that it happens if — and only if — the setting at Settings | Preferences… | Editing 2: Prevent control character (C0) typing into document is checked, which I would not call a bug.

PeterJones

@Coises said in Notepad++ v8.8.4 Release Candidate:

I would not call a bug

Indeed, it’s been a feature since v8.6.5. Sorry for not remembering that in my first reply to @guy038.

guy038

Hi, @peterjones, @coises and All,

First, I suppose it would be best to move all this discussion, from my first post, in an other location : the discussion part, for example, until things are clarified !

Secondly, as within your laptop, I have the EnableHexNumpad value set to 1 :

Thirdly, my 8.8.1 version, used on my W10 64 bits laptop, is the pre-version npp.8.8.1.portable.x64_RC2.7z. Thus, it’s quite possible that some results are not accurate ! As I also have a true 8.7.6 version ( npp.8.7.6.portable.x64.7z ), I verified that everything is allright with that 8.7.6 version. This means that :

With the 8.7.6, 64 bits version :
- ALT + + ( on NumPad ) + successively, on Numpad , 0 , 0 , 1 , F inserts the US character
- ALT + successively, on Numpad , 0 , 3 , 1 inserts the US character, too ( No hit on the + Numpad key )
- ALT + + ( on NumPad ) + successively, on Numpad , [ 0 ] , 1 , 1 , B inserts the ě character
Whereas, with the 8.8.3, 64 bits OR the 8.8.4, 64 bits version :
- ALT + + ( on NumPad ) + successively, on Numpad , 0 , 0 , 1 , F does NOT insert the US character
- ALT + successively, on Numpad , 0 , 3 , 1 does NOT insert the US character, too ( No hit on the + Numpad key )
- However, ALT + + ( on NumPad ) + successively, on Numpad , [ 0 ] , 1 , 1 , B DO insert the ě character : I suppose that because it’s a character over \x1F

Oh…, I’ve just seen the @coises’s answer which, in addition, is quite logical as it prevents for writing any C0 code !! Bravo, @coises : I would never thought about that Preferences option witch is quite clear and means that there’s no bug at all… Sorry for all that noise !

And, indeed, I verified that :

In my v8.7.6 version, the Prevent control character (C0) typing into document option is unchecked
In my v8.8.3 and 8.8.4 versions, this setting is set !

Best Regards,

guy038

PeterJones

@guy038 said in [FORK] How to get Alt-0### codes to work for newlines and similar:

First, I suppose it would be best to move all this discussion, from my first post, in an other location

I concur. Since it ended up not being a regression, I forked the 8 posts related to the Alt+0### codes to a new Help Wanted discussion.

xomx

@PeterJones said in [FORK] How to get Alt-0### codes to work for newlines and similar:

Indeed, it’s been a feature since v8.6.5

@guy038 said in [FORK] How to get Alt-0### codes to work for newlines and similar:

In my v8.7.6 version, the Prevent control character (C0) typing into document option is unchecked

In my v8.8.3 and 8.8.4 versions, this setting is set !

It’s true that the feature is there from the v8.6.5+ but until the v8.8 there was a bug preventing it to be ON by default as intended: v8.8 - 17.

Coises

Since the motivation for this feature was accidentally typing an invisible (depending on View settings) character:

https://community.notepad-plus-plus.org/topic/25498/notepad-enters-unwanted-invisible-ascii-0-31-characters

one could argue that this feature is poorly implemented. Alt+numpad is clearly not accidental. There is no reason — from a user’s point of view — that it should be blocked just because that user has chosen to block Ctrl+ combinations that aren’t defined shortcut keys from generating ASCII control characters.

There might be a reason it would be very difficult to implement this distinction, though; I have not looked into it. Nonetheless, if this bothers you, it seems it would be appropriate as a feature request to block only Ctrl+ combinations and not the almost certainly intentional Alt+numpad codes.

PeterJones

@Coises said in [FORK] How to get Alt-0### codes to work for newlines and similar:

There might be a reason it would be very difficult to implement this distinction, though; I have not looked into it.

I haven’t looked into it, either. But given that it’s a feature of the OS, my initial guess is that Windows only sends the actual character, not the individual keystrokes, to the application. Or, at least, the app would have to go to extra effort to extract the individual keystrokes rather than just receiving the plain text that’s generated as the result of the OS feature.

I personally don’t see a big enough benefit to distinguishing Alt+### from Ctrl+<key> . I am doubtful that there are really a significant number of users who both (1) accidentally type Ctrl+<non-mapped-shortcut> enough that it bothers them but (2) also wants to intentionally add C0 characters using Alt+0##; and without a significant base, I wouldn’t want the effort spent on that “fix”, when there are so many more important bugs and feature requests available to be fixed.

guy038

@peterjones, @m-andre-z-eckenrode, @xomx, @coises and All,

Peter I agree that the benefit of writing the C0 codes with the Alt + nnn method seems not obvious for most of them compared to the Ctrl + Letter solution.

However, for example, in the case of the line-break chars LF or CR, the Ctrl + Letter solution cannot be applied because :

Ctrl + J is devoted to the Edit > Line Operations > Join lines option
Ctrl + M is devoted to the Search > Mark... option

But, with Nicrosoft notepad, I’ve just verified that the two solutions can be either used, if you want to split a single line in two parts :

Ctrl + J or Alt + 010 on the numeric keypad for the LF character
Ctrl + M or Alt + 013 on the numeric keypad for the CR character

BR

guy038

PeterJones

@guy038 ,

I think you missed my point.

My point was not, “you can enter C0 using Ctrl+<key>, so there’s no need/benefit to be able to also enter C0 using Alt+0###”. My point is, all you have to do to be able to get Alt+0### access for C0 codes is to turn off the option named “prevent control character (C0 code) typing into document”: if you have things set up in a way that you want to be able to enter control codes, then you are the kind of user who probably doesn’t need the accidental-Ctrl+combo “protection” that enabling that option provides.

Making the developers try to intercept the keystrokes before Windows turns the keystrokes from multiple presses into sending a single character to the app, just because you aren’t willing to turn off the anti-C0-“protection” seems the wrong way around. N++ already provides the option that allows you to enable typing C0 codes, whether by Ctrl+<unmapped> or by Alt+0### for C0 codes, so if you want to enter C0 codes, then set the option appropriately.

solution cannot be applied because :

Or, I would say, the “solution cannot be applied without unmapping pre-defined shortcuts, which is simple to do using Shortcut mapper”. (Or, I would say that, if that were a “solution” I were recommending; but it wasn’t.)

Enabling vs disabling of features always come with tradeoffs, and power users of Notepad++ make those tradeoffs every day.

Maybe I’ll put it this way: the option is literally named “prevent control character (C0 code) typing into document”. If you want to be able to type control characters (C0 codes) into the document, you obviously have to turn off that option. This seems highly reasonable to me.