NotePad++ Setup help needed (Masterfile)

[toralf]

I'm trying to switch from PSPad to Notepad++ v7.5.8 (32bit) for AutoHotkey 1.1.29.01 (32bit, Unicode).
But I have some issues to set up Notepad to have similar features like PSPad.

- How to specify a "master" script that gets executed/run on a hotkey even when another file from a project is currently shown (active file) in NPP

Are there NPP users out there that could assist with this issue?
Are there other ways with NPP to achieve a similar result?

What I still want to look into is:
extending Auto-Completion of whole commands and parameters
- Hotstrings by Helgef
- Inster AHK Command by Boiler
- a script i can't remember the name of by majkinetor

[toralf]

On these topics I was able to succeed on.

I was able to set up NPP for AHK
- Setup Notepad++ for AutoHotkey by jNizM (Syntaxhighlighting, Auto-Completion)
- Function list (modification of existing XML)
- Run Script or Selection
- MsgBox Creator by boiler

And to install and use these plugins
- Language help
- Code alignment
- Explorer
- Task List
- TextFX
- RunMe

These build-in features I found useful (so far)
- Project Management (build in function)
- toggle comment line (via shortcut)
- duplicate lines (via shortcut)
- move lines up/down (via shortcut)
- RunScript (via executable)

[toralf]

I got the DBGp plugin working (at least a Little)
This Video helped me to get startet.
The Problem I now have is that when I rund AHK NPP give me the error:

Code: Select all

List index out of bounds (0)

I ahve posted the error on NPP sites, hoping someone can help. Any idea what I could do until then?

For Running a AHK script with

Code: Select all

/ErrorStdOut

I plan on checking out NPPExec, it seems to be the right tool for it.

[toralf]

I found the reason for my issue with DBGp. I had a german AE = “Ä” in the path of the script. Without that character in the path DBGp works as expected.

An I also got NPPExec to do the Thing as I wanted. This Little NPPExec Script does the job

Code: Select all

// keep the Console window
NPP_CONSOLE ?

// disable any output to the Console
NPP_CONSOLE -  

// save current file
NPP_SAVE

// go to directory of the current file
cd $(CURRENT_DIRECTORY) 

// enable output to the Console
NPP_CONSOLE +  

// clear Console screen
CLS

// show Console window
NPP_CONSOLE 1

// run script with /ErrorStdOut
"C:\Path-To-AutoHotkey\AutoHotkey.exe" /ErrorStdOut "$(FULL_CURRENT_PATH)"

// disable any output to the Console
NPP_CONSOLE - 

// check exit code of the last executed child process
If $(EXITCODE) = 0 
	// when successfull hide console window
	NPP_CONSOLE 0 
ENDIF

And these two Highlighter in the Console Output Filters of NPPExec

Code: Select all

%ABSFILE% (%LINE%) : ==> *

     Specifically: *

(set Color and/or style to your liking)
Allow me to Highlight the code that might be wrong and to jump to the correct line in that file.

[Helgef]

Hi toralf.

I had a german AE = “Ä” in the path of the script.

I did some investigations, and it seems this is an error on the notepad++ plugin side, it sends utf-16 code %E4 for ä (in a path) to the debugger engine, which expects the utf-8 code %c3%a4. feature_get -n encode returns only UTF-8 so npp should adhere to that. Setting a breakpoint via breakpoint_set for %c3%a4.ahk (ä.ahk) works just fine (you can send your own commands from npp if you open the Raw DGBP dialog via the DBG button in the DGBp UI.).

I guess this would have been an annoying thing to debug, so perhaps if @lexikos can confirm the error being on the plugin side, a note in the docs could be added.

Cheers.

[lexikos]

The DBGp docs are very unclear about exactly what the encoding feature should affect. It seems the supports_encodings feature wasn't even documented until 2017. Is the plugin attempting to feature_set -n encoding or feature_get -n supported_encodings?

I'm not sure that it's valid to use UTF-16 in encoding. I don't know that it's really "a code set which contains ASCII", since it is fundamentally incompatible with ASCII (or just 8-bit strings?). The plugin obviously uses an 8-bit encoding when sending commands, including the one that contained a UTF-16 encoded percent escapes. That seems like an error regardless of encoding.

The encoding can either be (7-bit) ASCII, or a code set which contains ASCII (Ex: ISO-8859-X, UTF-8).
Source: Xdebug: Documentation - Protocol - DBGp

I'm not sure whether UTF-16 is even valid in a file URI.

All file paths passed between the IDE and debugger engine must be in the URI format specified by IETF RFC 1738 and 2396, and must be absolute paths.
Source: Xdebug: Documentation - Protocol - DBGp

2396 does not specify a charset,

An individual URI scheme may require a single charset, define a default charset, or provide a way to indicate the charset used.

I suppose that 1738 (Uniform Resource Locators) would be the individual URI scheme. It does not mention any specific charsets other than ASCII, or define any means of indicating the charset used. It refers to "octets" and "characters", but never specifies a relation between the two or in an way excludes 16-bit charsets, as far as I can tell. I think the document predates UTF-16, but not UCS-2.

Since it's not prohibited, I suppose it's technically valid.

[Helgef]

I'm AFK but as far as I remember it neither tries to set nor get the encoding, if I'm mistaken I'll return. Thanks for your answer.