From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuuki Harano Newsgroups: gmane.emacs.devel Subject: Re: Merging the pgtk branch Date: Tue, 03 Aug 2021 21:52:45 +0900 (JST) Organization: Ingage Inc. Message-ID: <20210803.215245.224350998069594262.masm@luna.pink.masm11.me> References: <835ywpo8ar.fsf@gnu.org> <20210802.013859.2264148309496126056.masm@luna.pink.masm11.me> <83mtq0m5gu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19318"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: eliz@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 03 14:53:43 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 1mAtvR-0004qr-Tu for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Aug 2021 14:53:42 +0200 Original-Received: from localhost ([::1]:47434 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mAtvQ-0008VL-0T for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Aug 2021 08:53:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40386) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mAtum-0007pN-AZ for emacs-devel@gnu.org; Tue, 03 Aug 2021 08:53:00 -0400 Original-Received: from shiro.masm11.me ([150.95.182.25]:57632) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mAtui-0003Sf-Tp; Tue, 03 Aug 2021 08:52:59 -0400 Original-Received: from luna.pink.masm11.me (KD106180013089.au-net.ne.jp [106.180.13.89]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by shiro.masm11.me (Postfix) with ESMTPSA id 97164C0128; Tue, 3 Aug 2021 21:52:47 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=masm11.me; s=202002; t=1627995167; bh=gEwdYGhWNkXyE19IO2A6Adk+5WOGwqOnwGWeP6XBMaE=; h=Date:To:Cc:Subject:From:In-Reply-To:References; b=ll5zG4CjOjRKIXoSU9AFE/dfdWOxj+dF0xCu0rloV4AnHPnTdYGKI16txcdhKOlLW 0jThlAlMcdpFnfWye0I/czcDFxDsAI3KqmSwgYnwHsyoQWFuKiMxBRatE/9KIz0vb9 GIiow2AfH2YjGntieDnewtYYge1ovaFKwbIrXf1Q= In-Reply-To: <83mtq0m5gu.fsf@gnu.org> X-Mailer: Mew version 6.8 on Emacs 28.0 Received-SPF: pass client-ip=150.95.182.25; envelope-from=masm@masm11.me; helo=shiro.masm11.me 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:271969 Archived-At: On Mon, 02 Aug 2021 14:49:37 +0300, Eli Zaretskii wrote: >> >> -install: all install-arch-indep install-etcdoc install-arch-dep install-$(NTDIR) blessmail install-eln >> >> +install: all install-arch-indep install-etcdoc install-arch-dep install-$(NTDIR) blessmail install-eln install-gsettings-schemas >> >> @true >> > >> > Does this mean gsettings-schemas will be installed by non-PGTK builds >> > as well? If not, where are the conditions to prevent that? >> >> Yes, it is installed if gsettings is enabled, even if non-PGTK builds. > > Is that useful without the PGTK build? What is that used for? No, it is not useful for non-PGTK build. X build supports X defaults. But GTK doesn't support it. Instead, I implemented this hook with gsettings: terminal->get_string_resource_hook = pgtk_get_string_resource; gsettings supports type. Type of each key is written in the schema file etc/org.gnu.emacs.defaults.gschema.xml. (I implemented this feature instead of X defaults, so types of all the key are string.) However, I'm not sure whether people want Xdefaults-like feature. Emacs' frame parameters are enough... >> >> --- a/lisp/server.el >> >> +++ b/lisp/server.el >> >> @@ -900,12 +900,17 @@ server-create-window-system-frame >> >> ) >> > >> >> (cond (w >> >> - (server--create-frame >> >> - nowait proc >> >> - `((display . ,display) >> >> - ,@(if parent-id >> >> - `((parent-id . ,(string-to-number parent-id)))) >> >> - ,@parameters))) >> >> + (condition-case nil >> >> + (server--create-frame >> >> + nowait proc >> >> + `((display . ,display) >> >> + ,@(if parent-id >> >> + `((parent-id . ,(string-to-number parent-id)))) >> >> + ,@parameters)) >> >> + (error >> >> + (server-log "Window system unsupported" proc) >> >> + (server-send-string proc "-window-system-unsupported \n") >> >> + nil))) >> > >> > Why is this change needed? >> >> emacsclient tries WAYLAND_DISPLAY, and DISPLAY if the first try is failed. >> The code catches the display connection failure, and returns the failure >> to emacsclient. > > Hmm... what about window-systems that have neither WAYLAND_DISPLAY nor > DISPLAY? will this always fail? I feel that I'm missing something > here: why wasn't this needed before? Sorry, I mistook. GTK supports GDK_BACKEND environment variable. If GDK_BACKEND=wayland, GTK tries only wayland connection. If GDK_BACKEND=x11, GTK tries only X connection. If GDK_BACKEND=wayland,x11, GTK tries wayland connection, and X connection if the first try failed. If GDK_BACKEND=x11 and DISPLAY is not set, then emacs fails to start. ---- luna:objs % unset DISPLAY luna:objs % GDK_BACKEND=x11 ./src/emacs (emacs:322982): Gtk-WARNING **: 00:31:26.986: cannot open display: luna:objs % ---- If GDK_BACKEND=x11 and DISPLAY=:0, then emacs starts. However, `emacsclient -c` first tries with WAYLAND_DISPLAY and it fails, because GDK_BACKEND=x11 and emacs itself does not open wayland connection. The error is: ---- -error Cannot&_connect&_to&_display&_server&_wayland&-1 ---- (In case of WAYLAND_DISPLAY=wayland-1.) And emacsclient does not retry. I wanted to work around this error. I send -window-system-unsupported by that change. In this case, emacsclient retry with alt_display, which is DISPLAY by another change. > what about window-systems that have neither WAYLAND_DISPLAY nor > DISPLAY? will this always fail? emacsclient.c: ---- #if defined (NS_IMPL_COCOA) alt_display = "ns"; #elif defined (HAVE_NTGUI) alt_display = "w32"; #endif ---- if (!display) { display = alt_display; alt_display = NULL; } ---- On ns and w32, display is set. To make sure whether that change works on ns and w32, it is needed to test on such machines. I didn't test on such machines. -- Yuuki Harano