readtags-error on Windows

[kaiwk]

I am trying to use ctags on Windows with chromium. At the root directory of chromium, generating tags by ctags --languages=C,C++ -R .

It works indeed, but sometimes code completion by company-capf is laggy, and gives error below:

I think we may invoke readtags too often here?

My company config:

(setq company-backends '(company-capf
                     company-keywords
                     company-semantic
                     company-dabbrev-code
                     company-files
                     company-dabbrev
                     company-cmake
                     company-clang
                     company-bbdb
                     company-oddmuse))

(setq company-idle-delay 0
          company-echo-delay 0
          company-minimum-prefix-length 3
          company-tooltip-limit 12
          company-tooltip-align-annotations t
          company-require-match nil
          company-transformers nil
          company-global-modes '(not eshell-mode comint-mode erc-mode message-mode help-mode)

[AmaiKinono]

Based on my experience developing Citre, I can confirm there are some quirks in the readtags process part on Windows.

I have optimization for company (see citre-capf-optimize-for-popup), it allows typing while calculating completions. So, if you feel laggy, it's a bug, and I'll try to fix it.

...and gives error below:

I think they are not errors. They are just buffers called *readtags-error* to collect stderr output from readtags. I think I intentionally don't kill them due to some quirks on Windows.

Please allow a few days before I can try this on Windows.

note for my self: There are not multiple stderr buffers. There are multiple readtags processes tied to the same buffer. We have to properly clean up the processes.

[kaiwk]

I'm not sure if this will benefit performance, but here some ideas about compay-capf laggy: can we lazy load the completion candidates?

For example, there are 1000 candidates, but we let company-mode only get 100 of them.

[AmaiKinono]

can we lazy load the completion candidates?

This would be ideal, but requires company to implement "async backend" kind of thing.

The current implementation shouldn't be a problem, since once you start typing while Citre is calculating candidates, Citre just stops it. So, a long completion list may take a long time to popup, but that doesn't interfere your typing.

[AmaiKinono]

Could you try the latest version? I'm pretty sure I fixed the problem on Windows:

This is in the Chromium repo, with your config. I didn't feel any lag when typing. It feels better than the gif looks.

It may take several hours for MELPA to update, so make sure you've really got the latest version. Or you can just clone this repo to use it.

Edit: Latest version is on MELPA now.

[kaiwk]

Thanks! Double confirmed that "readtags-error" disappeared.

you can see the latency (the cursor stay after t but stop blinking) when I delete E or delete the word by subword-mode.

[AmaiKinono]

Thanks.

you can see the latency (the cursor stay after t but stop blinking) when I delete E or delete the word by subword-mode.

Confirmed. What happened here is you actually finished the deletion, but Citre starts calculating completions before redisplaying, so it looks like you haven't delete it.

I'll do a quick fix later today. Thanks for your patience!

Edit: I just found what you've seen is different from me. You saw a lag after deleting the word, while I saw a lag when deleting the word.

Although the cursor is frozen, does it actually stops you from typing?

I suspect the problem has something to do with blink-cursor-mode.

[AmaiKinono]

Could you try the develop branch? I've introduced some ugly workaround for this.

I expect the lag to be alleviated, but not completely solved.

[kaiwk]

No luck : (

I suspect the problem has something to do with blink-cursor-mode.

I check the commit, and I'm doubting that it's blink-cursor-mode issue, even though i turn off it, the lag still exist.

[AmaiKinono]

Sorry to hear that.

It does alleviate the problems on my side, and that's the best I can do for now.

Since we are kind of far away from the original bug report, If you do want to see this being solved, I suggest:

• Open a new dedicated issue.
• Put clear your Emacs version number and OS information.
• Write a recipe to reproduce the problem, start from $ emacs -Q.

and I'll stick a "help wanted" label to it and see if Windows users havr any ideas.

I do have another approach. There's (unscheduled) plan to create a Emacs dynamic module, bundled with Universal Ctags. Once it's done, Citre could read tags file using normal functions, so we can get rid of all the process related problems.

[kaiwk]

I will open another issue if possible, so close this one now.