Timeline for "Making tag completion table" Freezes/Blocks -- how to disable
Current License: CC BY-SA 3.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 25, 2014 at 22:39 | comment | added | Dmitry | @cheezy You really should test it in a bare Emacs session with an empty configuration. Maybe even without installing company: open one of the files, type M-x visit-tags-table, enter the path to TAGS, and then type C-M-i to complete using that table. company-etags reuses a lot of the same code. | |
| Nov 25, 2014 at 19:42 | comment | added | cheezy | @Dmitry additionally, your comment made me realize something. I'll check into it, but it's a possibility that something inside redguardtoo's emacs file that updates tags during a save, which could explain the (previously) random behavior | |
| Nov 25, 2014 at 19:34 | history | edited | cheezy | CC BY-SA 3.0 | Added package-activated-list variable |
| Nov 25, 2014 at 19:32 | comment | added | cheezy | @Dmitry, I may have some time tomorrow to check this. I'm using emacs 25.0.50.1 (x86_64-w64-mingw32). I was not aware that TAGs stay in the buffer, so it is very possible that a package that is installed is killing the buffer. I've updated my post with the variable package-activated-list if you're curious | |
| Nov 24, 2014 at 0:14 | comment | added | Dmitry | And if you can provide a stable step-by-step scenario where a non-modified TAGS file gets repeatedly re-parsed by Emacs, that should be a good material for a bug report. Do you maybe use some package that kills buffers that haven't been switched to for some time? Because a tags table is kept in a buffer. | |
| Nov 24, 2014 at 0:05 | comment | added | Dmitry | @cheezy What Emacs version are you using? Without touch the TAGS file, I was unable to make Emacs say "Making tag completion table ..." even twice. And when I changed that file (removed, actually), I've been prompted whether I wanted to re-read it. So you might want to check your value of tags-revert-without-query. | |
| Nov 2, 2014 at 9:11 | comment | added | Tu Do | I added auto-completion to the answer. Please check it out. It could solve your completion problem, since thousands of candidates are no problem with Helm. | |
| Nov 1, 2014 at 22:36 | vote | accept | cheezy | ||
| Oct 31, 2014 at 22:04 | answer | added | Tu Do | timeline score: 2 | |
| Oct 31, 2014 at 21:19 | comment | added | cheezy | Thanks! I saw your post on helm gtags and this'll work for me for now! Please create an answer so I can accept it :) | |
| Oct 31, 2014 at 18:17 | comment | added | Tu Do | There's one possibility, not sure if you try: since you already have you TAGS file at project root (generated by etags), ggtags will use that file instead of GTAGS. Did you move the TAGS file (generated by etags) elsewhere? Personally, I use helm-gtags + GTAGS and always jump instantly, even in the Linux kernel that etags generates almost 1 GB. You mention that only some ".h" files available at build time, do you mean those files only generated after the build? Even if it is the case, it's hard to think that any tag program misses those if search recursively. | |
| Oct 31, 2014 at 17:56 | comment | added | cheezy | Sorry I wasn't very clear. Without involving the make command, any tag generation is incomplete. You can turn your comment into an answer, and I can accept it in a day or two to give others a chance to answer | |
| Oct 31, 2014 at 17:54 | comment | added | cheezy | So, if I'm stuck with etags for completeness, do you have any suggestions for 1) Loading the tag file asynchronously 2) Disable autoreload of the tags file? | |
| Oct 31, 2014 at 17:45 | comment | added | Tu Do | So, it did work? If so, may I turn my comment into answer? | |
| Oct 31, 2014 at 17:44 | comment | added | cheezy | I verified your statement (all the tag programs can only generate from project root down the tree). make etags works because it calls etags once it evaluates where all the .h files live. | |
| Oct 31, 2014 at 16:49 | comment | added | Tu Do | Anyway, if gtags could not know about such details, I don't think the built-in etags (comes with Emacs), or ctags (I linked above) would be able to do it. I think you only use ggtags to create tags at current directory, not project root. Run the command gtags at project root, or when ggtags asks for where to generate, navigate to project root and you will be fine. | |
| Oct 31, 2014 at 16:42 | comment | added | Tu Do | Hmm I see. The situation is more complicated now. You mentioned ggtags cannot generate tags, but did you use plain gtags on the command line at project root? You should try this and invoke ggtags again. There should not be make ggtags because the real command is gtags; ggtags is just a package name of Emacs that use it. Another option is that you can use ctags; ggtags can also recognize ctags tags and it's also fast. You can generate ctags tags when invoking ggtags-create-tags and it asks for using ctags client. | |
| Oct 31, 2014 at 16:20 | comment | added | cheezy | Your guides were the ones that got me started with emacs (especially w/ C++)! Our build system is very complicated and #include "..." can live in various places that are not known until build time. So, ggtags wouldn't be able to generate tags for many of the files. Currently, our build tools allow us to make etags to generate emacs compatible tags, but there is no make ggtags equivalent. So, I'm stuck with etags for now. Any ideas? | |
| Oct 31, 2014 at 15:55 | comment | added | Tu Do | For jumping to definition/references, you can use GNU Global with ggtags/helm-gtags. Guarantee to work on large project like Linux kernel without any delay. You may want to look at my C/C++ guide. I covered code navigation (jump to definition/references), code completion, compiling and debugging support. I already created a demo configuration for playing with, so you only need to walk through the features without configuring anything. | |
| Oct 31, 2014 at 15:48 | review | First posts | |||
| Oct 31, 2014 at 15:50 | |||||
| Oct 31, 2014 at 15:47 | history | asked | cheezy | CC BY-SA 3.0 |