Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature request: apply conceal on tagbar. #79

Open
stardiviner opened this issue Jun 7, 2012 · 11 comments
Open

feature request: apply conceal on tagbar. #79

stardiviner opened this issue Jun 7, 2012 · 11 comments

Comments

@stardiviner
Copy link

Sometimes, those names, variables, function or class names are too long (if the whole vim window is not a enough width). So apply conceal on tagbar is a good idea to save space.

for example:
Function:
functionXXXXXXname1
functionXXXXXXname2

after conceal:
funcname1
func
name2

@majutsushi
Copy link
Collaborator

This could be an interesting idea, but I'm not sure how easy it would be to generate the conceal patterns on the fly. Also, how should function signatures be treated? How much of them should be shown? Do you have any concrete ideas for that? I'll have to think about that and give it a try once I have a bit more time.

@stardiviner
Copy link
Author

=> On [2012-06-10 00:18:25 -0700]:
Jan Larres Said:

This could be an interesting idea, but I'm not sure how easy it would be to generate the conceal patterns on the fly. Also, how should function signatures be treated? How much of them should be shown? Do you have any concrete ideas for that? I'll have to think about that and give it a try once I have a bit more time.
No need to hurry.
I do knot know much on programming, I think this conceal function should apply
on tags after those tags display in tagbar. In other words, just like a filer,
display tags in tagbar at first, then do conceal, instead of one tag by one tag.

(Talk about the "on-the-fly", maybe re-display all tags and apply conceal will
use too much source, and is not a good idea. But use partial updating for tags
and apply conceal on partial tags will need to write smart code. Of course the
partial updating is a better way.)

The function signature length should depend on what kinds type you display and
how much length is readable for human.
For example, function can be f or func. variable can be var.
Or add some signs around those type signature. e.g. function can be [f].
Or use special ASCII characters like Powerline's fugitive git branch signature.
(maybe here can set an option to let user choose which style of type signature
do they want to display.)


Reply to this email directly or view it on GitHub:
#79 (comment)

[ stardiviner ] ^^&^^ {I hate all of you ! Leave me alone}
IRC(freenode): stardiviner \ Twitter: @numbchild
GnuPG Key fingerprint
>>> 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433

@sethwoodworth
Copy link
Contributor

I'm not entirely sure how this would work in practice either. But I am a big fan of unicode symbol conceal in vim.

functions could use the unicode symbol LATIN SMALL LETTER F WITH HOOK: Ƒ or ƒ
classes could use the unicode symbol for [function composition](https://en.wikipedia.org/wiki/Function_(mathematics\)#Function_composition), the RING OPERATOR: ∘

@stardiviner
Copy link
Author

I love unicode symbol too. very much. I like this solution. hope you can implement this quickly. waiting for it.

@stardiviner
Copy link
Author

I think classes should not use , because it is not clear and literal enough for user.

@stardiviner
Copy link
Author

I think class should choose from http://www.fileformat.info/info/unicode/char/c.htm

@majutsushi
Copy link
Collaborator

Could you give a few concrete examples of how exactly you would want this to be displayed? Where should the symbol go? Before the tag? And if yes, before or after the visibility symbol? Or after the tag? I'm a bit worried that it may make the display look too crowded or confusing, but I'm wiling to give it a try.

@stardiviner
Copy link
Author

example

Ƒ function
  Fun~Example1
  Fun~Example2
  NeoC~Head

Fun~Example1 is concealed from FunctionExample1
NeoC~Head is concealed from NeoComplCacheHead
If you want a simple rule about them.
well, just display first 4 characters of long length string.
and display the end 3 characters of long length string.
You can adjust this two variable by your self.

@stardiviner
Copy link
Author

And I checked the tagbar source code, I find python has let type_python.kind2scope, and let type_python.scope2kind, I think function is too long especially for a long width function name, and bad when tagbar width is not width enough. So I suggest to simplify this too. Maybe those function term can be replaced with Ƒ, and class can be replaced with C. Or use other simple expression like (F) for function and (C) for class. and make this can be customized is better.

@gasparch
Copy link

gasparch commented Dec 9, 2016

I may suggest different approach. I've being patching tagbar to support Elixir, because default functionality does not enough. So that I came up with - vimscript function that allows to rewrite tag information completely.

It was because I had same functions parsed into two different kinds (which is technically correct, because they are just ordinary funcitons, but some of names have specific meaning in Erlang/OTP).

Also I wanted to avoid having several entries like following - which is specifics of language, you can have several clauses of same funciton and they look exactly the same in tag file.

apply_arguments
apply_arguments
apply_arguments

This is a filtering part, just to throw functions away.
But I also needed to rewrite function names, because functions of different arity (arg count) make difference in Elixir/Erlagn and it is important information. So I was able to rewrite function names into

    start_link/0

instead

    start_link

So I would suggest that may be function name rewrite can be done in vimscript, just after loading tag file. And any kind of complex logic can be implemented there.

Patched version of tagline + example how to define transform function is here

@alerque
Copy link
Member

alerque commented Oct 22, 2019

@gasparch Your fork is interesting on it's own apart from addressing this particular issue. Would you consider refactoring in such a way that the changes can be contributed back upstream? If I would suggest copying your current fork branch to a new one, then opening a GitHub PR opened in Draft mode, then we can muck around with rebasing it and figure out what would need to adapt both ends.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants