unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
@ 2013-08-07 19:39 Deyuan Deng
  2013-08-08 17:58 ` Jan Djärv
  2013-08-08 19:21 ` Deyuan Deng
  0 siblings, 2 replies; 35+ messages in thread
From: Deyuan Deng @ 2013-08-07 19:39 UTC (permalink / raw)
  To: 15046

[-- Attachment #1: Type: text/plain, Size: 6252 bytes --]


When i set font to Monaco 14 (and several different font and fontsize),
there is an extra line under minibuffer when using fullscreen in Mac
OSX. The extra line is not editable, and is not part of
minibuffer. It won't come out if no custom font is set.




In GNU Emacs 24.3.50.1 (i386-apple-darwin12.4.0, NS apple-appkit-1187.39)
of 2013-08-02 on Deyuans-MacBook-Air.local
Windowing system distributor `Apple', version 10.3.1187
Configured using:
`configure --with-ns'

Important settings:
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: C++/l

Minor modes in effect:
  hl-line-mode: t
  multi-web-global-mode: t
  shell-dirtrack-mode: t
  global-auto-complete-mode: t
  auto-complete-mode: t
  global-auto-revert-mode: t
  yas/global-mode: t
  yas/minor-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
<down-mouse-1> <mouse-1> <f1> e m <backspace> <backspace> 
d o <tab> <return> <return> a l <return> s o u r <return> 
<return> C-s <return> 1 2 <return> C-n C-n C-x 3 <f3> 
<f3> C-n M-b C-e <f8> e m <tab> <return> <f10> C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-p 
C-p C-p C-p M-f M-f M-f M-f M-f M-f M-f M-f M-f <M-backspace> 
1 4 <f2> C-e C-g C-g C-g M-x l o a d <tab> f <tab> 
<return> . e m <tab> <return> C-n C-e <down-mouse-1> 
<mouse-1> M-x d e <tab> C-g C-g <f1> C-g <f4> <return> 
C-x 3 M-n C-p C-e C-n C-n C-e C-p C-e C-n C-n C-n C-e 
C-a M-n M-p M-f M-b M-f C-n C-a M-b <return> / / SPC 
C-n <backspace> <backspace> <backspace> <backspace> 
SPC M-f M-f M-f M-f M-f M-f M-f M-f M-f M-f M-f M-b 
M-b M-f <return> / / SPC C-n <backspace> <backspace> 
<backspace> <backspace> SPC M-f M-f M-f M-f M-f M-f 
M-f M-f M-f M-f M-f M-f M-b M-f <return> / / SPC C-n 
<backspace> <backspace> <backspace> <backspace> SPC 
<f2> <f3> <f4> <return> ; <backspace> <f2> <down-mouse-1> 
<mouse-1> <down-mouse-1> <mouse-1> <down-mouse-1> <mouse-1> 
<down-mouse-1> <mouse-1> <wheel-down> <double-wheel-down> 
<triple-wheel-down> <triple-wheel-down> <triple-wheel-down> 
<triple-wheel-down> <down-mouse-1> <mouse-1> C-x k 
<return> <f1> <return> C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n <f3> M-n 
M-n M-n M-n M-n M-n M-n M-n M-n M-n M-n M-n M-n M-n 
M-n M-n M-n M-n M-n M-n <down-mouse-1> <mouse-1> M-x 
r e p o r <tab> <return>

Recent messages:
Restarting server
Loading /Users/deyuandeng/.emacs.d/plugins/javascript/js-config.el (source)...done
Loading /Users/deyuandeng/.emacs.d/.emacs...done
Making completion list...
Quit [3 times]
scroll-down-in-place: Beginning of buffer
Saving file /Users/deyuandeng/Documents/Computer_Science/Algorithm/_SourceCodes/GeeksforGeeks/DynamicProgramming/12.MatrixChainMultiplication.cpp...
Wrote /Users/deyuandeng/Documents/Computer_Science/Algorithm/_SourceCodes/GeeksforGeeks/DynamicProgramming/12.MatrixChainMultiplication.cpp
Saving file /Users/deyuandeng/.emacs.d/.emacs...
Wrote /Users/deyuandeng/.emacs.d/.emacs

Load-path shadows:
~/.emacs.d/plugins/javascript/js-comint hides /Users/deyuandeng/.emacs.d/elpa/js-comint-20080530.957/js-comint
~/.emacs.d/plugins/javascript/whitespace hides /Applications/Emacs.app/Contents/Resources/lisp/whitespace
~/.emacs.d/plugins/javascript/linum hides /Applications/Emacs.app/Contents/Resources/lisp/linum
/Users/deyuandeng/.emacs.d/elpa/flymake-0.4.12/flymake hides /Applications/Emacs.app/Contents/Resources/lisp/progmodes/flymake
/Users/deyuandeng/.emacs.d/elpa/magit-20130624.2315/.dir-locals hides /Applications/Emacs.app/Contents/Resources/lisp/gnus/.dir-locals

Features:
(shadow sort mail-extr emacsbug message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mail-utils vc-git
bookmark pp cc-langs cc-mode cc-fonts cc-guess cc-menus cc-styles
cc-align help-mode hl-line multi-term term disp-table ehelp electric
multi-web-mode dired-x dired whitespace smooth-scrolling linum
easy-mmode recentf tree-widget wid-edit uniquify ffap url-parse
auth-source eieio byte-opt bytecomp byte-compile cconv eieio-core
gnus-util mm-util mail-prsvr password-cache url-vars jade-mode sws-mode
js-comint gas-mode python-mode derived skeleton thingatpt imenu flymake
rx shell pcomplete cc-cmds cc-engine cc-vars cc-defs compile comint
ansi-color ring ctags-update auto-complete-config auto-complete popup
ido autorevert filenotify server zenburn-theme column-marker-autoloads
ctags-autoloads ctags-update-autoloads espresso-theme-autoloads
flymake-autoloads jade-mode-autoloads jedi-autoloads
auto-complete-autoloads epc-autoloads ctable-autoloads
concurrent-autoloads deferred-autoloads js-comint-autoloads
lua-mode-autoloads magit-autoloads info multi-term-autoloads
multi-web-mode-autoloads popup-autoloads smooth-scrolling-autoloads
sws-mode-autoloads websocket-autoloads yasnippet-autoloads
yasnippet-bundle-autoloads yasnippet-bundle cl-macs gv dropdown-list
advice help-fns yasnippet edmacro kmacro easymenu assoc cl nadvice
cl-loaddefs cl-lib zenburn-theme-autoloads package time-date tooltip
ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode
register page menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face macroexp files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process ns multi-tty
emacs)

[-- Attachment #2.1: Type: text/html, Size: 8468 bytes --]

[-- Attachment #2.2: PastedGraphic-1.png --]
[-- Type: image/png, Size: 18289 bytes --]

^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-07 19:39 bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen Deyuan Deng
@ 2013-08-08 17:58 ` Jan Djärv
  2013-08-09 10:22   ` Eli Zaretskii
  2013-08-08 19:21 ` Deyuan Deng
  1 sibling, 1 reply; 35+ messages in thread
From: Jan Djärv @ 2013-08-08 17:58 UTC (permalink / raw)
  To: Deyuan Deng; +Cc: 15046-done

Hello.

7 aug 2013 kl. 21:39 skrev Deyuan Deng <deyuan.deng@gmail.com>:

> 
> When i set font to Monaco 14 (and several different font and fontsize),
> there is an extra line under minibuffer when using fullscreen in Mac
> OSX. The extra line is not editable, and is not part of
> minibuffer. It won't come out if no custom font is set.
> 

Emacs display whole lines, and the space you see at the bottom is too small to fit a whole line, so it is just shown as empty space.  It is the same for other ports, like X11.

Closing as this is not a bug.

	Jan D.

> <PastedGraphic-1.png>
> 
> 
> In GNU Emacs 24.3.50.1 (i386-apple-darwin12.4.0, NS apple-appkit-1187.39)
> of 2013-08-02 on Deyuans-MacBook-Air.local
> Windowing system distributor `Apple', version 10.3.1187
> Configured using:
> `configure --with-ns'
> 
> Important settings:
>   locale-coding-system: nil
>   default enable-multibyte-characters: t
> 
> Major mode: C++/l
> 
> Minor modes in effect:
>   hl-line-mode: t
>   multi-web-global-mode: t
>   shell-dirtrack-mode: t
>   global-auto-complete-mode: t
>   auto-complete-mode: t
>   global-auto-revert-mode: t
>   yas/global-mode: t
>   yas/minor-mode: t
>   tooltip-mode: t
>   mouse-wheel-mode: t
>   file-name-shadow-mode: t
>   global-font-lock-mode: t
>   font-lock-mode: t
>   blink-cursor-mode: t
>   auto-composition-mode: t
>   auto-encryption-mode: t
>   auto-compression-mode: t
>   column-number-mode: t
>   line-number-mode: t
>   transient-mark-mode: t
>   abbrev-mode: t
> 
> Recent input:
> <down-mouse-1> <mouse-1> <f1> e m <backspace> <backspace> 
> d o <tab> <return> <return> a l <return> s o u r <return> 
> <return> C-s <return> 1 2 <return> C-n C-n C-x 3 <f3> 
> <f3> C-n M-b C-e <f8> e m <tab> <return> <f10> C-n 
> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-p 
> C-p C-p C-p M-f M-f M-f M-f M-f M-f M-f M-f M-f <M-backspace> 
> 1 4 <f2> C-e C-g C-g C-g M-x l o a d <tab> f <tab> 
> <return> . e m <tab> <return> C-n C-e <down-mouse-1> 
> <mouse-1> M-x d e <tab> C-g C-g <f1> C-g <f4> <return> 
> C-x 3 M-n C-p C-e C-n C-n C-e C-p C-e C-n C-n C-n C-e 
> C-a M-n M-p M-f M-b M-f C-n C-a M-b <return> / / SPC 
> C-n <backspace> <backspace> <backspace> <backspace> 
> SPC M-f M-f M-f M-f M-f M-f M-f M-f M-f M-f M-f M-b 
> M-b M-f <return> / / SPC C-n <backspace> <backspace> 
> <backspace> <backspace> SPC M-f M-f M-f M-f M-f M-f 
> M-f M-f M-f M-f M-f M-f M-b M-f <return> / / SPC C-n 
> <backspace> <backspace> <backspace> <backspace> SPC 
> <f2> <f3> <f4> <return> ; <backspace> <f2> <down-mouse-1> 
> <mouse-1> <down-mouse-1> <mouse-1> <down-mouse-1> <mouse-1> 
> <down-mouse-1> <mouse-1> <wheel-down> <double-wheel-down> 
> <triple-wheel-down> <triple-wheel-down> <triple-wheel-down> 
> <triple-wheel-down> <down-mouse-1> <mouse-1> C-x k 
> <return> <f1> <return> C-n C-n C-n C-n C-n C-n C-n 
> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n <f3> M-n 
> M-n M-n M-n M-n M-n M-n M-n M-n M-n M-n M-n M-n M-n 
> M-n M-n M-n M-n M-n M-n <down-mouse-1> <mouse-1> M-x 
> r e p o r <tab> <return>
> 
> Recent messages:
> Restarting server
> Loading /Users/deyuandeng/.emacs.d/plugins/javascript/js-config.el (source)...done
> Loading /Users/deyuandeng/.emacs.d/.emacs...done
> Making completion list...
> Quit [3 times]
> scroll-down-in-place: Beginning of buffer
> Saving file /Users/deyuandeng/Documents/Computer_Science/Algorithm/_SourceCodes/GeeksforGeeks/DynamicProgramming/12.MatrixChainMultiplication.cpp...
> Wrote /Users/deyuandeng/Documents/Computer_Science/Algorithm/_SourceCodes/GeeksforGeeks/DynamicProgramming/12.MatrixChainMultiplication.cpp
> Saving file /Users/deyuandeng/.emacs.d/.emacs...
> Wrote /Users/deyuandeng/.emacs.d/.emacs
> 
> Load-path shadows:
> ~/.emacs.d/plugins/javascript/js-comint hides /Users/deyuandeng/.emacs.d/elpa/js-comint-20080530.957/js-comint
> ~/.emacs.d/plugins/javascript/whitespace hides /Applications/Emacs.app/Contents/Resources/lisp/whitespace
> ~/.emacs.d/plugins/javascript/linum hides /Applications/Emacs.app/Contents/Resources/lisp/linum
> /Users/deyuandeng/.emacs.d/elpa/flymake-0.4.12/flymake hides /Applications/Emacs.app/Contents/Resources/lisp/progmodes/flymake
> /Users/deyuandeng/.emacs.d/elpa/magit-20130624.2315/.dir-locals hides /Applications/Emacs.app/Contents/Resources/lisp/gnus/.dir-locals
> 
> Features:
> (shadow sort mail-extr emacsbug message format-spec rfc822 mml mml-sec
> mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
> mailheader sendmail rfc2047 rfc2045 ietf-drums mail-utils vc-git
> bookmark pp cc-langs cc-mode cc-fonts cc-guess cc-menus cc-styles
> cc-align help-mode hl-line multi-term term disp-table ehelp electric
> multi-web-mode dired-x dired whitespace smooth-scrolling linum
> easy-mmode recentf tree-widget wid-edit uniquify ffap url-parse
> auth-source eieio byte-opt bytecomp byte-compile cconv eieio-core
> gnus-util mm-util mail-prsvr password-cache url-vars jade-mode sws-mode
> js-comint gas-mode python-mode derived skeleton thingatpt imenu flymake
> rx shell pcomplete cc-cmds cc-engine cc-vars cc-defs compile comint
> ansi-color ring ctags-update auto-complete-config auto-complete popup
> ido autorevert filenotify server zenburn-theme column-marker-autoloads
> ctags-autoloads ctags-update-autoloads espresso-theme-autoloads
> flymake-autoloads jade-mode-autoloads jedi-autoloads
> auto-complete-autoloads epc-autoloads ctable-autoloads
> concurrent-autoloads deferred-autoloads js-comint-autoloads
> lua-mode-autoloads magit-autoloads info multi-term-autoloads
> multi-web-mode-autoloads popup-autoloads smooth-scrolling-autoloads
> sws-mode-autoloads websocket-autoloads yasnippet-autoloads
> yasnippet-bundle-autoloads yasnippet-bundle cl-macs gv dropdown-list
> advice help-fns yasnippet edmacro kmacro easymenu assoc cl nadvice
> cl-loaddefs cl-lib zenburn-theme-autoloads package time-date tooltip
> ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd fontset
> image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode
> register page menu-bar rfn-eshadow timer select scroll-bar mouse
> jit-lock font-lock syntax facemenu font-core frame cham georgian
> utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
> japanese hebrew greek romanian slovak czech european ethiopic indian
> cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
> minibuffer loaddefs button faces cus-face macroexp files text-properties
> overlay sha1 md5 base64 format env code-pages mule custom widget
> hashtable-print-readable backquote make-network-process ns multi-tty
> emacs)






^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-07 19:39 bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen Deyuan Deng
  2013-08-08 17:58 ` Jan Djärv
@ 2013-08-08 19:21 ` Deyuan Deng
  2013-08-08 21:06   ` Jan Djärv
  2013-08-09  9:12   ` martin rudalics
  1 sibling, 2 replies; 35+ messages in thread
From: Deyuan Deng @ 2013-08-08 19:21 UTC (permalink / raw)
  To: 15046

Hi, Jan

Thanks for replying. Is there a way to get rid of this empty line? It takes some space and is pretty annoying. 

Best,
Deyuan


On Aug 7, 2013, at 1:39 PM, Deyuan Deng <Deyuan.Deng@gmail.com> wrote:

> 
> When i set font to Monaco 14 (and several different font and fontsize),
> there is an extra line under minibuffer when using fullscreen in Mac
> OSX. The extra line is not editable, and is not part of
> minibuffer. It won't come out if no custom font is set.
> 
> <PastedGraphic-1.png>
> 
> 
> In GNU Emacs 24.3.50.1 (i386-apple-darwin12.4.0, NS apple-appkit-1187.39)
> of 2013-08-02 on Deyuans-MacBook-Air.local
> Windowing system distributor `Apple', version 10.3.1187
> Configured using:
> `configure --with-ns'
> 
> Important settings:
>   locale-coding-system: nil
>   default enable-multibyte-characters: t
> 
> Major mode: C++/l
> 
> Minor modes in effect:
>   hl-line-mode: t
>   multi-web-global-mode: t
>   shell-dirtrack-mode: t
>   global-auto-complete-mode: t
>   auto-complete-mode: t
>   global-auto-revert-mode: t
>   yas/global-mode: t
>   yas/minor-mode: t
>   tooltip-mode: t
>   mouse-wheel-mode: t
>   file-name-shadow-mode: t
>   global-font-lock-mode: t
>   font-lock-mode: t
>   blink-cursor-mode: t
>   auto-composition-mode: t
>   auto-encryption-mode: t
>   auto-compression-mode: t
>   column-number-mode: t
>   line-number-mode: t
>   transient-mark-mode: t
>   abbrev-mode: t
> 
> Recent input:
> <down-mouse-1> <mouse-1> <f1> e m <backspace> <backspace> 
> d o <tab> <return> <return> a l <return> s o u r <return> 
> <return> C-s <return> 1 2 <return> C-n C-n C-x 3 <f3> 
> <f3> C-n M-b C-e <f8> e m <tab> <return> <f10> C-n 
> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-p 
> C-p C-p C-p M-f M-f M-f M-f M-f M-f M-f M-f M-f <M-backspace> 
> 1 4 <f2> C-e C-g C-g C-g M-x l o a d <tab> f <tab> 
> <return> . e m <tab> <return> C-n C-e <down-mouse-1> 
> <mouse-1> M-x d e <tab> C-g C-g <f1> C-g <f4> <return> 
> C-x 3 M-n C-p C-e C-n C-n C-e C-p C-e C-n C-n C-n C-e 
> C-a M-n M-p M-f M-b M-f C-n C-a M-b <return> / / SPC 
> C-n <backspace> <backspace> <backspace> <backspace> 
> SPC M-f M-f M-f M-f M-f M-f M-f M-f M-f M-f M-f M-b 
> M-b M-f <return> / / SPC C-n <backspace> <backspace> 
> <backspace> <backspace> SPC M-f M-f M-f M-f M-f M-f 
> M-f M-f M-f M-f M-f M-f M-b M-f <return> / / SPC C-n 
> <backspace> <backspace> <backspace> <backspace> SPC 
> <f2> <f3> <f4> <return> ; <backspace> <f2> <down-mouse-1> 
> <mouse-1> <down-mouse-1> <mouse-1> <down-mouse-1> <mouse-1> 
> <down-mouse-1> <mouse-1> <wheel-down> <double-wheel-down> 
> <triple-wheel-down> <triple-wheel-down> <triple-wheel-down> 
> <triple-wheel-down> <down-mouse-1> <mouse-1> C-x k 
> <return> <f1> <return> C-n C-n C-n C-n C-n C-n C-n 
> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n <f3> M-n 
> M-n M-n M-n M-n M-n M-n M-n M-n M-n M-n M-n M-n M-n 
> M-n M-n M-n M-n M-n M-n <down-mouse-1> <mouse-1> M-x 
> r e p o r <tab> <return>
> 
> Recent messages:
> Restarting server
> Loading /Users/deyuandeng/.emacs.d/plugins/javascript/js-config.el (source)...done
> Loading /Users/deyuandeng/.emacs.d/.emacs...done
> Making completion list...
> Quit [3 times]
> scroll-down-in-place: Beginning of buffer
> Saving file /Users/deyuandeng/Documents/Computer_Science/Algorithm/_SourceCodes/GeeksforGeeks/DynamicProgramming/12.MatrixChainMultiplication.cpp...
> Wrote /Users/deyuandeng/Documents/Computer_Science/Algorithm/_SourceCodes/GeeksforGeeks/DynamicProgramming/12.MatrixChainMultiplication.cpp
> Saving file /Users/deyuandeng/.emacs.d/.emacs...
> Wrote /Users/deyuandeng/.emacs.d/.emacs
> 
> Load-path shadows:
> ~/.emacs.d/plugins/javascript/js-comint hides /Users/deyuandeng/.emacs.d/elpa/js-comint-20080530.957/js-comint
> ~/.emacs.d/plugins/javascript/whitespace hides /Applications/Emacs.app/Contents/Resources/lisp/whitespace
> ~/.emacs.d/plugins/javascript/linum hides /Applications/Emacs.app/Contents/Resources/lisp/linum
> /Users/deyuandeng/.emacs.d/elpa/flymake-0.4.12/flymake hides /Applications/Emacs.app/Contents/Resources/lisp/progmodes/flymake
> /Users/deyuandeng/.emacs.d/elpa/magit-20130624.2315/.dir-locals hides /Applications/Emacs.app/Contents/Resources/lisp/gnus/.dir-locals
> 
> Features:
> (shadow sort mail-extr emacsbug message format-spec rfc822 mml mml-sec
> mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
> mailheader sendmail rfc2047 rfc2045 ietf-drums mail-utils vc-git
> bookmark pp cc-langs cc-mode cc-fonts cc-guess cc-menus cc-styles
> cc-align help-mode hl-line multi-term term disp-table ehelp electric
> multi-web-mode dired-x dired whitespace smooth-scrolling linum
> easy-mmode recentf tree-widget wid-edit uniquify ffap url-parse
> auth-source eieio byte-opt bytecomp byte-compile cconv eieio-core
> gnus-util mm-util mail-prsvr password-cache url-vars jade-mode sws-mode
> js-comint gas-mode python-mode derived skeleton thingatpt imenu flymake
> rx shell pcomplete cc-cmds cc-engine cc-vars cc-defs compile comint
> ansi-color ring ctags-update auto-complete-config auto-complete popup
> ido autorevert filenotify server zenburn-theme column-marker-autoloads
> ctags-autoloads ctags-update-autoloads espresso-theme-autoloads
> flymake-autoloads jade-mode-autoloads jedi-autoloads
> auto-complete-autoloads epc-autoloads ctable-autoloads
> concurrent-autoloads deferred-autoloads js-comint-autoloads
> lua-mode-autoloads magit-autoloads info multi-term-autoloads
> multi-web-mode-autoloads popup-autoloads smooth-scrolling-autoloads
> sws-mode-autoloads websocket-autoloads yasnippet-autoloads
> yasnippet-bundle-autoloads yasnippet-bundle cl-macs gv dropdown-list
> advice help-fns yasnippet edmacro kmacro easymenu assoc cl nadvice
> cl-loaddefs cl-lib zenburn-theme-autoloads package time-date tooltip
> ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd fontset
> image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode
> register page menu-bar rfn-eshadow timer select scroll-bar mouse
> jit-lock font-lock syntax facemenu font-core frame cham georgian
> utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
> japanese hebrew greek romanian slovak czech european ethiopic indian
> cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
> minibuffer loaddefs button faces cus-face macroexp files text-properties
> overlay sha1 md5 base64 format env code-pages mule custom widget
> hashtable-print-readable backquote make-network-process ns multi-tty
> emacs)






^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-08 19:21 ` Deyuan Deng
@ 2013-08-08 21:06   ` Jan Djärv
  2013-08-09  9:12   ` martin rudalics
  1 sibling, 0 replies; 35+ messages in thread
From: Jan Djärv @ 2013-08-08 21:06 UTC (permalink / raw)
  To: Deyuan Deng; +Cc: 15046@debbugs.gnu.org

Hello. 

8 aug 2013 kl. 21:21 skrev Deyuan Deng <deyuan.deng@gmail.com>:

> Hi, Jan
> 
> Thanks for replying. Is there a way to get rid of this empty line? It takes some space and is pretty annoying. 
> 

No, fullscreen is fullscreen. 

    Jan D. 

> Best,
> Deyuan
> 
> 
> On Aug 7, 2013, at 1:39 PM, Deyuan Deng <Deyuan.Deng@gmail.com> wrote:
> 
>> 
>> When i set font to Monaco 14 (and several different font and fontsize),
>> there is an extra line under minibuffer when using fullscreen in Mac
>> OSX. The extra line is not editable, and is not part of
>> minibuffer. It won't come out if no custom font is set.
>> 
>> <PastedGraphic-1.png>
>> 
>> 
>> In GNU Emacs 24.3.50.1 (i386-apple-darwin12.4.0, NS apple-appkit-1187.39)
>> of 2013-08-02 on Deyuans-MacBook-Air.local
>> Windowing system distributor `Apple', version 10.3.1187
>> Configured using:
>> `configure --with-ns'
>> 
>> Important settings:
>>  locale-coding-system: nil
>>  default enable-multibyte-characters: t
>> 
>> Major mode: C++/l
>> 
>> Minor modes in effect:
>>  hl-line-mode: t
>>  multi-web-global-mode: t
>>  shell-dirtrack-mode: t
>>  global-auto-complete-mode: t
>>  auto-complete-mode: t
>>  global-auto-revert-mode: t
>>  yas/global-mode: t
>>  yas/minor-mode: t
>>  tooltip-mode: t
>>  mouse-wheel-mode: t
>>  file-name-shadow-mode: t
>>  global-font-lock-mode: t
>>  font-lock-mode: t
>>  blink-cursor-mode: t
>>  auto-composition-mode: t
>>  auto-encryption-mode: t
>>  auto-compression-mode: t
>>  column-number-mode: t
>>  line-number-mode: t
>>  transient-mark-mode: t
>>  abbrev-mode: t
>> 
>> Recent input:
>> <down-mouse-1> <mouse-1> <f1> e m <backspace> <backspace> 
>> d o <tab> <return> <return> a l <return> s o u r <return> 
>> <return> C-s <return> 1 2 <return> C-n C-n C-x 3 <f3> 
>> <f3> C-n M-b C-e <f8> e m <tab> <return> <f10> C-n 
>> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
>> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-p 
>> C-p C-p C-p M-f M-f M-f M-f M-f M-f M-f M-f M-f <M-backspace> 
>> 1 4 <f2> C-e C-g C-g C-g M-x l o a d <tab> f <tab> 
>> <return> . e m <tab> <return> C-n C-e <down-mouse-1> 
>> <mouse-1> M-x d e <tab> C-g C-g <f1> C-g <f4> <return> 
>> C-x 3 M-n C-p C-e C-n C-n C-e C-p C-e C-n C-n C-n C-e 
>> C-a M-n M-p M-f M-b M-f C-n C-a M-b <return> / / SPC 
>> C-n <backspace> <backspace> <backspace> <backspace> 
>> SPC M-f M-f M-f M-f M-f M-f M-f M-f M-f M-f M-f M-b 
>> M-b M-f <return> / / SPC C-n <backspace> <backspace> 
>> <backspace> <backspace> SPC M-f M-f M-f M-f M-f M-f 
>> M-f M-f M-f M-f M-f M-f M-b M-f <return> / / SPC C-n 
>> <backspace> <backspace> <backspace> <backspace> SPC 
>> <f2> <f3> <f4> <return> ; <backspace> <f2> <down-mouse-1> 
>> <mouse-1> <down-mouse-1> <mouse-1> <down-mouse-1> <mouse-1> 
>> <down-mouse-1> <mouse-1> <wheel-down> <double-wheel-down> 
>> <triple-wheel-down> <triple-wheel-down> <triple-wheel-down> 
>> <triple-wheel-down> <down-mouse-1> <mouse-1> C-x k 
>> <return> <f1> <return> C-n C-n C-n C-n C-n C-n C-n 
>> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
>> C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n <f3> M-n 
>> M-n M-n M-n M-n M-n M-n M-n M-n M-n M-n M-n M-n M-n 
>> M-n M-n M-n M-n M-n M-n <down-mouse-1> <mouse-1> M-x 
>> r e p o r <tab> <return>
>> 
>> Recent messages:
>> Restarting server
>> Loading /Users/deyuandeng/.emacs.d/plugins/javascript/js-config.el (source)...done
>> Loading /Users/deyuandeng/.emacs.d/.emacs...done
>> Making completion list...
>> Quit [3 times]
>> scroll-down-in-place: Beginning of buffer
>> Saving file /Users/deyuandeng/Documents/Computer_Science/Algorithm/_SourceCodes/GeeksforGeeks/DynamicProgramming/12.MatrixChainMultiplication.cpp...
>> Wrote /Users/deyuandeng/Documents/Computer_Science/Algorithm/_SourceCodes/GeeksforGeeks/DynamicProgramming/12.MatrixChainMultiplication.cpp
>> Saving file /Users/deyuandeng/.emacs.d/.emacs...
>> Wrote /Users/deyuandeng/.emacs.d/.emacs
>> 
>> Load-path shadows:
>> ~/.emacs.d/plugins/javascript/js-comint hides /Users/deyuandeng/.emacs.d/elpa/js-comint-20080530.957/js-comint
>> ~/.emacs.d/plugins/javascript/whitespace hides /Applications/Emacs.app/Contents/Resources/lisp/whitespace
>> ~/.emacs.d/plugins/javascript/linum hides /Applications/Emacs.app/Contents/Resources/lisp/linum
>> /Users/deyuandeng/.emacs.d/elpa/flymake-0.4.12/flymake hides /Applications/Emacs.app/Contents/Resources/lisp/progmodes/flymake
>> /Users/deyuandeng/.emacs.d/elpa/magit-20130624.2315/.dir-locals hides /Applications/Emacs.app/Contents/Resources/lisp/gnus/.dir-locals
>> 
>> Features:
>> (shadow sort mail-extr emacsbug message format-spec rfc822 mml mml-sec
>> mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
>> mailheader sendmail rfc2047 rfc2045 ietf-drums mail-utils vc-git
>> bookmark pp cc-langs cc-mode cc-fonts cc-guess cc-menus cc-styles
>> cc-align help-mode hl-line multi-term term disp-table ehelp electric
>> multi-web-mode dired-x dired whitespace smooth-scrolling linum
>> easy-mmode recentf tree-widget wid-edit uniquify ffap url-parse
>> auth-source eieio byte-opt bytecomp byte-compile cconv eieio-core
>> gnus-util mm-util mail-prsvr password-cache url-vars jade-mode sws-mode
>> js-comint gas-mode python-mode derived skeleton thingatpt imenu flymake
>> rx shell pcomplete cc-cmds cc-engine cc-vars cc-defs compile comint
>> ansi-color ring ctags-update auto-complete-config auto-complete popup
>> ido autorevert filenotify server zenburn-theme column-marker-autoloads
>> ctags-autoloads ctags-update-autoloads espresso-theme-autoloads
>> flymake-autoloads jade-mode-autoloads jedi-autoloads
>> auto-complete-autoloads epc-autoloads ctable-autoloads
>> concurrent-autoloads deferred-autoloads js-comint-autoloads
>> lua-mode-autoloads magit-autoloads info multi-term-autoloads
>> multi-web-mode-autoloads popup-autoloads smooth-scrolling-autoloads
>> sws-mode-autoloads websocket-autoloads yasnippet-autoloads
>> yasnippet-bundle-autoloads yasnippet-bundle cl-macs gv dropdown-list
>> advice help-fns yasnippet edmacro kmacro easymenu assoc cl nadvice
>> cl-loaddefs cl-lib zenburn-theme-autoloads package time-date tooltip
>> ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd fontset
>> image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode
>> register page menu-bar rfn-eshadow timer select scroll-bar mouse
>> jit-lock font-lock syntax facemenu font-core frame cham georgian
>> utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
>> japanese hebrew greek romanian slovak czech european ethiopic indian
>> cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
>> minibuffer loaddefs button faces cus-face macroexp files text-properties
>> overlay sha1 md5 base64 format env code-pages mule custom widget
>> hashtable-print-readable backquote make-network-process ns multi-tty
>> emacs)
> 
> 
> 





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-08 19:21 ` Deyuan Deng
  2013-08-08 21:06   ` Jan Djärv
@ 2013-08-09  9:12   ` martin rudalics
  2013-08-09  9:52     ` Jan Djärv
  1 sibling, 1 reply; 35+ messages in thread
From: martin rudalics @ 2013-08-09  9:12 UTC (permalink / raw)
  To: Deyuan Deng; +Cc: 15046

 > Thanks for replying. Is there a way to get rid of this empty line? It takes some space and is pretty annoying.

If you or anyone else on OSX is interested, I can post my code which
works on Windows.  It probably won't compile immediately on OSX and
needs some adjustments, but I suppose it could be done without great
troubles.  And obviously, I need volunteers for fixing this with GNU
window managers as well.

martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09  9:12   ` martin rudalics
@ 2013-08-09  9:52     ` Jan Djärv
  2013-08-09 12:22       ` martin rudalics
  0 siblings, 1 reply; 35+ messages in thread
From: Jan Djärv @ 2013-08-09  9:52 UTC (permalink / raw)
  To: martin rudalics; +Cc: Deyuan Deng, 15046

Hello.

9 aug 2013 kl. 11:12 skrev martin rudalics <rudalics@gmx.at>:

> > Thanks for replying. Is there a way to get rid of this empty line? It takes some space and is pretty annoying.
> 
> If you or anyone else on OSX is interested, I can post my code which
> works on Windows.  It probably won't compile immediately on OSX and
> needs some adjustments, but I suppose it could be done without great
> troubles.  And obviously, I need volunteers for fixing this with GNU
> window managers as well.

What does it do?  If it makes the frame a bit smaller than fullscreen it will not work on X or NS.  There fullscreen is indeed fullscreen and there is no way around it (well easy way).
If it distributes the extra pixels elsewhere than at the bottom, I would assume only the display engine would need to be modified.

	Jan D.






^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-08 17:58 ` Jan Djärv
@ 2013-08-09 10:22   ` Eli Zaretskii
  2013-08-09 11:03     ` Dani Moncayo
  2013-08-09 12:41     ` Jan Djärv
  0 siblings, 2 replies; 35+ messages in thread
From: Eli Zaretskii @ 2013-08-09 10:22 UTC (permalink / raw)
  To: Jan Djärv; +Cc: deyuan.deng, 15046

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Thu, 8 Aug 2013 19:58:04 +0200
> Cc: 15046-done@debbugs.gnu.org
> 
> > When i set font to Monaco 14 (and several different font and fontsize),
> > there is an extra line under minibuffer when using fullscreen in Mac
> > OSX. The extra line is not editable, and is not part of
> > minibuffer. It won't come out if no custom font is set.
> > 
> 
> Emacs display whole lines, and the space you see at the bottom is too small to fit a whole line, so it is just shown as empty space.  It is the same for other ports, like X11.

I'm not sure what you mean by "displays whole lines", but at least
taken at face value, this is incorrect: Emacs is perfectly capable of
displaying partially visible lines.





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 10:22   ` Eli Zaretskii
@ 2013-08-09 11:03     ` Dani Moncayo
  2013-08-09 11:26       ` Dani Moncayo
                         ` (3 more replies)
  2013-08-09 12:41     ` Jan Djärv
  1 sibling, 4 replies; 35+ messages in thread
From: Dani Moncayo @ 2013-08-09 11:03 UTC (permalink / raw)
  To: 15046

This is a duplicate of bug #7004 (I think).

IMO, the right fix would be to always use all the available vertical
space to show content, putting the leftover vertical space at the
bottom side of the main windows (i.e. excluding the minibuffer/echo
area, obviously).

In fact, the above criterion seems the one that I currently observe in
Emacs for the leftover horizontal space (try adjusting the text size
with `C-x C-+', for example).

-- 
Dani Moncayo





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 11:03     ` Dani Moncayo
@ 2013-08-09 11:26       ` Dani Moncayo
  2013-08-09 12:23         ` martin rudalics
  2013-08-09 12:58         ` Jan Djärv
  2013-08-09 12:22       ` martin rudalics
                         ` (2 subsequent siblings)
  3 siblings, 2 replies; 35+ messages in thread
From: Dani Moncayo @ 2013-08-09 11:26 UTC (permalink / raw)
  To: 15046

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

On Fri, Aug 9, 2013 at 1:03 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:
> This is a duplicate of bug #7004 (I think).
>
> IMO, the right fix would be to always use all the available vertical
> space to show content, putting the leftover vertical space at the
> bottom side of the main windows (i.e. excluding the minibuffer/echo
> area, obviously).
>
> In fact, the above criterion seems the one that I currently observe in
> Emacs for the leftover horizontal space (try adjusting the text size
> with `C-x C-+', for example).

And FWIW, I've just noticed that, at least in the Windows port, this
problem is already fixed when both the menu bar and the tool bar are
hidden.

See the attached screenshots.  They show a fullscreen "emacs -Q" session.
* The first one has the menu and tool bars visible, and the echo area
takes too much, unnecessary vertical space.
* The second one has the menu and toll bars hidden, and now the
leftover space is given to the main windows (correct).

-- 
Dani Moncayo

[-- Attachment #2: Capture1.png --]
[-- Type: image/png, Size: 79048 bytes --]

[-- Attachment #3: Capture2.png --]
[-- Type: image/png, Size: 77874 bytes --]

^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09  9:52     ` Jan Djärv
@ 2013-08-09 12:22       ` martin rudalics
  0 siblings, 0 replies; 35+ messages in thread
From: martin rudalics @ 2013-08-09 12:22 UTC (permalink / raw)
  To: Jan Djärv; +Cc: Deyuan Deng, 15046

[-- Attachment #1: Type: text/plain, Size: 429 bytes --]

 > What does it do?

Have a look.

 > If it makes the frame a bit smaller than fullscreen it will not work on X or NS.  There fullscreen is indeed fullscreen and there is no way around it (well easy way).

Fullscreen is fullscreen and maximized is maximized.

 > If it distributes the extra pixels elsewhere than at the bottom, I would assume only the display engine would need to be modified.

Your assumption is wrong.

martin

[-- Attachment #2: pixelwise.diff.gz --]
[-- Type: application/gzip, Size: 88270 bytes --]

^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 11:03     ` Dani Moncayo
  2013-08-09 11:26       ` Dani Moncayo
@ 2013-08-09 12:22       ` martin rudalics
  2013-08-09 13:17       ` Eli Zaretskii
  2013-12-17 10:38       ` Dani Moncayo
  3 siblings, 0 replies; 35+ messages in thread
From: martin rudalics @ 2013-08-09 12:22 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 15046

 > IMO, the right fix would be to always use all the available vertical

... and horizontal ...

 > space to show content, putting the leftover vertical space at the
 > bottom side of the main windows (i.e. excluding the minibuffer/echo
 > area, obviously).

... which is not precise when such a window has a specified size (like
the ediff Control Panel).

Anyway, since you are on Windows you should be able to try the patch I
sent.

martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 11:26       ` Dani Moncayo
@ 2013-08-09 12:23         ` martin rudalics
  2013-08-09 13:19           ` Dani Moncayo
  2013-08-09 12:58         ` Jan Djärv
  1 sibling, 1 reply; 35+ messages in thread
From: martin rudalics @ 2013-08-09 12:23 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 15046

 > And FWIW, I've just noticed that, at least in the Windows port, this
 > problem is already fixed when both the menu bar and the tool bar are
 > hidden.
 >
 > See the attached screenshots.  They show a fullscreen "emacs -Q" session.
 > * The first one has the menu and tool bars visible, and the echo area
 > takes too much, unnecessary vertical space.
 > * The second one has the menu and toll bars hidden, and now the
 > leftover space is given to the main windows (correct).

What you see is probably an optical illusion.  With the current trunk,
leftover background space is colored correctly by Windows, but the
fringes and scrollbar (of the minibuffer window) don't cover the entire
screen.  Unless the screen size is a multiple of Emacs' frame character
height.

martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 10:22   ` Eli Zaretskii
  2013-08-09 11:03     ` Dani Moncayo
@ 2013-08-09 12:41     ` Jan Djärv
  2013-08-09 13:37       ` Eli Zaretskii
  1 sibling, 1 reply; 35+ messages in thread
From: Jan Djärv @ 2013-08-09 12:41 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: deyuan.deng, 15046

Hello.

9 aug 2013 kl. 12:22 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Thu, 8 Aug 2013 19:58:04 +0200
>> Cc: 15046-done@debbugs.gnu.org
>> 
>>> When i set font to Monaco 14 (and several different font and fontsize),
>>> there is an extra line under minibuffer when using fullscreen in Mac
>>> OSX. The extra line is not editable, and is not part of
>>> minibuffer. It won't come out if no custom font is set.
>>> 
>> 
>> Emacs display whole lines, and the space you see at the bottom is too small to fit a whole line, so it is just shown as empty space.  It is the same for other ports, like X11.
> 
> I'm not sure what you mean by "displays whole lines", but at least
> taken at face value, this is incorrect: Emacs is perfectly capable of
> displaying partially visible lines.

So why don't it?  The display engine got all information it needs, the frame size in pixels, the line sizes in pixels, the placement of the windows and so on.  It should be able to distribute the non-whole line pixels to a widow and display a partial line there (i.e. above the mode line as suggested elsewhere), but it currently don't.  That is what I mean by displays whole lines.

	Jan D.






^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 11:26       ` Dani Moncayo
  2013-08-09 12:23         ` martin rudalics
@ 2013-08-09 12:58         ` Jan Djärv
  2013-08-09 13:14           ` Dani Moncayo
  1 sibling, 1 reply; 35+ messages in thread
From: Jan Djärv @ 2013-08-09 12:58 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 15046

Hello.

9 aug 2013 kl. 13:26 skrev Dani Moncayo <dmoncayo@gmail.com>:

> On Fri, Aug 9, 2013 at 1:03 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:
>> This is a duplicate of bug #7004 (I think).
>> 
>> IMO, the right fix would be to always use all the available vertical
>> space to show content, putting the leftover vertical space at the
>> bottom side of the main windows (i.e. excluding the minibuffer/echo
>> area, obviously).
>> 
>> In fact, the above criterion seems the one that I currently observe in
>> Emacs for the leftover horizontal space (try adjusting the text size
>> with `C-x C-+', for example).
> 
> And FWIW, I've just noticed that, at least in the Windows port, this
> problem is already fixed when both the menu bar and the tool bar are
> hidden.
> 
> See the attached screenshots.  They show a fullscreen "emacs -Q" session.
> * The first one has the menu and tool bars visible, and the echo area
> takes too much, unnecessary vertical space.
> * The second one has the menu and toll bars hidden, and now the
> leftover space is given to the main windows (correct).

I think that has to with the fact that the buffer uses two different font sizes.  In that case both NS and X11 also displays partial lines.  Try with a buffer with just one font size, and adjust the size.  You should be able to get the blank leftover pixels at the bottom without menu and tool bar also.

	Jan D.

> 
> -- 
> Dani Moncayo
> <Capture1.png><Capture2.png>






^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 12:58         ` Jan Djärv
@ 2013-08-09 13:14           ` Dani Moncayo
  0 siblings, 0 replies; 35+ messages in thread
From: Dani Moncayo @ 2013-08-09 13:14 UTC (permalink / raw)
  To: Jan Djärv; +Cc: 15046

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

>> And FWIW, I've just noticed that, at least in the Windows port, this
>> problem is already fixed when both the menu bar and the tool bar are
>> hidden.
>>
>> See the attached screenshots.  They show a fullscreen "emacs -Q" session.
>> * The first one has the menu and tool bars visible, and the echo area
>> takes too much, unnecessary vertical space.
>> * The second one has the menu and toll bars hidden, and now the
>> leftover space is given to the main windows (correct).
>
> I think that has to with the fact that the buffer uses two different font sizes.  In that case both NS and X11 also displays partial lines.  Try with a buffer with just one font size, and adjust the size.  You should be able to get the blank leftover pixels at the bottom without menu and tool bar also.

I've just tried it, and it seems that your guess is wrong.  I'm
attaching two screenshots of a fullscreen "emacs -Q" showing a buffer
with a single font size:
* "Capture3" has visible menu and tool bars.  There is leftover space
at the bottom and right edges of the screen.
* "Capture4" has hidden menu and tool bars. Now the leftover vertical
space is given to the main window, but the leftover horizontal space
is still there.

-- 
Dani Moncayo

[-- Attachment #2: Capture3.png --]
[-- Type: image/png, Size: 75380 bytes --]

[-- Attachment #3: Capture4.png --]
[-- Type: image/png, Size: 77098 bytes --]

^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 11:03     ` Dani Moncayo
  2013-08-09 11:26       ` Dani Moncayo
  2013-08-09 12:22       ` martin rudalics
@ 2013-08-09 13:17       ` Eli Zaretskii
  2013-08-09 13:30         ` Dani Moncayo
  2013-08-09 17:10         ` martin rudalics
  2013-12-17 10:38       ` Dani Moncayo
  3 siblings, 2 replies; 35+ messages in thread
From: Eli Zaretskii @ 2013-08-09 13:17 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 15046

> Date: Fri, 9 Aug 2013 13:03:47 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> IMO, the right fix would be to always use all the available vertical
> space to show content, putting the leftover vertical space at the
> bottom side of the main windows (i.e. excluding the minibuffer/echo
> area, obviously).

The minibuffer/echo area window is just another window, so why would
Emacs treat it specially?  If other windows can have partially visible
lines, why cannot the minibuffer window have them?





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 12:23         ` martin rudalics
@ 2013-08-09 13:19           ` Dani Moncayo
  2013-08-09 17:08             ` martin rudalics
  0 siblings, 1 reply; 35+ messages in thread
From: Dani Moncayo @ 2013-08-09 13:19 UTC (permalink / raw)
  To: martin rudalics; +Cc: 15046

>> And FWIW, I've just noticed that, at least in the Windows port, this
>> problem is already fixed when both the menu bar and the tool bar are
>> hidden.
>>
>> See the attached screenshots.  They show a fullscreen "emacs -Q" session.
>> * The first one has the menu and tool bars visible, and the echo area
>> takes too much, unnecessary vertical space.
>> * The second one has the menu and toll bars hidden, and now the
>> leftover space is given to the main windows (correct).
>
> What you see is probably an optical illusion.  With the current trunk,
> leftover background space is colored correctly by Windows, but the
> fringes and scrollbar (of the minibuffer window) don't cover the entire
> screen.  Unless the screen size is a multiple of Emacs' frame character
> height.

I don't think what I see is an illusion.  I clearly see that, at the
moment I hide the menu and tool bars, the modeline moves a bit toward
the bottom, so that the remnant vertical space is now used by the main
window.

-- 
Dani Moncayo





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 13:17       ` Eli Zaretskii
@ 2013-08-09 13:30         ` Dani Moncayo
  2013-08-09 13:51           ` Eli Zaretskii
  2013-08-09 13:52           ` Dani Moncayo
  2013-08-09 17:10         ` martin rudalics
  1 sibling, 2 replies; 35+ messages in thread
From: Dani Moncayo @ 2013-08-09 13:30 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 15046

On Fri, Aug 9, 2013 at 3:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 9 Aug 2013 13:03:47 +0200
>> From: Dani Moncayo <dmoncayo@gmail.com>
>>
>> IMO, the right fix would be to always use all the available vertical
>> space to show content, putting the leftover vertical space at the
>> bottom side of the main windows (i.e. excluding the minibuffer/echo
>> area, obviously).
>
> The minibuffer/echo area window is just another window, so why would
> Emacs treat it specially?  If other windows can have partially visible
> lines, why cannot the minibuffer window have them?

IMO, it is much better to give the leftover space to the main
window(s) than to the mini-window.  The main reason I can think of now
is that the main window(s) is (are) more likely to have more text
beyond its last wholly-visible line than the mini-window (which
usually will not need more than one line).

-- 
Dani Moncayo





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 12:41     ` Jan Djärv
@ 2013-08-09 13:37       ` Eli Zaretskii
  2013-08-09 15:39         ` Deyuan Deng
  0 siblings, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2013-08-09 13:37 UTC (permalink / raw)
  To: Jan Djärv; +Cc: deyuan.deng, 15046

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Fri, 9 Aug 2013 14:41:24 +0200
> Cc: 15046@debbugs.gnu.org,
>  deyuan.deng@gmail.com
> 
> > I'm not sure what you mean by "displays whole lines", but at least
> > taken at face value, this is incorrect: Emacs is perfectly capable of
> > displaying partially visible lines.
> 
> So why don't it?  The display engine got all information it needs, the frame size in pixels, the line sizes in pixels, the placement of the windows and so on.  It should be able to distribute the non-whole line pixels to a widow and display a partial line there (i.e. above the mode line as suggested elsewhere), but it currently don't.  That is what I mean by displays whole lines.

What you mean is Emacs is unable to _resize_ a window in pixel
increments.  It can only change window size in integral increments of
the frame's default face.  That is correct (and AFAIU is the subject
or Martin's patch).

But once a window is created or resized, it can display partial
lines.  Just remap the default face and you will see it.





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 13:30         ` Dani Moncayo
@ 2013-08-09 13:51           ` Eli Zaretskii
  2013-08-09 13:53             ` Dani Moncayo
  2013-08-09 13:52           ` Dani Moncayo
  1 sibling, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2013-08-09 13:51 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 15046

> Date: Fri, 9 Aug 2013 15:30:24 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 15046@debbugs.gnu.org
> 
> IMO, it is much better to give the leftover space to the main
> window(s) than to the mini-window.  The main reason I can think of now
> is that the main window(s) is (are) more likely to have more text
> beyond its last wholly-visible line than the mini-window (which
> usually will not need more than one line).

But OTOH the other windows are taller, so they have more lines than
the poor little minibuffer window.





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 13:30         ` Dani Moncayo
  2013-08-09 13:51           ` Eli Zaretskii
@ 2013-08-09 13:52           ` Dani Moncayo
  2013-08-09 14:13             ` Eli Zaretskii
  1 sibling, 1 reply; 35+ messages in thread
From: Dani Moncayo @ 2013-08-09 13:52 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 15046

>> The minibuffer/echo area window is just another window, so why would
>> Emacs treat it specially?  If other windows can have partially visible
>> lines, why cannot the minibuffer window have them?
>
> IMO, it is much better to give the leftover space to the main
> window(s) than to the mini-window.  The main reason I can think of now
> is that the main window(s) is (are) more likely to have more text
> beyond its last wholly-visible line than the mini-window (which
> usually will not need more than one line).

And moreover: In the cases when the text in the mini-window spans to
more than one line, Emacs should expand the height of the mini-window
so that the whole text is visible (unless the number of lines is too
high.  In that case there is no choice but to scroll).

IOW: I don't think it is appropriate for the mini-window to show only
part of a line.  The whole text should be visible if possible,
resizing the mini-window when necessary.

-- 
Dani Moncayo





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 13:51           ` Eli Zaretskii
@ 2013-08-09 13:53             ` Dani Moncayo
  0 siblings, 0 replies; 35+ messages in thread
From: Dani Moncayo @ 2013-08-09 13:53 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 15046

On Fri, Aug 9, 2013 at 3:51 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 9 Aug 2013 15:30:24 +0200
>> From: Dani Moncayo <dmoncayo@gmail.com>
>> Cc: 15046@debbugs.gnu.org
>>
>> IMO, it is much better to give the leftover space to the main
>> window(s) than to the mini-window.  The main reason I can think of now
>> is that the main window(s) is (are) more likely to have more text
>> beyond its last wholly-visible line than the mini-window (which
>> usually will not need more than one line).
>
> But OTOH the other windows are taller, so they have more lines than
> the poor little minibuffer window.

Yes, but please see the post I've sent a moment ago.  I don't think it
is appropriate for the mini-window to show a line partially.

-- 
Dani Moncayo





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 13:52           ` Dani Moncayo
@ 2013-08-09 14:13             ` Eli Zaretskii
  2013-08-09 14:23               ` Dani Moncayo
  2013-08-09 16:19               ` Stefan Monnier
  0 siblings, 2 replies; 35+ messages in thread
From: Eli Zaretskii @ 2013-08-09 14:13 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 15046

> Date: Fri, 9 Aug 2013 15:52:02 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 15046@debbugs.gnu.org
> 
> And moreover: In the cases when the text in the mini-window spans to
> more than one line, Emacs should expand the height of the mini-window
> so that the whole text is visible

Unless resize-mini-windows is nil.





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 14:13             ` Eli Zaretskii
@ 2013-08-09 14:23               ` Dani Moncayo
  2013-08-09 16:19               ` Stefan Monnier
  1 sibling, 0 replies; 35+ messages in thread
From: Dani Moncayo @ 2013-08-09 14:23 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 15046

>> And moreover: In the cases when the text in the mini-window spans to
>> more than one line, Emacs should expand the height of the mini-window
>> so that the whole text is visible
>
> Unless resize-mini-windows is nil.

Indeed ;), but even for those people with such a strange setup (I
guess there are few), I still think that giving the leftover space to
the main windows would be better, because as I said, those windows are
more likely to have text beyond their last wholly-visible line.

-- 
Dani Moncayo





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 13:37       ` Eli Zaretskii
@ 2013-08-09 15:39         ` Deyuan Deng
  2013-08-09 17:08           ` martin rudalics
  0 siblings, 1 reply; 35+ messages in thread
From: Deyuan Deng @ 2013-08-09 15:39 UTC (permalink / raw)
  To: rudalics; +Cc: 15046

[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]

Hi Martin,

Thanks for your patch. I will try my best to apply it to OSX, i'm new to
elisp so it may take a little bit longer. I'm also interested in fixing it
in other platform if no one is working on that part.

Thanks for all your help, it's a great community.

Best,
Deyuan


On Fri, Aug 9, 2013 at 7:37 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Jan Djärv <jan.h.d@swipnet.se>
> > Date: Fri, 9 Aug 2013 14:41:24 +0200
> > Cc: 15046@debbugs.gnu.org,
> >  deyuan.deng@gmail.com
> >
> > > I'm not sure what you mean by "displays whole lines", but at least
> > > taken at face value, this is incorrect: Emacs is perfectly capable of
> > > displaying partially visible lines.
> >
> > So why don't it?  The display engine got all information it needs, the
> frame size in pixels, the line sizes in pixels, the placement of the
> windows and so on.  It should be able to distribute the non-whole line
> pixels to a widow and display a partial line there (i.e. above the mode
> line as suggested elsewhere), but it currently don't.  That is what I mean
> by displays whole lines.
>
> What you mean is Emacs is unable to _resize_ a window in pixel
> increments.  It can only change window size in integral increments of
> the frame's default face.  That is correct (and AFAIU is the subject
> or Martin's patch).
>
> But once a window is created or resized, it can display partial
> lines.  Just remap the default face and you will see it.
>



-- 
*Deyuan Derrick Deng*
*Master of Electrical and Computer Engineering*
*Carnegie Mellon University*

[-- Attachment #2: Type: text/html, Size: 2276 bytes --]

^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 14:13             ` Eli Zaretskii
  2013-08-09 14:23               ` Dani Moncayo
@ 2013-08-09 16:19               ` Stefan Monnier
  2013-08-09 16:59                 ` Dani Moncayo
  1 sibling, 1 reply; 35+ messages in thread
From: Stefan Monnier @ 2013-08-09 16:19 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 15046

>> And moreover: In the cases when the text in the mini-window spans to
>> more than one line, Emacs should expand the height of the mini-window
>> so that the whole text is visible
> Unless resize-mini-windows is nil.

At least for echo-area messages, half-lines are kind of useless, since
it's kind of awkward to see the missing part: if you're lucky you can
see it by looking for the copy stashed in *Messages*, but otherwise, any
attempt to run a command which might help would start by erasing
that message.
Of course if the "half-line" really shows 90% of the height, the missing
part is probably not a problem.


        Stefan





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 16:19               ` Stefan Monnier
@ 2013-08-09 16:59                 ` Dani Moncayo
  2013-08-09 18:57                   ` Stefan Monnier
  0 siblings, 1 reply; 35+ messages in thread
From: Dani Moncayo @ 2013-08-09 16:59 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 15046

On Fri, Aug 9, 2013 at 6:19 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> And moreover: In the cases when the text in the mini-window spans to
>>> more than one line, Emacs should expand the height of the mini-window
>>> so that the whole text is visible
>> Unless resize-mini-windows is nil.
>
> At least for echo-area messages, half-lines are kind of useless, since
> it's kind of awkward to see the missing part: if you're lucky you can
> see it by looking for the copy stashed in *Messages*, but otherwise, any
> attempt to run a command which might help would start by erasing
> that message.

Indeed.

> Of course if the "half-line" really shows 90% of the height, the missing
> part is probably not a problem.

But even in that case, a mini-window of 1.X lines high would look awful, IMO.

-- 
Dani Moncayo





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 13:19           ` Dani Moncayo
@ 2013-08-09 17:08             ` martin rudalics
  0 siblings, 0 replies; 35+ messages in thread
From: martin rudalics @ 2013-08-09 17:08 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 15046

 > I don't think what I see is an illusion.  I clearly see that, at the
 > moment I hide the menu and tool bars, the modeline moves a bit toward
 > the bottom, so that the remnant vertical space is now used by the main
 > window.

It might depend on the font used for menu and toolbar - on Windows the
menubar size is determined by the OS.

martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 15:39         ` Deyuan Deng
@ 2013-08-09 17:08           ` martin rudalics
  2013-08-09 18:57             ` Deyuan Deng
  0 siblings, 1 reply; 35+ messages in thread
From: martin rudalics @ 2013-08-09 17:08 UTC (permalink / raw)
  To: Deyuan Deng; +Cc: 15046

 > Thanks for your patch. I will try my best to apply it to OSX, i'm new to
 > elisp so it may take a little bit longer. I'm also interested in fixing it
 > in other platform if no one is working on that part.

You don't have to know Elisp for this.  You have to be able to apply a
patch (I noticed that I sent it together with my shell commands so you'd
have to remove them first) build Emacs from sources amd communicate the
errors you see to me.

martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 13:17       ` Eli Zaretskii
  2013-08-09 13:30         ` Dani Moncayo
@ 2013-08-09 17:10         ` martin rudalics
  1 sibling, 0 replies; 35+ messages in thread
From: martin rudalics @ 2013-08-09 17:10 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 15046

 > The minibuffer/echo area window is just another window, so why would
 > Emacs treat it specially?  If other windows can have partially visible
 > lines, why cannot the minibuffer window have them?

We have to handle minibufferless frames anyway.  But there's no reason
to not optionally give the space to the minibuffer.

martin





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 17:08           ` martin rudalics
@ 2013-08-09 18:57             ` Deyuan Deng
  0 siblings, 0 replies; 35+ messages in thread
From: Deyuan Deng @ 2013-08-09 18:57 UTC (permalink / raw)
  To: martin rudalics; +Cc: 15046

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

Hi, Martin,
Thanks, i ll do it shortly.
On Aug 9, 2013 11:08 AM, "martin rudalics" <rudalics@gmx.at> wrote:

> > Thanks for your patch. I will try my best to apply it to OSX, i'm new to
> > elisp so it may take a little bit longer. I'm also interested in fixing
> it
> > in other platform if no one is working on that part.
>
> You don't have to know Elisp for this.  You have to be able to apply a
> patch (I noticed that I sent it together with my shell commands so you'd
> have to remove them first) build Emacs from sources amd communicate the
> errors you see to me.
>
> martin
>

[-- Attachment #2: Type: text/html, Size: 885 bytes --]

^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 16:59                 ` Dani Moncayo
@ 2013-08-09 18:57                   ` Stefan Monnier
  2013-08-11 17:14                     ` Dani Moncayo
  0 siblings, 1 reply; 35+ messages in thread
From: Stefan Monnier @ 2013-08-09 18:57 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 15046

>> Of course if the "half-line" really shows 90% of the height, the missing
>> part is probably not a problem.
> But even in that case, a mini-window of 1.X lines high would look awful, IMO.

It probably depends on the specifics (e.g. what's the value of X and
the user's taste).  E.g. I use a non-resizable minibuffer (because it's
in a separate minibuffer-only frame) and would be happy to give a height
of about 1.2 lines: I'm happy with it displaying a single line, but the
extra 20% would let it display everything properly even when the text is
slightly larger because of the some face property (or because there's
an CJK char on the same line).


        Stefan





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 18:57                   ` Stefan Monnier
@ 2013-08-11 17:14                     ` Dani Moncayo
  0 siblings, 0 replies; 35+ messages in thread
From: Dani Moncayo @ 2013-08-11 17:14 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 15046

On Fri, Aug 9, 2013 at 8:57 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> Of course if the "half-line" really shows 90% of the height, the missing
>>> part is probably not a problem.
>> But even in that case, a mini-window of 1.X lines high would look awful, IMO.
>
> It probably depends on the specifics (e.g. what's the value of X and
> the user's taste).  E.g. I use a non-resizable minibuffer (because it's
> in a separate minibuffer-only frame) and would be happy to give a height
> of about 1.2 lines: I'm happy with it displaying a single line, but the
> extra 20% would let it display everything properly even when the text is
> slightly larger because of the some face property (or because there's
> an CJK char on the same line).

That's fine.  You may prefer to have a _constant_ extra height in you
mini-window.  Then, it should be something configurable.  But what
makes little sense (IMO) is having a mini-window with a _variable_
extra height (consisting of the leftover vertical space at every
moment).

-- 
Dani Moncayo





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-08-09 11:03     ` Dani Moncayo
                         ` (2 preceding siblings ...)
  2013-08-09 13:17       ` Eli Zaretskii
@ 2013-12-17 10:38       ` Dani Moncayo
  2013-12-18  2:12         ` Deyuan Deng
  3 siblings, 1 reply; 35+ messages in thread
From: Dani Moncayo @ 2013-12-17 10:38 UTC (permalink / raw)
  To: Deyuan Deng; +Cc: 15046

On Fri, Aug 9, 2013 at 1:03 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:
> This is a duplicate of bug #7004 (I think).
>
> IMO, the right fix would be to always use all the available vertical
> space to show content, putting the leftover vertical space at the
> bottom side of the main windows (i.e. excluding the minibuffer/echo
> area, obviously).

At least on MS-Windows, the current development version behaves
correctly (as I described above).

Do you also see a correct behavior in your Mac?  (if so, we could
close these two bug reports)

-- 
Dani Moncayo





^ permalink raw reply	[flat|nested] 35+ messages in thread

* bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen
  2013-12-17 10:38       ` Dani Moncayo
@ 2013-12-18  2:12         ` Deyuan Deng
  0 siblings, 0 replies; 35+ messages in thread
From: Deyuan Deng @ 2013-12-18  2:12 UTC (permalink / raw)
  To: Dani Moncayo; +Cc: 15046

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

Hi, I just make from current development version, it works correctly now.
Thanks!

Best


On Tue, Dec 17, 2013 at 6:38 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:

> On Fri, Aug 9, 2013 at 1:03 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:
> > This is a duplicate of bug #7004 (I think).
> >
> > IMO, the right fix would be to always use all the available vertical
> > space to show content, putting the leftover vertical space at the
> > bottom side of the main windows (i.e. excluding the minibuffer/echo
> > area, obviously).
>
> At least on MS-Windows, the current development version behaves
> correctly (as I described above).
>
> Do you also see a correct behavior in your Mac?  (if so, we could
> close these two bug reports)
>
> --
> Dani Moncayo
>



-- 
*Deyuan Derrick Deng*
*Master of Electrical and Computer Engineering*
*Carnegie Mellon University*

[-- Attachment #2: Type: text/html, Size: 1425 bytes --]

^ permalink raw reply	[flat|nested] 35+ messages in thread

end of thread, other threads:[~2013-12-18  2:12 UTC | newest]

Thread overview: 35+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-07 19:39 bug#15046: 24.3.50; Extra Line under minibuffer in Mac OSX fullscreen Deyuan Deng
2013-08-08 17:58 ` Jan Djärv
2013-08-09 10:22   ` Eli Zaretskii
2013-08-09 11:03     ` Dani Moncayo
2013-08-09 11:26       ` Dani Moncayo
2013-08-09 12:23         ` martin rudalics
2013-08-09 13:19           ` Dani Moncayo
2013-08-09 17:08             ` martin rudalics
2013-08-09 12:58         ` Jan Djärv
2013-08-09 13:14           ` Dani Moncayo
2013-08-09 12:22       ` martin rudalics
2013-08-09 13:17       ` Eli Zaretskii
2013-08-09 13:30         ` Dani Moncayo
2013-08-09 13:51           ` Eli Zaretskii
2013-08-09 13:53             ` Dani Moncayo
2013-08-09 13:52           ` Dani Moncayo
2013-08-09 14:13             ` Eli Zaretskii
2013-08-09 14:23               ` Dani Moncayo
2013-08-09 16:19               ` Stefan Monnier
2013-08-09 16:59                 ` Dani Moncayo
2013-08-09 18:57                   ` Stefan Monnier
2013-08-11 17:14                     ` Dani Moncayo
2013-08-09 17:10         ` martin rudalics
2013-12-17 10:38       ` Dani Moncayo
2013-12-18  2:12         ` Deyuan Deng
2013-08-09 12:41     ` Jan Djärv
2013-08-09 13:37       ` Eli Zaretskii
2013-08-09 15:39         ` Deyuan Deng
2013-08-09 17:08           ` martin rudalics
2013-08-09 18:57             ` Deyuan Deng
2013-08-08 19:21 ` Deyuan Deng
2013-08-08 21:06   ` Jan Djärv
2013-08-09  9:12   ` martin rudalics
2013-08-09  9:52     ` Jan Djärv
2013-08-09 12:22       ` martin rudalics

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).