How to unselect files in Visual mode?

[veltza]

In Visual mode, there is a command called visual-accept that adds the visual selection to the selection list, but I would like to do the opposite and remove the selection from the selection list. So should there be visual-unselect or something similar that would work like this and then exit Visual mode?

[CatsDeservePets]

Currently, there are:

• visual-accept Add the visual selection to the selection list, quit visual mode and
  return to normal mode.
• visual-discard Discard the visual selection, quit visual mode and return to normal
  mode.

I think you are not asking about visual-discard but about removing the visually selected files from your normal selection.
In my pull request, I asked @joelim-work whether I should implement an unselect mode or something like that but he said no. Also, the visual selection currently does not get exported to scripts. That means, currently there sadly is no way of doing this.
I see 2 options here:

• We introduce a function visual-unselect that instead of adding the current visual selection to the normal selection, removes the current visual selection from the normal selection.
• We export the visual selection to scripts (like the current env variable fs) and make users create their own own command to do that.

I am open of doing both but ultimately we have to wait what @joelim-work thinks and perhaps also gather more user feedback regarding visual mode.

As a quick workaround, add the following to the function eval(app *app, args []string) inside eval.go

case "visual-unselect":
	if !app.nav.init {
		return
	}
	dir := app.nav.currDir()
	for _, path := range dir.visualSelections() {
		if _, ok := app.nav.selections[path]; ok {
			delete(app.nav.selections, path)
			app.nav.selectionInd--
		}
	}
	dir.visualAnchor = -1
	normal(app)

and map it to something like vmap u visual-unselect.

[veltza]

@CatsDeservePets Your workaround is exactly what I need! I found it counterintuitive that in Visual mode you could only add items to the normal selection list, but not remove them.

[DusanLesan]

As a user who’s gotten pretty used to invert-below, I’ve developed a habit of selecting large sections of files and then pruning out selected files somewhere in the middle. I think I would need visual-unselect command (or even visual-toggle, as in most cases I’d like to use one mapped command for both selecting and unselecting, and use a specific action only when there are both selected and unselected files mixed in the visual selection).

I like the idea of having the visual list exposed, as I could possibly perform actions on batches of files while building a large selection list. For example, I could have dozens of files selected, come across a file I want to tag, and without affecting the entire $fs, I could tag only the file in the visual selection. There are several other commands where I would first try to perform an action on the visual selection before falling back to $fs.

[CatsDeservePets]

visual-toggle would look like this:

case "visual-toggle":
	if !app.nav.init {
		return
	}
	dir := app.nav.currDir()
	for _, path := range dir.visualSelections() {
		app.nav.toggleSelection(path)
	}
	dir.visualAnchor = -1
	normal(app)

Thinking about it... when having visual-toggle and visual-unselect, perhaps visual-accept should get renamed to visual-select.

[DusanLesan]

Toggle would not be needed in eval if users could have the list exposed. It is probably a edge case anyway

[CatsDeservePets]

I added the env variable fv in my test branch which does exactly that. Not yet tested but should work.

[DusanLesan]

Thanks. I've taken the code from the latest commit and I'm trying it out

[edit]
I'll keep testing later but so far this works fine:

cmd visual-toggle &{{
	while read -r file; do
		lf -remote "send $id toggle \"$file\""
	done <<< "$fv"
	lf -remote "send $id visual-discard"
}}

[CatsDeservePets]

@DusanLesan, @veltza
Edit:
I created a new branch with just the changes @joelim-work agreed to:
https://github.com/CatsDeservePets/lf/tree/visual-mode

Just so you know, I created this experimental branch for improvements to Visual mode. https://github.com/CatsDeservePets/lf/tree/visual

[veltza]

I already like your improvements. The new commands feel natural to me. Unfortunately, I don't have any use cases for the $fv variable, so I can't evaluate its usefulness.

[0x7375]

I thought about something like $fv immediately after trying out visual mode but I think it's because I was expecting visual mode to use the native selection, having to confirm visual selection feels a bit off coming from vim

[joelim-work]

The main reason I was initially against during the implementation of #2021 was because I felt it was unnecessary - you can use Visual mode to select a large block of files, then quickly use toggle (or :toggle; down) to unselect anything that should be excluded. I'm just not sure if visual-unselect adds any real benefit here.

I guess we can consider adding visual-unselect though - it almost feels like users don't even want to use the original toggle/invert/unselect functionality anymore when Visual mode exists. So the code provided above is fine, but app.nav.selectionInd should not be decremented (only reset to 0 if the selection list becomes empty). Also, I don't know what keybinding is appropriate to assign to visual-unselect by default.

visual-toggle and exporting $fv still feels too niche to add though.

[DusanLesan]

select is already used for the focus action and unselect for clearing all selected files. I have already looked into it and if Joe agrees I would go with something like:

Diff

diff --git a/eval.go b/eval.go
index 7fcfe56..d23c6bf 100644
--- a/eval.go
+++ b/eval.go
@@ -1262,18 +1262,33 @@ func (e *callExpr) eval(app *app, args []string) {
 		if len(e.args) == 0 {
 			app.nav.toggle()
 		} else {
-			dir := app.nav.currDir()
-			for _, path := range e.args {
-				path = replaceTilde(path)
-				if !filepath.IsAbs(path) {
-					path = filepath.Join(dir.path, path)
-				}
-				if _, err := os.Lstat(path); !os.IsNotExist(err) {
-					app.nav.toggleSelection(path)
-				} else {
-					app.ui.echoerrf("toggle: %s", err)
-				}
+			if err := app.nav.setPathsSelection(e.args, app.nav.toggleSelection); err != nil {
+				app.ui.echoerrf("toggle: %s", err)
+			}
+		}
+	case "select-path":
+		if !app.nav.init || len(e.args) == 0 {
+			return
+		}
+		if err := app.nav.setPathsSelection(e.args, func(path string) {
+			if _, ok := app.nav.selections[path]; !ok {
+				app.nav.selections[path] = app.nav.selectionInd
+				app.nav.selectionInd++
 			}
+		}); err != nil {
+			app.ui.echoerrf("file-select: %s", err)
+		}
+	case "unselect-path":
+		if !app.nav.init || len(e.args) == 0 {
+			return
+		}
+		if err := app.nav.setPathsSelection(e.args, func(path string) {
+			delete(app.nav.selections, path)
+		}); err != nil {
+			app.ui.echoerrf("file-unselect: %s", err)
+		}
+		if len(app.nav.selections) == 0 {
+			app.nav.selectionInd = 0
 		}
 	case "tag-toggle":
 		if !app.nav.init {
diff --git a/nav.go b/nav.go
index 3d3686a..72b8880 100644
--- a/nav.go
+++ b/nav.go
@@ -1217,6 +1217,24 @@ func (nav *nav) toggle() {
 	nav.toggleSelection(curr.path)
 }
 
+func (nav *nav) setPathsSelection(paths []string, handler func(path string)) error {
+	var errMsg error
+	dir := nav.currDir()
+	for _, path := range paths {
+		path = replaceTilde(path)
+		if !filepath.IsAbs(path) {
+			path = filepath.Join(dir.path, path)
+		}
+
+		if _, err := os.Lstat(path); !os.IsNotExist(err) {
+			handler(path)
+		} else {
+			errMsg = err
+		}
+	}
+	return errMsg
+}
+
 func (nav *nav) tagToggleSelection(path string, tag string) {
 	path = evalSymlinks(path)
 

I still need to think of better names and add to documentation. Name suggestions are very welcome

[joelim-work]

Unconditional select and unselect was discussed in #1234, but there were a few reasons I never ended up doing this:

• For the most part, builtin commands are based on simple, interactive operations that are associated with keybindings (e.g. navigation via h/j/k/l, or toggle via <space>). I doubt users are interested in a keybinding that unconditionally selects or unselects a file.
• $fs is already exported to shell commands, so shouldn't you be able to implement select-path/unselect-path in terms of user configuration? This is the reason why such information is exported, to allow users to build their own functionality instead of having to request it being added to the already large pile of existing commands.
• Your implementation of select-path/unselect-path accepts any number of filenames, but this might not cover all use cases. What if the user instead wants to pass in the name of a directory containing the files to be selected/unselected? Or a glob indicating the set of files?

[DusanLesan]

• I doubt users are interested in a keybinding that unconditionally selects or unselects a file

It is not really needed when navigating, especially considering visual-accept already unconditionally selects all files in the range, but it can be very helpful if we want to add to existing select list from the external commands like custom search engines etc.

• shouldn't you be able to implement select-path/unselect-path in terms of user configuration

I sure would be able to do it but that sounds a bit computationally expensive as we would need to check each path of the new selection list with each path in $fs while the built in support should be pretty easy and it would not interfere with any other functionality while it could be considered a basic file manager feature

• Your implementation of select-path/unselect-path accepts any number of filenames, but this might not cover all use cases

I was just attempting to do the same thing as toggle does. Since I am not very familiar with go, I do not see how this change does anything differently than what previously toggle did apart from new commands requiring arguments

Also, I have separated the common code so the maintenance should not be any harder, but I can just duplicate the code without affecting toggle if that is preferred

[joelim-work]

It's not about the additional maintenance effort (which I think is very little) - it's about minimalizing feature bloat in lf, which I'm pretty sure was a design goal from the very start. There's no official set of rules regarding whether a new feature should be accepted or not, but I tend to use #950 (comment) as a baseline.

Regarding "computationally expensive", I'm not sure about this because I haven't tried it out yet - I was thinking to just print out the contents of $fs and all the files, pass it to sort | uniq and then finally to :unselect; toggle <files>. If the performance is really that bad then I could reconsider.

Also, this really should go in a separate discussion, but I don't always want to be the person that says "no" to everything. I do try to be accepting of the views and requests from other users, but the fact remains that once a new feature is merged, it practically cannot be removed. And usually new features often have bugs, are flawed from a design point of view, conflict with other features, open the gates for additional feature requests, and also just make it more likely for new users to feel overwhelmed. Furthermore this is not my project to begin with, so I feel like I would be disrespectful if I just started adding every new feature that was suggested, without keeping the original design goal in mind.

[DusanLesan]

Ok. I usually agree with that stance about new features as long as it can be done with user configs. Since it is the case here as well, I will keep my changes downstream.

[CatsDeservePets]

I created a pull request to add visual-unselect and $fv.
Not sure if this should still get merged before the release as we don't want to merge new features but it might be better than releasing an "incomplete" Visual mode.

• Additions to visual-mode #2035

@DusanLesan, @veltza, @0x7375 you can test it if you want using this branch:
https://github.com/CatsDeservePets/lf/tree/visual-mode

Note: This branch is called visual-mode and is different to the one I previously shared, just called visual.

[0x7375]

When testing out your previous visual branch, using visual-toggle instead of visual-unselect and visual-accept felt the most intuitive to me since it just inverts what you had selected and you only need a single keymap but that might just be me.

I do wish there was some way to be able to run actions like deleting or moving/cutting files without having to confirm the selection ($fv would sort of work but not for built-in mappings), maybe acting as if the visual selection is selected unless discarded? I understand if it's not easy to implement or conflicts with other uses, just an idea.

[CatsDeservePets]

I do get your points! Personally I am not against visual-toggle, I am just following Joelim's advice. I also do get that lf's vision is to keep it simple and light, so every feature added needs to be evaluated. For features like this, it might take some time to truly see what users actually want and what makes sense.

Regarding your wish of removing the need to confirm the visual selection, you could work around this by using remaps like vmap d push Vd.

[0x7375]

Regarding your wish of removing the need to confirm the visual selection, you could work around this by using remaps like vmap d push Vd.

Didn't think about using push, this is a nice work around

[joelim-work]

I have merged the above PR, thanks for submitting it.

Regarding visual-toggle, once you have a visual selection, how do you know whether the files will finally end up being selected or unselected? The visual selection indicator (visualfmt) takes precedence over the selection indicator (selectfmt) in the UI, so if you happen to forget which files were initially selected then you have to start again just to be certain about the desired result. At this point in time, I'm not really convinced it is worth adding visual-toggle - $fv exists now so you should be able to script that behavior via configuration if you really need it.

Didn't think about using push, this is a nice work around

That isn't a workaround, it's intentional design. vmap d :visual-accept; cut also works if you want to explicitly list the commands instead of keybindings.

[0x7375]

Regarding visual-toggle, once you have a visual selection, how do you know whether the files will finally end up being selected or unselected? The visual selection indicator (visualfmt) takes precedence over the selection indicator (selectfmt) in the UI, so if you happen to forget which files were initially selected then you have to start again just to be certain about the desired result. At this point in time, I'm not really convinced it is worth adding visual-toggle - $fv exists now so you should be able to script that behavior via configuration if you really need it.

Well yes with the current UI you can't tell what's going to happen If you forget about the initial selection (drawing the visual selection green block 1 char to the left would make more sense maybe?), but my point was just to share what felt the most intuitive since having 2 keybinds for something that can work with 1 did not really make sense to me. And I assume most users are already familiar with using toggle.

But adding visual-toggle in addition to visual-accept and visual-unselect is not relevant yes, it was more of a replacement. And if it's possible to script it then it's fine.