
"Workarounds" are for problems, but I don't understand why duplicate file names are a problem. Can you elaborate? Perhaps this is problem with your IDE/editor setup? Many of us (as can be seen in responses) use tools/editors/IDEs that can handle this just fine.
I worked on projects with duplicate file names in the past too; having tools that can deal with this helps, and I don't think this is too hard to achieve. You can't ask devs of every project you join to rename their files because your editor can't handle them. But I can ask if we really want to create more identical ones :) GHC already has a few duplicate file names. It's not a tragedy.
File names as the primary identifier crops up all the time. Be it `find`ind files, jumping to them in the editor or other things. It's not horrible by any means. VS Code has fuzzy search which usually works for me in these cases. Although it might not work so well if we rename all 15 Utils modules in ghc to Utils.hs. Overall it just seems easier to work with unique names when we have the choice to do so. And clearly in this case we have the choice. Personally I never ran into a situation where prefixing the file name was an issue at all. But cases where non-unique names cause annoyance do happen from time to time. Hence why I prefer one over the other.
(I don't know VS Code enough to help ..)
Ömer
Andreas Klebinger
, 24 Eki 2019 Per, 14:48 tarihinde şunu yazdı: Hello devs,
I also often jump to files. In my case usually using VS Code using Ctr+P as well which searches for files by name. While I can check which folder a file is in in the case of duplicates it is a overhead which this refactor forces onto me.
While there are workarounds, both for my case as for Matts. It's worth asking if requiring these workarounds is better than just accepting redundant prefixes on module names.
Personally I would prefer unique file names even at the cost of redundancy. I rarely add import statements/full module names, but I *very* often jump to files.
Cheers Andreas
Bryan Richter schrieb am 23.10.2019 um 18:00:
Duplicate record fields is going to make this a bigger problem. Vim does support duplicate tags (:tselect and :tjump and related bindings), but hopefully haskell-ide-engine will one day provide us with semantic tags and solve this problem once and for all!
On Wed, 23 Oct 2019, 17.49 Matthew Pickering,
wrote: Thanks Omer, Sylvain and Sebastian
.
I just configured my editor to use fzf and now I can use the `:GFiles` command to perform fuzzy search on files which is probably better than tags. If anyone else is using NixOS, all I had to do was add the `fzf-vim` plugin to the vim configuration.
Cheers,
Matt
On Wed, Oct 23, 2019 at 2:54 PM Ömer Sinan Ağacan
wrote: I use a file finder (fzf) for jumping to files. Because module names follow file paths to jump to e.g. StgToCmmUtils.Utils I usually type `<C-p>stgcmmutils` and fzf finds the correct file `compiler/GHC/StgToCmm/Utils.hs`.
When generating tags I omit module names for this reason, it's easy with a good file finder to jump to modules already, no need to generate tags for the modules.
fast-tags commands I use:
- When working on the compiler:
$ fast-tags --no-module-tags driver ghc compiler
- When working on the RTS:
$ fast-tags --no-module-tags driver ghc compiler $ ctags --append -R rts/**/*.c rts/**/*.h includes/**/*.h
- When working on the libraries:
$ fast-tags --no-module-tags driver ghc compiler libraries
Ömer
Sebastian Graf
, 23 Eki 2019 Çar, 16:49 tarihinde şunu yazdı: FWIW, I'm using VSCode's fuzzy file search with Ctrl+P (and vim's equivalent) rather successfully. Just tried it for Hs/Utils.hs by typing 'hsutils.hs'. It didn't turn up as the first result in VSCode, but it in vim.
Am Mi., 23. Okt. 2019 um 14:27 Uhr schrieb Matthew Pickering
: I use `fast-tags` which doesn't look at the hierarchy at all and I'm not sure what the improvement would be as the names of the modules would still clash.
If there is some other recommended way to jump to a module then that would also work for me.
Matt
On Wed, Oct 23, 2019 at 12:08 PM Sylvain Henry
wrote: > Hi, > > How do you generate your tags file? It seems to be a shortcoming of the > generator to not take into account the location of the definition file. > > > Perhaps `HsUtils` and `StgUtils` would be appropriate to > disambiguate`Hs/Utils` and `StgToCmm/Utils`. > > We are promoting the module prefixes (`Hs`, `Stg`, `Tc`, etc.) into > proper module layers (e.g. `HsUtils` becomes `GHC.Hs.Utils`) so it would > be redundant to add the prefixes back. :/ > > Cheers, > Sylvain > > On 23/10/2019 12:52, Matthew Pickering wrote: >> Hi, >> >> The module rework has broken my workflow. >> >> Now my tags file is useless for jumping for modules as there are >> multiple "Utils" and "Types" modules. Invariable I am jumping to the >> wrong one. What do other people do to avoid this? >> >> Can we either revert these changes or give these modules unique names >> to facilitate that only reliable way of navigating the code base. >> Perhaps `HsUtils` and `StgUtils` would be appropriate to disambiguate >> `Hs/Utils` and `StgToCmm/Utils`. >> >> Cheers, >> >> Matt >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs