emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Should https://www.gnu.org/software/emacs/manual/html_node/efaq/Full


From: Eli Zaretskii
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: Sat, 30 Sep 2023 21:36:19 +0300

> From: chad <yandros@gmail.com>
> Date: Sat, 30 Sep 2023 14:09:22 -0400
> Cc: David Hedlund <public@beloved.name>, Emacs-devel@gnu.org
> 
> I'm trying to catch up here, as David Hedlund asked me if I could help
> out (as English is not his most comfortable language), and the
> conversation has splintered somewhat. I myself joined the conversation
> a bit late, so I might be confused myself.
> 
> The issue that DH has raised, as I understand it, surrounds the FAQ
> entry in the Emacs manual titled "Fullscreen mode on MS-Windows". This
> FAQ covers a few different ways to adjust the emacs frame under
> MS-Windows, including older versions of emacs that predate the emacs
> function toggle-frame-maximized (or perhaps predate it functioning
> under MS-Windows). He also prefers to avoid the situation where Emacs
> maps a "normal" window and then resizes it later (perhaps because it's
> distracting, because it seems to take longer, or some other reason).
> 
> The FAQ entry in the most recent release talks about avoiding this
> "distracting visual effect" by setting ersatz X Resources via the
> Windows registry or a short set of emacs commands. IIUC, DH was
> searching for a solution that would cause emacs to start with a
> fullscreen window (rather than start and quickly grow to fullscreen),
> and that would work across platforms. This is where I jumped in.
> 
> The solution I proposed was: add this line to the early-init.el file:
> 
>   (push '(fullscreen . maximized) default-frame-alist)
> 
> There is a variant of this solution that instead uses:
> 
>   (push '(fullscreen . maximized) initial-frame-alist)
> 
> to effect only the initial window.
> 
> With that as the background, I think the proposal is:
> 
>  In the efaq node "Fullscreen mode on MS-Windows", replace the
>  following text:
> 
> >Beginning with Emacs 24.4 either run Emacs with the ‘--maximized’
> >command-line option or put the following form in your init file (*note
> >Setting up a customization file::):
> >
> >     (add-hook 'emacs-startup-hook 'toggle-frame-maximized)
> 
> With something like this:
> 
> >Beginning with Emacs 24.4 either run Emacs with the ‘--maximized’
> >command-line option or put the following form in your early-init file
> >(*note*note (emacs)Early Init File::):
> >
> >     (push '(fullscreen . maximized) default-frame-alist)

Thanks.

Unfortunately, this just increases the confusion in this thread.  Let
me explain why.

First, that section in the FAQ is specifically about MS-Windows.  So
looking for a portable solution is okay, but is out of scope of the
question that section tries to answer.

Second, I don't understand what is wrong with what the FAQ says
already, viz.:

  Beginning with Emacs 24.4 either run Emacs with the ‘--maximized’
  command-line option or put the following form in your init file (*note
  Setting up a customization file::):

       (add-hook 'emacs-startup-hook 'toggle-frame-maximized)

  [...]
  Alternatively, you can avoid the visual effect of Emacs changing its
  frame size entirely in your init file (i.e., without using the
  Registry), like this:

  @lisp
  (setq frame-resize-pixelwise t)
  (set-frame-position nil 0 0)
  (set-frame-size nil (display-pixel-width) (display-pixel-height) t)
  @end lisp

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).

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.

To summarize:

  . if what we have in the FAQ is incorrect or not good enough, please
    someone explain what and why
  . if it _is_ correct, why replace it?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]