[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Automatic (e)tags generation and incremental updates

From: Dmitry Gutov
Subject: Re: Automatic (e)tags generation and incremental updates
Date: Tue, 12 Jan 2021 03:33:10 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]