moo-jump-local should display tags in tree format

[tuhdo]

In helm-semnatic, when it encounters struct and nested structs, it can display tags in a nice tree, with inner structs indent two extra spaces compare with parent struct. It would be nice if moo-jump-local can display like that. Currently, moo-jump-local displays nested tags in the same level as parent tags, which looks messy.

You can refer to the implementation from Semantic here: https://github.com/emacs-helm/helm/blob/master/helm-semantic.el#L53

[tuhdo]

Thanks for the change.

There's a minor improvement that could make it better: is it possible to add the struct or class keyword after a tag that is either one of those? Or, just the keyword "class" is enough.

[tuhdo]

Nevermind. I find this good enough. I was just want to know what member is a struct and what is not at a glance, but I can get used too. And this has the advantage of being more compact.

[abo-abo]

I think the ideal situation would be for CEDET to track if the member function is public or private. Then I would highlight them with the appropriate face it would not matter if it's a struct or a class as long as you see the function access (since struct can be made all private and class can be made all public).

Unfortunately currently CEDET parses function access as just labels. I could hack something on top of it, but it would be done much better on the parser level.

[tuhdo]

What I meant was simpler. For example, I have this struct:

struct A {
     int a;
     int b;
};

struct B {
      struct A sa;
      int c;
};

when I invoke moo-jump-local, instead of just displaying like this:

A
    int a
    int b
B
    A sa
    int c

I expected it to be like this:

struct A
    int a
    int b
struct B
    struct A sa
         int a
         int b
    int c

because struct keyword is highlighted, it is easier to see how many non-primitive members in your struct/class.

[abo-abo]

I'm not too sure about this one. I like fa-face-type-definition, but fa-face-type-compound doesn't look consistent.

I think I'll change the fa-face-type-compound to a plain inherit from font-lock-type-face that users can customize if they want. What do you think?

[tuhdo]

Thanks for adding it. Could you add the faces to nested struct/class as well?

[abo-abo]

You mean a different face for nested depth 2, nested depth 3 etc?

[tuhdo]

No, just the same face is fine, for consistency. Currently we have struct with its own face at top level, but not for its child structs.

[abo-abo]

The child structs have a face, see:

[tuhdo]

Hmm I had to change fa-face-type-compound. Could you make it inherit fa-face-type-definition by default, because new users would not know about this face?

[abo-abo]

No, that makes the stuff look too gaudy for me.

Also it's inconsistent in that the compound types are highlighted in the type definitions but not in the function signatures.

The font-locking interface is quite discoverable with customize-group function-args-faces. There's no need to have every possible thing on by default:)

[tuhdo]

Alright then. I will set it for myself to quickly identify structs inside my struct. Detecting it for struct definition is enough, I don't think it's necessary for function signature. Probably you have a compound type that has all members made of compound types. For me, it's useful when a struct has primitives mixed with other compound types. With such face on, I can quickly identify compound members and quickly navigate between them. Or if I want to find primitive members, I can quickly exclude all the members with background color without even reading them.

The font-locking interface is quite discoverable with customize-group function-args-faces. There's no need to have every possible thing on by default:)

Well yes I use helm-colors, which is much better than stock customize-face. Just type fa- and I have every fa faces. The problem is , to do this you have to explore fa faces one by one, if you are new. New users won't even notice such feature exists

[abo-abo]

New users won't even notice such feature exists

That's not too bad. I like to follow org-mode's approach of not having every single feature on. I'd rather find a feature when I need it, rather than have a useless one on by default and annoying me.