From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: David Hedlund Newsgroups: gmane.emacs.devel Subject: Re: Should https://www.gnu.org/software/emacs/manual/html_node/efaq/Fullscreen-mode-on-MS_002dWindows.html be renamed to Maxmize-mode-on-MS_002dWindows.html ? Date: Tue, 3 Oct 2023 00:40:49 +0200 Message-ID: <2d4fcd29-6b93-4e8f-9a43-80d950255687@beloved.name> References: <83o7hjahlw.fsf@gnu.org> <837co7a4po.fsf@gnu.org> <8ca2201b-c0f9-4e8d-b4ca-82d02ad78b99@beloved.name> <8334yva2m8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------ua7ugmRYVgg51zO98QMteIUq" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5918"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 03 00:41:43 2023 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 1qnRbj-0001Dd-1P for ged-emacs-devel@m.gmane-mx.org; Tue, 03 Oct 2023 00:41:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qnRb9-0005Tk-BI; Mon, 02 Oct 2023 18:41:07 -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 1qnRb4-0005TS-Cj for emacs-devel@gnu.org; Mon, 02 Oct 2023 18:41:02 -0400 Original-Received: from relay9-d.mail.gandi.net ([2001:4b98:dc4:8::229]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qnRaz-0000vo-GC for emacs-devel@gnu.org; Mon, 02 Oct 2023 18:41:02 -0400 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 48A51FF803 for ; Mon, 2 Oct 2023 22:40:50 +0000 (UTC) Content-Language: en-US In-Reply-To: <8334yva2m8.fsf@gnu.org> X-GND-Sasl: public@beloved.name Received-SPF: pass client-ip=2001:4b98:dc4:8::229; envelope-from=public@beloved.name; helo=relay9-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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.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:311246 Archived-At: This is a multi-part message in MIME format. --------------ua7ugmRYVgg51zO98QMteIUq Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 9/30/23 21:21, Eli Zaretskii wrote: >> Date: Sat, 30 Sep 2023 21:06:52 +0200 >> From: David Hedlund >> >> Do these two methods not work, or have some downside? If they do >> work, then we could perhaps _add_ an alternative solution, but I don't >> see why we should _replace_ the existing one(s). >> >> I agree that it should be added (not replaced). > OK. > >> Next, the alternative solution does have a drawback, albeit a minor >> one: it uses early-init.el, something that is explicitly NOT >> recommended for display-related customizations. It evidently works in >> this case, but advertising this in the FAQ flies in the face of our >> general recommendation not to do this kind of stuff there. > Specifically, the Emacs user manual says: > > We do not recommend that you move into ‘early-init.el’ customizations > that can be left in the normal init files. That is because the early > init file is read before the GUI is initialized, so customizations > related to GUI features will not work reliably in ‘early-init.el’. By > contrast, the normal init files are read after the GUI is initialized. > If you must have customizations in the early init file that rely on GUI > features, make them run off hooks provided by the Emacs startup, such as > ‘window-setup-hook’ or ‘tty-setup-hook’. *Note Hooks::. > > So I wonder whether we should advertise the suggested addition for > early-init file. Stefan, WDYT? > >> While we're speaking about this, this is a relevant question regarding the issue for GNU/Linux: So >> even "(push '(fullscreen . maximized) default-frame-alist)" to ~/.emacs.d/early-init.el is the only >> solution to automatically maximize emacs without the visually distracting effect in GNU/Linux, should >> it not be added to the FAQ to a new section, say >> https://www.gnu.org/software/emacs/manual/html_node/efaq/Fullscreen-mode-on-GNU-Linux.htm? >> Just "(add-hook 'emacs-startup-hook 'toggle-frame-maximized)" to the top ~/.emacs file if it has a >> common size (say 100 lines), will cause it to maximize the windows but not without the visually >> distracting effect. > Is this indeed a "frequently-asked" question, about GNU/Linux? Yes. > If it > is, I'm okay with adding such a section, or even rewriting this > section (and renaming it) to make it not Windows-specific. But we do > not usually add here answers for questions just because they _could_ > be asked. Again, I'd like to hear Stefan's opinion on this. > --------------ua7ugmRYVgg51zO98QMteIUq Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 9/30/23 21:21, Eli Zaretskii wrote:
Date: Sat, 30 Sep 2023 21:06:52 +0200
From: David Hedlund <public@beloved.name>

Do these two methods not work, or have some downside?  If they do
work, then we could perhaps _add_ an alternative solution, but I don't
see why we should _replace_ the existing one(s).

I agree that it should be added (not replaced).

OK.


Next, the alternative solution does have a drawback, albeit a minor
one: it uses early-init.el, something that is explicitly NOT
recommended for display-related customizations.  It evidently works in
this case, but advertising this in the FAQ flies in the face of our
general recommendation not to do this kind of stuff there.

Specifically, the Emacs user manual says:

     We do not recommend that you move into ‘early-init.el’ customizations
  that can be left in the normal init files.  That is because the early
  init file is read before the GUI is initialized, so customizations
  related to GUI features will not work reliably in ‘early-init.el’.  By
  contrast, the normal init files are read after the GUI is initialized.
  If you must have customizations in the early init file that rely on GUI
  features, make them run off hooks provided by the Emacs startup, such as
  ‘window-setup-hook’ or ‘tty-setup-hook’.  *Note Hooks::.

So I wonder whether we should advertise the suggested addition for
early-init file.  Stefan, WDYT?


While we're speaking about this, this is a relevant question regarding the issue for GNU/Linux: So
even "(push '(fullscreen . maximized) default-frame-alist)" to ~/.emacs.d/early-init.el is the only
solution to automatically maximize emacs without the visually distracting effect in GNU/Linux, should
it not be added to the FAQ to a new section, say
https://www.gnu.org/software/emacs/manual/html_node/efaq/Fullscreen-mode-on-GNU-Linux.htm?
Just "(add-hook 'emacs-startup-hook 'toggle-frame-maximized)" to the top ~/.emacs file if it has a
common size (say 100 lines), will cause it to maximize the windows but not without the visually
distracting effect.

Is this indeed a "frequently-asked" question, about GNU/Linux?

Yes.

If it
is, I'm okay with adding such a section, or even rewriting this
section (and renaming it) to make it not Windows-specific.  But we do
not usually add here answers for questions just because they _could_
be asked.  Again, I'd like to hear Stefan's opinion on this.
--------------ua7ugmRYVgg51zO98QMteIUq--