Oh-my-posh3: Checking for default user

[meakbiyik]

Is there a way to check for the default user in the "Session" segment, just like the way in version 2? I really do not find it necessary to add a whole colorful segment to every prompt when I am not ssh-ing somewhere or doing something out of ordinary.

Thanks in advance!

[JanDeDobbeleer]

@meakbiyik you mean hide the segment when it's "you"?

[meakbiyik]

Yep, exactly. I have the default user profile name set up in the powershell profile, but I guess at this point it should be somehow included into the theme, or maybe a config file of ohmyposh3?

[JanDeDobbeleer]

I would in that case add the name of the default and have a switch that hides the segment when that matches.

{
  "type": "session",
  "style": "diamond",
  "foreground": "#ffffff",
  "background": "#c386f1",
  "leading_diamond": "\uE0B6",
  "trailing_diamond": "\uE0B0",
  "properties": {
    "default_user": "jan",
    "hide_default_user": true
  }
}

[meakbiyik]

Although I asked for this, I can also see that this would break the abstraction of the themes. I have a different proposal if you are interested: ohmyposh can save the username that installs itself or runs it the first time (into a config file), and do the checking with that. This configuration might be made editable with a cmd command.

The property addition looks very accurate though.

[JanDeDobbeleer]

Those properties can be added without breaking existing functionality, it's simply an extension. hide_default_user defaults to false and there's nothing that breaks. I'll do this. I want to avoid using config files like that as the cross platform nature makes that very challenging too (there's not only Powershell to consider anymore ;-))

[meakbiyik]

No no, not that it breaks any component, I was referring to a more idealistic concept. Like, in order to activate that feature, one would have to manually go into the theme and add their username, the themes would not be ready out of the box.

I see your point though (having your own config file as ohmyposh shouldn't mess with cross platform, but would indeed increase the component count and make it harder to move around). One plus side: since the user name is something that the program can infer, you can completely hide it maybe by adding it to the themes as variable:

{
  "type": "session",
  "style": "diamond",
  "foreground": "#ffffff",
  "background": "#c386f1",
  "leading_diamond": "\uE0B6",
  "trailing_diamond": "\uE0B0",
  "properties": {
    "default_user": $USER,
    "hide_default_user": true
  }
}

And when installing a theme, you can fill that space with the username of the installer.

-- Well, to be honest it does not matter how it works for me as long as the "out-of-the-box" nature of the themes are preserved.

---- You know what, on the second thought I am not so sure if it is that important. Your first proposal looks neat, I would certainly like that.

[JanDeDobbeleer]

@meakbiyik I see, the themes are there for illustrative and backwards compatibility purposes, but if you really want to get the most out of it, creating your own custom theme is advised. I'll include this functionality, if you go through the documentation, you'll see there's plenty more you can do when going down the custom path ;-)

[JanDeDobbeleer]

@meakbiyik this is what it results to:

[meakbiyik]

@JanDeDobbeleer perfect, exactly the way I wanted. Thanks!

With the configuration, you are right. It is safe to assume that anyone using this tool would also happily play with the configuration themselves.