Re: Automatic (e)tags generation and incremental updates

[Dmitry Gutov <dgutov@yandex.ru>]

On 11.01.2021 16:56, Eli Zaretskii wrote:

>> Correction: it's actually writing the updated file to disk which takes
>> half a second. This call:
>>
>>     (write-region (point-min) (point-max) buffer-file-name nil 'silent)
>>
>> I wonder if *that* could be done asynchronously.
> 
> What kind of asynchronicity did you have in mind?

One where the Lisp code doesn't have to wait for the disk write to 
complete. Could use being able to set up a callback for the end, though.

> And I'm probbaly missing something, because I don't understand how
> Emacs is involved in updating the tags table.

It's part of the secret sauce for the quick incremental updates: if 
etags writes to disk, even just to update one file's index, we'll have 
to revert-buffer, and the bigger the tags file is, the longer the revert 
will take. Basically, N(project-size).

To go around that, when updating a file, we delete its existing entry 
inside the buffer visiting the tags file, and then call etags directing 
its output to the end of the same buffer. This way we avoid reverting 
the buffer, although the completion table still needs to be regenerated.

To synchronize the buffer contents with disk, though, we need that 
write-region. *If* we want to synchronize it, of course, e.g. to be able 
to open the file in some future Emacs session. Or I guess we could write 
to that file only once later, in kill-emacs-hook.

BTW, writing it to disk becomes 10x faster if the tags file is visited 
literally. I wonder if that mode could work well for most users. Some 
quick testing showed that it's functional, though I'm guessing it won't 
work for identifiers containing unicode characters.