Configuration Files

Configuration Files Location

In a standard installation, the per-user configuration files go in %AppData%\Notepad++\. (For a refresher course on %AppData%, see the Community Forum FAQ’s %AppData% entry.) The machine-wide configuration files go in the executable directory (so usually c:\program files\notepad++\). When Notepad++ is looking for shortcuts, stylers and themes, function list definitions, and user defined language definitions (and usually the default session file, though that has exceptions enumerated below), it will try to read from the per-user directory; if the right file isn’t found there, then it will check machine-wide configuration files.

In a portable installation, the configuration files all go in the same directory as the notepad++.exe executable (or the appropriate subdirectory), and there is no per-user configuration location. An installation is treated as “portable” if the zero-byte doLocalConf.xml file is present alongside the notepad++.exe executable (see also Undoing Portable, below). The ? menu’s Debug Info will show Local Conf mode: ON for a portable version.

If you enable the Cloud settings, some per-user configuration files will go in the defined directory, including contextMenu.xml, shortcuts.xml, userDefineLang.xml, langs.xml, stylers.xml, and config.xml; the themes\ subfolder will go in the cloud directory, and will start empty (when the cloud directory is first populated); the userDefineLang\ subfolder can be placed there as well, though it won’t be created by default when the Cloud settings folder is first populated. It should be emphasized that session.xml does not work in the cloud folder, so if you have the cloud settings, session.xml will still be found in either the %AppData% hierarchy for a normal installation, or in the installed directory for a portable installation.

There is a command-line option -settingsDir which will set a specific directory for the per-user configuration-files location. This folder allows all the configuration files metioned for cloud directory in the paragraph above; but, unlike the cloud directory, session.xml does work in the -settingsDir directory (so if you want to have all your per-user configuration, including your session information, in your cloud folder, it might be wise to not use the Cloud settings option, and instead point -settingsDir to the cloud folder).

Search order: If the -settingsDir option is set, that configuration file directory will take priority over any other configuration file directory. If the Cloud directory setting is defined and enabled, that will take priority over the portable or standard configuration file directory. If doLocalConf.xml is present, the portable configuration file location will take priority over the %AppData%\Notepad++\ directory. If none of the other configuration file directories are active, then the standard configuration file directory is %AppData%\Notepad++\. If it cannot find a configuration file in any of the per-user locations, it will use the version from the same directory as the executable.

Missing Subdirectories?

Reading the above section, one may go looking for the user functionList\ or themes\ folders in %AppData%\Notepad++\ (or your Cloud folder, or wherever -settingsDir option points) after an initial installation, and be surprised those directories aren’t there: the installer doesn’t create those empty directories for you. If you want to add a custom function list definition or theme to your user-config folder in the %AppData%\Notepad++ (or equivalent) hierarchy, you may have to create the appropriate subdirectory first, then put your custom function list or theme definition in the newly-created folder.

Starting Fresh

If you want to reset your Notepad++ back to “factory condition”, and are using the normal installation, you can exit all instances of Notepad++ then delete (or rename) the %AppData%\Notepad++ folder (or your Cloud folder, or wherever -settingsDir option points). The next time you run Notepad++, it will create %AppData%\Notepad++ (or Cloud or -settingsDir location) and populate it with a minimal set of config files.

If you just want to start fresh on a particular config file: Notepad++ knows how to recreate the necessary files if it doesn’t find them. For the ones that have an <XXX>.model.xml file in the Notepad++ application directory, all you have to do is delete your per-user <XXX>.xml (from %AppData%\Notepad++\ or the Cloud or -settingsDir location) and restart Notepad++, and Notepad++ will copy the <XXX>.model.xml version into the right place for you. If the config.xml or your session or shortcuts or contextMenu config files are intentionally deleted (or otherwise missing) from the config-file folder, Notepad++ can recreate those as necessary as well on its next start (it is programmed on how to create them from scratch, rather than using a .model. file – though Notepad++ will use config.model.xml instead of its internal defaults, if it exists).

Undoing Portable

Since doLocalConfig.xml being in the same directory as notepad++.exe will cause Notepad++ to use the config files in that directory (“portable mode”), deleting doLocalConfig.xml will stop Notepad++ from using the config files in the executable directory, and it will go back to looking for config files in the %AppData% hierarchy. (As with any change to an external config file in Notepad++, for it to take effect, you have to exit Notepad++ then restart the application for it to run in the new mode.)

When you delete doLocalConfig.xml, it will no longer look for config.xml, session.xml, and other such files in the application directory. If you want to clean up the application-directory version of unnecessary config files, those two are safe to delete. Also, stylers.xml and langs.xml are safe to delete from the application folder after leaving local-config mode; however, make sure you keep the stylers.model.xml and langs.model.xml, because those are the model files that are used to create the files in %AppData%. Before v8.9.3, it was recommended that you not delete shortcuts.xml or contextMenu.xml from the application directory, because those are used as the fallback/default version of those configurations if there is no version found in %AppData%, and it was thus best to always have a copy in the application directory; starting in v8.9.3, Notepad++ copies shortcuts.model.xml and contextMenu.model.xml into %AppData% if they exist, and falls back to creating shortcuts.xml and contextMenu.xml from scratch if the model files don’t exist. Please note: it is never required that you delete any of the files mentioned in this paragraph (except doLocalConfig.xml) to leave local-configuration / portable mode; when in normal mode, Notepad++ will use the copies in the %AppData% hierarchy and ignore the ones in the application directory; this section is just here to make it more clear what it’s safe to delete if you’re trying to save a handful of bytes after leaving portable mode.

Editing Configuration Files

ALWAYS BACKUP THE FILE TO BE EDITED. If you make a mistake, Notepad++ may erase the whole contents and replace it with useless defaults. This is probably the worst that can happen, but it does happen.

If changes are made in the Notepad++ UI to settings which are stored in configuration files, those will be written to disk when you exit Notepad++ after any file saves you do. Thus, if you are going to edit a Notepad++ configuration file with Notepad++ (and why would you want to edit it with anything else?), you will need to be careful. The safest sequence when editing a configuration file:

1. Close all active instances of Notepad++
2. Open one instance of Notepad++
3. Edit the configuration file
4. Save
5. Exit Notepad++
6. Reload Notepad++
7. The changes will now be in effect.

The config.xml file may be overwritten by Notepad++ on exit, even if you follow this procedure, so that sequence won’t reliably work for config.xml. To edit config.xml, close all instances of Notepad++; edit config.xml in some “other” editor and save; reload Notepad++ and the changes should take effect. (For the “other” editor, you could use something like Windows’ builtin notepad.exe. But it would be better if you had another portable Notepad++ somewhere on your machine, and use that portable Notepad++ to edit your main Notepad++'s config.xml, thus never having to use a non-Notepad++ editor: so close your main Notepad++, run the portable Notepad++ and open your main config.xml, edit and save, exit the portable Notepad++, then re-run the main Notepad++, and everything should be updated.)

Configuration File Encoding

The Notepad++ XML configuration files are expected to be in UTF-8 encoding (with no BOM), and so should use the prolog of <?xml version=“1.0” encoding=“UTF-8” ?>. If you use the BOM character at the beginning of a UTF-8 encoded XML file, or if you use another encoding like UTF-16, Notepad++ will not be able to read that configuration file.

Configuration Files during Upgrades

When you use the installer to upgrade your existing copy of Notepad++ (either manually, or through the ?-menu’s Upgrade Notepad++, or through Notepad++'s auto-update feature), the installer will avoid overwriting configuration files that you have customized – this is to prevent you losing your preferred settings and customizations.

However, this means that occasionally, updated functionList parsing files, or theme definitions, or new keywords in langs.xml, or new default contextMenu entries, or new shortcut entries might not be added to your local copy of Notepad++. So if you upgrade and keep your existing configuration, it is a good idea to occasionally compare your configuration files to the “standard/default” configuration files: some of the config files come with *.model.xml versions in the installation directory, which show you the default settings for those files; for other configuration files, you could download a portable zipfile of the same version you are using, and compare the config files from the portable to your installed; and you can always look in the source code repository for the various configuration files. (You can use two Views to look at the files side-by-side, and the synchronized scrolling feature can help keep the copies aligned; plugins such as the Compare plugin are designed to show differences between files as well.)

For the config.xml (which contains the settings from the GUI’s Settings > Preferences dialog), if Notepad++ has a setting that it doesn’t find defined in your current config.xml, it will apply the default value compiled in the program, and the next time it writes config.xml it will write that default value in config.xml. Once it gets written, future changes to that default value will not override the value already in your file, even when you upgrade Notepad++. config.xml will only get a default value for a setting in three situations:

1. On a new installation (running the installer when there isn’t a previous Notepad++, or when there isn’t a config.xml file and/or settings directory for the active user).
2. When you run Notepad++, and there is no config.xml (either because there isn’t a config.xml file and/or settings file for the current user, or the config.xml has been deleted), so Notepad++ writes a complete config.xml with all default values.
3. When your config.xml is missing the attribute/value pair for a given setting.

Specifics on Configuration Files

The context menu: contextMenu.xml

The context menu does not have a GUI-based editor; you just need to edit the file. As a result, the Settings > Edit Popup Context Menu entry exists to make it easy for you to access this config file.

All menu commands can be added to the Context Menu, including plugin commands:

• To add a built-in command, you may provide the main menu name (as it appears in the main menu bar) as the value of the MenuEntryName attribute and the command’s item name (as it appears in the menu) as the value of the MenuItemName attribute. The MenuEntryName attribute must reference an entry on the main menu bar and must be an ancestor of the MenuItemName attribute, regardless of its depth.
• For example, <Item MenuEntryName=“Edit” MenuItemName=“Cut”/> will add a context-menu entry that calls the Edit menu’s Cut entry.
• Alternately, to add a built-in command, you may instead provide the menu command ID via the id attribute. The command ID values for a given menu can be found in your localization file (like ), which will map the localized text you see in the menu to the command ID, or in .
• For example, <Item id=“42001”/> will add a context-menu entry that calls the Edit > Cut action by its command ID.
• NOTE: <Item id=“0”/> has a special meaning: it acts as a horizonal separator line – that’s how you can get a line between groups in the context menu.
• To add a plugin command, you need to provide the plugin’s menu item name (as it appears in the Plugins menu) as the value of the PluginEntryName attribute and the command’s menu item name (as it appears in the plugin’s sub-menu) as the value of the PluginCommandItemName attribute. (Note: Context menu entries will only work for entries immediately under the plugin name; entries deeper than that, like Plugins > Super Plugin Name > Submenu Here > I Want This Command, will not work.)
• For example: <Item PluginEntryName=“MIME Tools” PluginCommandItemName=“Base64 Encode” /> will add a context-menu entry that calls Plugins > MIME Tools > Base64 Encode

Note that the menu names and menu item names (whether built-in or plugin names) that you use in the should be in English, not in a translated language. The Shortcut Mapper can help you find the English name of plugin commands; simply switch to English localization for the raw name of built-in commands; or you can look at the that shipped with your distribution.

By default, each <Item> will be rendered in the top level of the context menu with a localized name matching the normal menu entry, unless overridden by the attributes described next.

If contextMenu.xml doesn’t exist in the user configuration folder, Notepad++ will copy contextMenu.model.xml from the installation folder (if it exists), or will fall back to creating a new default contextMenu.xml based on internal default values.

Grouping items into sub-menus

Each <Item> will go in the first level of the context menu. This can be overridden by adding a FolderName=“name_of_submenu” attribute to consecutive items, so that they will be grouped into a sub-menu with that name. Specifying “” is the same as leaving the FolderName attribute out. Note that sub-menus do not nest - you cannot add a sub-menu to a sub-menu. Non-Latin characters are supported.

Overriding a menu item name

Each <Item> will use the same text as the main menu entry uses, as defined by your current localization. This can be overridden by adding an ItemNameAs=“new_name_for_the_item” attribute, so that the new name will be displayed instead of the standard one. This is useful when the name is lengthy, as it makes the Context Menu unwieldy otherwise. Non-Latin characters are supported.

Context menu syntax summary

In brief, the structure of the context menu file is as follows

• Top Level Node: <NotepadPlus> (no attributes)
• Intermediate Node: <ScintillaContextMenu> (no attributes)
• Entry Nodes: <Item ...>
• MenuEntryName attribute: Used for accessing Notepad++ menu items by name. The value should be name of the menu.
• MenuItemName attribute: Used for accessing Notepad++ menu items by name. The value should be the name of the menu item inside the given menu.
• id attribute: Used for accessing Notepad++ commands by CommandID. The value should be the CommandID number, as seen in and similar translation files.
  • <Item id=“0” /> will make a separator line in the menu.
• ItemNameAs attribute: Used for for overriding a menu item name: using your own “display name” for a given entry in your context menu, instead of using the one inherited from the main Notepad++ menu system.
• PluginEntryName attribute: Used for accessing Plugin commands. The value should be the name of the plugin as seen in the Plugins menu.
• PluginCommandItemName attribute: Used for accessing Plugin commands. The value should be the name of the menu entry inside that Plugin’s menu. (Note: Context menu entries will only work for entries immediately under the plugin name; entries deeper than that, like Plugins > Super Plugin Name > Submenu Here > I Want This Command, will not work.)
• FolderName attribute: Used for grouping items into sub-menus in the context menu.
• TranslateID attribute: Used for auto-translating your sub-menu names. If the attribute’s value matches one of the nodes in the <MiscStrings> section of or similar translation files, the menu will use your active translation’s value for the displayed FolderName.
• As with all XML files, using <!-- and --> around the code will “comment it out”. So you can use text comments or comment out XML syntax that you want Notepad++ to ignore. To “uncomment” the XML, remove the <!-- and --> surrounding that piece of code.

The context menu: tabContextMenu.xml

The tab-bar context menu (the popup menu that you see when you right-click on the title of the tab in the tab bar) is user-configurable using the tabContextMenu.xml config file.

The format is the same as the contextMenu.xml described above, except the “Intermediate Node” is <TabContextMenu> instead of <ScintillaContextMenu>.

You may have gotten a copy of tabContextMenu_example.xml when you installed, or you can download a copy from the Notepad++ source here (possibly needed if you have a portable or minimal copy of Notepad++, or if the file didn’t get created when you updated an existing Notepad++ installation) – if you rename that example to tabContextMenu.xml in your configuration directory, and restart Notepad++, then the example will be used. In that example, the default replicates the structure released with v8.4.7; if you comment that out and uncomment the second half of the file, it will instead replicate the Tab Context Menu found in v8.4.6 and earlier (useful for those who like “the old way” of doing things in the tab context menu).

To go back to the default tab context menu, you can just rename or delete tabContextMenu.xml (or download the fresh copy and save it over the current tabContextMenu.xml) then restart Notepad++.

Keyboard shortcuts: shortcuts.xml

Defines keyboard shortcuts for various types of commands. The shortcuts are most-easily defined in the various tabs of the Settings > Shortcut Mapper.

This file has the following nodes:

1. <InternalCommands>: Keyboard shortcuts for Notepad++ menu commands that have been remapped by the user. (Commands that have never changed from their default shortcuts are not listed here.)
2. <Macros>: Keyboard shortcuts for the macros listed in the lower part of the Macro menu. Also defines what commands those macros execute.
3. <UserDefinedCommands>: Keyboard shortcuts for the Run menu entries. Also defines what actions those entries take.
4. <PluginCommands>: Keyboard shortcuts for plugin commands that have been remapped. (Commands that use their default shortcuts are not listed here.)
5. <ScintillaKeys>: Keyboard shortcuts for Scintilla commands, most of which relate to selecting text and moving around in the editor. (Commands that use their default shortcuts are not listed here.)

The definitions of the <Macros> and <UserDefinedCommands> are generally all that benefit from manual editing of the shortcuts.xml. It is much safer to edit the shortcuts using the Shortcut Mapper

If shortcuts.xml doesn’t exist in the user configuration folder, Notepad++ will copy shortcuts.model.xml from the installation folder (if it exists), or will fall back to creating a new default shortcuts.xml based on internal default values.

Virtual Key Number

All the types of commands in shortcuts.xml have a key attribute, which uses the Windows virtual key number as the value (Microsoft documentation on virtual keycodes can be found here). This keycode is not necessarily the same as the ASCII code or Unicode codepoint. In standard English locales, the virtual key usually lines up with the ASCII code for the character, but that is not universally true. The list of base virtual key codes that Notepad++ uses in the GUI for shortcut definitions can be found namedKeyArray[] in shortcut.cpp (you can see one snapshot – if you then switch from the branch to the master, you can look for the most recent version of that list). Notepad++ correctly polls the operating system’s keyboard settings when Notepad++ is run, and shows the correct keyboard character name for your keyboard, and will adjust the list to include extra keys from your keyboard for mapping, even if those keys aren’t on the standard US-english keyboard. Using keycodes that aren’t listed in the namedKeyArray[] is not recommended, as ones outside of that list might not work for you, or might work at first but be mangled by the GUI if you make use of the keyboard shortcut feature in the GUI.

The keycodes in the Microsoft list, or in the shortcut.cpp , are listed in hexadecimal numerical format. If you don’t already have a tool to convert that to decimal for entry in your key attributes in shortcuts.xml: you can run calc.exe that comes with your Windows operating system, and the “Programmer” mode of the calculator app allows you to click on Hex to change to hexadecimal mode, then you can type or click the hex value from the source code, and it will translate it decimal next to the Dec in the app GUI; to get back to normal calculations, make sure to click on Dec again, or switch back to “Standard” or whatever calc.exe mode you normally use. (For example, the VK_DECIMAL keycode 0x6E represents the decimal-separator character on your numeric keypad (the ./Delete on most US keyboards); if you type the 6E into calc.exe in Hex mode, you will see it’s 110 in decimal, so key=“110” would be what you’d need to enter in the shortcuts.xml to map that key.)

<Macros>

When not empty, this node is made of <Macro> nodes, each of which represents an individual macro. Each <Macro> holds a non-empty list of <Action> tags which represent individual macro steps. These steps are either Scintilla commands or Notepad++ commands, not raw keystrokes. For more details on macro recording, see Macros.

Attributes for the <Macro> node

Note: FolderName can only be entered by hand-editing the shortcuts.xml file; it is not available in the Shortcut Mapper or any other GUI element.

Although it is possible for several macros to share the same name or shortcut, this practice is highly discouraged.

Attributes for the <Action> tag

The full list of Scintilla messages for type=0 and type=1 Scintilla messages, as well as a concise documentation, can be found in and/or . More details on those messages can be found in the Scintilla Docs. You can use any Scintilla message that does not return a value, that passes an integer in wParam, and uses either an integer or string in lParam. There are some messages that require strings in the wParam, or various data structures in one or both parameters: those will not work in a macro. (For more on the messaging system, see Plugin Communication.)

Each type=2 message runs a corresponding menu entry from Notepad++'s menu system. The wParam command IDs for type=2 Notepad++ messages can be found as the IDM constants in the source file , or you can look at the localization\English.xml (or your language of choice), which lists the <Item id=“...”> next to the text of the command (as it is labeled in the localized menu system); the value of the id attribute is the “command ID” for that menu command, which is used as the wParam command ID for the type=2 macro command.

For type=3 search-and-replace macros, see the detailed description in “Searching > Searching actions when recorded as macros”.

If your automation task requires conditional execution, counters, variables, using the results of one action to influence the next, or other complex behavior, the macro system will not be sufficient for your needs: you will need a Plugin: there are scripting plugins available in Plugins Admin that allow automating Notepad++ with the full power of a variety of programming languages behind them, or you might find a pre-existing plugin that already accomplishes your automation task, or you could write your own plugin).

<UserDefinedCommands>

When not empty, this node contains <Command> tags, which have the command string as contents. Their order is reflected in the Run menu, otherwise it doesn’t matter.

Attributes for the <Command> tag

Note: FolderName can only be entered by hand-editing the shortcuts.xml file; it is not available in the Shortcut Mapper or any other GUI element.

Although it is possible for several commands to have the same name, this is confusing and thus discouraged.

The run command may contain any valid command for the Windows OS. If you use a command that can be found in your PATH (like cmd.exe), then you don’t need to specify the full path to the command. If it’s not in your path, then you should specify the full path. Note that Windows will launch your default browser if you put a URL in this. If the command, or one of its arguments, has an embedded space, then put quotes around it (like you would for any command line environment). For example, <Command name=“Run Putty” ... >“c:\program files\putty\putty.exe” -ssh -load “my session”</Command> shows the quotes around the executable and one of the arguments, because both have spaces. (That same command in the Run-menu’s Run… action dialog would need to be “c:\program files\putty\putty.exe” -ssh -load “my session” to encapsulate all the paths with spaces inside double-quotes.)

Variables for Run Commands

There are a number of Notepad++-specific variables available for Run commands, which are accessed in the form $(VARIABLE_NAME), which can be used to supply portions of the command entry (whether creating the command in the shortcuts.xml or through the Run > Run… entry).

If the variable contains one or more space characters in the path, like $(FULL_CURRENT_PATH) being C:\Path With Spaces\Goes\Here.txt, then you should include quotes around the variable, like “c:\Program Files\App Name\blah.exe” “$(FULL_CURRENT_PATH)”

If you want access to a Windows environment variable (like TMP), use the standard %-notation for Windows variables (like %TMP%). If the variable references a path with one or more spaces in the name, then putting quotes around environment variables is required: for example, if %TMP% is defined as C:\Users\First Last\Temp\, then you will need to use C:\AppDir\blah.exe “%TMP%” as your command.

shortcuts.xml Security

Starting in v8.9.6.1, extra security was added to the shortcuts file (originally, just for the Run-menu entries):

• In v8.9.6.1, any saved Run-menu entry that tried to execute outside certain trusted locations (the Windows and System32 directories from the OS, and Program Files), it would pop a warning dialog every time that Run-menu entry is chosen.
• In v8.9.6.2, this behavior was modified: instead of prompting every time, the first time you run such an entry after shortcuts.xml has been modified, or the first time after updating from v8.9.6.1-or-earlier to v8.9.6.2-or-later, Notepad++ will warn you that shortcuts.xml has changed, will open the file so you can review it to make sure there were no unexpected changes; after you are sure, use Run > Validate shortcuts.xml to save a signature of the current shortcuts.xml, so that Notepad++ can detect changes. After that, Notepad++ will allow you to execute such Run-menu entries without interruption (until shortcuts.xml is changed again). To be clear, if the changes to shortcuts.xml come from within the GUI (saving a new Run-menu command, saving a new macro, updating a keyboard shortcut), Notepad++ will automatically save the new signature, so it won’t prompt you; it is only if the shortcuts.xml is changed manually (by editing the XML text) that you will have to use Run > Validate shortcuts.xml: most users should only rarely (if ever) need to use that action, except one time after upgrading from v8.9.6.1-or-earlier to something v8.9.6.2-or-later.
• In v8.9.7, this behavior was extended to also cover macros, so that running a macro would also trigger the HMAC verification.
• If you have a scripting plugin like PythonScript or LuaScript, and one of your scripts runs menu commands, and/or has a shortcut assigned, this security warning may be triggered once as well.

NOTE: After doing a Run > Validate shortcuts.xml, you should exit Notepad++ to get it to save the config file with the new HMAC signature, so that future runs will see that signature and recognize that shortcuts.xml has not been modified unexpectedly. If you use multiple instances of Notepad++ (using -multiInst or the preference-equivalent), then you need to close all instances of Notepad++ but the main one, then review shortcuts.xml and Run > Validate shortcuts.xml, then exit the last Notepad++; from now on, your first instance and any subsequently launched instances will all see the same signature. (If you validate from the first instance, then launch new instances before N++ has been exited, the config file will still have the old HMAC signature, or no signature at all, so those new instances will still pester you.)

shortcuts.xml encoding and entities

Notepad++ stores most characters in macros as actual UTF-8 encoded characters, and it treats nearly all entities as raw text. Thus, π is interpreted as 8 characters, not an entity-representation of the underlying character.

There are still a small number of entities that will be recognized inside macros:

• The 5 predefined XML named-entities: & < > ' "
• Any of the hexadecimal entities that only include two hex digits, like 
 and 
 for CR and LF, and " for double-quotes. This notation works for all ASCII codepoints from 1 ( for the SOH character) through 127 ( for the DEL character)

User Interface settings: config.xml

The following sections are defined:

1. <GUIConfigs>: user interface settings (usually set in the Settings > Preferences).
2. <FindHistory>: most of the latest state of the Find/Replace dialog box.
3. <History>: the list of recently used files.
4. <ProjectPanels>: associates workspace files with a given project panel

There are some non-UI options for advanced users, please check Preferences for Advanced Users to get more details.

Keyword lists: langs.xml

This file contains the keyword lists for syntax highlighting languages.

Attributes for the <Language> node

The value used in the tabSettings attribute value depends on the Settings > Preferences > Indentation > Indent Settings:

• If it is set to use ☑ Tab character, then the value stored in this XML attribute is the same as in the preference’s Indent Size value.
• If it is set to use ☑ Space character(s), then the value stored in this XML attribute is 128 higher than the preference’s Indent Size value (so a value of 4 in the preference dialog would be stored here as tabSettings=“132”).
• If it is set to use ☑ Use Default Value, then this attribute will be tabSettings=“-1”.
• If this <Language...> entry is missing the tabSettings attribute, it will behave as if it had tabSettings=“-1”.

Inside each of the languages, you could add keywords. However, it’s better to use Settings > Style Configurator and make use of the user-defined keywords box for a given category (when available). These user-defined keywords are stored in stylers.xml (described below).

The order of the ext list here determines the order of extensions in the file-type pulldowns of the Windows-common-dialogs like Open, Save, and Save As dialogs. The automatically-added extension will be the first extension from this ext list.

The commentLine, commentStart, and commentEnd attributes are used by the Edit Menu‘s Comment/Uncomment actions for adding or removing the comment syntax to the selected lines of text. These are independent of the selected programming Language‘s syntax lexer, so changing these attributes will not affect what code sections will get highlighted as comments by the active syntax highlighter. (Because of the way the Scintilla library that Notepad++ uses for the lexers, in order to change what gets highlighted as a comment, one would need to edit and re-compile the lexer for the chosen and then rebuild the Notepad++ project; in other words, it would have to be changed by the developers for a new release, not changed by the user in the langs.xml configuration file.) These attributes can only define one type of line and block comments; if your language has multiple types of either, you will have to choose the one type that you’d like Comment/Uncomment to work with.

Highlighting schemes: stylers.xml

This file sets the color scheme for the default theme. The other themes are stored in themes\*.xml, which follow the same format at stylers.xml. In general, use Settings > Style Configurator for easier maintenance of styles.

Each lexer type has its own <LexerType> section, with multiple <WordsStyle> entries. Each lexer from the Language menu has it’s own list of available <WordsStyle> entries. Trying to add a new <WordsStyle> to a lexer to try to get more categories of keywords will not be successful, because the underlying code which does the syntax highlighting has no internal rules for mapping the entries found to that style.

If you have added user-defined keywords in the Settings > Style Configurator, they will be stored as the contents of the <WordsStyle>, as a space-separated list (for example, <WordsStyle>fancyKeyword1 fancyKeyword2</WordsStyle>).

The <WordsStyle> fontStyle attribute encodes the setting of the Bold, Italic, and Underline checkboxes from the Styler dialog, using the sum of Bold=1, Italic=2, and Underline=4 (so something with all three checkboxes set would have fontStyle=“7”).

The <WordsStyle> colorStyle attribute decides whether to use the defined colors from fgColor and bgColor attributes, or to use the default color setting (from Settings > Style Configurator > Global Styles > Default Style). The attribute should be set to one of the following:

• No colorStyle attribute: this style will use both the fgColor and bgColor attributes from this <WordsStyle> item (standard behavior)
• Set colorStyle=“2”: this style will inherit the foreground color from the Default style, and use the bgColor value as the background color (equivalent to right-clicking the foreground color in the UDL styler dialog box)
• Set colorStyle=“1”: this style will inherit the background color from the Default style, and use the fgColor value as the background color (equivalent to right-clicking the background color in the UDL styler dialog box)
• Set colorStyle=“0”: this style will inherit both the foreground and background colors from the Default style (equivalent to right-clicking both the foreground and background colors in the UDL styler dialog box)

Function List

Defines what counts as a “function” for View > Function List. There are some comments in the file(s), and lots of examples of the builtin languages, which you can customize.

Function List Definitions

The functionList folder contains a separate XML file (function list parser definition) for each language’s function list capability. Each function list parser definition links to a language with the language default name. For example the file name of php language parse rule is php.xml, the file name of Java language parse rule is java.xml, Check for the naming list of all supported programming languages.

For built-in languages that already have Function List behavior, editing is optional: if you edit the existing functionList\XYZ.xml for that language, you don’t need to edit overrideMap.xml; however, if you create a new functionList\my_XYZ.xml that yo

（本文超出站点单文档体积上限，已截断）