[Discussion] Enabling bash-it components to communicate messages to users #2181
Replies: 13 comments
-
Good points! Here's the thing about failing silently. This was mostly based on the fact that error messages printed during Bash-it initialization were causing issues with things like If we can ensure that Bash-it is not initialized on non-interactive shell sessions (like If we can rule out that messages are printed in undesirable situations, we could add a couple of sensible messages. We certainly don't want to flood the user with dozens of messages, but a note that something is wrong might be OK. Personally, I like the way things like Homebrew handle this. There's a This of course would mean that we introduce a logging system in Bash-it. When a plugin is enabled, but the required command is not installed, the plugin would need to log a message for that, which would be shown when you run The So the following main blocks of work:
Thoughts? |
Beta Was this translation helpful? Give feedback.
-
+1 for |
Beta Was this translation helpful? Give feedback.
-
FYI the fix for non-interactive |
Beta Was this translation helpful? Give feedback.
-
My $0.02 (only worth $0.01): I agree with @nwinkler. If we can ensure initialization is covered, it'd be great not to have silent failures. #1533 is a great first step (plus it fixes macos users' double initializing). |
Beta Was this translation helpful? Give feedback.
-
@cornfeedhobo, @davidpfarrell, @rico-chet, @jpmcb - please see the implementation of the Since there are no log statements so far, the command does not print anything at the moment. As a start, I thought that we might want to add some output to the Other thoughts about places where logging makes sense? |
Beta Was this translation helpful? Give feedback.
-
@nwinkler Thanks for the update - #1623 does look like a good start. Some immediate thoughts: Log Context
I'm thinking that the core bash-it code maintain a I see it as an array of strings, ie Aborted PluginsI think one of the first areas to add logging would be to plugins, adding error messages when plugins abort without activating (due to missing commands, folders, etc). Logging in _command_existsI think adding logging here is probably a good idea, especially in the short term where little/no other logging will exist.
Wondering if That's all for now - Looking forward to seeing how this progresses ! -DF cc: @NoahGorny |
Beta Was this translation helpful? Give feedback.
-
@davidpfarrell Thanks for the summary - that looks good to me!
|
Beta Was this translation helpful? Give feedback.
-
If adding logging to |
Beta Was this translation helpful? Give feedback.
-
Since the logging has been added to A more advanced version with a callstack has been discussed above and in #1628, but was not implemented at the time. If someone wants to build a more advanced version, that would be cool. |
Beta Was this translation helpful? Give feedback.
-
This issue is very stale, so I close it |
Beta Was this translation helpful? Give feedback.
-
I'd like to reopen this. An easy first step would be to just change the default from "fail silently" to "report errors and warnings" (set |
Beta Was this translation helpful? Give feedback.
-
I am reopening- to leave this as a follow-up mission to enhance our logging information. |
Beta Was this translation helpful? Give feedback.
-
My mental model of logging levels (some of which Bash It doesn't have):
I strongly feel that Bash It should run without errors unless something is broken. (There's still a lot of work to do before we can make this claim, but it's a reasonable near-term goal!) If something is broken, Bash It should complain (loudly, IMO)! Warnings I think should alsö be reported to the user, but again I alsö think that Bash It should run without warnings. This may be more of a medium-term goal. Notice seems like what commands should use to tell the user things, like in I'm working towards normal operation without errors or warnings, so hopefully that will come soon. 😃 |
Beta Was this translation helpful? Give feedback.
-
[Adapted from recent Gitter posts]
Q: Seeing how bash-it appears to have a
fail silently
mantra to prevent unwanted terminal output, is there a means for bash-it to communicate issues/messages to the user?At first I was thinking something simple like
bash-it logs
and give components a means for creating log messages to communicate error conditions (ie. functions likelog_error
,log_warning
, etc)But then I thought, in addition to that, maybe something like
bash-it messages
which would contain messages that components generated specifically for the user to see (where as logs could contain many types of messaging, auto-generated statuses, etc) ... (ie.user_message
function)THEN we could also design a prompt segment for letting the user know when messages are waiting to be read.
Also, feels like we could give ourselves permission to message the user when initiating a
login
session. Even if it was just to say something like"You have bash-it messages waiting to be read. Use 'bash-it messages' to read them."
Beta Was this translation helpful? Give feedback.
All reactions