From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: crstml@libero.it Newsgroups: gmane.emacs.help Subject: Re: emacs settings priority Date: Sat, 6 Apr 2024 14:58:57 +0200 Message-ID: References: <45fa1e7c-8397-89d9-3c25-ad4c0ffdef6c@libero.it> <86le5s57tm.fsf@gnu.org> <5eb56522-55f0-9b47-31ce-e6772b0622df@libero.it> <864jcf68ac.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28601"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.18.2 To: Eli Zaretskii , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 06 14:59:34 2024 Return-path: Envelope-to: geh-help-gnu-emacs@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 1rt5du-0007D2-5R for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 06 Apr 2024 14:59:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rt5dS-0000fR-NZ; Sat, 06 Apr 2024 08:59:06 -0400 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 1rt5dQ-0000f3-J9 for help-gnu-emacs@gnu.org; Sat, 06 Apr 2024 08:59:04 -0400 Original-Received: from smtp-36.italiaonline.it ([213.209.10.36] helo=libero.it) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rt5dN-0005iD-8t for help-gnu-emacs@gnu.org; Sat, 06 Apr 2024 08:59:04 -0400 Original-Received: from [192.168.1.81] ([82.48.216.66]) by smtp-36.iol.local with ESMTPA id t5dJric1BgGJat5dJreXIX; Sat, 06 Apr 2024 14:58:57 +0200 x-libjamoibt: 1601 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=libero.it; s=s2021; t=1712408337; bh=nhJUSAQq7SfaRo2d3yARtgZMYJ3bjhWdv0A9O+LFtmc=; h=From; b=lNBMfIw8Vc7Gmg7CQOOiM9TtWFJCnaTHJvl5mGsMPXAGFkZkFLEYRl3RL8Wi4UHLY LbdqvnXe05m9sfYHyVwzDpt7EwLmGKb2OtAinYcJH0z0Twu5CsHgMZqZ6sVUPu0aH1 vUeRgSGfjdcrWq+cBgsv8phatRVGOlPE+wu8q/gJJ4nKUVdCDzddpJtSSx8Wc1W3/H htNqYTko46CDhz7oCNBxbTl/0oh4kjW+OkVoT3OOrkYdqjB335E3czaqb3bazH2qle AW28EcsfRDj5lY772X32X0PdPZWlZO3Iwg5HcXVeeLzkv7FRL/+oJVM6MFKA1CzTab GeVHjjcGp1Wwg== X-CNFS-Analysis: v=2.4 cv=XYRCz555 c=1 sm=1 tr=0 ts=66114711 cx=a_exe a=E5W9XbWavI9sVty9kX9hfw==:117 a=E5W9XbWavI9sVty9kX9hfw==:17 a=IkcTkHD0fZMA:10 a=Sjl_284XKy_0prSpHaEA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 In-Reply-To: <864jcf68ac.fsf@gnu.org> X-CMAE-Envelope: MS4xfJ2po1Nt+++PybX7ECpWRx1BHcdKMvXPyRUVIbrFzS8ChVLsMleRe5pXc75AF80LvHI9NU7A+ysiaSj6clUrWyd2BN4WMbp2qqGAlJC5OKhWXZY+pL3t idBM3+Xog+Bdh/7xfpgk9Wby3JcqQFAPSE1VI885p7JWnd0hcf9Dba0bXbpTJ9GfFTwRXoXNsB9qcqOdb5bXU+bhIeO9rrxvods= Received-SPF: pass client-ip=213.209.10.36; envelope-from=crstml@libero.it; helo=libero.it X-Spam_score_int: -55 X-Spam_score: -5.6 X-Spam_bar: ----- X-Spam_report: (-5.6 / 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, NICE_REPLY_A=-3.458, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:146252 Archived-At: Eli Zaretskii wrote: >> From: crstml@libero.it >> Date: Fri, 5 Apr 2024 18:07:57 +0200 >> >> Eli Zaretskii wrote: >>>> I've tried without success to find in the manual information >>>> about these priorities/precedences. >>>> >>>> Is it possible to know how emacs decides what font is used when the >>>> same font is specified in more places: X resource, command line, >>>> init file? >>> Why is it important to know? >> When a user specify some setting in the command line for example he expects >> some feedback from the application. If the effect of that setting is not visible >> the user must understand the cause. > If you can describe a situation where a setting from the command line > didn't have any effect, please do. Of course. Here is my configuration: ---- begin OS Version ---- Distributor ID: Debian Description:    Debian GNU/Linux 12 (bookworm) Release:        12 Codename:       bookworm Basically a clean Debian 12 installation. ---- end OS Version ---- ---- begin ~/.emacs ---- (custom-set-faces  ;; custom-set-faces was added by Custom.  ;; If you edit it by hand, you could mess it up, so be careful.  ;; Your init file should contain only one such instance.  ;; If there is more than one, they won't work right.  '(default ((t (:inherit nil :extend nil :stipple nil :background "black" :foreground "gray" :inverse-video nil :box nil :strike-through nil :overline nil :underline nil :slant normal :weight normal :height 113 :width normal))))  '(font-lock-builtin-face ((t (:foreground "cornflower blue"))))  '(font-lock-comment-delimiter-face ((default (:inherit font-lock-comment-face)) (((class color) (min-colors 16)) nil)))  '(font-lock-comment-face ((t (:foreground "red"))))  '(font-lock-function-name-face ((((class color) (min-colors 88) (background dark)) (:foreground "gray" :weight bold))))  '(font-lock-keyword-face ((((class color) (min-colors 88) (background dark)) (:foreground "RoyalBlue"))))  '(font-lock-string-face ((((class color) (min-colors 88) (background dark)) (:foreground "orange"))))  '(font-lock-type-face ((((class color) (min-colors 88) (background dark)) (:foreground "darkslategray"))))  '(font-lock-variable-name-face ((t (:foreground "goldenrod"))))  '(mode-line ((((class color) (min-colors 88)) (:background "orange" :foreground "black"))))) ;;No other contents is present in this file ;; ---- end ~/.emacs ---- Here are the tests: 1) Try the following command lines:     emacs -fn 10x20 &     emacs -fn lucidasanstypewriter-24 &     There is no difference between the emacs instances regarding the fonts. 2) Rename the .emacs to .emacs.disabled and run the same commands again.    mv .emacs .emacs.disabled    emacs -fn 10x20 &    emacs -fn lucidasanstypewriter-24 &    Now without the .emacs file the -fn command line option is taken    into account. From these tests it's obvious that -fn has lower precedence than the .emacs file. It turns that probably I always need to specify an init file in the command line when I start emacs (if sometimes I want a different behavior). Not that it's impossible or difficult. But I had to do some experiments to understand what is going on and in the end I was interested if this stuff is documented probably with some advice/best practices about how the users should set up their environments. >>> Users aren't supposed to specify >>> contradictory setting via several different means of doing so. >> Is the fact that the users aren't supposed to specify different settings >> via several different means an overall design decision? If yes, then the >> users should be aware of this decision and it should be specified in the >> manual. >> >> But (personal opinion based on my way of using emacs) such a design decision >> is not very wise. Users must be able to control how the settings are applied >> or what are the causes of their impossibility of specifying settings. >> >> Maybe I want to start an instance of emacs with a different background color >> and font size in a certain context (using the command line or a context >> dependent configuration file) and I see that these settings are not applied. >> >> How can I understand why not or what can I do? > Please describe a specific situation where this happens, and let's > take it from there. You seem to be talking about some general > principles, and I'm not sure that is useful. In general, Emacs does > sensible things in these cases, so it isn't like the user is > completely in the dark. >