From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: [External] : Running emacs without any customisation Date: Fri, 14 Oct 2022 07:10:51 +0200 Message-ID: <87k053xa5g.fsf@dataswamp.org> References: <87r0zc4vf8.fsf@web.de> <7HiwKI9ptNll3M2bOs3ZkSdNAwhZVriIna8lWb4iFHq8HXpm2snZJVHjpxj5gq5GSaaq5OjY5vE-8j7ZECzKIdcDJjzPR5m4mOs7B9mkfOQ=@proton.me> <87lepk4te0.fsf@web.de> <87r0zcn13o.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7784"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:TMZP08aLBpvwZkf1V4O6d7h5MnU= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 14 17:18:05 2022 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 1ojMRp-0001pq-6A for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 14 Oct 2022 17:18:05 +0200 Original-Received: from localhost ([::1]:53228 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojMRn-0007bc-LG for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 14 Oct 2022 11:18:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35426) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojCyM-00024h-8O for help-gnu-emacs@gnu.org; Fri, 14 Oct 2022 01:11:02 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]:42812) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojCyK-0002EC-NR for help-gnu-emacs@gnu.org; Fri, 14 Oct 2022 01:11:02 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1ojCyI-00005X-Cv for help-gnu-emacs@gnu.org; Fri, 14 Oct 2022 07:10:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 14 Oct 2022 11:07:25 -0400 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" Xref: news.gmane.io gmane.emacs.help:139940 Archived-At: Here is that old (2013-08-07) article again. I understand it but not the 1-3 part, really? I wonder what I is? ~/.Xdefaults and ~/.Xresources The old solution was: Whenever an X (Xlib) application is started, it looks in ~/.Xdefaults for settings before it executes; the file had to be on the same filesystem, in the user's HOME. The new or half-new solution is: Whenever an X application is started, it looks for settings in RESOURCE_MANAGER (XA_RESOURCE_MANAGER) in the root window of screen 0. Settings are there only if xrdb(1) has been executed since the start of X. If not, the _fallback_ is to look for settings in ~/Xdefaults (every time and for every application, i.e. the same as the old solution). xrdb doesn't necessarily read ~/.Xresources, that's a convention. In face xrdb can read many and any file, even ~/.Xdefaults. xrdb has to be used even for With Xresources any user can use, or not use, xrdb to load settings. Xresources are mobile; compare to ~/.Xdefaults which hs to be in $HOME. To test the enhanced mobility, after reading resources with xrdb, do the following: 1. In X, a WM (e.g. openbsd-cwm) a terminal emulator (xterm), ssh to some system with the -Y option. There, start xterm, or any other application that you have configured on your local system but not on the system to which you ssh'd. Then, do the same on you local system, start xterm. They look the same! 2. Now, on your local system, run 'xrdb -remove'. Again, start xterm on both the remote and the local system - again, they look the same, only now, they aren't configured. 3. Last, to demonstrate the limited scope of Xdefaults, without using xrdb since step 2, on you local system, run 'cp ~/.Xresources ~/.Xdefaults' (after salvaging anything of value from Xdefaults), then run xterm on both remote and local system. The remote xterm is unconfigured, but the local xterm is - only this time from Xdefaults. Notes: The #1 Google hit on this issue recommends making ~/.xinitrc an executable, with 'chmod +x' - this is not needed. Also, the same article exemplifies the use of xrdb in .xinitrc with a trailing '&', making xrdb a background process. This isn't right, as the next program run from .xinitrc may use the very same settings, that xrdb is in the process of setting up, and that must be completed before any application that depends on it can be run. The cure is, remove the '&'. Some xterm settings useful for testing: xterm*autoWrap: true xterm*pointerMode: 2 xterm*geometry: 77x28 xterm*background: black xterm*foreground: green4 xterm*faceName: default xterm*metaSendsEscape: true -- underground experts united https://dataswamp.org/~incal