* bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows
@ 2008-11-14 22:46 Themba Fletcher
2008-11-15 9:40 ` Eli Zaretskii
2014-09-21 18:02 ` martin rudalics
0 siblings, 2 replies; 25+ messages in thread
From: Themba Fletcher @ 2008-11-14 22:46 UTC (permalink / raw)
To: bug-gnu-emacs
When migrating to Emacs 22.3.1 on microsoft windows, the following
lines in my .emacs file do not behave as expected:
(set-frame-position (selected-frame) 0 0)
(sleep-for 2) ; not originally in my .emacs -- testing only
(set-frame-width (selected-frame) 150)
(sleep-for 2)
(set-frame-height (selected-frame) 55)
(sleep-for 2))
This used to leave me with a 150 X 55 frame located at 0,0 on my
display but it instead now leaves me with a default size frame still
located at 0,0 as expected. Please note that when I said M-x ielm and
pasted in the set-frame-width and -height lines as above after emacs
finished loading they did as I expected, ie. resized the frame
without problem.
I replaced these lines with the following in my .emacs as a
workaround:
(let ((destructo-target (selected-frame)))
(make-frame (list '(top . 0)
'(left . 0)
'(width . 150)
'(height . 55)))
(delete-frame destructo-target))
In GNU Emacs 22.3.1 (i386-mingw-nt5.1.2600)
of 2008-09-06 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: ENU
locale-coding-system: cp1252
default-enable-multibyte-characters: t
Major mode: Lisp
Minor modes in effect:
icomplete-mode: t
partial-completion-mode: t
encoded-kbd-mode: t
tooltip-mode: t
mouse-wheel-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
size-indication-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
<drag-n-drop> M-x l i s p SPC m o d e <tab> <return>
<wheel-down> <double-wheel-down> <triple-wheel-down>
<triple-wheel-down> <triple-wheel-down> <wheel-up>
<double-wheel-up> M-x f i l e SPC b u <tab> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> r e p o r <tab> <return>
Recent messages:
Loading goto-addr...done
top.org has auto save data; consider M-x recover-this-file
Loading c:/Program Files/emacs-22.3/site-lisp/org-6.12b/lisp/org.el
(source)...
Loading easy-mmode...done
Loading derived...done
Loading c:/Program Files/emacs-22.3/site-lisp/org-6.12b/lisp/org.el
(source)...done
OVERVIEW
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading url-util...done
Loading emacsbug...done
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows
2008-11-14 22:46 bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows Themba Fletcher
@ 2008-11-15 9:40 ` Eli Zaretskii
2008-11-15 10:04 ` Eli Zaretskii
2008-11-17 20:50 ` Themba Fletcher
2014-09-21 18:02 ` martin rudalics
1 sibling, 2 replies; 25+ messages in thread
From: Eli Zaretskii @ 2008-11-15 9:40 UTC (permalink / raw)
To: Themba Fletcher, 1348; +Cc: bug-gnu-emacs
> From: "Themba Fletcher" <themba@shirleymachine.com>
> Date: Fri, 14 Nov 2008 17:46:19 -0500
> Cc:
>
> When migrating to Emacs 22.3.1 on microsoft windows, the following
> lines in my .emacs file do not behave as expected:
>
> (set-frame-position (selected-frame) 0 0)
> (sleep-for 2) ; not originally in my .emacs -- testing only
> (set-frame-width (selected-frame) 150)
> (sleep-for 2)
> (set-frame-height (selected-frame) 55)
> (sleep-for 2))
^
(Extra paren here.)
> This used to leave me with a 150 X 55 frame located at 0,0 on my
> display but it instead now leaves me with a default size frame still
> located at 0,0 as expected.
This leaves me with a 80x55 frame located at (0,0), not a default size
frame. I see this both in Emacs 22.3.1 and in the current CVS trunk.
So, while still not entirely correct, the behavior I see is different,
and I wonder why. Is the above the _only_ contents of your .emacs?
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows
2008-11-15 9:40 ` Eli Zaretskii
@ 2008-11-15 10:04 ` Eli Zaretskii
2008-11-15 14:12 ` martin rudalics
2008-11-17 20:50 ` Themba Fletcher
1 sibling, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2008-11-15 10:04 UTC (permalink / raw)
To: 1348; +Cc: bug-gnu-emacs, themba
> Date: Sat, 15 Nov 2008 11:40:39 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: bug-gnu-emacs@gnu.org
>
> This leaves me with a 80x55 frame located at (0,0), not a default size
> frame. I see this both in Emacs 22.3.1 and in the current CVS trunk.
I think this might be because of the code in
w32term.c:x_set_window_size that was ifdef'ed away to solve a more
grave problem.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows
2008-11-15 10:04 ` Eli Zaretskii
@ 2008-11-15 14:12 ` martin rudalics
0 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2008-11-15 14:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 1348, themba
>> This leaves me with a 80x55 frame located at (0,0), not a default size
>> frame. I see this both in Emacs 22.3.1 and in the current CVS trunk.
>
> I think this might be because of the code in
> w32term.c:x_set_window_size that was ifdef'ed away to solve a more
> grave problem.
Yes. But why does `set-frame-height' work after loading .emacs? The
menubar lines problem can bite whenever we resize a single-frame Emacs.
So what am I missing?
BTW, is this related to Bugs#117 and #201?
martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows
2008-11-15 9:40 ` Eli Zaretskii
2008-11-15 10:04 ` Eli Zaretskii
@ 2008-11-17 20:50 ` Themba Fletcher
2008-11-18 13:03 ` martin rudalics
1 sibling, 1 reply; 25+ messages in thread
From: Themba Fletcher @ 2008-11-17 20:50 UTC (permalink / raw)
To: 'Eli Zaretskii'; +Cc: bug-gnu-emacs
[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]
> From: Eli Zaretskii [mailto:eliz@gnu.org]
> Sent: Saturday, November 15, 2008 4:41 AM
> To: Themba Fletcher; 1348@emacsbugs.donarmstrong.com
> Cc: bug-gnu-emacs@gnu.org
> > From: "Themba Fletcher" <themba@shirleymachine.com>
> > Date: Fri, 14 Nov 2008 17:46:19 -0500
> > Cc:
> > When migrating to Emacs 22.3.1 on microsoft windows, the following
> > lines in my .emacs file do not behave as expected:
> > (set-frame-position (selected-frame) 0 0)
> > (sleep-for 2) ; not originally in my .emacs -- testing only
> > (set-frame-width (selected-frame) 150)
> > (sleep-for 2)
> > (set-frame-height (selected-frame) 55)
> > (sleep-for 2))
> (Extra paren here^)
Whoops, this was nested in an expression while I was testing.
> > This used to leave me with a 150 X 55 frame located at 0,0 on my
> > display but it instead now leaves me with a default size frame still
> > located at 0,0 as expected.
> This leaves me with a 80x55 frame located at (0,0), not a default size
> frame. I see this both in Emacs 22.3.1 and in the current CVS trunk.
> So, while still not entirely correct, the behavior I see is different,
> and I wonder why. Is the above the _only_ contents of your .emacs?
No, but the behavior held even when the rest of my .emacs was commented out.
Please feel free to play with my original .emacs file, attached.
I was upgrading, due to standard windows problems (ie I had to reformat and
reinstall), from Emacs 22.1 when I found this. Over the weekend I moved my
home machine from Emacs 22.2 to 22.3 and discovered two things:
1. The bug is present in 22.2
2. (set-frame-size) is not affected, and is probably a better work-around
than I gave in my previous message.
[-- Attachment #2: dot-emacs --]
[-- Type: application/octet-stream, Size: 2518 bytes --]
(server-start)
;; ***************************************************************************
(custom-set-variables
;; custom-set-variables was added by Custom.
;; If you edit it by hand, you could mess it up, so be careful.
;; Your init file should contain only one such instance.
;; If there is more than one, they won't work right.
'(column-number-mode t)
'(org-agenda-files (quote ("c:/Documents and Settings/tif/Desktop/top.org")))
'(scroll-bar-mode nil)
'(size-indication-mode t)
'(tool-bar-mode nil))
(custom-set-faces
;; custom-set-faces was added by Custom.
;; If you edit it by hand, you could mess it up, so be careful.
;; Your init file should contain only one such instance.
;; If there is more than one, they won't work right.
)
;; ***************************************************************************
(set-frame-position (selected-frame) 0 0)
(set-frame-height (selected-frame) 66)
(set-frame-width (selected-frame) 178)
(set-frame-name "emacs")
(set-default-font "-outline-Bitstream Vera Sans Mono-normal-r-normal-normal-12-90-96-96-c-*-iso8859-1")
(iconify-frame)
;; my global settings
(put 'upcase-region 'disabled nil)
(transient-mark-mode)
(global-font-lock-mode 1)
(partial-completion-mode 1)
(icomplete-mode 1)
(setq inhibit-splash-screen t)
;; colors
(require 'color-theme)
(color-theme-select) ; bullshit
(kill-buffer "*Color Theme Selection*") ; bullshit
(color-theme-jsc-dark)
;; print to dell laser, shared by local machine
;; M-x eshell, then net view cadstation01 to see shares list
(setq printer-name "//cadstation01/dell1710")
;; programming modes
(require 'generic-x)
(add-to-list 'auto-mode-alist '("\\.el$" . emacs-lisp-mode))
(add-to-list 'auto-mode-alist '("\\.elisp$" . emacs-lisp-mode))
;; sql-mode settings for local oracle installation
(require 'sql)
(defalias 'sql-get-login 'ignore)
;; org-mode
(require 'org-install)
(add-to-list 'auto-mode-alist '("\\.org$" . org-mode))
(define-key global-map "\C-cl" 'org-store-link)
(define-key global-map "\C-ca" 'org-agenda)
(setq org-log-done t)
(setq org-agenda-custom-commands
'(("n" occur-tree ":next:")))
(setq org-hide-leading-stars t)
;; NC-MODE !!!
(require 'nc)
(add-to-list 'auto-mode-alist '("\\.nc$" . nc-mode))
(defun edit-dot-emacs ()
(interactive)
(find-file "c:\.emacs"))
(put 'downcase-region 'disabled nil)
;; startup
(find-file "c:/Documents and Settings/tif/Desktop/top.org")
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows
2008-11-17 20:50 ` Themba Fletcher
@ 2008-11-18 13:03 ` martin rudalics
0 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2008-11-18 13:03 UTC (permalink / raw)
To: Themba Fletcher; +Cc: 1348
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
>>> When migrating to Emacs 22.3.1 on microsoft windows, the following
>>> lines in my .emacs file do not behave as expected:
>
>>> (set-frame-position (selected-frame) 0 0)
>>> (sleep-for 2) ; not originally in my .emacs -- testing only
>>> (set-frame-width (selected-frame) 150)
>>> (sleep-for 2)
>>> (set-frame-height (selected-frame) 55)
>>> (sleep-for 2))
[...]
> 1. The bug is present in 22.2
> 2. (set-frame-size) is not affected, and is probably a better work-around
> than I gave in my previous message.
Interesting. Does the attached patch give better results?
martin
[-- Attachment #2: dispnew.diff --]
[-- Type: text/plain, Size: 1002 bytes --]
*** dispnew.c.~1.424.~ 2008-10-28 07:22:51.656250000 +0100
--- dispnew.c 2008-11-18 13:57:27.546875000 +0100
***************
*** 6305,6310 ****
--- 6305,6316 ----
int new_frame_total_cols;
int count = SPECPDL_INDEX ();
+ /* If an argument is zero, set it to the current value. */
+ if (newheight == 0)
+ newheight = FRAME_LINES (f);
+ if (newwidth == 0)
+ newwidth = FRAME_COLS (f);
+
/* If we can't deal with the change now, queue it for later. */
if (delay || (redisplaying_p && !safe))
{
***************
*** 6318,6329 ****
f->new_text_lines = 0;
f->new_text_cols = 0;
- /* If an argument is zero, set it to the current value. */
- if (newheight == 0)
- newheight = FRAME_LINES (f);
- if (newwidth == 0)
- newwidth = FRAME_COLS (f);
-
/* Compute width of windows in F.
This is the width of the frame without vertical scroll bars. */
new_frame_total_cols = FRAME_TOTAL_COLS_ARG (f, newwidth);
--- 6324,6329 ----
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows
2008-11-14 22:46 bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows Themba Fletcher
2008-11-15 9:40 ` Eli Zaretskii
@ 2014-09-21 18:02 ` martin rudalics
2014-09-22 8:32 ` bug#456: menu-bar does not resize window martin rudalics
` (3 more replies)
1 sibling, 4 replies; 25+ messages in thread
From: martin rudalics @ 2014-09-21 18:02 UTC (permalink / raw)
To: 1348-done
> When migrating to Emacs 22.3.1 on microsoft windows, the following
> lines in my .emacs file do not behave as expected:
>
> (set-frame-position (selected-frame) 0 0)
> (sleep-for 2) ; not originally in my .emacs -- testing only
> (set-frame-width (selected-frame) 150)
> (sleep-for 2)
> (set-frame-height (selected-frame) 55)
> (sleep-for 2))
>
> This used to leave me with a 150 X 55 frame located at 0,0 on my
> display but it instead now leaves me with a default size frame still
> located at 0,0 as expected. Please note that when I said M-x ielm and
> pasted in the set-frame-width and -height lines as above after emacs
> finished loading they did as I expected, ie. resized the frame
> without problem.
Should work in emacs-24 as intended. Closing this bug.
Thanks, martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#456: menu-bar does not resize window
2014-09-21 18:02 ` martin rudalics
@ 2014-09-22 8:32 ` martin rudalics
2014-09-22 9:02 ` bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account martin rudalics
` (2 subsequent siblings)
3 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2014-09-22 8:32 UTC (permalink / raw)
To: 456-done
> M-x menu-bar-mode creates an awful effect on the emacs window. Lets
> say that menu-bar-mode is nil, that is, menu does not appear, and we
> have emacs "maximized". When activating it (M-x menu-bar-mode) the
> emacs window resizes and the minibuffer is out of the screen.
>
> The same happens on the other way around. if the window is maximized
> and the menu-bar is removed, it "stops" being maximized.
This should work with current trunk as intended. Bug closed.
Thanks, martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2014-09-21 18:02 ` martin rudalics
2014-09-22 8:32 ` bug#456: menu-bar does not resize window martin rudalics
@ 2014-09-22 9:02 ` martin rudalics
2014-09-22 14:02 ` Drew Adams
2014-09-22 9:07 ` bug#9105: Feature req: Remembering emacs frames, windows, buffer position to subsequent session martin rudalics
2014-09-22 9:26 ` bug#203: Maximize frame does not work at startup martin rudalics
3 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2014-09-22 9:02 UTC (permalink / raw)
To: 7822-done
> `fit-window-to-buffer' does not take any display artefacts into account,
> except for visual (screen) lines. The enhancement would be to have it
> do so.
As with emacs-24 `fit-window-to-buffer' does so. Bug closed.
Thanks, martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2014-09-22 9:02 ` bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account martin rudalics
@ 2014-09-22 14:02 ` Drew Adams
2014-09-22 17:42 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: Drew Adams @ 2014-09-22 14:02 UTC (permalink / raw)
To: martin rudalics, 7822-done
> > `fit-window-to-buffer' does not take any display artefacts into
> > account, except for visual (screen) lines. The enhancement would
> > be to have it do so.
>
> As with emacs-24 `fit-window-to-buffer' does so. Bug closed.
Thanks.
But is this enhancement request really fulfilled? The paragraph
after the intro one that you quote from the ER specifically
states the requirement:
How much it tries to do so should be under programmer
control, so that, e.g., one could tell it (e.g. via a new
optional parameter) not to take any display stuff into account
(i.e., to treat the buffer content as just plain text with a
fixed-width font of the current char size).
And the ER explicitly refers to this emacs-devel thread for
details: "`fit-window-to-buffer-as-displayed'?", 2011-01-10:
http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00323.html
And of course, how users can control the behavior needs to be
well documented.
Is this ER really addressed? I don't have a Windows binary
more recent than 2014-08-15 to test (they are no longer being
built, it seems). If so, then yes this should be closed.
If not then it should not be closed, even if it is good that
some progress has apparently been made. Thanks.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2014-09-22 14:02 ` Drew Adams
@ 2014-09-22 17:42 ` martin rudalics
2014-09-22 18:24 ` Drew Adams
0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2014-09-22 17:42 UTC (permalink / raw)
To: Drew Adams, 7822-done
> But is this enhancement request really fulfilled? The paragraph
> after the intro one that you quote from the ER specifically
> states the requirement:
>
> How much it tries to do so should be under programmer
> control, so that, e.g., one could tell it (e.g. via a new
> optional parameter) not to take any display stuff into account
> (i.e., to treat the buffer content as just plain text with a
> fixed-width font of the current char size).
>
> And the ER explicitly refers to this emacs-devel thread for
> details: "`fit-window-to-buffer-as-displayed'?", 2011-01-10:
> http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00323.html
The current behavior is, in fact, based on Stefan's remark that
There's no point trying to add support for some properties but not all:
adding support for all properties is likely to be easier because it'd
rely on (re)using the existing display code.
in that thread.
> And of course, how users can control the behavior needs to be
> well documented.
>
> Is this ER really addressed? I don't have a Windows binary
> more recent than 2014-08-15 to test (they are no longer being
> built, it seems).
The changes are from 2013 so the binaries you have should include them.
> If so, then yes this should be closed.
>
> If not then it should not be closed, even if it is good that
> some progress has apparently been made. Thanks.
If you can give a practical example where the present code fails to do
what you want, feel free to reopen the bug.
Thanks, martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2014-09-22 17:42 ` martin rudalics
@ 2014-09-22 18:24 ` Drew Adams
2014-09-22 19:31 ` Stefan Monnier
0 siblings, 1 reply; 25+ messages in thread
From: Drew Adams @ 2014-09-22 18:24 UTC (permalink / raw)
To: martin rudalics, 7822-done
> If you can give a practical example where the present code fails to
> do what you want, feel free to reopen the bug.
I think I understand your reply, but I don't see anything in it that
directly answers the question:
Does a user have a way to "tell it *not* to take any display stuff
into account (i.e., to treat the buffer content as just plain text
with a fixed-width font of the current char size)"? IOW, optional
simple fit, disregarding/ignoring display artefacts.
The ER is for that and more. It asks that a user be able to control
"how much" it "takes display artefacts into account". But just
being able to tell it not to take any into account would probably
be acceptable.
If there is no way to even do that then the ER is not satisfied,
and it should be left open until a user has the option of turning
off this taking-display-artefacts-into-account.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2014-09-22 18:24 ` Drew Adams
@ 2014-09-22 19:31 ` Stefan Monnier
2014-09-22 20:24 ` Drew Adams
0 siblings, 1 reply; 25+ messages in thread
From: Stefan Monnier @ 2014-09-22 19:31 UTC (permalink / raw)
To: Drew Adams; +Cc: 7822, 7822-done
> The ER is for that and more. It asks that a user be able to control
> "how much" it "takes display artefacts into account". But just
> being able to tell it not to take any into account would probably
> be acceptable.
Could we have at least some kind of motivating example for why one might
want that kind of control?
Stefan
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account
2014-09-22 19:31 ` Stefan Monnier
@ 2014-09-22 20:24 ` Drew Adams
2014-09-22 20:54 ` Stefan Monnier
0 siblings, 1 reply; 25+ messages in thread
From: Drew Adams @ 2014-09-22 20:24 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 7822, 7822-done
> > The ER is for that and more. It asks that a user be able to
> > control "how much" it "takes display artefacts into account".
> > But just being able to tell it not to take any into account
> > would probably be acceptable.
>
> Could we have at least some kind of motivating example for why one
> might want that kind of control?
1. He who can do more can do less.
2. That is what the function did before the ER. Some users might
prefer that longstanding behavior generally.
3. Code might want to handle things differently than the current
automatic handling. In particular, it might want to not take into
account some display artefacts, or to deal with them differently.
It is likely to be harder for code to compensate for automatic,
fancy fitting than it would be to add custom fitting behavior to
rudimentary-fit behavior. Best would be as the ER suggested: be
able to choose just which display artefacts are to be taken into
account.
4. Providing also a simple, no-bells-and-whistles behavior lets
users roll their own fitting behavior (#3). Providing only a
one-size-fits-all-do-everything behavior does not. Keep our
options open.
5. What extra cost is there, to provide this flexibility? (See
#1.)
6. Finally, that is what the ER explicitly requested (!). It did
not ask for only do-it-all behavior. It asked to allow users to
be able to obtain that behavior and to do without it - au choix.
The request stands, unless it has been realized. Has it?
I might have had additional things explicitly in mind when I filed
the ER almost 4 years ago, but at least these simple motivations
come to mind immediately now.
I haven't seen where the code for this is (where is it?). If this
was "fixed" in Lisp code then presumably it will be possible for
users to tease apart the various parts, in order to, in the end,
put together whatever behavior they need. But if this was "fixed"
in C code then there is all the more need for explicit provision
for users to turn parts of it off.
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#9105: Feature req: Remembering emacs frames, windows, buffer position to subsequent session
2014-09-21 18:02 ` martin rudalics
2014-09-22 8:32 ` bug#456: menu-bar does not resize window martin rudalics
2014-09-22 9:02 ` bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account martin rudalics
@ 2014-09-22 9:07 ` martin rudalics
2014-09-22 9:26 ` bug#203: Maximize frame does not work at startup martin rudalics
3 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2014-09-22 9:07 UTC (permalink / raw)
To: 9105-done
> Often I'll have five or more frames open, some split vertically, perhaps
> a couple split horizontally, all of them with different files (or
> "buffers") in them-- though in some instances it's possible to have the
> same buffer in more than one window or frame. When I close emacs down
> and then invoke it again, I'd like to have the same windows come up,
> split the same way, with the same buffers/files in each frame and
> window, and even with the frames in the same location onscreen as they
> were in the prior session. In short, the current session should be set
> up exactly like the prior session at the time it was closed.
Thanks to Juanma's frameset functions `desktop-save-mode' should do that
now by default. Closing this bug.
Thanks, martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#203: Maximize frame does not work at startup
2014-09-21 18:02 ` martin rudalics
` (2 preceding siblings ...)
2014-09-22 9:07 ` bug#9105: Feature req: Remembering emacs frames, windows, buffer position to subsequent session martin rudalics
@ 2014-09-22 9:26 ` martin rudalics
3 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2014-09-22 9:26 UTC (permalink / raw)
To: 203-done
Maximizing and fullscreen frames should work with current trunk as
intended using the fullscreen frame parameter. Closing this bug.
martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#456: menu-bar does not resize window
@ 2008-06-21 5:38 David Trallero
2008-06-21 7:43 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: David Trallero @ 2008-06-21 5:38 UTC (permalink / raw)
To: bug-gnu-emacs
M-x menu-bar-mode creates an awful effect on the emacs window. Lets
say that menu-bar-mode is nil, that is, menu does not appear, and we
have emacs "maximized". When activating it (M-x menu-bar-mode) the
emacs window resizes and the minibuffer is out of the screen.
The same happens on the other way around. if the window is maximized
and the menu-bar is removed, it "stops" being maximized.
In GNU Emacs 22.1.1 (i586-suse-linux-gnu, GTK+ Version 2.12.0)
of 2007-09-22 on balada
Windowing system distributor `The X.Org Foundation', version 11.0.70199902
configured using `configure '--with-gcc' '--with-pop'
'--without-hesiod' '--with-kerberos' '--with-kerberos5' '--with-leim'
'--with-xim' '--with-system-malloc' '--prefix=/usr'
'--infodir=/usr/share/info' '--mandir=/usr/share/man'
'--localstatedir=/var' '--sharedstatedir=/var/lib'
'--libexecdir=/usr/lib' '--with-x' '--with-sound' '--with-xpm'
'--with-jpeg' '--with-tiff' '--with-gif' '--with-png'
'--with-x-toolkit=gtk' '--x-includes=/usr/include'
'--x-libraries=/usr/lib:/usr/share/X11' '--build=i586-suse-linux-gnu'
'build_alias=i586-suse-linux-gnu' 'CC=gcc' 'CFLAGS=-O2 -march=i586
-mtune=i686 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2
-fstack-protector -g -pipe -fno-strict-aliasing -D_GNU_SOURCE
-Wno-pointer-sign -Wno-unused-variable -Wno-unused-label
-DSYSTEM_PURESIZE_EXTRA=55000 -DSITELOAD_PURESIZE_EXTRA=10000 '
'LDFLAGS=''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8
default-enable-multibyte-characters: t
Major mode: XHTML
Minor modes in effect:
shell-dirtrack-mode: t
recentf-mode: t
change-cursor-mode: t
desktop-save-mode: t
encoded-kbd-mode: t
show-paren-mode: t
tooltip-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
<down-mouse-1> <mouse-1> <double-down-mouse-1> <double-mouse-1>
<down-mouse-1> <mouse-1> M-x m e n <tab> b <tab> m
<tab> <return> <help-echo> <down-mouse-1> <mouse-1>
<double-down-mouse-1> <double-mouse-1> <down-mouse-1>
<mouse-1> <double-down-mouse-1> <double-mouse-1> <down-mouse-1>
<mouse-1> M-x <up> <return> M-x <up> <return> <up>
<up> M-x b u g <tab> <tab> <backspace> <tab> <backspace>
<backspace> <tab> <tab> C-x o C-x o C-s b u g C-s C-s
C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s
C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-r
C-r C-s C-s C-s <left> <return>
Recent messages:
For information about the GNU Project and its goals, type C-h C-p. [2 times]
Menu-Bar mode disabled
Menu-bar mode disabled. Use M-x menu-bar-mode to make the menu bar appear.
Menu-Bar mode enabled
Menu-Bar mode disabled
Menu-bar mode disabled. Use M-x menu-bar-mode to make the menu bar appear.
Making completion list...
Loading help-mode...done
Making completion list...
Loading emacsbug...done
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#456: menu-bar does not resize window
2008-06-21 5:38 bug#456: menu-bar does not resize window David Trallero
@ 2008-06-21 7:43 ` martin rudalics
2008-06-21 9:24 ` David Trallero
0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2008-06-21 7:43 UTC (permalink / raw)
To: David Trallero, 456; +Cc: bug-gnu-emacs
> M-x menu-bar-mode creates an awful effect on the emacs window. Lets
> say that menu-bar-mode is nil, that is, menu does not appear, and we
> have emacs "maximized". When activating it (M-x menu-bar-mode) the
> emacs window resizes and the minibuffer is out of the screen.
>
> The same happens on the other way around. if the window is maximized
> and the menu-bar is removed, it "stops" being maximized.
This happens by design. The driving idea behind is, that the numbers of
lines for displaying buffers should remain unaltered when menu-/toolbars
are added/removed. There were discussions about the desired behavior in
the past but no conclusion as far as I recall.
martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#456: menu-bar does not resize window
2008-06-21 7:43 ` martin rudalics
@ 2008-06-21 9:24 ` David Trallero
2008-06-21 12:39 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: David Trallero @ 2008-06-21 9:24 UTC (permalink / raw)
To: martin rudalics; +Cc: 456
> This happens by design. The driving idea behind is, that the numbers of
> lines for displaying buffers should remain unaltered when menu-/toolbars
> are added/removed. There were discussions about the desired behavior in
> the past but no conclusion as far as I recall.
Oops! sorry then. I do not want to re-open the topic. I personally think that
behavior is not correct because many visual non-desired effects are produced.
For example if you change to another buffer which has a bigger "tool-bar" that
needs two lines, all text is moved up and down. Unfortunately, I do not know
the reason why emacs is "line-oriented" instead of being "window-representa-
tion independent".
Even more, I think it should be possible to overlay the menu in the
graphical mode
when the mouse pointer is "over it", after all, what you desire is to
have as much
space as possible for editing.
Thanks for the reply,
David
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#456: menu-bar does not resize window
2008-06-21 9:24 ` David Trallero
@ 2008-06-21 12:39 ` martin rudalics
2008-06-21 15:38 ` Drew Adams
0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2008-06-21 12:39 UTC (permalink / raw)
To: David Trallero; +Cc: 456
>>This happens by design. The driving idea behind is, that the numbers of
>>lines for displaying buffers should remain unaltered when menu-/toolbars
>>are added/removed. There were discussions about the desired behavior in
>>the past but no conclusion as far as I recall.
>
> Oops! sorry then. I do not want to re-open the topic.
You can't ;-)
It's still unclosed, see
http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=25
> I personally think that
> behavior is not correct because many visual non-desired effects are produced.
ISTR bad interaction with some window managers.
> For example if you change to another buffer which has a bigger "tool-bar" that
> needs two lines, all text is moved up and down.
Can you explain this in more detail?
> Unfortunately, I do not know
> the reason why emacs is "line-oriented" instead of being "window-representa-
> tion independent".
Quite often you want an exact text-layout within a window. For example,
you might want windows to display exactly 80 columns of buffer text.
Adding/removing scroll-bars shouldn't change that. And what holds for
the width of windows should probably also hold for their height.
> Even more, I think it should be possible to overlay the menu in the
> graphical mode
> when the mouse pointer is "over it", after all, what you desire is to
> have as much
> space as possible for editing.
I don't understand what you mean here. Please elaborate.
martin
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#456: menu-bar does not resize window
2008-06-21 12:39 ` martin rudalics
@ 2008-06-21 15:38 ` Drew Adams
2008-06-21 19:44 ` Stefan Monnier
2008-06-22 8:28 ` martin rudalics
0 siblings, 2 replies; 25+ messages in thread
From: Drew Adams @ 2008-06-21 15:38 UTC (permalink / raw)
To: 'martin rudalics', 456, 'David Trallero'
> >>This happens by design. The driving idea behind is, that
> >>the numbers of lines for displaying buffers should remain
> >>unaltered when menu-/toolbars are added/removed. There were
> >>discussions about the desired behavior in
> >>the past but no conclusion as far as I recall.
I don't agree that it happens by design, unless you mean that it happens just
because it happens and no one has fixed it yet. ;-)
AFAICT, it was agreed in the previous discussion that this bug should be fixed,
but we haven't yet found the right time to do it. Eli mentioned also that it
might be difficult to fix this (treat menu-bar like tool-bar) completely for
some platforms because of the difference between handling pixels and chars.
> > Oops! sorry then. I do not want to re-open the topic.
>
> You can't ;-) It's still unclosed, see
> http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=25
>
> > I personally think that behavior is not correct because
> > many visual non-desired effects are produced.
>
> ISTR bad interaction with some window managers.
AFAICT, people agreed that the menu-bar should be treated like the tool-bar is,
but that might be difficult to do precisely (pixel vs char) for some platforms.
Eli mentioned that he seemed to remember that the size of the menu-bar "may not
be known to some toolkits, so resizing the text area might be tricky".
He called the current behavior a "misfeature", and lamented the fact that this
hadn't yet been fixed after several years (+ two more years now). The reason he
gave for not fixing it, however, was just that fixing it then would have been
ill-timed, so close to the release, especially on top of other display-related
changes at that time.
> > For example if you change to another buffer which has a
> > bigger "tool-bar" that
> > needs two lines, all text is moved up and down.
>
> Can you explain this in more detail?
>
> > Unfortunately, I do not know the reason why emacs is
> > "line-oriented" instead of being "window-representa-
> > tion independent".
>
> Quite often you want an exact text-layout within a window.
> For example, you might want windows to display exactly 80
> columns of buffer text.
> Adding/removing scroll-bars shouldn't change that. And what holds for
> the width of windows should probably also hold for their height.
That might be one use case, for some people. If so, it is also an argument
against the current way of handling the tool-bar. You can't have it both ways.
If there are such use cases, then we should let users decide the behavior using
a user option. I and some others clearly have a different use case from that and
prefer that the frame size be left alone - for menu-bar (bugged) as well as
tool-bar (OK).
We seem somehow to have wandered from "Yes, we'd all like to fix this but that
would be difficult right now" to "No, it's the way it is by design, because some
people want the number of displayed lines to remain constant."
Let's be honest: This has been flagged as a bug that should be fixed for a long
time. The current behavior obviously does not suit at least some people. David's
example of the frame being resized larger than "maximum" so the minibuffer
disappears is one more testimonial.
If someone can fix this bug, then we should fix it. If some people actually
prefer the bugged behavior, then we can create a user option so that users can
decide for themselves. But let's not use the fact that some people might prefer
the bugged behavior as a rationale not to fix the bug.
And if this bug is just too difficult to fix - for whatever reason, then let's
note that clearly, with the precise reasons, so revisionist history doesn't pop
up from time to time.
FWIW, the emacs-devel thread referring to this (there are apparently other,
older threads also) in 2006-06 and 2007-07 is: "frame parameter menu-bar-lines
changes height of frame".
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#456: menu-bar does not resize window
2008-06-21 15:38 ` Drew Adams
@ 2008-06-21 19:44 ` Stefan Monnier
2008-06-22 8:28 ` martin rudalics
1 sibling, 0 replies; 25+ messages in thread
From: Stefan Monnier @ 2008-06-21 19:44 UTC (permalink / raw)
To: Drew Adams; +Cc: 456, 'David Trallero'
> I don't agree that it happens by design, unless you mean that it happens just
> because it happens and no one has fixed it yet. ;-)
Yes, it might have been considered a good idea at some point (probably
when the issue was mixed up with the question of whether an
"emacs --geometry 80x25" frame should have the same pixel size with
menu-bar as without), but it now considered a misfeature.
So patches welcome. Problem is: it appears that it requires a lot
of changes.
Stefan
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#456: menu-bar does not resize window
2008-06-21 15:38 ` Drew Adams
2008-06-21 19:44 ` Stefan Monnier
@ 2008-06-22 8:28 ` martin rudalics
1 sibling, 0 replies; 25+ messages in thread
From: martin rudalics @ 2008-06-22 8:28 UTC (permalink / raw)
To: Drew Adams; +Cc: 'David Trallero', 456
> I don't agree that it happens by design, unless you mean that it happens just
> because it happens and no one has fixed it yet. ;-)
No. It happens because it _was_ designed that way.
>>Quite often you want an exact text-layout within a window.
>>For example, you might want windows to display exactly 80
>>columns of buffer text.
>>Adding/removing scroll-bars shouldn't change that. And what holds for
>>the width of windows should probably also hold for their height.
>
> That might be one use case, for some people. If so, it is also an argument
> against the current way of handling the tool-bar. You can't have it both ways.
Adding/removing tool-bars _may_ change the height of the frame on some
platforms. I was told by Richard
I think that change causes another bug. The height in lines of an
Emacs frame is not supposed to include the tool bar. If you create a
frame and specify 40 lines, you should get 40 lines of text, plus a
tool bar.
[http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01148.html]
and by Robert
I like it that the number of lines of text stays the same.
[http://lists.gnu.org/archive/html/emacs-devel/2007-12/msg01172.html]
Hence, unless we reach a common opinion on how to handle these issues
accross _all_ platforms and window managers, hardly anyone will try to
fix them (IIUC Jan gave up already).
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2014-09-22 21:04 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-11-14 22:46 bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows Themba Fletcher
2008-11-15 9:40 ` Eli Zaretskii
2008-11-15 10:04 ` Eli Zaretskii
2008-11-15 14:12 ` martin rudalics
2008-11-17 20:50 ` Themba Fletcher
2008-11-18 13:03 ` martin rudalics
2014-09-21 18:02 ` martin rudalics
2014-09-22 8:32 ` bug#456: menu-bar does not resize window martin rudalics
2014-09-22 9:02 ` bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account martin rudalics
2014-09-22 14:02 ` Drew Adams
2014-09-22 17:42 ` martin rudalics
2014-09-22 18:24 ` Drew Adams
2014-09-22 19:31 ` Stefan Monnier
2014-09-22 20:24 ` Drew Adams
2014-09-22 20:54 ` Stefan Monnier
2014-09-22 21:04 ` Drew Adams
2014-09-22 9:07 ` bug#9105: Feature req: Remembering emacs frames, windows, buffer position to subsequent session martin rudalics
2014-09-22 9:26 ` bug#203: Maximize frame does not work at startup martin rudalics
-- strict thread matches above, loose matches on Subject: below --
2008-06-21 5:38 bug#456: menu-bar does not resize window David Trallero
2008-06-21 7:43 ` martin rudalics
2008-06-21 9:24 ` David Trallero
2008-06-21 12:39 ` martin rudalics
2008-06-21 15:38 ` Drew Adams
2008-06-21 19:44 ` Stefan Monnier
2008-06-22 8:28 ` martin rudalics
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.