original nedit behavior losses

[awaeag]

Hi,
I'm heavily using nedit for years. And I just tried this port.
I noticed 2 annoying things that are different from the original nedit (and should not in my opinion):

• when displaying the search (or replace) popup using CTRL+F or CTRL+R, the opened popup is displayed at a random place: on the original nedit, it was displayed right at the mouse pointer position, which was very convenient.
• when some text is selected on the original nedit, we can shift it to the right or the left using CTRL+9 or CTRL+0, and shift from the configured TAB value with CTRL+SHIFT+9 and CTRL+SHIFT+0. With this port, CTRL+9 and CTRL+0 just display the characters 9 and 0, and adding CTRL shifts only one character. I really miss the tab shift.

[eteran]

OK, I can look into these, but do have a question regarding the second:

What is your locale / platform? Because on a US keyboard in linux the shift by both tabs and spaces IS implemented. But on windows, it overlaps with another shortcut. Let me know.

[awaeag]

I'm on a debian stable (gnome desktop), and my keyboard mapping is French (AZERTY).

[eteran]

OK, I think the issue is the French keyboard mapping, and that maybe there's a conflict with a different key. One addition that I added was some zoom related shortcuts. I might need to gate those behind a setting because I'm guessing that they are conflicting for you. I can do that and get back to you and see if it helps. maybe tomorrow.

[awaeag]

great ! Thanks !

[eteran]

As for the first one, can you confirm, that the setting enabled that places popups under the cursor? It is found here:

EDIT: Worth noting that I just tested it and on Windows native the setting works, but if launched under WSL2 it does not work (and I think it's out of my control with WSL2)

[awaeag]

Sorry: I did not realize the option even existed. Yes, it works in my case.

[grege2]

Hi, this was useful, to remind me that the popup-under-cursor control existed, I had totally forgotten it. (I've been using X11 nedit on SGI boxes and now Nedit-ng on Mac since the mid 90's, but things you rarely use just get forgotten). Re the shifting of text left and right - I use this now and then - select a block of text with Command + sweep-out-a-block, and then Command+0 or Command+9 to shift one step, or Shift+Command+0/9 tp shift by several steps. My "several" is 3. I don't know where thet is coming from. Ciao, Greg.

…

On Thu, 25 Jun 2026 at 17:52, awaeag ***@***.***> wrote: Sorry: I did not realize the option even existed. Yes, it works in my case. — Reply to this email directly, view it on GitHub <#409?email_source=notifications&email_token=AH66LHH3TEOEHQCWRTIHT535BTK3JA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZUGMYDOMRUUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FMMZXW65DFOJPWG3DJMNVQ#discussioncomment-17430724>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AH66LHF7O54PA4B2NAHWSZL5BTK3JAVCNFSNUABHKJSXA33TNF2G64TZHM2DINBUG43TMNB3IRUXGY3VONZWS33OHMYTAMZQGEYTENVBOYBA> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AH66LHA7VETZKMLWTLSAWDD5BTK3JA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZUGMYDOMRUUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FKMZXW65DFOJPWS33T> and Android <https://github.com/notifications/mobile/android/AH66LHG6JSSS6TI5PCDKTUT5BTK3JA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZUGMYDOMRUUZZGKYLTN5XKU43VMJZWG4TJMJSWJJLFOZSW45FOMZXW65DFOJPWC3TEOJXWSZA>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- *Greg Edwards*

[eteran]

@grege2 The "several" should be whatever the size of your tab is configured to be :-).

@awaeag I haven't forgotten about you! I'm looking into the Ctrl+Shift+0 issue.

So looking at my added "zoom" mappings, they are Ctrl+Equals and Ctrl+Minus (equals is the same key as Plus for US keyboards). I don't THINK that this should be conflicting. Right now, this is the code that I use to attach the shortcuts for shifting left/right by tabs:

	CreateShortcut(QKeySequence(Qt::CTRL | Qt::SHIFT | Qt::Key_9), this, [this]() { action_Shift_Left_Tabs(); });
	CreateShortcut(QKeySequence(Qt::CTRL | Qt::SHIFT | Qt::Key_0), this, [this]() { action_Shift_Right_Tabs(); });

Which of course seems pretty straight forwards. So my question is, in AZERTY, What would "Shift+0" normally be? Google says it's just 0. Which is interesting. This may end up being a bit more complicated than I had thought because from what I can tell, when you hit "Shift+0" on an AZERTY keyboard, Qt is delivering that message as just "Qt::Key_0" (no CTRL) because that's the "effective key" being pressed.

The ultimate solution is of course for me to (finally) allow custom shortcut definitions, but I haven't thought of a great way to handle the "shift variants" because there is nuance regarding displaying the "[SHIFT]" hint in the menus. There's no really a good way to guarantee that the pairs of operations that are chosen via the addition of shift are even related if users can set things to anything.

I'm guessing that all of the Ctrl+[number] are not quite right for your setup :-/. I actually think that SOME of this can be handled via localization if you're feeling up to helping out :-). (Basically the shortcuts in the .ui files are defined via strings, and those can be altered by the locale).

[eteran]

@awaeag OH! Here's an experiemnt you can do to help me:

Open the macro menu as shown in this screenshot:

Pick any macro and the put the focus on the accelerator field here:

Then do the following:

1. Click the circle "x" to clear the accelerator if any:
2. Use your keyboard to do the key sequence you expect for shift right by tabs "Ctrl+Shift+0" and then see what appears in the box. Whatever it is, that is what Qt is seeing when you type those keys.
3. If you can, repeat for all of these and let me know what they each report:

• Ctrl+1
• Ctrl+2
• Ctrl+6
• Ctrl+9
• Ctrl+0
• Ctrl+Shift+1
• Ctrl+Shift+2
• Ctrl+Shift+6
• Ctrl+Shift+9
• Ctrl+Shift+0

As those are all of the shortcuts that are being used which involve the number keys (which are the ones which would be problematic).

If you can do this, it would help a ton!

[awaeag]

Ok. Please note that the regular numbers are gotten using the shift key on the French keyboard mapping. For example, the '1' character on the US keyboard mapping is obtained by hitting the '1' key without any other. On the French mapping, this key displays a '&' character. For displaying a '1', we must hold the SHIFT key.
That said, this is what your test gave:
Ctrl+1 => Ctrl+&
Ctrl+2 => Ctrl+É
Ctrl+6 => Ctrl+-
Ctrl+9 => Ctrl+Ç
Ctrl+0 => Ctrl+À
Ctrl+Shift+1 => Ctrl+Shift+1
Ctrl+Shift+2 => Ctrl+Shift+2
Ctrl+Shift+6 => Ctrl+Shift+6
Ctrl+Shift+9 => Ctrl+Shift+9
Ctrl+Shift+0 => Ctrl+Shift+0

[eteran]

Very interesting and useful results! So it actually reported "Ctrl+Shift+0" even though that is functionally doing a 0 key plus a Ctrl (because Shift+0 is how you type the digit 0). That's unexpected!

[eteran]

Also with this, I would have expected that the shift by tabs would work and that the shift by spaces would not... So it's a bit confusing! I would have expected the second half to look like this:

Ctrl+Shift+1 => Ctrl+1
Ctrl+Shift+2 => Ctrl+2
Ctrl+Shift+6 => Ctrl+6
Ctrl+Shift+9 => Ctrl+9
Ctrl+Shift+0 => Ctrl+0

But I suppose it still sees that Shift was pressed...

This is gonna make it complicated to work out.