GNU nano - Bugs: bug #54535, [Request] add search functionality...
You are not allowed to post comments on this tracker with your current authentication level.
bug #54535: [Request] add search functionality to command-line options
Submitter: | Derek <dwwolfe1> | ||
Submitted: | Sat 18 Aug 2018 08:26:28 PM UTC | ||
Severity: | 1 - Wish | Status: | Fixed |
Assigned to: | bens | Open/Closed: | Closed |
Discussion locked!
Jump to the original submission
Sun 01 Sep 2019 12:42:36 PM UTC, comment #40: |
Benno Schulenberg <bens> |
Thu 29 Aug 2019 02:17:37 PM UTC, comment #39: Ok that makes sense if you think about it like opening a file and then doing ctrl+W to jump to the next match. It may not be worth the trouble but I suppose it might be possible to make some special case that will consider a match at the beginning (or end?) of file only in the case of this searching feature?
|
Derek <dwwolfe1> |
Thu 29 Aug 2019 04:36:18 AM UTC, comment #38: That is how nano's search functionality works, it just stands out more with this new feature. Open that same file, put cursor at top and try searching. It doesn't make sense to jump to the match the cursor is sitting on, and would probably break the ability to continue jumping between matches.
|
Brand Huntsman <brand> |
Wed 28 Aug 2019 08:14:15 PM UTC, comment #37: This feature is awesome, thank you for implementing it. I installed v4.4 from source and have been putting it to use. I noticed a small bug where it doesn't find a match that starts at the first character:
|
Derek <dwwolfe1> |
Mon 26 Aug 2019 05:13:44 PM UTC, comment #36: Released in 4.4. |
Benno Schulenberg <bens> |
Sun 18 Aug 2019 11:12:45 AM UTC, comment #35: The main feature has been pushed to master in commit a9dd73fb, and the "crCR" search modifiers from Brand in commit 2326bf69 (slightly edited). |
Benno Schulenberg <bens> |
Sat 17 Aug 2019 10:17:06 PM UTC, comment #34: Ugh, I even knew about the infinite loop and forgot to add the default path. I also fixed the issue with rcRC not working with gotolinecolumn by simply changing the [1] to [n]. So +rc2,2 works if you want to toggle the modifiers and use gotolinecolumn.
|
Brand Huntsman <brand> |
Sat 17 Aug 2019 01:07:15 PM UTC, comment #33: Thanks for the review. Improved patch attached.
|
Benno Schulenberg <bens> |
Thu 15 Aug 2019 01:51:22 AM UTC, comment #32: It will probably fail to compile without ENABLE_HISTORIES. The positionlog #endif needs to be moved up a line before the closing brace.
|
Brand Huntsman <brand> |
Fri 09 Aug 2019 01:39:49 PM UTC, comment #31: Attached is a second version of the patch that also works when having 'set regexp' in your ~/.nanorc file. |
Benno Schulenberg <bens> |
Fri 09 Aug 2019 01:17:14 PM UTC, comment #30: Attached is a first implementation of the requested feature. To open a file at the first occurrence of "someword", run:
|
Benno Schulenberg <bens> |
Tue 04 Jun 2019 01:49:02 AM UTC, comment #29: Ok if it is just waiting based on priority that's good news for me because it will come eventually. Thank you for the update |
Derek <dwwolfe1> |
Mon 03 Jun 2019 02:42:20 PM UTC, comment #28: Yeah, I've eyed this request once or twice during the past month. But... other things to do. There are still some optimizations that can be made that will increase performance for everyone. |
Benno Schulenberg <bens> |
Sat 01 Jun 2019 02:34:49 AM UTC, comment #27: Hello again, just checking on the status of this request because I would still very much like to use this feature. It seemed like we agreed on a simple +/ and +? type implementation but it is still in postponed status and not assigned to anyone |
Derek <dwwolfe1> |
Tue 23 Oct 2018 02:35:33 PM UTC, comment #26: If +/ and +? are implemented, they would simply call 'findnextstr(thegivenstring, FALSE, JUSTFIND, NULL, TRUE, openfile->current, openfile->current_x)', which would not automatically add thegivenstring to the search history. But yes, that is easy enough to make, and would be expected, so it would be done. |
Benno Schulenberg <bens> |
Tue 23 Oct 2018 05:22:00 AM UTC, comment #25: @Derek, it would call the same code used inside nano, so ya, the search query would be added to the history and the findnext and findprevious keys would work with it.
|
Brand Huntsman <brand> |
Mon 22 Oct 2018 03:41:52 PM UTC, comment #24: The +/string and +?string implementation would work perfectly fine for me. I'm assuming it would be possible to leave that keyword in the search buffer so I can move along to the next occurrence once inside the program |
Derek <dwwolfe1> |
Sun 21 Oct 2018 10:39:02 AM UTC, comment #23: Derek, we're talking only about a --find option (what you call -s). The forms "+/string" and "+?string" are equivalent to it, only better, because they would work per file. The -e or --execute or --implant options are off the table.
|
Benno Schulenberg <bens> |
Fri 19 Oct 2018 02:25:08 AM UTC, comment #22: echo -n "^X" |nano NEWS
|
Brand Huntsman <brand> |
Thu 18 Oct 2018 02:26:21 PM UTC, comment #21: What if we reconsidered my original concept of something that applies specifically to search and does not address the more general functionality of your -e? For example:
|
Derek <dwwolfe1> |
Thu 18 Oct 2018 01:57:04 PM UTC, comment #20: Benno, yes,the grep solution is good enough for my scenario.
|
Ondrej Zizka <pekarna> |
Wed 17 Oct 2018 06:47:31 PM UTC, comment #19: The main reason for postponement is that there is no easy way to implement this. The -e option (although easy to implement) is not clean enough. The +/string and +?string manner looked easy, but it isn't.
|
Benno Schulenberg <bens> |
Wed 17 Oct 2018 05:03:29 PM UTC, comment #18: Just so I'm clear, what are the developers opinions on this feature? Is it that there's no easy or clean way to implement it? Or it doesn't seem useful enough to be part of the main program?
|
Derek <dwwolfe1> |
Wed 03 Oct 2018 05:33:30 PM UTC, comment #17: Yes please. I vote for this. Would be a big help for most of my work scenarios (opening large configs at the right place). |
Ondrej Zizka <pekarna> |
Tue 11 Sep 2018 03:12:50 AM UTC, comment #16: It partially works. The following was used to benchmark file loading speed.
|
Brand Huntsman <brand> |
Mon 10 Sep 2018 07:55:16 PM UTC, comment #15: Another thought I had was to try piping a string into nano on startup. Something like the following:
|
Derek <dwwolfe1> |
Mon 27 Aug 2018 04:28:40 PM UTC, comment #14: My immediate intentions are to use the search functionality however implemented to launch me directly to the first occurrence of a keyword from within a script. At that point I would like to be able to ctrl+w and hit enter to search to the next hit if necessary. All of that worked fine with this patch as is
|
Derek <dwwolfe1> |
Mon 27 Aug 2018 12:06:50 AM UTC, comment #13: You should probably imagine -e supports function interpolation ("${justify}" vs "^[^J"), when thinking of useful examples for it. |
Brand Huntsman <brand> |
Sun 26 Aug 2018 09:08:26 PM UTC, comment #12: One thing I was thinking of using it for was justifying at least some of the file before opening it (since, given my recent work, I have justify on the brain :) ), but that's exposed one problem with the patch as-is, that I should have noticed before.
|
David Lawrence Ramsey <dolorous> |
Sun 26 Aug 2018 10:38:06 AM UTC, comment #11: Derek, David, what else (apart from searching) could you imagine using the -e feature for?
|
Benno Schulenberg <bens> |
Wed 22 Aug 2018 07:25:59 AM UTC, comment #10: Someone is working on function interpolation for string binds which is what this -e option uses. It will allow typing ${search} instead of ^W and ${enter} instead of ^M. And it still works if you bind search to another key, or a future version of nano rebinds it for you. Of course it does nothing if a future version of nano renames the function. If the -e feature is added, all function names will need to be locked from future renaming, otherwise any scripts that use the renamed function will break. Its one thing to rename a function that is only used in nanorc, but totally different when scripts depend on it. |
Brand Huntsman <brand> |
Wed 22 Aug 2018 04:50:38 AM UTC, comment #9: I like the functionality of the more general purpose execute command, it supports what I was originally asking for and also a lot more
|
Derek <dwwolfe1> |
Wed 22 Aug 2018 04:38:35 AM UTC, comment #8: You can jump to a position from command line, jumping to a word makes sense. If a cli search is used, position log should be ignored. It would also be nice if position log could be turned off entirely from the cli to prevent saving.
|
Brand Huntsman <brand> |
Wed 22 Aug 2018 04:20:12 AM UTC, comment #7: Although, after some more thought, the initial patch doesn't have either of the issues I brought up, since the nanorc options and +LINE,COLUMN would always work consistently for (1), and using Ctrl-Q via verbatim input would allow backward searches in (2).
|
David Lawrence Ramsey <dolorous> |
Tue 21 Aug 2018 06:51:05 PM UTC, comment #6: It's interesting, but requiring control characters on the command line to use it is... iffy.
|
David Lawrence Ramsey <dolorous> |
Tue 21 Aug 2018 05:33:30 PM UTC, comment #5: True, it's not very intuitive, and not very convenient to use either. Whether it will be added in a future version of nano... it doesn't seem like it, because no one has responded (yet) to the patch that I posted: http://lists.gnu.org/archive/html/nano-devel/2018-08/msg00045.html.
|
Benno Schulenberg <bens> |
Tue 21 Aug 2018 02:52:59 AM UTC, comment #4: Ok I was able to get it working from script using Esc+v, ctrl+w, etc. It does exactly what I was looking for so thank you for implementing. My only concern is how intuitive it will be to use, although some good documentation would help with that. Will this be added to future releases of nano? |
Derek <dwwolfe1> |
Mon 20 Aug 2018 06:43:38 PM UTC, comment #3: Copying and pasting with the mouse will not work, because it will copy what you actually see: ^W and ^M etcetera. If you want to put those characters in a script, you have to edit the script with nano and enter those control characters by preceding them with M-V (the verbatim keystroke in nano, because ^V was used by Pico for PageDown). |
Benno Schulenberg <bens> |
Mon 20 Aug 2018 06:09:14 PM UTC, comment #2: That seems like a good idea, it would make this feature a lot more flexible. I was able to compile, patch, and use the new version of nano which was something of a feat for me. Entering the special characters ^W and ^M created the desired effect when running directly from the bash prompt
|
Derek <dwwolfe1> |
Sun 19 Aug 2018 06:57:29 AM UTC, comment #1: How about the more general feature in the attached patch?
|
Benno Schulenberg <bens> |
Sat 18 Aug 2018 08:26:28 PM UTC, original submission:
I frequently run nano from scripts and would like to open a file and immediately search/seek to a keyword (similar to ctrl+w functionality). Would it be possible to add this as a command line argument?
|
Derek <dwwolfe1> |
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 18 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2019-09-01 | bens | Discussion Lock | None | Locked | |
2019-08-26 | bens | Open/Closed | Open | Closed | |
2019-08-18 | bens | Status | In Progress | Fixed | |
2019-08-17 | brand | Attached File | - | Added toggles-for-case-sensitivity-and-regular-expressions-when.patch, #47358 | |
2019-08-17 | bens | Attached File | - | Added 0001-new-feature-allow-specifying-a-search-string-to-jump.patch, #47355 | |
2019-08-15 | brand | Attached File | - | Added toggles-for-case-sensitivity-and-regular-expressions-when.patch, #47347 | |
2019-08-09 | bens | Attached File | - | Added 0001-new-feature-allow-specifying-a-string-to-jump-to-in-.patch, #47312 | |
2019-08-09 | bens | Attached File | - | Added 0001-new-feature-allow-specifying-a-string-to-jump-to-in-.patch, #47311 | |
Status | Postponed | In Progress | |||
Assigned to | None | bens | |||
2018-10-19 | brand | Attached File | - | Added 0001-implant-from-command-line.patch, #45242 | |
Attached File | - | Added nano-search-and-replace.sh, #45243 | |||
2018-08-26 | bens | Status | Ready For Test | Postponed | |
2018-08-19 | bens | Attached File | - | Added 0001-new-feature-option-e-for-specifying-commands-to-exec.patch, #44810 | |
Severity | 3 - Normal | 1 - Wish | |||
Status | None | Ready For Test | |||
Summary | Request - Add search functionality to command line arguments | [Request] add search functionality to command-line options | |||
2018-08-18 | dwwolfe1 | Carbon-Copy | - | Added dwwolfe1 |
Powered by Savane 3.13-f8d8.
Corresponding source code
When finding a bug, please report it as a new issue. In this case, I've done it for you: bug #56845. Summary: I agree that +/string should find the first occurrence of "string", also when it's at the start of the file. Specifying +/string on the command line is not the same as typing ^W string <Enter>, because for the latter the user can already see what is under the cursor.