Ticket #3594 (closed enhancement: fixed)

Opened 4 years ago

Last modified 4 years ago

Find File -> rationale behind "Search for content"?

Reported by: egmont Owned by: andrew_b
Priority: minor Milestone: 4.8.16
Component: mc-core Version: master
Keywords: Cc:
Blocked By: Blocking:
Branch state: merged Votes for changeset: committed-master

Description

In the Find File dialog, there's a checkbox "Search for content", unchecking it disables the fields of the right column.

The left column, however, doesn't have a corresponding "Search for file name" checkbox, there's no quick way to toggle if I'm interested in a file name or not.

This asymmetric behavior is in my opinion inconsistent and should be made consistent.

I'd personally remove the "Search for content" checkbox. It's superfluous, clutters the UI and doesn't provide any useful feature. If I'm not interested in the content, I can just clear the "Content:" field. (We need to make sure that the code doesn't actually scan all the files for the empty string.) If I become interested again, I can easily recall the previous value from the history of that input field.

Change History

comment:1 follow-up: ↓ 3 Changed 4 years ago by zaytsev

I'm not sure if I agree, but I guess I just have to try clearing the input field before unchecking the checkbox and see if it feels much different.

Maybe if we decide to change that, we can disable the other checkboxes below the said checkbox if it's value is empty as a sort of visual feedback that this part of the search feature is inactive?

I use the checkbox rather often, and it never occurred to me that this is somehow cumbersome. I often look for something in files, then uncheck the box and look again, and then check it back again and look again, so it's kind of convenient that the last search value stays there.

On the other hand, of course, the input can be cleared just as easily (Ctrl+W) and last item recalled from history (Alt+H)... Hmmmm.

comment:2 Changed 4 years ago by ossi

+1 on the OP. in fact, i have argued this years ago (not sure whether in a ticket or on the list).

comment:3 in reply to: ↑ 1 ; follow-up: ↓ 5 Changed 4 years ago by egmont

Replying to zaytsev:

Maybe if we decide to change that, we can disable the other checkboxes below the said checkbox if it's value is empty as a sort of visual feedback that this part of the search feature is inactive?

Sounds good to me, and is a good feedback to distinguish a misleading whitespace-only field from the empty one. Of course, the left-hand fields should also receive this feature.

comment:4 Changed 4 years ago by andrew_b

  • Blocked By 3597 added

comment:5 in reply to: ↑ 3 Changed 4 years ago by andrew_b

Replying to egmont:

Replying to zaytsev:

Maybe if we decide to change that, we can disable the other checkboxes below the said checkbox if it's value is empty as a sort of visual feedback that this part of the search feature is inactive?

Sounds good to me, and is a good feedback to distinguish a misleading whitespace-only field from the empty one. Of course, the left-hand fields should also receive this feature.

#3597

comment:6 Changed 4 years ago by andrew_b

  • Blocked By 3597 removed

comment:7 Changed 4 years ago by andrew_b

  • Owner set to andrew_b
  • Status changed from new to accepted
  • Branch state changed from no branch to on review
  • Milestone changed from Future Releases to 4.8.16

Branch: 3594_find_file_content
Initial changeset:a43018c2651d018884aa4ded2f6cb8909644d324

comment:8 Changed 4 years ago by zaytsev

  • Votes for changeset set to zaytsev

Pushed a minor nit fixup.

comment:9 Changed 4 years ago by andrew_b

  • Votes for changeset changed from zaytsev to zaytsev andrew_b
  • Branch state changed from on review to approved

comment:10 Changed 4 years ago by andrew_b

  • Status changed from accepted to testing
  • Votes for changeset changed from zaytsev andrew_b to committed-master
  • Resolution set to fixed
  • Branch state changed from approved to merged

Merged to master: [d5668b60b6e6fbad508d6c00f34ebc33e0e8c878].

git log --pretty=oneline ebf57a8..d5668b6

comment:11 Changed 4 years ago by andrew_b

  • Status changed from testing to closed

comment:12 Changed 4 years ago by zyxmon

I do not think this was a good idea for such a change. I am using mc for many years and this change makes mc uncomfortable.
May be this feature can be set up in configuration.

comment:13 Changed 4 years ago by ossi

there is always somebody who will complain about a change. that's not a reason to stick with a bad decision indefinitely.

introducing a micro-option for such a thing is also counterproductive for about every reason you can imagine.

so just get used to it.

Note: See TracTickets for help on using tickets.