From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.devel Subject: Re: Missing snprintf in ucrt mingw + vc-refresh in find-file hook? Date: Wed, 14 Feb 2024 22:04:14 +0100 Message-ID: References: <6aed5106-b78c-49f1-8caa-a7f9d34c161b@gutov.dev> <207528e2-6bec-436e-8868-8e7b707133f6@gutov.dev> <86sf1wpjui.fsf@gnu.org> <8876d606-c4af-4a27-a1b1-4c3dea6d720e@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39698"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 15 06:31:54 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1raULh-000A7t-Mo for ged-emacs-devel@m.gmane-mx.org; Thu, 15 Feb 2024 06:31:54 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1raULK-0002OS-3i; Thu, 15 Feb 2024 00:31:30 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1raMQb-0003m7-IJ for emacs-devel@gnu.org; Wed, 14 Feb 2024 16:04:25 -0500 Original-Received: from mail-vi1eur02olkn2030.outbound.protection.outlook.com ([40.92.48.30] helo=EUR02-VI1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1raMQW-0002ii-O9; Wed, 14 Feb 2024 16:04:24 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AcqyqPoOPNKNJsGACnq5I0ScpKHfZGC0yqtRRP4uH3buKtznbkykf0uBAWTCn9BqaMmxE4KOZuR1yKnkIFoRKApx5sPuegHCgSnhNvcrc38/MqcOa8aIL92t2EOcL1623g7BFA1CgENtJoH4zEHP1gk7VNi0CLL0lwFvCUykBr6OC0m7gAOVYU35QhXHiE92V4xKxPBwU7JYK8ybx7uf3/iO7vs1zuabxUE9gR8k0+3afQyu7O9cTIwr4E36jCJ1TW3igqhSq1xIU8egE1EpM1dxv3R61Ip2CnXe2NuOt7L9h6uypTTtseILvKS+1nO3rqKXCzXsLf8XDPpWDJiYgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/TnbK+ts+NJ92zsKFGMqFUNW8D5c31XB+CsVobsbv3M=; b=X/njBaoZ0Hizk0alQopmrDlg7ypFO2VLhXrRp+o6qO+B6Rm62SwjW7C8MuypIYrzN9efSL5ABQ6ckcZ8ejNBW9uODg7x5sA9CczJCwI0jtRyhfellV/OyPCxjPzLfYQ7dF7KnCdFenKJS64rYvuNtbucOX4u4AhRTdemqbXSrlhFTwELdPFdrPHsZMCIQ1nd7lqsIpDpPmMjF648Dz/0ZRBCmrDKciMeUHb6SdXpXxKWA3eDNPhm7IqWYmYs1gyBURYBIa0c0jvT9Gj6mCVr2KzAxz2jb4zzoF7H56WaYXRiDDZt3uLGSG9FaIPb+0v+Y+nZGs0EJlrQIPCYFm4RDQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/TnbK+ts+NJ92zsKFGMqFUNW8D5c31XB+CsVobsbv3M=; b=ayq327W3RdMzR3ujGtJ0R9D/n84WSRb8oTcw2gu4QZhJcu2vqIDNOPisqofZjNxxGd8qCFMOmTZTn7d6mgGtZQR1YDTJDmT6VHIPfHmnJ5hhUCI8TcmV/Fd8AJDf4E3dKPxlfyO1cHdwDlHuvPHLZZflTyW5sNJnSLFauvXRFPbiYZUKzo0kYWHjiXRdQgKL7reqjBQkh7ONXCg2BQJycwhFpqK91Z6Ry4qXi8/3LN6sIkjWG2efJd9JeYx085sgVsXB+ey59tujNge0/MSS5nBoD/TrcIxireBP1bqrGknVOypGlEexoOA8f8ph5TSqMWDDP7bUpSnpYx9PoaesBQ== Original-Received: from DU2PR02MB10109.eurprd02.prod.outlook.com (2603:10a6:10:497::14) by PA4PR02MB6798.eurprd02.prod.outlook.com (2603:10a6:102:d1::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7270.33; Wed, 14 Feb 2024 21:04:15 +0000 Original-Received: from DU2PR02MB10109.eurprd02.prod.outlook.com ([fe80::1752:9b0:4c48:15f8]) by DU2PR02MB10109.eurprd02.prod.outlook.com ([fe80::1752:9b0:4c48:15f8%7]) with mapi id 15.20.7270.036; Wed, 14 Feb 2024 21:04:15 +0000 In-Reply-To: (Dmitry Gutov's message of "Wed, 14 Feb 2024 05:42:52 +0200") X-TMN: [8gtoo9o3FA1a7AHd7bE87Sy0283SYva6M+xZ/kFPkOQ=] X-ClientProxiedBy: FR4P281CA0332.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:ea::18) To DU2PR02MB10109.eurprd02.prod.outlook.com (2603:10a6:10:497::14) X-Microsoft-Original-Message-ID: <874jea7o6p.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PR02MB10109:EE_|PA4PR02MB6798:EE_ X-MS-Office365-Filtering-Correlation-Id: 9b0c4ddd-b54d-4e80-c1cd-08dc2da08048 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Gh16hKdSNOLUbBR+HCEJsFiQelZOFqAfVJPYGhYy7zmu3I+LX3DCbfrNDyg9O9X05FuJrtnvsCxyPmLgyW57vmm+euj1shU2KlSeaw86jJNuv/iW7Js9t5V1rGpOR/3cIAOW35TVef4eS67FAxgR5anELHV3We1HrUgJODh5hE+cnszvynyirUDODdVM96UOvTeZTzoZvYTShVXKW1LbB7soj1SyU9/+JgvFjlMAizbM1IcxMKTv4vngZjy0GjKSTVTy1wOZuye4zP3QD8mon85N4zgodgmqM9CMdwaNo943+8AjG4a2ZCm2j1no/WWJeBdvcogXmmRPCgVumXvBu0J+SYiTVKfZuJD2hEhl2t2TX3JRoLlWE1TtHVfizEctnwqoLHMEMbpmy0Soc+XKul05JZvk4d9fBCFRZ9PZYfb/Kd+h6utY/1R/lGpmfj/ya1JaM2VywQpziDyzPJ0TG7KLw2hpJKDtu2GT7eQOWZoL+LAc3t+gNE+df8firnkRNHXM9IK+ZwQ1QKfFFj2OCBfwsFMRq5nQ8DwrXrdhAV4efC6yPUbc5I2oWZYD15mp X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?RTR4RY4dJx4XUgnvMngteELn3e8igcsbPFqqUJpaDvdPsT5KmPwFplXQIXFp?= =?us-ascii?Q?9wKnLs4yJGAPm5DK7hE13442qZCQklipxNrKLcREmE+oMbdLEeCmDxADw7eC?= =?us-ascii?Q?Wkh9oarrXjvUpNoz2SwxKwzZvWig0HErwgdultQXaL0PEDIhQDVbpLwuBAs8?= =?us-ascii?Q?FphZRBl7Mdf4fBmMllMFZQuB2jb7lG+xoyh4cYvLr8oRxUGYW4BSUJTTxksF?= =?us-ascii?Q?P9iBiVsWBDYvS9mv84SIxGRY2QbHOpL4OHt7wJ6KBcb2JqhP+Gr3lwk0uXo5?= =?us-ascii?Q?GSzCM77/1dPoRu+9L9Jgw1l2k6Ybp8Dt5mfi4cowQEe0cRgYuBTJk7iTABmb?= =?us-ascii?Q?IaOekC94FtXLlHTiahib8Ghhcx9KjH+EUkNUt6zuJObhaDgY3xozwwZVo4Pa?= =?us-ascii?Q?ZKg85Dv9esKFBMKOft6bCV12c6Iwqly0/WCEDbYtp9p/+hRKkEYXRJ29p/tj?= =?us-ascii?Q?Fyabs1ORYGGFvQShUYXrS9XDVFf9vV0ZCGP2f0R8WuJkcySX8STN2uCEG5q2?= =?us-ascii?Q?QNRcRwtUUIpjG+QXB//it4a+6wd0ABbPGBDGH+xkKl1gzy/FNTEH5tC5qzzv?= =?us-ascii?Q?cxv6PlDDhHExxErT2t9AU1TJnJJAPBs65BrbYHFMk8IyaQjr7J1GX0u2YmRg?= =?us-ascii?Q?C2 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-ab7de.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 9b0c4ddd-b54d-4e80-c1cd-08dc2da08048 X-MS-Exchange-CrossTenant-AuthSource: DU2PR02MB10109.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2024 21:04:15.3988 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR02MB6798 Received-SPF: pass client-ip=40.92.48.30; envelope-from=arthur.miller@live.com; helo=EUR02-VI1-obe.outbound.protection.outlook.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 15 Feb 2024 00:31:26 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:316217 Archived-At: Dmitry Gutov writes: > On 14/02/2024 01:10, Arthur Miller wrote: > >>> We could try dropping the forced refresh from find-file-hook. Then we'd have a >>> function there that should be called differently, which would just reset the >>> saved backend/status for the file, and the cached value for vc-mode (the >>> mode-line element). >> I didn't suggest to rebuild everything :). Just an option to remove the update >> for those who don't want the update (I guess I am the only one). > > That's wouldn't be a big rewrite, I think. So far it seems the required changes > would be limited, that's why I outlined the idea. Allright; I'll have to learn vc-mode and see how it works in that case; I am not familiar with that code at all. >>> Then, if the user disabled showing the VC state in the mode-line, and doesn't >>> have any other packages installed that use the status, Git won't be called, at >>> least not right away. >> It would be one's own responsibility to keep track if it is needed by other >> applicaitons or not. This why I asked, if there is something else than modeline >> that needs this. >> I see defcustom declaration fo vc-display-status is changed from what it was >> in >> 29.2 to what is now in the master. I guess you (or someone) is already planning >> something in this direction? Was it meant that vc-refresh (or something in the >> chain of call) decide to call git or not based on the value of that variable? >> Looks to me like that was the plan, but I don't know the intentions. > > The idea behind it was something else: to be able to unify mode-line elements > (from vc and project). Ok, I see. A question: is it importnat to keep display on modeline or elsewhere decoupled from the actual repo query? >> In case when list of files are checked, one can let-binding vc-display-status >> to nil in vc-refresh (or the responsible one) so to not trigger git? > > vc-display-status only affects vc's mode-line element. Can I use to in the meaning "no status display" = "no git query"? That is why I ask if it is important to keep display decoupled from the query. >>> So I would welcome such an experiment, especially if one is careful to retain >>> support for vc-follow-symlinks. >>> >>> vc-after-save could similarly avoid doing the full refresh until the file's >>> backend/state are requested again. >> When they request for the backend state; they could do so asyncrhonously to, >> by >> starting a timer? The update will not be immideate; run first when Emas is idle, >> if it is just the modeline; but third party apps, if there are such, can be more >> picky. > > That's not simpler. After looking more at it; what I find problematic is that it is automatic. Also, use of hooks find-file/after-save (eventually) means either all or nothing. I looked a bit in vc-hooks and vc-dir, and come up with this little ugly hack: (define-minor-mode vc-mode "vc-mode test" :global nil :lighter " vcm " (setq-local vc-handled-backends (if vc-mode '(RCS CVS SVN SCCS SRC Bzr Git Hg) nil))) Since vc-mode is just a dummy function; I per-used it. Now I can keep in my init file (setq vc-handled-backends nil) and nothing screems after Git when it is not in the path; and in projects where I wish to work with vc-mode and run vc-dir, I can start vc-mode and than vc-dir works as expected. I also don't see how Emacs could know when to start vc-mode and when not, without user taking an action. If complete automatic handling of version control is desired than something like that is not acceptable. An alternative could be to have another find-file/save-file functions, say find/save-vc-file, that does the same, but also runs the vc-refresh-status. Than those who prefer to always see vc status when in a vc repo could use it as the default find-file function; and those like me, who would prefer it on-demand, could call it when they need it. But that is not so pretty and automatic. Anyway, I think I can personally live with my hack, unless there is something really nasty I am forseeing there. That achieves what I asked for, without you needed to change anything.