From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: master f8fed41 2/3: image-dired: Improve XDG compliance Date: Tue, 26 Oct 2021 16:45:04 +0200 Message-ID: References: <83sfwp1c27.fsf@gnu.org> <83sfwnyi65.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3407"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs developers To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 26 16:47:13 2021 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 1mfNjN-0000dQ-1E for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Oct 2021 16:47:13 +0200 Original-Received: from localhost ([::1]:58666 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mfNjL-0005CE-NA for ged-emacs-devel@m.gmane-mx.org; Tue, 26 Oct 2021 10:47:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60338) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mfNhX-0003kV-SV for emacs-devel@gnu.org; Tue, 26 Oct 2021 10:45:21 -0400 Original-Received: from mail-pj1-f45.google.com ([209.85.216.45]:38657) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mfNhW-0004GQ-C9; Tue, 26 Oct 2021 10:45:19 -0400 Original-Received: by mail-pj1-f45.google.com with SMTP id y1-20020a17090a134100b001a27a7e9c8dso2085496pjf.3; Tue, 26 Oct 2021 07:45:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bsigtWdzLNlULSe8XY+Dk9gvaxGsNbEb/JDe3LS1d7E=; b=IZUDcYFpR1XJ1W/shoiY6Pjs54src0PvPeo5i4HnCk5rDhCjEOmoLJs/1MoELoXb7h d+UpEdyDrokco9yOIP8beak6kQLO0dKQowcZmuJDxJ7fNOaS+m3jdk00X3DkCMayGKkh s8m+nwZeFKsuEcTkvGK2tHZc3dwyv255+BRKUV9RPgiNsjmfzjaOj2xxunJtJY4PC0Ut 1nwNrJZrObmdM6yESHXABRCjGmwNSNPeGPyqF4UZwAGIMCyXs6zbCNcN5ERWW9FWTlEf pRkSJkyj7YM88qRY+3eucRntOU8igNBnUvAvvBSheditpsth3WG6sFUgC99ePDeuArfA v1RQ== X-Gm-Message-State: AOAM532eCKZWFRJCgiRkvKFL86Z3qlHM6T5NRZytsbCJKm8Zz9tK542V MkcXr0txcym6eeOk/d+748T0eBJR81WvrkNAYiGFjpdL X-Google-Smtp-Source: ABdhPJwR8b2SaA3YO3mSl2zlvfLMFnShvnI9yyV4mIlerlJL901AoSwuYcNFbiWKKURrdgmk1HOnlgphJqnx00hUG98= X-Received: by 2002:a17:90a:d917:: with SMTP id c23mr21705927pjv.133.1635259516473; Tue, 26 Oct 2021 07:45:16 -0700 (PDT) In-Reply-To: <83sfwnyi65.fsf@gnu.org> Received-SPF: pass client-ip=209.85.216.45; envelope-from=stefankangas@gmail.com; helo=mail-pj1-f45.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:277873 Archived-At: Eli Zaretskii writes: > I proposed to have a couple of higher-level APIs that will hide > system-dependent stuff, including hard-coded strings if some systems > need that. xdg.el will then be one layer lower, and application code > will not call it directly. OK, I think we agree that this would be a good thing. The contentious point seems to be what we should do until we have such a library. I think that it is better to update hardcoded strings to use xdg.el, since it will make the above idea easier to implement. However, if we have a plan for a higher-level API in a reasonable time-frame (for example, before Emacs 29 is released), then I am more than happy to accept that we might as well wait with any such changes until that work is done.