For an API documentation project I have created custom help files in Vim's helptext format. I also created a tags files with :helptext docs/. The tags file looks like:
yii\base\Component::trigger yii-base-component.txt /*yii\\base\\Component::trigger*
yii\base\Controller::$action yii-base-controller.txt /*yii\\base\\Controller::$action*
While the first tag yii\base\Component::trigger works fine, the second one yii\base\Controller::$action doesn't. Vim complains that it can't find the tag.
Is there a way to make $ characters work in tags?
And more general: Is there a better way to make vim tags play nice with namespaced classes and tags?
Related
I am writing documentation that has steps for Windows, Mac, Linux.
I want to make it look like this HTML5 tabbed HTML5 example
there is support for HTML in gitlab markdown
There is a reference to a sanitation class that validates the inline HTML in gitlab marrkdown
My question is:
Recommendations to achieve the tabbed documentation. Is there a workaround for displaying CSS correctly in markdown?
how to make this work?
Simply insert the relevant HTML/CSS/JS into your Markdown document.
As Markdown's Syntax Rules state (emphasis in original):
Markdown's syntax is intended for one purpose: to be used as a format
for writing for the web.
Markdown is not a replacement for HTML, or even close to it. Its
syntax is very small, corresponding only to a very small subset of
HTML tags. The idea is not to create a syntax that makes it easier
to insert HTML tags. In my opinion, HTML tags are already easy to
insert. The idea for Markdown is to make it easy to read, write, and
edit prose. HTML is a publishing format; Markdown is a writing
format. Thus, Markdown's formatting syntax only addresses issues that
can be conveyed in plain text.
For any markup that is not covered by Markdown's syntax, you simply
use HTML itself. There's no need to preface it or delimit it to
indicate that you're switching from Markdown to HTML; you just use
the tags.
The only restrictions are that block-level HTML elements -- e.g. <div>,
<table>, <pre>, <p>, etc. -- must be separated from surrounding
content by blank lines, and the start and end tags of the block should
not be indented with tabs or spaces. Markdown is smart enough not
to add extra (unwanted) <p> tags around HTML block-level tags.
However, there is one down side to this:
Note that Markdown formatting syntax is not processed within block-level
HTML tags. E.g., you can't use Markdown-style *emphasis* inside an
HTML block.
Finally, there is the concern that you appear to looking to have this document hosted on a third party site (perhaps in a readme on Gitlab). Most third party sites who process and host Markdown documents (including Gitlab) run the output through an HTML sanitizer for security reasons (to avoid XSS attaches, etc). Therefore, you are likely to find that various required hooks in your HTML will be stripped out and it won't work. Of course, this won't be a problem on your own site where you have total control.
The solution was tried in readme.rd from the text processor used by Microsoft VsCode and commited to gitlab. In the attached picture there is the rendering. It was not as expected. Perhaps the functionality to have tabs will be available soon.
An alternative is "collapsible sections" in GitLab Flavored Markdown. Link to documentation: link
I wanna know if anybody is aware about the possibility to get in Vim all tags for the current/specific buffer. Should mean ignoring how the tags are generated, don't matter if as a single project file or stored anywhere outside. As long as Vim could find tags for that buffer I like to get this whole "snippet" as return. So of cause it's easily possible to search for a tag and get the buffer/file plus position, but how to do this in reverse, having a buffer and getting all related tags?
Of cause I read a lot of documentation and searched a while for it, but it's seems like this direction of working with tags isn't a topic anywhere. Some suggestions by anyone? Thank you!
Vim has the tagfiles() and taglist() functions. The latter will provide a List of objects that have tag name, filespec, and some attributes. If you pass a regular expression that matches any tag (.*), you'll get a (potentially huge) list of all tags.
Tags are not directly scoped to the current buffer. The 'tags' option provides the sources of tags (which can be queried via the mentioned tagfiles()). That option value can be global, or overridden by a particular buffer.
You're right, many tags-related plugins invoke ctags et al. directly and parse the output. I guess that's because the taglist() function didn't exist in older Vim versions (or it doesn't provide information that the plugin needs).
I want run multiple cucumber feature tags. I don't want to mention all the tags in the command line because it can be tedious if there are lots of tags. Instead I want to provide a pattern of tags that will run all the tags which matches the pattern like -Dcucumber.options=" --tags #my-test*". This will run all the tags that matches #my-test patter.
So is there any way to do this?
What happened when you tried?
I don't there is a way to do it and I have a hard time to see that you would have so many tags that it would be valuable. If you have that many tags, maybe you have another problem and should cut down on the number of tags used?
If you are using Cucumber ruby, then you can use profiles to do this using cucumber.yml. I don't know if there is an equivalent in java. If there isn't I would just create some shell scripts (maybe even aliases) to deal with this.
I'm just getting acquainted with Vim's CTags functionality - and it's damn handy.
One issue I have, though, is regenerating common tags for each project.
For example - I do a fair bit of work in rails, and like to generate ctags for the whole rails framework with
alias rctags="ctags -R `bundle show rails`/../*"
The issue is I have to do this for every rails project I start up.
So, what's the standard way to automatically access a set of tags in any vim session - ideally only if the opened file satisfies a specific condition. (Eg rails ctags preloaded for .rb files, but not .py files)
Any ideas appreciated
See :help 'tags'.
You could use, for example:
set tags+=~/.rails-tags
Which would cause ~/.rails-tags to be searched for tags.
(also, on the topic of tags: it's probably useful to suffix the tags variable with ;/. This means "search for a tags file in every parent of the working directory (ex, all the files /foo/bar/tags, /foo/tags, and /tags will be searched. For example, I use: set tags=tags;/).
Why not to use plugin Indexer that was made especially for managing the ctags in Vim?
You can define your project in ~/.indexer_files like this:
[my_rails_project]
/path/to/the/needed/directory
or even
[my_rails_project]
option:ctags_params = "--languages=Ruby"
/path/to/the/needed/directory
Then every time you opened Ruby file (i.e. *.rb or *.ruby) from the directory /path/to/the/needed/directory (with subdirs, of course), your tags will be generated automatically in background process, and when you save any file from this project, the tags will be updated automatically too (again, in the background).
So, you should not care about your tags generation, it just works.
For more information, see the article: Vim: convenient code navigation for your projects, which explains the usage of Indexer + Vimprj thoroughly.
Is there a way to get a title tag in the search results of indexed_search?
Instead of
Text
there should be
Text
Not a real solution but best I could do:
I think this won't be possible without changing the extension's PHP code. If you do so, copy the extension folder from the systext folder to your typo3conf/ext folder, otherwise you will get in trouble when updating Typo3.
indexed_search seems to have only hardcoded -Tags. You can check this by looking first at the actual HTML output (your search results). Then compare this with the HTML template used. If you have shell access to your server, a grep command might help to locate the correct template. Then try to find the marker. I suppose in your case it's ###TITLE###. Then you have to figure out how the marker is filled. Again a grep command for '###TITLE###' in the folder's extension might help you. Then you will see if the tag is hardcoded or not and how you can change it.
Often the faster solution is to use the template object browser and to try to find a piece of TypoScript below plugin.indexed_search which could be responsible what you want to change.
Unfortunately in your case both didn't help. For some strange reason, '###TITLE###' isn't contained anywhere in the the indexed_search extension.
A very ugly workaround would be to use javascript or jquery to insert the attribute.