bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows

bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows

[Themba Fletcher]

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 

bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows

[Eli Zaretskii]

> 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?

bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows

[Eli Zaretskii]

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

bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows

[martin rudalics]

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

bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows

[Themba Fletcher]

[-- 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")

bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows

[martin rudalics]

[-- 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 ----

bug#9105: Feature req: Remembering emacs frames, windows, buffer position to subsequent session

[ken]

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.

Yes, this is asking quite a bit.  So I'll add one more thing.  In Linux
and other OSs employing X it's possible to have multiple viewports
(i.e., desktops) and to place any GUI application into any viewport.  So
it's possible that all emacs windows might not be all in the same
viewport... six emacs frames could be positioned in two, four, or more
different viewports.  Accurately positioning all of them in the correct
viewports would constitute a thorough recreation of the previous session.


Thanks.

bug#9105: Feature req: Remembering emacs frames, windows, buffer position to subsequent session

[martin rudalics]

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

All this should be doable now using the functions `window-state-get' and
`window-state-put'.  Could you try implementing this in desktop.el?

martin

bug#9105: Feature req: Remembering emacs frames, windows, buffer position to subsequent session

[Drew Adams]

> All this should be doable now using the functions 
> `window-state-get' and
> `window-state-put'.  Could you try implementing this in desktop.el?

Please do it in a separate library, and keep it decoupled from Desktop.  Yes, it
should be possible and easy to use it in conjunction with Desktop.  But it
should also be possible to use each separately, and preferably without loading
the other.

These are two different functionalities which can be useful if used together.

bug#9105: Feature req: Remembering emacs frames, windows, buffer position to subsequent session

[ken]

On 07/17/2011 05:46 AM martin rudalics wrote:
>> 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.
> 
> All this should be doable now using the functions `window-state-get' and
> `window-state-put'.  Could you try implementing this in desktop.el?
> 
> martin

Thanks, Martin!

Where do I find these two functions?

Once I download them, would it make any difference if I put them in my
emacs-path rather than inserting them in or appending them to desktop.el?

Thanks++,
ken

bug#9105: Feature req: Remembering emacs frames, windows, buffer position to subsequent session

[martin rudalics]

 > Where do I find these two functions?

In window.el of the development version, that is Emacs 24.0.50.1.

 > Once I download them, would it make any difference if I put them in my
 > emacs-path rather than inserting them in or appending them to desktop.el?

You will have to install Emacs 24 on your system.  After that you will
have to write two functions - one that writes for each frame the value
returned by `window-state-get' on file together with the parameters of
the frame, and one that reads the values from file, creates a new frame
for each entry, and uses `window-state-put' to restore the window
layouts within that frame.  All this after you have recreated the
buffers visiting files.  And you have to decide what to do with windows
whose buffers did not visit a file in the old session.

martin

bug#9105: Feature req: Remembering emacs frames, windows, buffer position to subsequent session

[Juri Linkov]

> Yes, this is asking quite a bit.  So I'll add one more thing.  In Linux
> and other OSs employing X it's possible to have multiple viewports
> (i.e., desktops) and to place any GUI application into any viewport.  So
> it's possible that all emacs windows might not be all in the same
> viewport... six emacs frames could be positioned in two, four, or more
> different viewports.  Accurately positioning all of them in the correct
> viewports would constitute a thorough recreation of the previous session.

Do you know what commands can move Emacs frames to different viewports?

bug#9105: Feature req: Remembering emacs frames, windows, buffer position to subsequent session

[Juri Linkov]

> Please do it in a separate library, and keep it decoupled from Desktop.  Yes, it
> should be possible and easy to use it in conjunction with Desktop.  But it
> should also be possible to use each separately, and preferably without loading
> the other.

Most of the functionality of desktop.el is already duplicated in
savehist.el and saveplace.el because they use different formats.
So remembering Emacs frames and windows could be implemented separately
in two places: in desktop.el and in a new library like savewindows.el
or saveframes.el.

bug#9105: Feature req: Remembering emacs frames, windows, buffer position to subsequent session

[Juri Linkov]

> And you have to decide what to do with windows whose buffers did not
> visit a file in the old session.

This is possible already by specifying `desktop-buffer-mode-handlers'
to reconstruct non-persistent buffers like it's done by
`Info-restore-desktop-buffer', `dired-restore-desktop-buffer', etc.
Implenting it in more packages will save and restore more different buffers.

bug#9105: Feature req: Remembering emacs frames, windows, buffer position to subsequent session

[Jan Djärv]

Juri Linkov skrev 2011-07-18 00.54:
>> Yes, this is asking quite a bit.  So I'll add one more thing.  In Linux
>> and other OSs employing X it's possible to have multiple viewports
>> (i.e., desktops) and to place any GUI application into any viewport.  So
>> it's possible that all emacs windows might not be all in the same
>> viewport... six emacs frames could be positioned in two, four, or more
>> different viewports.  Accurately positioning all of them in the correct
>> viewports would constitute a thorough recreation of the previous session.
>
> Do you know what commands can move Emacs frames to different viewports?
>
>

With a window manager that supports extended window manager hints, it is a 
property: http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507080.

	Jan D.

bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows

[martin rudalics]

 > 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

bug#456: menu-bar does not resize window

[martin rudalics]

 > 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

bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account

[martin rudalics]

 > `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

bug#9105: Feature req: Remembering emacs frames, windows, buffer position to subsequent session

[martin rudalics]

 > 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

bug#203: Maximize frame does not work at startup

[martin rudalics]

Maximizing and fullscreen frames should work with current trunk as
intended using the fullscreen frame parameter.  Closing this bug.

martin

bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account

[Drew Adams]

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

bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account

[martin rudalics]

 > 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

bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account

[Drew Adams]

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

bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account

[Stefan Monnier]

> 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

bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account

[Drew Adams]

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

bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account

[Stefan Monnier]

> 1. He who can do more can do less.
[..etc...]

None of these are motivating examples.  If a need ever comes up, we can
open a new bug.


        Stefan

bug#7822: 24.0.50; `fit-window-to-buffer': take display artefacts into account

[Drew Adams]

> > 1. He who can do more can do less.
> [..etc...]
> 
> None of these are motivating examples.  If a need ever comes up, we
> can open a new bug.

The enhancement request is not fulfilled, and you have decided that
it should not be.  So be it.  The proper way to close it in that
case is to classify it as "won't fix", not as "done".