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.

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

Make gf not prompt with helm if file exists in normal state #4837

Closed
nixmaniack opened this issue Jan 27, 2016 · 12 comments
Closed

Make gf not prompt with helm if file exists in normal state #4837

nixmaniack opened this issue Jan 27, 2016 · 12 comments
Labels
Enhancement ☺ Reported upstream stale marked as a stale issue/pr (usually by a bot)

Comments

@nixmaniack
Copy link
Contributor

Description

gf shouldn't prompt with helm if file already exits and visitable. The normal behaviour of vim is to visit that file directly.

Reproduction guide

  • Start Emacs
  • On a valid file under point(e.g. ~/.spacemacs), in normal state, press gf

Observed behaviour:
Opens up helm prompt where you have to hit return to visit the file.

Expected behaviour:
You shouldn't need to hit return in case file is present and readable.

System Info

  • OS: darwin
  • Emacs: 24.5.1
  • Spacemacs: 0.105.9
  • Spacemacs branch: develop (rev. 72e1413)
  • Distribution: spacemacs
  • Editing style: hybrid
  • Completion: helm
  • Layers:
((auto-completion :variables auto-completion-enable-snippets-in-popup t auto-completion-enable-sort-by-usage t auto-completion-enable-help-tooltip nil auto-completion-private-snippets-directory "~/.spacemacs.d/snippets/" :disabled-for org erc)
 semantic better-defaults emacs-lisp
 (git :variables git-gutter-use-fringe t git-magit-status-fullscreen nil)
 github markdown yaml shell
 (spell-checking :variables spell-checking-enable-by-default t spell-checking-enable-auto-dictionary t)
 syntax-checking
 (elfeed :variables rmh-elfeed-org-files
         (list "~/.emacs.d/private/elfeed.org"))
 lua python ruby ruby-on-rails
 (clojure :variables clojure-enable-fancify-symbols t)
 shell-scripts html javascript dockerfile eyebrowse spacemacs-layouts
 (mu4e :variables mu4e-installation-path "/usr/local/share/emacs/site-lisp/mu4e/")
 nix-mu4e gnus colors deft finance
 (ibuffer :variables ibuffer-group-buffers-by 'projects)
 (version-control :variables version-control-diff-tool 'diff-hl)
 ansible emoji ranger osx typography
 (theming :variables theming-headings-inherit-from-default 'all theming-headings-same-size 'all theming-headings-bold 'all)
 org)
@CestDiego
Copy link
Contributor

this ^

@nixmaniack
Copy link
Contributor Author

@StreakyCobra To me, it looks this is a bug rather than enhancement.

@TheBB
Copy link
Collaborator

TheBB commented Jan 27, 2016

@StreakyCobra
Copy link
Contributor

@nixmaniack As far as understand there is no wrong behavior here, no? I mean, it would be a better default and closer to vim of course, but currently this is the intended behavior.

Feel free to correct me if I'm wrong :-)

@nixmaniack
Copy link
Contributor Author

Okay, may be an enhancement at spacemacs but certainly a bug at evil! 😄 Should this be reported upstream?

@StreakyCobra
Copy link
Contributor

Oh, I think I understand your point now, why you say it's maybe a bug.

Can you try in a raw emacs with evil only if gf directly open the file or if it prompts for it? If it prompts for it then it means that spacemacs is doing it correctly by just replacing the prompt with helm. If it opens directly the file, it means that we are doing it wrong as we ask for the file.

@zakkak
Copy link
Contributor

zakkak commented Jan 31, 2016

evil-mode's gf both in spacemacs and vanilla emacs invokes find-file-at-point which prompts for the file, so I guess this should be fixed in evil-mode.

@nixmaniack
Copy link
Contributor Author

@StreakyCobra
Copy link
Contributor

@nixmaniack 👍 Thanks

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

@github-actions github-actions bot added the stale marked as a stale issue/pr (usually by a bot) label Feb 29, 2020
@nixmaniack
Copy link
Contributor Author

Relocated upstream issue link: emacs-evil/evil#614

@duianto duianto removed the stale marked as a stale issue/pr (usually by a bot) label Mar 15, 2020
@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

@github-actions github-actions bot added the stale marked as a stale issue/pr (usually by a bot) label Mar 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement ☺ Reported upstream stale marked as a stale issue/pr (usually by a bot)
Projects
Upstream bugs
Reported, waiting
Development

No branches or pull requests

6 participants