Bug 358221 - Tilde/variable expansion is treated differently than the equivalent path
Summary: Tilde/variable expansion is treated differently than the equivalent path
Status: RESOLVED FIXED
Alias: None
Product: krunner
Classification: Plasma
Component: general (show other bugs)
Version: 5.5.3
Platform: Other Linux
: NOR minor
Target Milestone: ---
Assignee: Alexander Lohnau
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-19 18:34 UTC by Chris Spiegel
Modified: 2020-12-30 10:44 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.21


Attachments
Proof of concept patch to partially address the issue (3.83 KB, patch)
2016-01-19 18:37 UTC, Chris Spiegel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Spiegel 2016-01-19 18:34:36 UTC
When tilde/variable expansion is used in krunner, suggested completions are different than if the complete path had been used.

Example: I open krunner and type:

~/foobar

or

$HOME/foobar

Where $HOME/foobar is a directory.  The result is that a lot of documents are returned in the search dropdown, followed by the Locations area, which has “Go to file:///home/me/foobar”.

However, if instead I enter:

/home/me/foobar

Just the Locations area shows up and it directly says “Open /home/me/foobar”.

The biggest problem with this is that if I type “~/foobar” and hit enter, it opens whatever document happens to be at the top of the list, whereas my expected behavior is that it opens the directory, since I specified it exactly.  Essentially, since ~/foo and /home/me/foo are the same thing, they should be treated identically.

Reproducible: Always

Steps to Reproduce:
1. Hit Alt-F2 to open the krunner dialog
2. Enter a valid path to a file in your home directory, using ~ to represent your home directory

Actual Results:  
If the search string matches documents, they are listed first, meaning you have to navigate down to the Locations area to open the file/directory.

Expected Results:  
If a path to an existing file is specified, that is the first entry in the list so hitting enter causes the file to be opened.
Comment 1 Chris Spiegel 2016-01-19 18:37:46 UTC
Created attachment 96739 [details]
Proof of concept patch to partially address the issue

With this patch, search entries using a tilde which exist as local files are treated as such rather than as unknown URLs.  It doesn't support variable expansion, so it's really just a proof of concept.
Comment 2 Justin Zobel 2020-11-22 03:47:05 UTC
Confirmed here on openSUSE Tumbleweed. I agree, the path if it exists should be the first option.
Comment 3 Alexander Lohnau 2020-12-12 21:59:43 UTC
>With this patch, search entries using a tilde which exist as local files are treated as such rather than as unknown URLs. 

This is fixed already. Variable expansion is more difficult, but I am on it :)
Comment 4 Alexander Lohnau 2020-12-30 10:44:01 UTC
Git commit 736218793abd50d04bf140cc5cd2a8e9292c47f3 by Alexander Lohnau.
Committed on 30/12/2020 at 10:43.
Pushed by alex into branch 'master'.

Expand ENV variables before displaying results

Before the variables would get expanded later and consequently
go through another code path than file locations. This leads to the
text being differently displayed and users getting confused.

Also this allows us to check if the file actually exists.
FIXED-IN: 5.21

M  +8    -14   runners/locations/locationrunner.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/736218793abd50d04bf140cc5cd2a8e9292c47f3