Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

_filedir: remove . and .. from suggestions #364

Closed
wants to merge 1 commit into from
Closed

_filedir: remove . and .. from suggestions #364

wants to merge 1 commit into from

Conversation

Maelan
Copy link
Contributor

@Maelan Maelan commented Nov 10, 2019

The title says it all. This is a breaking change, but I would be surprised if anyone entered e.g. the text .. by typing Ctrl+j twice. This change allows to fully complete a hidden file name when there is only one hidden file besides . and .. (or at least, to benefit from prefix completion, such as with .git and .gitignore).

@Maelan
Copy link
Contributor Author

Maelan commented Mar 14, 2021

Any chance that this gets merged some day? This is easy to review.

@scop scop force-pushed the master branch 3 times, most recently from c0e9459 to 09307f8 Compare March 30, 2021 15:12
@scop
Copy link
Owner

scop commented Apr 6, 2021

Easy to review, hard to decide. The goal makes sense to me, but then again I'm not convinced we want to do that. It feels just so weird not be able to start to complete a longer path that way.

I don't follow what you mean by Ctrl+J though, I thought the offending completions would be there just by entering them, i.e. the periods, as is, then tab as usual etc.

There's a bunch of stylistic issues in the patch, some of which would likely be fixed by shfmt. But I'll point them out if/once we know that + the fixing work wouldn't be a waste of your and my time.

@Maelan
Copy link
Contributor Author

Maelan commented Apr 6, 2021

I’m not sure I get your concern about longer paths. Which kind of paths this patch would prevent you from completing? Unless I’ve overlooked something, it only removes paths which are equal to . or .., it does not remove longer paths that involve such dots.

(About Ctrl+J: I was simply saying that, currently, someone who would want to enter .. using bash-completion, would use Ctrl+J for that purpose (typing .<tab> wouldn’t work because the dot is a common prefix to at least . and ..). But this looks pointless anyway.)

@scop
Copy link
Owner

scop commented Apr 16, 2021

It will break for example ls ..<Tab>, no completions offered after that. One has to manually type at least up to the trailing slash as in ./or ../ to get completion towards the current or parent dir going further. Personally, the current dir case is a rarity, but with completions starting with the parent dir I tab a lot, and having to enter the slash interferes badly with my muscle memory there. Likely because at least with my keyboard layout (Finnish FWIW) it is much easier to reach the tab than the slash (which requires both hands).

@Maelan
Copy link
Contributor Author

Maelan commented Apr 17, 2021

I see now. Then, what about removing . and .. only when the word being completed is . ?

By the way, I realize that the behavior I originally proposed and implemented lacks generality, we should do this instead: when the word being completed is . or ends with /., we discard . and .. and anything that ends with /. or /.. from completions.

@scop
Copy link
Owner

scop commented Apr 17, 2021

For the . case, I think I would be annoyed if hitting tab after it gave me e.g. .gitignore without any options when I meant to be going to the parent dir. Surely I could learn not to hit tab there but just do the two periods, but I don't know.

For the ends with /. case, I see some problems too, for example when variables are involved ($somedir/.. etc) or tildes (~/.. etc). And actually just going more than one level upwards (../.. etc).

@Maelan Maelan closed this Jun 23, 2024
@Maelan Maelan deleted the master branch June 23, 2024 12:06
@Maelan Maelan mentioned this pull request Jul 2, 2024
Merged
akinomyoga pushed a commit to Maelan/bash-completion that referenced this pull request Aug 11, 2024
@Maelan @akinomyoga
feat(_comp_compgen_filedir{,_xspec}): do not generate . and ..
f543c7e 
Currently, "." and ".." are generated as completions when the current
path segment starts with a dot.  However, this impedes the completion
of any dotfiles when the current path segments is "." because the word
"." already matches the generated ".".  When the user attempts the
completion after inputting ".", the user is likely to intend to
complete a dotfile name as ".dotfile" (rather than to complete just a
slash as "./" because the user could just press "/" in such a case).
In this patch, we do not generate "." and ".." unless the user has
explicitly input "..".

The behavioral changes are summarized below.  Other possibilities of
the detailed behaviors are commented in the "[ Note: ... ]" sections.
If necessary, they can be reconsidered and adjusted in later commits.

* cmd .[TAB]

  When the current directory has no dotfiles (i.e., filenames starting
  with "."), it completed a slash.  Nothing will happen after this
  patch. [ Note: as another option, we might generate "." only when no
  dotfiles are found.  However, that might be annoying when the user
  tries to probe the existence of the dotfiles by pressing TAB, where
  the user does not expect the insertion of a slash. ]

  When the current directory has dotfiles, nothing happened.  After
  this patch, this will insert the common prefix of the dotfiles.
  Note that both "." and ".." are ignored in determining the common
  prefix.

* cmd ..[TAB]

  When the current directory has no files starting with "..", this
  completes a slash to form "../".  The behavior will not be changed
  by this patch. [ Note: as another option, we might disable ".." at
  all to be consistent with the case of ".".  However, the files
  starting with ".." are unlikely, and the user is less likely to
  probe the existence of the files starting with ".." by pressing TAB
  after "..".  For this reason, we generate ".." even if it would
  prevent completion of the common prefix of the files. ]

  When the current directory has files starting with "..", nothing
  happens with this.  The behavior will not be changed by this
  patch. [ Note: as another option, we might generate ".." only when
  there are no files starting with "..", but we here assume that the
  user may want to complete a slash as ".." even when there are files
  starting with "..". ]

References:
scop#364
scop#1230
akinomyoga pushed a commit to Maelan/bash-completion that referenced this pull request Aug 11, 2024
@Maelan @akinomyoga
feat(_comp_compgen_filedir{,_xspec}): do not generate "." and ".."
0973b43 
Currently, "." and ".." are generated as completions when the current
path segment starts with a dot.  However, this impedes the completion
of any dotfiles when the current path segments is "." because the word
"." already matches the generated ".".  When the user attempts the
completion after inputting ".", the user is likely to intend to
complete a dotfile name as ".dotfile" (rather than to complete just a
slash as "./" because the user could just press "/" in such a case).
In this patch, we do not generate "." and ".." unless the user has
explicitly input "..".

The behavioral changes are summarized below.  Other possibilities of
the detailed behaviors are commented in the "[ Note: ... ]" sections.
If necessary, they can be reconsidered and adjusted in later commits.

* cmd .[TAB]

  When the current directory has no dotfiles (i.e., filenames starting
  with "."), it completed a slash.  Nothing will happen after this
  patch. [ Note: as another option, we might generate "." only when no
  dotfiles are found.  However, that might be annoying when the user
  tries to probe the existence of the dotfiles by pressing TAB, where
  the user does not expect the insertion of a slash. ]

  When the current directory has dotfiles, nothing happened.  After
  this patch, this will insert the common prefix of the dotfiles.
  Note that both "." and ".." are ignored in determining the common
  prefix.

* cmd ..[TAB]

  When the current directory has no files starting with "..", this
  completes a slash to form "../".  The behavior will not be changed
  by this patch. [ Note: as another option, we might disable ".." at
  all to be consistent with the case of ".".  However, the files
  starting with ".." are unlikely, and the user is less likely to
  probe the existence of the files starting with ".." by pressing TAB
  after "..".  For this reason, we generate ".." even if it would
  prevent completion of the common prefix of the files. ]

  When the current directory has files starting with "..", nothing
  happens with this.  The behavior will not be changed by this
  patch. [ Note: as another option, we might generate ".." only when
  there are no files starting with "..", but we here assume that the
  user may want to complete a slash as ".." even when there are files
  starting with "..". ]

References:
scop#364
scop#1230
akinomyoga added a commit to Maelan/bash-completion that referenced this pull request Aug 11, 2024
@Maelan @akinomyoga
feat(_comp_compgen_filedir{,_xspec}): do not generate "." and ".."
eaa9bca 
Currently, "." and ".." are generated as completions when the current
path segment starts with a dot.  However, this impedes the completion
of any dotfiles when the current path segments is "." because the word
"." already matches the generated ".".  When the user attempts the
completion after inputting ".", the user is likely to intend to
complete a dotfile name as ".dotfile" (rather than to complete just a
slash as "./" because the user could just press "/" in such a case).
In this patch, we do not generate "." and ".." unless the user has
explicitly input "..".

The behavioral changes are summarized below.  Other possibilities of
the detailed behaviors are commented in the "[ Note: ... ]" sections.
If necessary, they can be reconsidered and adjusted in later commits.

* cmd .[TAB]

  When the current directory has no dotfiles (i.e., filenames starting
  with "."), it completed a slash.  Nothing will happen after this
  patch. [ Note: as another option, we might generate "." only when no
  dotfiles are found.  However, that might be annoying when the user
  tries to probe the existence of the dotfiles by pressing TAB, where
  the user does not expect the insertion of a slash. ]

  When the current directory has dotfiles, nothing happened.  After
  this patch, this will insert the common prefix of the dotfiles.
  Note that both "." and ".." are ignored in determining the common
  prefix.

* cmd ..[TAB]

  When the current directory has no files starting with "..", this
  completes a slash to form "../".  The behavior will not be changed
  by this patch. [ Note: as another option, we might disable ".." at
  all to be consistent with the case of ".".  However, the files
  starting with ".." are unlikely, and the user is less likely to
  probe the existence of the files starting with ".." by pressing TAB
  after "..".  For this reason, we generate ".." even if it would
  prevent completion of the common prefix of the files. ]

  When the current directory has files starting with "..", nothing
  happens with this.  The behavior will not be changed by this
  patch. [ Note: as another option, we might generate ".." only when
  there are no files starting with "..", but we here assume that the
  user may want to complete a slash as ".." even when there are files
  starting with "..". ]

References:
scop#364
scop#1230

Co-authored-by: Koichi Murase <myoga.murase@gmail.com>
scop pushed a commit that referenced this pull request Nov 13, 2024
@Maelan @akinomyoga @yedayak
feat(_comp_compgen_filedir,_comp_compgen_filedir_xspec): don’t sugges…
0e7a0cf 
…t . and .. (#1230)

* feat(_comp_compgen_filedir{,_xspec}): do not generate "." and ".."

Currently, "." and ".." are generated as completions when the current
path segment starts with a dot.  However, this impedes the completion
of any dotfiles when the current path segments is "." because the word
"." already matches the generated ".".  When the user attempts the
completion after inputting ".", the user is likely to intend to
complete a dotfile name as ".dotfile" (rather than to complete just a
slash as "./" because the user could just press "/" in such a case).
In this patch, we do not generate "." and ".." unless the user has
explicitly input "..".

The behavioral changes are summarized below.  Other possibilities of
the detailed behaviors are commented in the "[ Note: ... ]" sections.
If necessary, they can be reconsidered and adjusted in later commits.

* cmd .[TAB]

  When the current directory has no dotfiles (i.e., filenames starting
  with "."), it completed a slash.  Nothing will happen after this
  patch. [ Note: as another option, we might generate "." only when no
  dotfiles are found.  However, that might be annoying when the user
  tries to probe the existence of the dotfiles by pressing TAB, where
  the user does not expect the insertion of a slash. ]

  When the current directory has dotfiles, nothing happened.  After
  this patch, this will insert the common prefix of the dotfiles.
  Note that both "." and ".." are ignored in determining the common
  prefix.

* cmd ..[TAB]

  When the current directory has no files starting with "..", this
  completes a slash to form "../".  The behavior will not be changed
  by this patch. [ Note: as another option, we might disable ".." at
  all to be consistent with the case of ".".  However, the files
  starting with ".." are unlikely, and the user is less likely to
  probe the existence of the files starting with ".." by pressing TAB
  after "..".  For this reason, we generate ".." even if it would
  prevent completion of the common prefix of the files. ]

  When the current directory has files starting with "..", nothing
  happens with this.  The behavior will not be changed by this
  patch. [ Note: as another option, we might generate ".." only when
  there are no files starting with "..", but we here assume that the
  user may want to complete a slash as ".." even when there are files
  starting with "..". ]

References:
#364
#1230

Co-authored-by: Koichi Murase <myoga.murase@gmail.com>
Co-authored-by: Yedaya Katsman <yedaya.ka@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@Maelan @scop