Newest at the top
| 2024-09-22 23:32:33 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-22 23:24:46 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-09-22 23:21:44 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2024-09-22 23:16:47 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-22 23:08:00 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-09-22 23:03:07 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-22 23:01:24 +0200 | <haskellbridge> | <sm> it also gets more complicated if you want your tool to run external exes as subcommands, as recent cabal does |
| 2024-09-22 23:00:18 +0200 | <haskellbridge> | <sm> I think that kind of position sensitivity in clis is uncommon because it requires custom logic (or more flexibility than exists in the vast majority of parsing libs) |
| 2024-09-22 22:57:08 +0200 | <tomsmeding> | `cabal run foo xyz` does run `foo xyz` |
| 2024-09-22 22:57:01 +0200 | <tomsmeding> | it's not what cabal does, for better or for worse |
| 2024-09-22 22:56:29 +0200 | <gwern> | (ie. 'cabal run --option foo' obviously means that '--option' is for 'cabal run' and not for 'foo', and so 'cabal run --option1 foo --option2' is not ambiguous and doesn't need any guarding) |
| 2024-09-22 22:55:57 +0200 | <haskellbridge> | <sm> gwern: that's a possible convention, but would be surprising to some people. Robust command line processing is quite hard |
| 2024-09-22 22:55:42 +0200 | <gwern> | a wrapper like that doesn't usually *need* the ' -- ' guard |
| 2024-09-22 22:55:40 +0200 | <tomsmeding> | it also takes them after the executable name -- not sure why |
| 2024-09-22 22:55:17 +0200 | <gwern> | just sounds odd. I would expect cabal run to only take its options if they came before 'foo', or before 'run' even |
| 2024-09-22 22:54:52 +0200 | <tomsmeding> | I mean, even if that did work, that wouldn't make fish's completion any more functional :p |
| 2024-09-22 22:54:25 +0200 | <gwern> | `cabal run foo --abc` doesn't automatically turn that into running `foo --abc`? |
| 2024-09-22 22:54:23 +0200 | <haskellbridge> | <sm> when I want to run anything in the context of a project's package environment, I'm doing stack exec -- ... or cabal exec -- ... |
| 2024-09-22 22:54:17 +0200 | <tomsmeding> | `cabal run` takes an executable name (to build and run) and, after `--`, arguments to said executable |
| 2024-09-22 22:53:53 +0200 | <tomsmeding> | gwern: just to pass arguments to the program I'm `cabal run`ing |
| 2024-09-22 22:53:41 +0200 | <gwern> | what unsafe arguments do you need ' -- ' for? |
| 2024-09-22 22:53:15 +0200 | <haskellbridge> | <sm> -- is important |
| 2024-09-22 22:53:00 +0200 | <haskellbridge> | <sm> oh that's annoying |
| 2024-09-22 22:52:49 +0200 | <tomsmeding> | (fish's cabal completion script doesn't understand '--' meaning that I get negative utility when passing arguments to 'cabal run something -- ...', and I hate it, but not quite enough to go and fix it) |
| 2024-09-22 22:52:34 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 260 seconds) |
| 2024-09-22 22:52:07 +0200 | <tomsmeding> | (in the cases where the completion script is overly restrictive) |
| 2024-09-22 22:51:52 +0200 | <tomsmeding> | I always find it incredibly annoying if some completion script decides for me that it will only complete certain kinds of things for me, meaning that I don't even get a list reminding me of the full thing to type -- I actually have to bail out, `ls`, and type if over |
| 2024-09-22 22:51:48 +0200 | <haskellbridge> | <sm> completion scripts can be smart about such things |
| 2024-09-22 22:51:10 +0200 | <tomsmeding> | mind that some options to ghc(i) do take non-.hs files, such as ghci -ghci-script |
| 2024-09-22 22:49:56 +0200 | <haskellbridge> | <sm> sounds like a good addition to ghc.bash |
| 2024-09-22 22:49:50 +0200 | <haskellbridge> | <sm> s/and especially ghc contributors// |
| 2024-09-22 22:49:38 +0200 | <tomsmeding> | and if they are, it's for small examples where dumb tab completion is more than sufficient |
| 2024-09-22 22:49:37 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2024-09-22 22:49:12 +0200 | <haskellbridge> | <sm> I think a lot of haskellers and especially ghc contributors are not often running "ghc" directly |
| 2024-09-22 22:48:39 +0200 | <gwern> | (gwern.net has gotten kinda complicated in terms of tooling and libraries) |
| 2024-09-22 22:48:22 +0200 | <gwern> | and the more hs files you have, the worse it gets since it's multiplicative: a .o and .hi for every .hs, or worse, in my case because I have a bunch of php, python, and bash scripts which also get picked up by the tab-completion... |
| 2024-09-22 22:47:32 +0200 | <haskellbridge> | <sm> yes I see, you have to type all of "foo" |
| 2024-09-22 22:47:20 +0200 | merijn | (~merijn@204-220-045-062.dynamic.caiway.nl) |
| 2024-09-22 22:47:10 +0200 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-09-22 22:46:27 +0200 | <gwern> | then you have to cycle through the wrong ones |
| 2024-09-22 22:45:52 +0200 | <haskellbridge> | <sm> and excluding wrong file extensions is another use I hadn't thought of. I would tend to just type "ghc foo" omitting the extension |
| 2024-09-22 22:44:51 +0200 | <haskellbridge> | <sm> I never use bash completions, because they don't work in emacs shell and because I'm using osh, but I must say when you have good ones they're pretty handy for discovery and learning |
| 2024-09-22 22:43:58 +0200 | <haskellbridge> | <sm> yup |
| 2024-09-22 22:43:46 +0200 | <gwern> | maybe. but in this case, it was very quickly apparent why it wasn't working: because there was none at all on my system. the question became, why isn't it there |
| 2024-09-22 22:43:46 +0200 | <tomsmeding> | I see, I should have actually looked at the file :p |
| 2024-09-22 22:43:09 +0200 | <haskellbridge> | <sm> would claude or chatgpt tell you why ghc completions don't work on your system ? I guess maybe |
| 2024-09-22 22:43:05 +0200 | <gwern> | tomsmeding: the ghc.bash looks like it's ancient and hasn't been touched in years, and is focused on the cli options. while what I want is to avoid the damn thing completing on *.hi and *.o and stuff like that |
| 2024-09-22 22:42:10 +0200 | <haskellbridge> | <sm> cool |
| 2024-09-22 22:42:04 +0200 | <tomsmeding> | I would assume the ghc.bash original the ghc repo is higher-quality than whatever comes out of an AI -- and if not, that's a bug report to the GHC repo :) |
| 2024-09-22 22:41:17 +0200 | <gwern> | sm: well, I ran through a bunch of versions to get the cycling right, yeah, and to clean it up and remove shellcheck warnings and document it. haven't run into any further issues inasmuch as I just created it |