-print-selection and -selection-path not work

[superiums]

i'm wondering to use lf as a filepicker in qute.

but found in terminal: lf -print-selection print nothiing while selected and quit. also lf -selection-path /tmp/s writes no file.

• os : voidlinux
• version: lf r32

[DusanLesan]

@superiums I think selection works only for files and that it works when you select and open (instead of select and quit)

[joelim-work]

I had a look through past issues, it looks like you're not the first person to be confused about how -selection-path/-print-selection works:

• https://github.com/gokcehan/lf/issues/82
• https://github.com/gokcehan/lf/issues/89
• https://github.com/gokcehan/lf/discussions/1080
• https://github.com/gokcehan/lf/issues/1342
• https://github.com/gokcehan/lf/issues/1791

---

IMO the current workflow (toggle some files with space and then open using l) is not intuitive because:

• lf is supposed to quit after the files have been selected, and open generally does not imply quitting.
• The purpose of using lf in this way is to select some files and do something with them, but that action is not necessarily opening them.

If I could change the way this feature works I would make it so that:

• The user should toggle the desired files and then quit. open will no longer have any relation to this feature in any way.
• Files must explicitly be selected - if no files are selected then the current file under the cursor should not be selected instead.
• In the case of selection-path, if no files are selected then the output file will still be created but be blank (as opposed to not creating the output file at all). Although this point is debatable.

The only concern is that this feature has existed for a very long time and that changing the way it works would constitute a breaking change. I am also not particularly interested in maintaining an additional option to allow users to choose between the old and new behaviors (if implemented).

---

As a side note I managed to implement this kind of functionality based entirely on configuration, without having to use -selection-path/-print-selection at all:

map Q :{{
    $echo "$fs" > "/proc/$id/fd/1"
    quit
}}

Though at this point I think it's probably too late to remove these options, and that it's better to just keep them as builtins.

[joelim-work]

I think the following patch should work, leaving it here for reference.

Click to expand

diff --git a/app.go b/app.go
index 45e0dbd..2dc7575 100644
--- a/app.go
+++ b/app.go
@@ -31,11 +31,10 @@ type app struct {
 	cmdHistoryBeg  int
 	cmdHistoryInd  int
 	menuCompActive bool
 	menuComps      []string
 	menuCompInd    int
-	selectionOut   []string
 	watch          *watch
 }
 
 func newApp(ui *ui, nav *nav) *app {
 	quitChan := make(chan struct{}, 1)
diff --git a/client.go b/client.go
index 00fa1f5..d358aa2 100644
--- a/client.go
+++ b/client.go
@@ -68,20 +68,20 @@ func run() {
 
 	if gLastDirPath != "" {
 		writeLastDir(gLastDirPath, app.nav.currDir().path)
 	}
 
-	if gSelectionPath != "" && len(app.selectionOut) > 0 {
-		writeSelection(gSelectionPath, app.selectionOut)
+	if gSelectionPath != "" {
+		writeSelection(gSelectionPath, app.nav.currSelections())
 	}
 
 	if gPrintLastDir {
 		fmt.Println(app.nav.currDir().path)
 	}
 
-	if gPrintSelection && len(app.selectionOut) > 0 {
-		for _, file := range app.selectionOut {
+	if gPrintSelection {
+		for _, file := range app.nav.currSelections() {
 			fmt.Println(file)
 		}
 	}
 }
 
diff --git a/eval.go b/eval.go
index 445d081..16f7d63 100644
--- a/eval.go
+++ b/eval.go
@@ -1074,16 +1074,10 @@ func (e *callExpr) eval(app *app, args []string) {
 			restartIncCmd(app)
 			onChdir(app)
 			return
 		}
 
-		if gSelectionPath != "" || gPrintSelection {
-			app.selectionOut, _ = app.nav.currFileOrSelections()
-			app.quitChan <- struct{}{}
-			return
-		}
-
 		app.ui.loadFileInfo(app.nav)
 
 		if cmd, ok := gOpts.cmds["open"]; ok {
 			cmd.eval(app, e.args)
 		}
diff --git a/main.go b/main.go
index 985d842..efaf8c2 100644
--- a/main.go
+++ b/main.go
@@ -248,11 +248,11 @@ func main() {
 		"print the last dir to stdout on exit (to use for cd)")
 
 	printSelection := flag.Bool(
 		"print-selection",
 		false,
-		"print the selected files to stdout on open (to use as open file dialog)")
+		"print the selected files to stdout on exit")
 
 	remoteCmd := flag.String(
 		"remote",
 		"",
 		"send remote command to server")
@@ -273,11 +273,11 @@ func main() {
 		"path to the file to write the last dir on exit (to use for cd)")
 
 	flag.StringVar(&gSelectionPath,
 		"selection-path",
 		"",
-		"path to the file to write selected files on open (to use as open file dialog)")
+		"path to the file to write selected files on exit")
 
 	flag.StringVar(&gConfigPath,
 		"config",
 		"",
 		"path to the config file (instead of the usual paths)")

[superiums]

got it, thanks very much !

[CatsDeservePets]

I updated the documentation. It now explains how -print-selection and -selection-path work. Hopefully, this makes things more clear.

I also added the following example:

lf -command 'set nopreview; set ratios 1; set drawbox; set promptfmt "Select files [%w] %S q: cancel, l: confirm"' -print-selection

It creates an "open file" dialog like this:

[joelim-work]

@CatsDeservePets Oh was this the main reason why you added documentation for the command line options in #2200?

It's been a while since I last thought about this, but if this is such a big problem then I would say that it's best to just change the behavior to write the selection on quit instead of open. Aside from being unintuitive, using open for selection is problematic if there are only directories in view (have to find a regular file just to quit), or if dironly is enabled. Cancellation can still be done by selecting nothing (unselect) and then quitting.

The only concern is that other file managers like joshuto and yazi have also decided to copy this behavior from ranger. However I am still fine with changing it (even if it is a breaking change), so long as users can still configure the old behavior. The lf_flag_print_selection environment variable can be used to see if this mode is enabled or not.

[CatsDeservePets]

This flag made me think about the lack of flag documentation in general so it definitely was one if not the reason for it.

Personally, I find the current behaviour quite logical, actually. Just imagine the "open dialog" inside a gui application. You first select the files you want to open and then confirm the selection by pressing <enter>. Pressing <esc> discards the dialog.

The least logical part about this seems to me being able to open/confirm the selected files by opening a not selected file (I did not look inside the code but I assume $fx being used here). And yeah, combining -print-selection with dironly is something I tried myself while writing the documentation and it made me giggle a bit.

[joelim-work]

The least logical part about this seems to me being able to open/confirm the selected files by opening a not selected file (I did not look inside the code but I assume $fx being used here).

The code for confirming the selection is here: https://github.com/gokcehan/lf/blob/a949d4a5d186f07e3a7a6cf1a1356fa72adfb4d1/eval.go#L1073-L1077

You just need to trigger the open command on any file that isn't a directory.

I would say that 'confirming' has a different meaning to 'opening' so assigning them the same key is confusing, but I am also of the opinion that this kind of feature should have been implemented as a tip (i.e. configuration file only) rather than a builtin, so it is too late to do anything about it.

Anyway I don't have much more to add to the discussion, especially since I don't use this feature personally.