bug#70900: 30.0.50; tramp complains "File error: Cannot remove lock file for /ssh:..." on every save when remote-file-name-inhibit-locks is non-nil

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 13 May 2024 14:30:06 +0300
> Cc: 70900@debbugs.gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 13/05/2024 09:54, Eli Zaretskii wrote:
> >>> It would also make sense to switch it on by default - it has a
> >>> noticeable effect on performance.
> >> No. File locks are an essential part of Emacs. Disabling them has the
> >> potential to damage something (see above), so it shall be decided by the user.
> > Agreed.
> 
> In this aspect I'm commenting as someone who sees user complaints from 
> time to time about how VS Code or etc are faster at remote development 
> than Emacs, and now saw this myself.

VS Code is written for people who own the computer and only have a
single session active at all times (that's how Visual Studio works,
remember?), so they don't need to lock file.  People who use Emacs in
the same way could indeed disable file locking.  But Emacs itself
cannot know whether this is the case, and given the proliferation of
Emacs usage patterns whereby people use the same session locally and
from a remote machine, we cannot disable file locking by default, IMO.