It would be nice to be able to assign each label a color, and use that color every time the label is printed.

My thought on this:

• the good end game way to have properly defined colors for each label would be to have a git-bug config where admins could define various properties including what label exist and their colors, define what status exist for a bug and how you can transition from one status to another ... but we are not there yet
• there is already in the webUI some code to assign arbitrary colors to a label (https://github.com/MichaelMure/git-bug/blob/master/webui/src/Label.js#L10-L43)

My proposal:

1. migrate the webui color code into the core. That way, a label will have the same color in all UIs, will get simpler and the core APIs will be ready for the end game
2. [ ] when we have the code to define the config, we will just have to plug that in the core and we will have either automatic label colors or configured labels if users care enough to define them.

For the termui, there needs to be a fallback for the colors since some terminals only support 16 or 256 colors.

@j-f1 good point. That should be fairly easy to reduce the color precision to 16 or 8bits. I'm a bit confused as to how one is supposed to detect the terminal capabilities. I have the same question for how to detect the terminal size btw.

Here’s a series of checks (in JavaScript, from the supports-color module) that determine the level of color support. Please @mention me if you have any questions about what it’s doing:

if (env.COLORTERM === 'truecolor') {
  return 3;
}


if ('TERM_PROGRAM' in env) {
  const version = parseInt((env.TERM_PROGRAM_VERSION || '').split('.')[0], 10);


  switch (env.TERM_PROGRAM) {
    case 'iTerm.app':
      return version >= 3 ? 3 : 2;
    case 'Apple_Terminal':
      return 2;
    // No default
  }
}


if (/-256(color)?$/i.test(env.TERM)) {
  return 2;
}


if (/^screen|^xterm|^vt100|^vt220|^rxvt|color|ansi|cygwin|linux/i.test(env.TERM)) {
  return 1;
}


if ('COLORTERM' in env) {
  return 1;
}


if (env.TERM === 'dumb') {
  return min;
}

source

@j-f1 Thanks

More info on the subject: https://gist.github.com/XVilka/8346728

I found a go implementation: https://github.com/xo/terminfo/blob/master/color.go#L49-L91

Michael Muré (MichaelMure) added label enhancement 7 years ago

Michael Muré (MichaelMure) closed the bug 6 years ago

Label's color are now defined directly in the core and used in the webUI through the graphQL API.

Next steps are:

• display the label's color in the termui
• make the colors configurable

Michael Muré (MichaelMure) opened the bug 6 years ago

Code used by Github's hub command to display labels: https://github.com/github/hub/blob/master/utils/color.go

Mind if I ask the current state of this issue?

Labels should be displayed everywhere with the correct color, but you can't choose the color yourself. That would require a proper configuration data structured stored in git and shared.

Alright, I understand. Do you planning to support colour selection in near future?

Probably not as there is some significant development with higher priority (some being required to implement that feature).

My git-bug choose the same color for two labels on a total of three labels!

A silly idea: replace or add to colors a special character symbol.

Color blind people, and others could distinguish issues more easily...

I second @vtexier. On the CLI and TUI, displaying a (coloured) character (e.g. the first letter of the label) would be much more useful than the current square.

I just created 2 labels on a repo and git-bug chose exactly the same colour for them.

This bot triages untriaged issues and PRs according to the following rules:

• After 90 days of inactivity, the lifecycle/stale label is applied
• After 30 days of inactivity since lifecycle/stale was applied, the issue is closed

To remove the stale status, you can:

• Remove the lifecycle/stale label
• Comment on this issue

github-actions (github-actions) added label lifecycle/stale 1 year ago

Well, spamming the issue then… It's still relevant to me. I wouldn't like it to be closed by a bot.

(I find this kind of bot detrimental. What's the problem with keeping unfixed issues open?…)

github-actions (github-actions) removed label lifecycle/stale 1 year ago

I find this kind of bot detrimental. What's the problem with keeping unfixed issues open?

:wave: hey there, i added the stale bot workflow. it's since been refactored so that it will never close issues or pull requests.

it is primarily useful for larger backlogs as a way to indicate where some attention is needed, e.g. what has gone unattended for a long time and should be looked at.

This bot triages issues in order to help the maintainers identify what needs attention, according to the following lifecycle rules:

• After 90 days of inactivity, lifecycle/stale is applied
• After 90 days of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied

This bot will not automatically close stale issues.

To remove the stale status, you can:

• Remove the stale label from this issue
• Comment on this issue
• Close this issue
• Offer to help out with triaging

To avoid automatic lifecycle management of this issue, add lifecycle/frozen.

github-actions (github-actions) added label lifecycle/stale 1 year ago

github-actions (github-actions) removed label lifecycle/idle 7 months ago