emacs-devel
[Top][All Lists]
Advanced

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

RE: difference between maximized and fullscreen?


From: Drew Adams
Subject: RE: difference between maximized and fullscreen?
Date: Wed, 1 Jul 2009 10:52:33 -0700

> I added a frame parameter called sticky.  Please try it.

1. I haven't been following this thread. Please ignore if I misunderstand.

Does this mean that the current frame size (and position?) can be "pinned"
(locked), so that frame sizing (and positioning?) functions have no effect
(unless the `sticky' frame parameter is reset to nil)?

That could be interesting. But it might be even better to have a frame-local
variable to control such locking, instead of a frame parameter. That way, a
function could `let'-bind the variable, to inhibit frame movements and resizing
for a given `let' scope (duration). A user could still unconditionally lock a
frame, but would do so by setting the variable instead of a frame parameter.

----

2. We might even have a user option whose value is a list of frame parameters
(not their values) that are to be controlled by this locking. By default, the
list could be just the size and position parameters, but other parameters might
be made susceptible also.

----

3. BTW, I see that the Elisp manual (node Frame-Local Variables) suggests that
frame-local vars are more or less deprecated (since 22.2). Why? The only reason
given is that they "have not proven very useful." The same could be said for
lots of Emacs features that have never been used much. That's hardly been a
sufficient reason to deprecate.

I've never used frame-local variables, myself, but it seems like they could be
useful, as suggested above. `let' binding could be handier than calling
`modify-frame-parameters' explicitly to set and then reset (and perhaps wrapping
with `unwind-protect', to ensure restoration).

Now if there is some additional reason for deprecating - some _problems_ that
arise from having frame-local vars, then that is a different matter. But the
only reason given seems pretty weak: lack of use of a feature is not much of a
reason to remove it. Especially since this feature was introduced only a short
while before it was deprecated (IIUC, it was introduced in Emacs 22.1 and
deprecated in Emacs 22.2?).






reply via email to

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