notepad-plus: IdeaTorrent

Written by eksortso the 24 Jun 09 at 02:40.

An option could be added to the N++ configuration so that when a large file is opened, syntax highlighting is set to Normal Text instead of according to the file's type. This would only apply to existing files when they are loaded; the syntax highlighting could be turned on by the user at their discretion.

An option could be added to the N++ configuration so that when a large file is opened, syntax highlighting is set to Normal Text instead of according to the file's type. This would only apply to existing files when they are loaded; the syntax highlighting could be turned on by the user at their discretion.

Written by eksortso the 24 Jun 09 at 02:48.

This may require a more complex implementation, but a file could be opened to only the first N lines or the last N lines (ideal for logs), or some window in between. All edits could be applied to the window only, and unloaded lines could not be edited. In addition, whole-file options (such as "Rename Me" or "Delete Me") would be grayed out while this mode is active.

An alternate approach could be to open a single file into several easy-to-handle portions in separate tabs.

This could be a good option for a plugin developer to pursue.

This may require a more complex implementation, but a file could be opened to only the first N lines or the last N lines (ideal for logs), or some window in between. All edits could be applied to the window only, and unloaded lines could not be edited. In addition, whole-file options (such as "Rename Me" or "Delete Me") would be grayed out while this mode is active. An alternate approach could be to open a single file into several easy-to-handle portions in separate tabs. This could be a good option for a plugin developer to pursue.

Written by eksortso the 24 Jun 09 at 02:57.

If possible, a large file could be opened in a view that is not a Scintilla widget. This could be difficult to implement, but the potential benefits for large-file users would be immediate. A special no-frills editor, or an editor that can load documents incrementally, could be used in place of Scintilla at the user's request. In addition, read-only widgets with advanced searching and indexing features could be loaded and used.

The downside to this is that N++ could become too Emacs-like, allowing far more functionality inside a text editor than what ought to be tolerated. It could also be an upside, but you get my drift.

If possible, a large file could be opened in a view that is not a Scintilla widget. This could be difficult to implement, but the potential benefits for large-file users would be immediate. A special no-frills editor, or an editor that can load documents incrementally, could be used in place of Scintilla at the user's request. In addition, read-only widgets with advanced searching and indexing features could be loaded and used. The downside to this is that N++ could become too Emacs-like, allowing far more functionality inside a text editor than what ought to be tolerated. It could also be an upside, but you get my drift.

Written by joleg74 the 13 Jul 09 at 16:00.

On the behalf of: lucas_malor

I think a better solution for big files is to add a "minimal mode" to Npp. Where
Npp is in this mode, it should:

1. alert it is in "minimal mode" with a slide alert (as Firefox do when you
can save passwords)
2. disable all plugins
3. disable all autocomplete features
4. do not apply syntax styles
5. disable all highlight and similar features
6. do not wrap the output
7. do not show any simbols (white chars, indent guide, ...)
8. disable indent features (folding etc.)
9. do not display vertical edges
10. do not save session at exit
11. disable clickable link feature
12. disable file status auto-detection

This mode can be started automatically when a large file is opened, as suggested,
but it could also added as a command line argument.

On the behalf of: lucas_malor I think a better solution for big files is to add a "minimal mode" to Npp. Where Npp is in this mode, it should: 1. alert it is in "minimal mode" with a slide alert (as Firefox do when you can save passwords) 2. disable all plugins 3. disable all autocomplete features 4. do not apply syntax styles 5. disable all highlight and similar features 6. do not wrap the output 7. do not show any simbols (white chars, indent guide, ...) 8. disable indent features (folding etc.) 9. do not display vertical edges 10. do not save session at exit 11. disable clickable link feature 12. disable file status auto-detection This mode can be started automatically when a large file is opened, as suggested, but it could also added as a command line argument.

Written by cchris the 23 Jan 10 at 14:39.

Written by hkubba the 22 Jan 10 at 19:24 as solution #198 to his new idea #136, marled as duplicate.

Just as a suggestion, can we have 2 command-line arguments:
-LinesFromEnd 50
-LinesFromStart 80

the first will only show the last 50 lines, the second will only show the first 80, using them both will only show beginning 80 and end 50 lines of a file
Later on, a warning could be added if you try to open a file > 100M for example, and advice to use the arguments

Written by hkubba the 22 Jan 10 at 19:24 as solution #198 to his new idea #136, marled as duplicate. Just as a suggestion, can we have 2 command-line arguments: -LinesFromEnd 50 -LinesFromStart 80 the first will only show the last 50 lines, the second will only show the first 80, using them both will only show beginning 80 and end 50 lines of a file Later on, a warning could be added if you try to open a file > 100M for example, and advice to use the arguments

Written by garycoast the 17 Feb 10 at 18:03.

Put the code in N++ to automatically detect when available memory and any other resources are insufficient to open and work with the file being opened. Then alert the user that the file can only be opened in "minimal mode" meaning many TBD features will not be available.

Also, allow users the option to select "open in minimal mode" beforehand.

Thank You.

Put the code in N++ to automatically detect when available memory and any other resources are insufficient to open and work with the file being opened. Then alert the user that the file can only be opened in "minimal mode" meaning many TBD features will not be available. Also, allow users the option to select "open in minimal mode" beforehand. Thank You.

Written by joleg74 the 23 Mar 10 at 18:20.

99.9% of the time, when users open really large files, they mostly want to view a log and have no need to edit it.
With this in mind, I suggest that we implement a read only mode that would not load the entire file in memory, but rather work with the file from disk. This would have the downside of not being able to edit the file, but we could open files of any size and browse through them rather quickly.

99.9% of the time, when users open really large files, they mostly want to view a log and have no need to edit it. With this in mind, I suggest that we implement a read only mode that would not load the entire file in memory, but rather work with the file from disk. This would have the downside of not being able to edit the file, but we could open files of any size and browse through them rather quickly.

Written by bfez the 6 Apr 10 at 22:57.

Just like Solution #2 opening only fractions of the big file seems reasonable. This could be done automatically.

When opening the file the first 1000 lines are opened (could be done based on some parameters (performance of machine, number of lines visible in editor)) in the editor.
In the background the file is read further to count the newline characters and note their positions in the file.

With the information of the count and position of the newline characters the editor can show the scrollbar in a correct manner.

When scrolling the editor should reload the part the user wants to see at the moment +- several hundred lines.

The UI wouldn't change (maybe some notification of the loading state of a file) but the solution requires some complex abstraction...
So depending on the internal structure this could be a quite difficult task.

Never the less I'd prefer this way of handling the problem.
Maybe the code of some hex-editor has solved this problem already. I remember using some hex-editor that supported inserting new data in the middle of a file. Seemed pretty fast back than.

Just like Solution #2 opening only fractions of the big file seems reasonable. This could be done automatically. When opening the file the first 1000 lines are opened (could be done based on some parameters (performance of machine, number of lines visible in editor)) in the editor. In the background the file is read further to count the newline characters and note their positions in the file. With the information of the count and position of the newline characters the editor can show the scrollbar in a correct manner. When scrolling the editor should reload the part the user wants to see at the moment +- several hundred lines. The UI wouldn't change (maybe some notification of the loading state of a file) but the solution requires some complex abstraction... So depending on the internal structure this could be a quite difficult task. Never the less I'd prefer this way of handling the problem. Maybe the code of some hex-editor has solved this problem already. I remember using some hex-editor that supported inserting new data in the middle of a file. Seemed pretty fast back than. The SGI rope container has a load on demand feature which is most likely very handy for this.

Written by tgr_ the 4 Jun 09 at 17:03.

Right now highlighting of TODO flags cannot be done because 1) no further highlight rules are applied to comments, and 2) there is no way to define global highlight rules (it would be tedious to set such a rule separately for every language; it makes sense to make rules that apply to comments language-independent).

The solution would be to add a new class of keywords (comment flags) that are applied to all languages, but are restricted to the contents (or first words) of comments.

Right now highlighting of TODO flags cannot be done because 1) no further highlight rules are applied to comments, and 2) there is no way to define global highlight rules (it would be tedious to set such a rule separately for every language; it makes sense to make rules that apply to comments language-independent). The solution would be to add a new class of keywords (comment flags) that are applied to all languages, but are restricted to the contents (or first words) of comments.

Written by deemerrick the 17 Sep 10 at 00:55.

Perhaps a blob in the bookmark column different from the normal bookmark. e.g. a coloured star.

When there is both bookmark and star, an icon there showing the one inside the other, so both are displayed

Perhaps a blob in the bookmark column different from the normal bookmark. e.g. a coloured star. When there is both bookmark and star, an icon there showing the one inside the other, so both are displayed

Written by dregad the 11 Mar 10 at 11:07.

Provide two fields in the Preferences to define the delimiters (left + right as they may be different)

Make the editor select all text left and right of the position where user double-clicked until one of the delimiters is found.

As an option, as I've seen this requested by others, another field could be added to define what characters to include for normal word selection (DblClick)

Provide two fields in the Preferences to define the delimiters (left + right as they may be different) Make the editor select all text left and right of the position where user double-clicked until one of the delimiters is found. As an option, as I've seen this requested by others, another field could be added to define what characters to include for normal word selection (DblClick)

Written by tablaji the 20 Mar 10 at 18:33.

On pressing a pre-defined hotkey combination, all text between quotes (" and ') should be selected. There could actually be two commands, * selecting text //between// quotes and * selecting text //including// the surrounding quotes.

On pressing a pre-defined hotkey combination, all text between quotes (" and ') should be selected. There could actually be two commands, * selecting text //between// quotes and * selecting text //including// the surrounding quotes.

Written by aathell the 9 May 09 at 06:17.

three things that would make shortcut mapping easier:

1) Have the columns be sortable by clicking the column header.

2) Be able to search by entering a shortcut combo and list matching commands. If there is, make shortcut red or popup an warning displaying which command is associated for the shortcut.

3) Filter commands based on origin. Perhaps menu origin for internal commands, and plugin name for plugin commands.

three things that would make shortcut mapping easier: 1) Have the columns be sortable by clicking the column header. 2) Be able to search by entering a shortcut combo and list matching commands. If there is, make shortcut red or popup an warning displaying which command is associated for the shortcut. 3) Filter commands based on origin. Perhaps menu origin for internal commands, and plugin name for plugin commands.

Written by deemerrick the 17 Sep 10 at 00:43.

In the Gimp, you have dynamic menu shortcuts where you can just go to the menu item itself and instead of clicking it, you hit a key-combination and that menu item is set to that key-combo.

Perhaps this could be done, or right-clicking the menu item to customise its shortcut

In the Gimp, you have dynamic menu shortcuts where you can just go to the menu item itself and instead of clicking it, you hit a key-combination and that menu item is set to that key-combo. Perhaps this could be done, or right-clicking the menu item to customise its shortcut

Written by alexbreems the 3 Dec 09 at 12:19.

To replace old a label-image on this image with a gradient transparency: http://img262.imageshack.us/img262/5412/bookmarkimg.png

To replace old a label-image on this image with a gradient transparency: http://img262.imageshack.us/img262/5412/bookmarkimg.png

Written by alexbreems the 5 Dec 09 at 11:26.

The alternative decision - instead of image-labels to use background highlight at number of a line which could be adjusted in Styles for each theme:
http://img14.imageshack.us/img14/7972/bespinthemealt.png

This decision seems to me even more flexible than previous, especially if the user uses debugging and breakpoints

The alternative decision - instead of image-labels to use background highlight at number of a line which could be adjusted in Styles for each theme: http://img14.imageshack.us/img14/7972/bespinthemealt.png This decision seems to me even more flexible than previous, especially if the user uses debugging and breakpoints

Written by alexiljin the 21 Dec 09 at 13:28.

I liked the good-old yellow bookmarks. Perfectly visible on any background, not too bulky and require no special transparency handling:
http://img63.imageshack.us/img63/853/scibookmark.png

This solution is supported by Scintilla, which I doubt of solutions #1 & #2, so it's _very_easy_ to implement.

I liked the good-old yellow bookmarks. Perfectly visible on any background, not too bulky and require no special transparency handling: http://img63.imageshack.us/img63/853/scibookmark.png This solution is supported by Scintilla, which I doubt of solutions #1 & #2, so it's _very_easy_ to implement.

Written by csavie the 25 Dec 10 at 22:24.

Highlight the complete textline when toggling a bookmark, cause I want to use a view without margins.

Highlight the complete textline when toggling a bookmark, cause I want to use a view without margins.

Written by cynip the 14 Aug 12 at 01:20.

If a high res icon is too much work, or making the NP++ package too big, use ">" character

If a high res icon is too much work, or making the NP++ package too big, use ">" character

Written by dudeforge the 6 Aug 10 at 16:31.

Add an option in preferences to set a font-size for printing, either a percentage or a font-size. Might even be nice to add it to the stylers file

Add an option in preferences to set a font-size for printing, either a percentage or a font-size. Might even be nice to add it to the stylers file

Written by b-sharp the 27 Jul 12 at 11:24.

Add functionality to configure different fonts and font sizes for printing in Style Configurator, separate from those for the editor. (See Visual Studio for an example.)

Add functionality to configure different fonts and font sizes for printing in Style Configurator, separate from those for the editor. (See Visual Studio for an example.)

Written by jerry1970 the 7 Aug 12 at 08:47.

Good idea. A more specific possible solution is, on the Style Configurator dialog, to add a checkbox "Use different colour and style for printing", which is unchecked by default.
Then copy the Colour Style and Font Style frames for all language / style combinations - disabled by default. When checking the "Use different colour and style for printing" box, the Print Colour Style and Print Font Style are enabled.
I guess the dialog has to be bigger, or the screen and print styles are to be placed on tabs or something.

Good idea. A more specific possible solution is, on the Style Configurator dialog, to add a checkbox "Use different colour and style for printing", which is unchecked by default. Then copy the Colour Style and Font Style frames for all language / style combinations - disabled by default. When checking the "Use different colour and style for printing" box, the Print Colour Style and Print Font Style are enabled. I guess the dialog has to be bigger, or the screen and print styles are to be placed on tabs or something.

Written by thoazu the 29 Jan 10 at 08:04.

Change Shortcut Mapper dialog

Change Shortcut Mapper dialog

Written by etko the 22 Sep 10 at 11:36.

The problem is much more complicated, sometimes the shortcuts can be already occupied when new plugin is added, even with solution #1 you will learn about this only after you change one of the colliding shortcuts.

Shortcut mapper should really change background color of the colliding shortcuts (whole mapper row to red), and show the list of colliding source(scintilla/npp/plugins):command in tooltip or status bar (within mapper dialog). Keep in mind multiple components (scintilla/npp/plugins) might want to use same shortcut so the notification about the collision should take that into account. More over when browsing through plugins part of the mapper, you have no idea whatsoever to which crap, which command belongs. There really should be another column with plugin name there.

The problem is much more complicated, sometimes the shortcuts can be already occupied when new plugin is added, even with solution #1 you will learn about this only after you change one of the colliding shortcuts. Shortcut mapper should really change background color of the colliding shortcuts (whole mapper row to red), and show the list of colliding source(scintilla/npp/plugins):command in tooltip or status bar (within mapper dialog). Keep in mind multiple components (scintilla/npp/plugins) might want to use same shortcut so the notification about the collision should take that into account. More over when browsing through plugins part of the mapper, you have no idea whatsoever to which crap, which command belongs. There really should be another column with plugin name there.

Written by adem0x the 1 May 10 at 16:21.

Here is what I propose:

Get rid of the OK dialogbox altogether.

Instead, add a statusbar under the SR dialog itself, and display whatever message that would have been shown in the OK dialog in the statusbar within the SR dialog.

Here is where it was discussed: https://sourceforge.net/projects/notepad-plus/forums/forum/331753/topic/3692483

Here is what I propose: Get rid of the OK dialogbox altogether. Instead, add a statusbar under the SR dialog itself, and display whatever message that would have been shown in the OK dialog in the statusbar within the SR dialog. Here is where it was discussed: https://sourceforge.net/projects/notepad-plus/forums/forum/331753/topic/3692483

Written by lanulos the 7 May 11 at 17:14.

Add a checkbox in Preferences, under Editing, to turn off this OK dialog.

Add a checkbox in Preferences, under Editing, to turn off this OK dialog.

Written by rayjamesfun the 29 Jun 10 at 22:34.

Have the program save the folded state of every document upon exit and restore the folded state upon running of the program(notepad++).

Thanks.

Have the program save the folded state of every document upon exit and restore the folded state upon running of the program(notepad++). Thanks.

Written by janschreiber the 2 May 09 at 14:33.

The GUI should always default to English when no translation string is found for a particular item. If possible, the menu structure should be hard-coded and not be read from a potentially outdated language file. Can be pretty dangerous.

The GUI should always default to English when no translation string is found for a particular item. If possible, the menu structure should be hard-coded and not be read from a potentially outdated language file. Can be pretty dangerous.

Written by cchris the 7 May 09 at 16:57.

I see the current UI configuration as the first step towards a fully configurable UI. The most difficult one and one we can build upon.

An UI connects commands with visual items.

A command is "an action or item". It has an internal id, could have an icon, has a default name. The current english.xml does provide this list.

A visual item is anything visible that relates to a command. Labels, buttons, tooltips, menu items, tab items are visual items

A localisation file should have nothing to do with a menu. It is a simple association table: command internal id -> name. Current localisation files are too rich since they have redundant information like in which dialog does this item display.

A menu system is a tree, the root of which is the app menu bar.t could be described by an xml file with two sots of nodes: the leaf nodes are commads, designated by their ids, while non leaf nodes are embedded menus whose only statuc attribute is a name.

If we disconnect these three subsystems, we get a fully configurable UI with on the fly internationalisation, user definable menus and independence between localisation and menu system. Let's do it add the logic to read the extra config file, that's the only missing piece f the puzzle.

I see the current UI configuration as the first step towards a fully configurable UI. The most difficult one and one we can build upon. An UI connects commands with visual items. A command is "an action or item". It has an internal id, could have an icon, has a default name. The current english.xml does provide this list. A visual item is anything visible that relates to a command. Labels, buttons, tooltips, menu items, tab items are visual items A localisation file should have nothing to do with a menu. It is a simple association table: command internal id -> name. Current localisation files are too rich since they have redundant information like in which dialog does this item display. A menu system is a tree, the root of which is the app menu bar.t could be described by an xml file with two sots of nodes: the leaf nodes are commads, designated by their ids, while non leaf nodes are embedded menus whose only statuc attribute is a name. If we disconnect these three subsystems, we get a fully configurable UI with on the fly internationalisation, user definable menus and independence between localisation and menu system. Let's do it add the logic to read the extra config file, that's the only missing piece f the puzzle. The only drawbacks I can see there are: 1/ There is a need for a menus.model.xml to take over when an user menu file is corrupted somehow; 2/ Building the menu template in memory, copying all the strings from the localisation file, may or may not incur a noticeable load time penalty. A benchmmark would be needed. CChris PS: this elaborates a little on an earlier text that wound up as a comment.

Written by xm1 the 27 May 09 at 12:38.

I miss at least two additioonal info-items in the language xml-files, namely:
- version (for which the translation file has been done/intended)
- author (and maybe a contact info too)

In situation when somebody tries to use an old/outdated translation file, the Notepad++ can easily detect that (and display a warning etc...).

I miss at least two additioonal info-items in the language xml-files, namely: - version (for which the translation file has been done/intended) - author (and maybe a contact info too) In situation when somebody tries to use an old/outdated translation file, the Notepad++ can easily detect that (and display a warning etc...).

Written by k7rim the 20 Mar 12 at 23:22.

we can add a menu called 'tools' or favorites' or whatever
the menu can be customized through window or through config file
i can place global run commands , macros or even plugin commands
i can specify how the menu appears with certain file types
something like that:
the menu contain the global items he choosed( to be in the reach of the hand)
some commands or items specific to the current lexer of the file so if the current lang is python : commands associated with python(probably in the config file) would appear in the menu

thank you for the great program

we can add a menu called 'tools' or favorites' or whatever the menu can be customized through window or through config file i can place global run commands , macros or even plugin commands i can specify how the menu appears with certain file types something like that: the menu contain the global items he choosed( to be in the reach of the hand) some commands or items specific to the current lexer of the file so if the current lang is python : commands associated with python(probably in the config file) would appear in the menu thank you for the great program

Written by chriss85 the 6 May 10 at 16:06.

I suggest enabling it automatically if there is a selection and the user pressed CTRL+H to access the search/replace dialog.

I suggest enabling it automatically if there is a selection and the user pressed CTRL+H to access the search/replace dialog.

Written by lwchris the 3 Apr 13 at 21:41.

Pretty often you highlight the string you want to replace and then press Ctrl+H to automatically "load" it into the search&replace dialog as search text. I do this even if the S&R dialog is already open, because it's much faster than Ctrl+C from file and Ctrl+V into search text field. For this you need the checkbox stay unchecked by default.

Use case: you've got some text, but several surnames are wrong. You doubleclick the surname, Ctrl+H, Tab, type correct name, replace all, doubleclick the next wrong surname, Ctrl+H, Tab, ...
Characteristical about this use case is that the search text is NOT altered after you press Ctrl+H.

If you want to replace something like a variable name "In Selection", your search text is definitely going to change at least once after you pressed Ctrl+H. This is because the search text is all the selected text by default, which is not sensible for "In Selection". So if the search text is altered for the first time, the check box could be checked automatically.

Every other alternation does not change the checkbox state whatever it is set to.

The update-lock lasts until the dialog window is closed or Ctrl+H is pressed anew.

Pretty often you highlight the string you want to replace and then press Ctrl+H to automatically "load" it into the search&replace dialog as search text. I do this even if the S&R dialog is already open, because it's much faster than Ctrl+C from file and Ctrl+V into search text field. For this you need the checkbox stay unchecked by default. Use case: you've got some text, but several surnames are wrong. You doubleclick the surname, Ctrl+H, Tab, type correct name, replace all, doubleclick the next wrong surname, Ctrl+H, Tab, ... Characteristical about this use case is that the search text is NOT altered after you press Ctrl+H. If you want to replace something like a variable name "In Selection", your search text is definitely going to change at least once after you pressed Ctrl+H. This is because the search text is all the selected text by default, which is not sensible for "In Selection". So if the search text is altered for the first time, the check box could be checked automatically. Every other alternation does not change the checkbox state whatever it is set to. The update-lock lasts until the dialog window is closed or Ctrl+H is pressed anew.

Written by cchris the 5 Feb 10 at 11:20.

This would somehow display window(s) showing the page(s) that the current printer will output on actual printing.

This would somehow display window(s) showing the page(s) that the current printer will output on actual printing.

Written by rpaskudniak the 26 Jul 10 at 21:57.

Many Windows printers include a "show preview" option in their settings windows. NP++ currently ignores these settings (see ). If NP++ would obey the settings, many users would have a print preview available, along with other driver-provided functions like n-up printing, etc., etc., etc.

Many Windows printers include a "show preview" option in their settings windows. NP++ currently ignores these settings (see <https://sourceforge.net/projects/notepad-plus/forums/forum/331754/topic/3782349>). If NP++ would obey the settings, many users would have a print preview available, along with other driver-provided functions like n-up printing, etc., etc., etc.

Written by newlog the 4 Jun 09 at 22:10.

The “idea” to solve this issue seems rather obvious:
the line used as a reference for computing auto-indentation should simply be the one above the current line.

At least, this should be left as an option.

The “idea” to solve this issue seems rather obvious: the line used as a reference for computing auto-indentation should simply be the one above the current line. At least, this should be left as an option.

Written by donho the 11 Jun 09 at 21:58.

https://sourceforge.net/project/showfiles.php?group_id=189927&package_id=305321 &release_id=661432

https://sourceforge.net/project/showfiles.php?group_id=189927&package_id=305321&release_id=661432

Written by remoo the 24 Feb 10 at 19:44.

The problem will be resolved if there could be an extra option in "preferences" to define the default directory for new files

The problem will be resolved if there could be an extra option in "preferences" to define the default directory for new files

Written by wonea the 3 Mar 10 at 16:54.

You can change the Current Working Directory (CWD) with using NPPexec. In fact you can create a macro with NPPexec, and use the following command

echo $(CWD)

Then all you need todo is

cd ../.. to wherever you like

then cd Mysuperfunkydirectory

Echo the CWD again, and hey presto. Set NPPexec to start the script on launch, (in the NPPexec advanced settings), and that might work!

You can change the Current Working Directory (CWD) with using NPPexec. In fact you can create a macro with NPPexec, and use the following command echo $(CWD) Then all you need todo is cd ../.. to wherever you like then cd Mysuperfunkydirectory Echo the CWD again, and hey presto. Set NPPexec to start the script on launch, (in the NPPexec advanced settings), and that might work!

Written by halilozgur the 10 Jun 10 at 09:10.

The default directory needs to be something meaningful like the last used dir, and user may select a different directory using an option.

The default directory needs to be something meaningful like the last used dir, and user may select a different directory using an option.

Written by blachi the 2 Aug 10 at 10:52.

all "new 1", "new 2", ... files should be automatically saved in defined directory without asking while program exits, and restored on program start.

all "new 1", "new 2", ... files should be automatically saved in defined directory without asking while program exits, and restored on program start.

Written by uninfected the 17 Nov 10 at 06:01.

Since the action is not about viewing but about creating a language one might expect it to be under the "Language" menu.
Additionally, the action is defining a language not a dialogue.

Since the action is not about viewing but about creating a language one might expect it to be under the "Language" menu. Additionally, the action is defining a language not a dialogue.

Written by binaryforge the 3 Aug 09 at 13:22.

Physically separate those two options. Move "Close all but me" a few notches down. This should make above accident much more unlikely.

Of course this will introduce a problem to any other option next to the new location of "Close all but me".

Physically separate those two options. Move "Close all but me" a few notches down. This should make above accident much more unlikely. Of course this will introduce a problem to any other option next to the new location of "Close all but me".

Written by binaryforge the 3 Aug 09 at 13:22.

Not unlike the standard context menus customizability via xml, the tabulator context menu could be made customizable.

This way the user could separate these options, as he sees fit or disable one option altogether.

Not unlike the standard context menus customizability via xml, the tabulator context menu could be made customizable. This way the user could separate these options, as he sees fit or disable one option altogether.

Written by binaryforge the 3 Aug 09 at 13:28.

After choosing context menu entry "close all but me" an optional security / confirmation dialog pops up.

The user then has the choice to opt out of execution if he made a wrong selection.

After choosing context menu entry "close all but me" an optional security / confirmation dialog pops up. The user then has the choice to opt out of execution if he made a wrong selection.

Written by frboyer the 5 Aug 09 at 14:00.

If you realize you did not want to "close all but me", you could "undo" and files would be reopened as they were before.

If you realize you did not want to "close all but me", you could "undo" and files would be reopened as they were before.

Written by alexiljin the 16 Dec 09 at 03:19.

Create "Close" submenu for the "dangerous" entries like "All tabs" and "All tabs but this one".

Create "Close" submenu for the "dangerous" entries like "All tabs" and "All tabs but this one".

Written by xhpohanka the 30 Apr 10 at 09:24.

Add F3 (or correct shortcut) as a mnemonic for 'Find next' button on search dialog.

Add F3 (or correct shortcut) as a mnemonic for 'Find next' button on search dialog.

Written by duhl the 2 Apr 10 at 11:23.

search the potential words in opened buffers

search the potential words in opened buffers

Written by janschreiber the 2 May 09 at 16:05.

It would be nice if brackets (and other symbols, for that matter) could be added as folding "keywords" while at the same time their status as symbols is preserved. In short, the folding for user-defined languages with a c-like syntax should mimic the behavior of the built-in c++ parser as closely as possible, including code folding _and_ highlighting of matching brackets.

It would be nice if brackets (and other symbols, for that matter) could be added as folding "keywords" while at the same time their status as symbols is preserved. In short, the folding for user-defined languages with a c-like syntax should mimic the behavior of the built-in c++ parser as closely as possible, including code folding _and_ highlighting of matching brackets.

Written by tigerix the 22 Jul 10 at 14:02.

Keyboard shortcut for removing history entries in the Search/Replace window.
Shift-Del is the standard shortcut in Firefox and other applications for removing history entries.

Keyboard shortcut for removing history entries in the Search/Replace window. Shift-Del is the standard shortcut in Firefox and other applications for removing history entries.

Written by brittney24 the 8 Oct 11 at 17:16.

Either add a button to Search > Find UI: "Clear Search History (terms, etc.), or have something in drop box for previous search terms.

In addition, many apps have global preferences to retain things like search terms, etc. Probably easiest would be add a button to search UI.

Current buttons on UI for Find, Count, Close, etc. are huge. Not like these couldn't be reduced a bit & make room for another.

Either add a button to Search > Find UI: "Clear Search History (terms, etc.), or have something in drop box for previous search terms. In addition, many apps have global preferences to retain things like search terms, etc. Probably easiest would be add a button to search UI. Current buttons on UI for Find, Count, Close, etc. are huge. Not like these couldn't be reduced a bit & make room for another.