GNU bug report logs -
#25408
Remove Decorations Around Emacs Frame (Windows OS)
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25408 in the body.
You can then email your comments to 25408 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Mon, 09 Jan 2017 22:21:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Arthur Miller <arthur.miller.no1 <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 09 Jan 2017 22:21:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I would like to be able to run Emacs without frame decorations on Win
OS. I don't like those since they break visual styles of my Emacs,
especially if I use a dark theme. Also caption bar take some of
vertical screen estate unnecessary. I didn't found any reliable way
to do this from Emacs.
It can be done via Win32 API SetWindowLongPtr by changing EMACS_CLASS
style to WS_POPUP|WS_TABSTOP|WS_VISIBLE. It can be changed back to
original by either saving old style in a variable or by setting
corresponding style bits for standard window frame. I suggest either
to implement this in a "border-width" property when border width
is set to 0, or to implement a new variable/function that can be set in
init file, such as for example "no-frame-borders t". I have made small
prototype/mockup to illustrate what I mean which can be seen on
https://www.youtube.com/watch?v=ii_gTRCuXog
Care has to be taken to note that when removing caption bar and borders
it will be no longer possible to move and resize window unless user
have other means of performing those applications. I am using a small
opensource app called alt-drag (https://stefansundin.github.io/altdrag/).
For convienience one might implement moving/resizing ops in Emacs
window procedure. For ex they can be faked by just sending corresponding
messages
back to wnd proc. I think standard way to do this is by handling
WM_NCHITTEST, as for example:
case WM_NCHITTEST: {
LRESULT hit = DefWindowProc(hWnd, message, wParam, lParam);
if (hit == HTCLIENT) hit = HTCAPTION;
return hit;
}
Similar could maybe work for HTSIZE but I haven't tested it myself
though, so I can't tell for sure.
In GNU Emacs 26.0.50.1 (x86_64-w64-mingw32)
of 2017-01-05 built on DESKTOP-EBMFI2K
Repository revision: d88cdad2847726438c7d1de9fd2651c4be9243aa
Windowing system distributor 'Microsoft Corp.', version 10.0.14393
Recent messages:
Wrote c:/Users/Arthur/.emacs
[yas] Prepared just-in-time loading of snippets successfully. [2 times]
Loading c:/Users/Arthur/.emacs.d/plugins/realgud/realgud/common/custom.el
(source)...done
Loading c:/Users/Arthur/.emacs.d/plugins/bookmark-plus/bookmark+-mac.el
(source)...done
Loading c:/Users/Arthur/.emacs.d/plugins/bookmark-plus/bookmark+-mac.el
(source)...done
Loading c:/Users/Arthur/.emacs.d/plugins/bookmark-plus/bookmark+-mac.el
(source)...done
Loading c:/Users/Arthur/.emacs.d/plugins/bookmark-plus/bookmark+-mac.el
(source)...done
Loading c:/Users/Arthur/.emacs.d/plugins/bookmark-plus/bookmark+-mac.el
(source)...done
Loading c:/Users/Arthur/.emacs.d/etc/recentf...done
(Shell command succeeded with no output) [2 times]
Configured using:
'configure --without-imagemagick --with-modules --without-makeinfo'
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS MODULES
Important settings:
value of $LANG: SVE
locale-coding-system: cp1252
Major mode: Emacs-Lisp
Minor modes in effect:
window-number-mode: t
global-semanticdb-minor-mode: t
global-semantic-idle-scheduler-mode: t
semantic-mode: t
global-ede-mode: t
helm-mode: t
shell-dirtrack-mode: t
helm-autoresize-mode: t
async-bytecomp-package-mode: t
global-auto-complete-mode: t
auto-complete-mode: t
yas-global-mode: t
yas-minor-mode: t
global-undo-tree-mode: t
undo-tree-mode: t
override-global-mode: t
which-function-mode: t
save-place-mode: t
global-auto-revert-mode: t
global-hl-line-mode: t
electric-pair-mode: t
winner-mode: t
show-paren-mode: t
recentf-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-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
Load-path shadows:
c:/Users/Arthur/.emacs.d/plugins/company/company-cmake hides
c:/Users/Arthur/.emacs.d/plugins/company-cmake/company-cmake
c:/Users/Arthur/.emacs.d/plugins/helm/helm hides
c:/Users/Arthur/.emacs.d/plugins/helm-core/helm
c:/Users/Arthur/.emacs.d/plugins/helm/helm-source hides
c:/Users/Arthur/.emacs.d/plugins/helm-core/helm-source
c:/Users/Arthur/.emacs.d/plugins/helm/helm-multi-match hides
c:/Users/Arthur/.emacs.d/plugins/helm-core/helm-multi-match
c:/Users/Arthur/.emacs.d/plugins/helm/helm-lib hides
c:/Users/Arthur/.emacs.d/plugins/helm-core/helm-lib
c:/Users/Arthur/.emacs.d/plugins/load-relative/el-get-install hides
c:/Users/Arthur/.emacs.d/plugins/loc-changes/el-get-install
c:/Users/Arthur/.emacs.d/plugins/load-relative/el-get-install hides
c:/Users/Arthur/.emacs.d/plugins/realgud/el-get-install
c:/Users/Arthur/.emacs.d/plugins/realgud/realgud hides
c:/Users/Arthur/.emacs.d/plugins/xxrealgud/realgud
c:/Users/Arthur/.emacs.d/plugins/loc-changes/test/test-basic hides
c:/Users/Arthur/.emacs.d/plugins/test-simple/test/test-basic
Features:
(shadow flyspell ispell mail-extr emacsbug sendmail helm-command
helm-elisp helm-eval edebug emms-player-simple-mpv-control-functions
emms-player-simple-mpv extras emms-player-vlc emms-player-mplayer
emms-setup emms-librefm-stream emms-librefm-scrobbler
emms-playlist-limit emms-volume emms-volume-amixer emms-i18n
emms-history emms-score emms-stream-info emms-metaplaylist-mode
emms-bookmarks emms-cue emms-mode-line-icon emms-browser sort
emms-playlist-sort emms-last-played emms-player-xine emms-player-mpd tq
emms-playing-time emms-lyrics emms-url emms-player-simple emms-streams
emms-show-all emms-tag-editor emms-info-metaflac emms-mark
emms-mode-line emms-cache emms-info-ogginfo emms-info-mp3info emms-info
later-do emms-playlist-mode emms-source-playlist emms-source-file locate
emms emms-compat ztree ztree-diff ztree-diff-model ztree-dir ztree-view
ztree-util rainbow-delimiters vline sanityinc-solarized-dark-theme
color-theme-sanityinc-solarized neotree dired-xtra direx dired+
image-file bookmark+ bookmark+-key bookmark+-1 gnus-sum gnus-group
gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source tls gnutls
utf7 netrc nnoo gnus-spec gnus-int gnus-range message puny rfc822 mml
mml-sec epa epg epg-config mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader gnus-win gnus nnheader gnus-util
rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums mail-utils mm-util
mail-prsvr bookmark+-bmu bookmark+-lit bookmark+-mac ediff-merg
ediff-wind ediff-diff ediff-mult ediff-help ediff-init ediff-util ediff
realgud realgud-recursive-autoloads realgud-zshdb
realgud:zshdb-track-mode realgud:zshdb-core realgud:zshdb-init
realgud-trepan3k realgud:trepan3k-track-mode realgud:trepan3k-core
realgud:trepan3k-init realgud-trepan2 realgud:trepan2-track-mode
realgud:trepan2-core realgud:trepan2-init realgud-trepanpl
realgud:trepanpl-track-mode realgud:trepanpl-core realgud:trepanpl-init
realgud-trepanjs realgud:trepanjs-track-mode realgud:trepanjs-core
realgud:trepanjs-init realgud-trepan realgud:trepan-track-mode
realgud:trepan-core realgud:trepan-init realgud-remake
realgud:remake-track-mode realgud:remake-core realgud:remake-init
realgud-rdebug realgud-rdebug-track-mode realgud-rdebug-core
realgud-rdebug-init realgud-perldb realgud:perldb-track-mode
realgud:perldb-core realgud:perldb-init realgud-lang-perl realgud-pdb
realgud:pdb-track-mode realgud:pdb-core realgud:pdb-init realgud-nodejs
realgud:nodejs-track-mode realgud:nodejs-core realgud:nodejs-init
realgud-lang-js realgud-kshdb realgud:kshdb-track-mode
realgud:kshdb-core realgud:kshdb-init realgud-jdb realgud:jdb-track-mode
realgud-lang-ruby realgud:jdb-core realgud:jdb-init gud realgud-ipdb
realgud:ipdb-track-mode realgud:ipdb-core realgud:ipdb-init
realgud-lang-python realgud-gub realgud:gub-track-mode realgud:gub-core
realgud:gub-init realgud-gdb realgud:gdb-track-mode realgud:gdb-init
realgud:gdb-core realgud-bashdb realgud:bashdb-track-mode
realgud:bashdb-core realgud:bashdb-init realgud-lang-posix-shell
realgud:run realgud-track-mode realgud-backtrace-mode realgud-track
realgud-shortkey realgud-menu realgud-eval realgud-cmds realgud-send
realgud-window realgud-utils realgud-init realgud-file esh-var esh-io
esh-cmd esh-opt esh-ext esh-proc esh-arg esh-groups eshell esh-module
esh-util esh-mode realgud-core realgud-reset realgud-buffer-helper
realgud-buffer-backtrace realgud-buffer-command realgud-buffer-info
realgud-regexp realgud-lochist the-org-mode-expansions org org-macro
org-footnote org-pcomplete org-list org-faces org-entities noutline
outline org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-src ob-keys ob-comint ob-core ob-eval org-compat org-macs
org-loaddefs cal-menu calendar cal-loaddefs realgud-bp
realgud-bp-image-data realgud-loc realgud-buffer-source realgud-key
realgud-custom key realgud-follow realgud-lang realgud-fringe
realgud-helper test-simple loc-changes load-relative company avy
window-number thing-edit sr-speedbar semantic/db-mode semantic/db
semantic/idle semantic/ctxt semantic/sb semantic/sort semantic/format
semantic/tag-ls semantic/find semantic/util-modes semantic/util semantic
semantic/tag semantic/lex semantic/fw mode-local find-func ede/speedbar
ede/files ede ede/detect ede/base ede/auto ede/source eieio-base
eieio-speedbar speedbar sb-image ezimage dframe eieio-custom cedet
indent-guide helm-gtags pulse ggtags ewoc helm-descbinds helm-mode
helm-files rx image-dired image-mode tramp tramp-compat tramp-loaddefs
trampver ucs-normalize shell pcomplete parse-time format-spec dired-x
dired-aux ffap helm-buffers helm-elscreen helm-tags helm-bookmark
helm-adaptive helm-info info bookmark pp helm-locate helm-grep
helm-regexp helm-external helm-net xml url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf mailcap
helm-utils helm-help helm-types helm helm-source eieio-compat
helm-multi-match helm-lib dired dired-loaddefs helm-config
helm-autoloads helm-easymenu async-bytecomp flymake compile comint
ansi-color auto-complete-config auto-complete popup autopair
fill-column-indicator js2-mode-expansions js2-mode etags xref project
js-mode-expansions js html-mode-expansions sgml-mode subr-x dom json map
seq cc-mode-expansions cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs yasnippet expand-region
text-mode-expansions er-basic-expansions thingatpt expand-region-core
expand-region-custom undo-tree derived edmacro kmacro diff cl
smart-mode-line advice rich-minority speck async bind-key easy-mmode
diminish misearch multi-isearch add-log browse-url url-util url-parse
auth-source cl-seq eieio byte-opt bytecomp byte-compile cl-extra
help-mode cconv eieio-core cl-macs gv eieio-loaddefs password-cache
url-vars server warnings which-func imenu saveplace autorevert
filenotify hl-line elec-pair winner ring paren time-date recentf
tree-widget wid-edit cl-loaddefs pcase cl-lib easymenu mule-util tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote w32notify w32 multi-tty
make-network-process emacs)
Memory information:
((conses 16 793703 34966)
(symbols 56 60903 3)
(miscs 48 166 213)
(strings 32 132076 15794)
(string-bytes 1 4760642)
(vectors 16 81947)
(vector-slots 8 1290395 16246)
(floats 8 1646 412)
(intervals 56 1557 50)
(buffers 976 17))
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Tue, 10 Jan 2017 08:24:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> I suggest either
> to implement this in a "border-width" property when border width
> is set to 0, or to implement a new variable/function that can be set in
> init file, such as for example "no-frame-borders t".
I'm using a frame parameter "undecorated" for this. On Windows it is
handled by the following function in w32fns.c:
void
x_set_undecorated (struct frame *f, Lisp_Object new_value, Lisp_Object old_value)
{
HWND hwnd = FRAME_W32_WINDOW (f);
DWORD dwStyle = GetWindowLong (hwnd, GWL_STYLE);
Lisp_Object border_width = Fcdr (Fassq (Qborder_width, f->param_alist));
block_input ();
if (!NILP (new_value) && !FRAME_UNDECORATED (f))
{
dwStyle = ((dwStyle & ~WS_THICKFRAME & ~WS_CAPTION)
| ((NUMBERP (border_width) && (XINT (border_width) > 0))
? WS_BORDER : false));
SetWindowLong (hwnd, GWL_STYLE, dwStyle);
SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER | SWP_NOACTIVATE
| SWP_FRAMECHANGED);
FRAME_UNDECORATED (f) = true;
}
else if (NILP (new_value) && FRAME_UNDECORATED (f))
{
SetWindowLong (hwnd, GWL_STYLE, dwStyle | WS_THICKFRAME | WS_CAPTION
| WS_MAXIMIZEBOX | WS_MINIMIZEBOX | WS_SYSMENU);
SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER | SWP_NOACTIVATE
| SWP_FRAMECHANGED);
FRAME_UNDECORATED (f) = false;
}
unblock_input ();
}
where FRAME_UNDECORATED (f) returns false if f is currently decorated.
If the `border-width' parameter is 0 the frame gets no border, otherwise
it gets the standard Windows thin-line border.
> Care has to be taken to note that when removing caption bar and borders
> it will be no longer possible to move and resize window unless user
> have other means of performing those applications.
You can use the `left', `top', `width' and `height' frame parameters for
that.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Tue, 10 Jan 2017 17:08:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 10 Jan 2017 09:23:02 +0100
> From: martin rudalics <rudalics <at> gmx.at>
>
> > I suggest either
> > to implement this in a "border-width" property when border width
> > is set to 0, or to implement a new variable/function that can be set in
> > init file, such as for example "no-frame-borders t".
>
> I'm using a frame parameter "undecorated" for this. On Windows it is
> handled by the following function in w32fns.c:
>
> void
> x_set_undecorated (struct frame *f, Lisp_Object new_value, Lisp_Object old_value)
I don't see this in the current sources. Is this your local change?
If so, is there a matching implementation for 'undecorated' on X? Can
both be added to Emacs?
If there's only an implementation of 'undecorated' for MS-Windows, I
suggest to adapt it such that the same effect is produced when
border-width is set to zero. The border-width parameter is already
supported on X, so we will have no problem with that.
WDYT?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Tue, 10 Jan 2017 18:08:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> I don't see this in the current sources. Is this your local change?
Yes.
> If so, is there a matching implementation for 'undecorated' on X? Can
> both be added to Emacs?
There is one for X and a separate one for GTK. All of them work here
but I read that a few X window managers notoriously ignore them. BTW,
the term "undecorated" is derived from gtk_window_set_decorated - just
that our frames are by default decorated so I had to negate it.
> If there's only an implementation of 'undecorated' for MS-Windows, I
> suggest to adapt it such that the same effect is produced when
> border-width is set to zero. The border-width parameter is already
> supported on X, so we will have no problem with that.
As mentioned before I process `border-width' specially on Windows - that
is, I produce the one-pixel wide thin-line border if border-width is a
positive number. X11 allows to specifiy an arbitrary border-width. So
far I haven't been able to produce any border with GTK. But I have
added an option to color the internal border which can then be used in a
uniform manner on all frames.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Tue, 10 Jan 2017 18:29:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 10 Jan 2017 19:07:23 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: arthur.miller.no1 <at> gmail.com, 25408 <at> debbugs.gnu.org
>
> > If so, is there a matching implementation for 'undecorated' on X? Can
> > both be added to Emacs?
>
> There is one for X and a separate one for GTK. All of them work here
> but I read that a few X window managers notoriously ignore them.
Then I suggest to add this to Emacs. That some wm's ignore it is not
a reason to avoid having the feature for those that don't ignore it.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Tue, 10 Jan 2017 19:37:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> I would like to be able to run Emacs without frame decorations on Win
> OS.
We call it "Losedows" or "Lose OS", because if you use it, you lose
your freedom.
We're glad if Emacs gives you a taste of freedom, but a taste is
all it can give you. To escape from Microsoft's power, you need to
stop using Losedows.
Here's what Microsoft does with its unjust power:
http://gnu.org/proprietary/malware-microsoft.html.
Here's explaining what gives Microsoft that unjust power:
http://gnu.org/philosophy/free-software-even-more-important.html.
--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Tue, 10 Jan 2017 20:41:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2017-01-10 13:27, Eli Zaretskii wrote:
> Then I suggest to add this to Emacs. That some wm's ignore it is not
> a reason to avoid having the feature for those that don't ignore it.
Indeed, it would be wonderful!
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 11 Jan 2017 07:09:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
"We call it "Losedows" or "Lose OS", because if you use it, you lose
your freedom.
We're glad if Emacs gives you a taste of freedom, but a taste is
all it can give you. To escape from Microsoft's power, you need to
stop using Losedows."
Haha :-) Indeed.
I do run Arch Linux otherwise, but I do some consulting with programming
databases and GUIs in access & spss and I also play some games
occasionally, so I still need losedows. I know I could run it in wine and
pass through vga, but I feel a bit too old for that :).
This was a great excursion in Emacs src code. I added above mention
method to my w32fns.c, added FRAME_DECORATED() macro to frame.h
a boolean_bf undecorated :1, to frame struct, initiated it to false in
"make_frame"
added an entry to frame_parms: {"undecorated", SYMBOL_INDEX
(Qundecorated)},
added connecction to w32_frame_parm_handlers[] to x_set_undecorated at same
place where symbol is declared in frame_parms (last in the list), added an
INLINE void fset_undecorated( ... ) to frame.h (not sure if it is needed),
and now
I can change my new param with lisp from emacs, but my connection seem
never to be called.
By the way, I think world is better without borders, so I have modified
Martin's
x_set_undecorated to
void
x_set_undecorated (struct frame *f, Lisp_Object new_value, Lisp_Object
old_value)
{
HWND hwnd = FRAME_W32_WINDOW (f);
DWORD dwStyle = GetWindowLong (hwnd, GWL_STYLE);
/*Lisp_Object border_width = Fcdr (Fassq (Qborder_width,
f->param_alist));*/
/*Lisp_Object undecorated = Fcdr (Fassq (Qundecorated, f->param_alist));*/
block_input ();
if (!NILP (new_value) && !FRAME_UNDECORATED (f))
{
dwStyle = (dwStyle & ~WS_THICKFRAME & ~WS_CAPTION);
SetWindowLong (hwnd, GWL_STYLE, dwStyle);
SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER | SWP_NOACTIVATE
| SWP_FRAMECHANGED);
FRAME_UNDECORATED (f) = true;
}
else if (NILP (new_value) && FRAME_UNDECORATED (f))
{
SetWindowLong (hwnd, GWL_STYLE, dwStyle | WS_THICKFRAME | WS_CAPTION
| WS_MAXIMIZEBOX | WS_MINIMIZEBOX | WS_SYSMENU);
SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER | SWP_NOACTIVATE
| SWP_FRAMECHANGED);
FRAME_UNDECORATED (f) = false;
}
unblock_input ();
}
So it should just switch on "undecorated" param and ignore borders (at
least I hope). I am not sure where do
I have to make change more to get it to work.
2017-01-10 21:39 GMT+01:00 Clément Pit--Claudel <clement.pit <at> gmail.com>:
> On 2017-01-10 13:27, Eli Zaretskii wrote:
> > Then I suggest to add this to Emacs. That some wm's ignore it is not
> > a reason to avoid having the feature for those that don't ignore it.
>
> Indeed, it would be wonderful!
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 11 Jan 2017 07:25:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I appologize, I was too fast to answer, I made a bad call from
modify-frame-parameters
when I tested it. It works like a charm as you say it in english. I have
also changed
the else-if statement in Martins method to else if (!NILP (new_value) &&
FRAME_UNDECORATED (f))
(check for !NILP) so I can switch back decorations. It works. Thanks all,
it was great
exercise to learn a bit of emacs internals and to make a simple hack.
2017-01-11 8:08 GMT+01:00 Arthur Miller <arthur.miller.no1 <at> gmail.com>:
> "We call it "Losedows" or "Lose OS", because if you use it, you lose
> your freedom.
>
> We're glad if Emacs gives you a taste of freedom, but a taste is
> all it can give you. To escape from Microsoft's power, you need to
> stop using Losedows."
>
> Haha :-) Indeed.
>
> I do run Arch Linux otherwise, but I do some consulting with programming
> databases and GUIs in access & spss and I also play some games
> occasionally, so I still need losedows. I know I could run it in wine and
> pass through vga, but I feel a bit too old for that :).
>
> This was a great excursion in Emacs src code. I added above mention
> method to my w32fns.c, added FRAME_DECORATED() macro to frame.h
> a boolean_bf undecorated :1, to frame struct, initiated it to false in
> "make_frame"
> added an entry to frame_parms: {"undecorated", SYMBOL_INDEX
> (Qundecorated)},
> added connecction to w32_frame_parm_handlers[] to x_set_undecorated at same
> place where symbol is declared in frame_parms (last in the list), added an
> INLINE void fset_undecorated( ... ) to frame.h (not sure if it is needed),
> and now
> I can change my new param with lisp from emacs, but my connection seem
> never to be called.
>
> By the way, I think world is better without borders, so I have modified
> Martin's
> x_set_undecorated to
>
> void
> x_set_undecorated (struct frame *f, Lisp_Object new_value, Lisp_Object
> old_value)
> {
> HWND hwnd = FRAME_W32_WINDOW (f);
> DWORD dwStyle = GetWindowLong (hwnd, GWL_STYLE);
> /*Lisp_Object border_width = Fcdr (Fassq (Qborder_width,
> f->param_alist));*/
> /*Lisp_Object undecorated = Fcdr (Fassq (Qundecorated,
> f->param_alist));*/
>
> block_input ();
> if (!NILP (new_value) && !FRAME_UNDECORATED (f))
> {
> dwStyle = (dwStyle & ~WS_THICKFRAME & ~WS_CAPTION);
> SetWindowLong (hwnd, GWL_STYLE, dwStyle);
> SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
> SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER | SWP_NOACTIVATE
> | SWP_FRAMECHANGED);
> FRAME_UNDECORATED (f) = true;
> }
> else if (NILP (new_value) && FRAME_UNDECORATED (f))
> {
> SetWindowLong (hwnd, GWL_STYLE, dwStyle | WS_THICKFRAME | WS_CAPTION
> | WS_MAXIMIZEBOX | WS_MINIMIZEBOX | WS_SYSMENU);
> SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
> SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER | SWP_NOACTIVATE
> | SWP_FRAMECHANGED);
> FRAME_UNDECORATED (f) = false;
> }
> unblock_input ();
> }
>
> So it should just switch on "undecorated" param and ignore borders (at
> least I hope). I am not sure where do
> I have to make change more to get it to work.
>
> 2017-01-10 21:39 GMT+01:00 Clément Pit--Claudel <clement.pit <at> gmail.com>:
>
>> On 2017-01-10 13:27, Eli Zaretskii wrote:
>> > Then I suggest to add this to Emacs. That some wm's ignore it is not
>> > a reason to avoid having the feature for those that don't ignore it.
>>
>> Indeed, it would be wonderful!
>>
>>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 11 Jan 2017 07:49:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
There is a slightly cosmetic issue with above function. When one switches
back on decorations,
the frame will not resize properly and minibuffer will be not visible. It's
there but just
covered by frame. Just resizing emacs framefixes it.
Adding call to PostMessage(hwnd, WM_SIZE,0,0) in Martins function fixes it.
void
x_set_undecorated (struct frame *f, Lisp_Object new_value, Lisp_Object
old_value)
{
HWND hwnd = FRAME_W32_WINDOW (f);
DWORD dwStyle = GetWindowLong (hwnd, GWL_STYLE);
/*Lisp_Object border_width = Fcdr (Fassq (Qborder_width,
f->param_alist));*/
/*Lisp_Object undecorated = Fcdr (Fassq (Qundecorated, f->param_alist));*/
block_input ();
if (!NILP (new_value) && !FRAME_UNDECORATED (f))
{
dwStyle = (dwStyle & ~WS_THICKFRAME & ~WS_CAPTION);
SetWindowLong (hwnd, GWL_STYLE, dwStyle);
SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER | SWP_NOACTIVATE
| SWP_FRAMECHANGED);
FRAME_UNDECORATED (f) = true;
}
else if (!NILP (new_value) && FRAME_UNDECORATED (f))
{
SetWindowLong (hwnd, GWL_STYLE, dwStyle | WS_THICKFRAME | WS_CAPTION
| WS_MAXIMIZEBOX | WS_MINIMIZEBOX | WS_SYSMENU);
SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER | SWP_NOACTIVATE
| SWP_FRAMECHANGED);
PostMessage(hwnd, WM_SIZE,0,0);
FRAME_UNDECORATED (f) = false;
}
unblock_input ();
}
2017-01-11 8:24 GMT+01:00 Arthur Miller <arthur.miller.no1 <at> gmail.com>:
> I appologize, I was too fast to answer, I made a bad call from
> modify-frame-parameters
> when I tested it. It works like a charm as you say it in english. I have
> also changed
> the else-if statement in Martins method to else if (!NILP (new_value) &&
> FRAME_UNDECORATED (f))
> (check for !NILP) so I can switch back decorations. It works. Thanks all,
> it was great
> exercise to learn a bit of emacs internals and to make a simple hack.
>
> 2017-01-11 8:08 GMT+01:00 Arthur Miller <arthur.miller.no1 <at> gmail.com>:
>
>> "We call it "Losedows" or "Lose OS", because if you use it, you lose
>> your freedom.
>>
>> We're glad if Emacs gives you a taste of freedom, but a taste is
>> all it can give you. To escape from Microsoft's power, you need to
>> stop using Losedows."
>>
>> Haha :-) Indeed.
>>
>> I do run Arch Linux otherwise, but I do some consulting with programming
>> databases and GUIs in access & spss and I also play some games
>> occasionally, so I still need losedows. I know I could run it in wine and
>> pass through vga, but I feel a bit too old for that :).
>>
>> This was a great excursion in Emacs src code. I added above mention
>> method to my w32fns.c, added FRAME_DECORATED() macro to frame.h
>> a boolean_bf undecorated :1, to frame struct, initiated it to false in
>> "make_frame"
>> added an entry to frame_parms: {"undecorated", SYMBOL_INDEX
>> (Qundecorated)},
>> added connecction to w32_frame_parm_handlers[] to x_set_undecorated at
>> same
>> place where symbol is declared in frame_parms (last in the list), added an
>> INLINE void fset_undecorated( ... ) to frame.h (not sure if it is
>> needed), and now
>> I can change my new param with lisp from emacs, but my connection seem
>> never to be called.
>>
>> By the way, I think world is better without borders, so I have modified
>> Martin's
>> x_set_undecorated to
>>
>> void
>> x_set_undecorated (struct frame *f, Lisp_Object new_value, Lisp_Object
>> old_value)
>> {
>> HWND hwnd = FRAME_W32_WINDOW (f);
>> DWORD dwStyle = GetWindowLong (hwnd, GWL_STYLE);
>> /*Lisp_Object border_width = Fcdr (Fassq (Qborder_width,
>> f->param_alist));*/
>> /*Lisp_Object undecorated = Fcdr (Fassq (Qundecorated,
>> f->param_alist));*/
>>
>> block_input ();
>> if (!NILP (new_value) && !FRAME_UNDECORATED (f))
>> {
>> dwStyle = (dwStyle & ~WS_THICKFRAME & ~WS_CAPTION);
>> SetWindowLong (hwnd, GWL_STYLE, dwStyle);
>> SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
>> SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER |
>> SWP_NOACTIVATE
>> | SWP_FRAMECHANGED);
>> FRAME_UNDECORATED (f) = true;
>> }
>> else if (NILP (new_value) && FRAME_UNDECORATED (f))
>> {
>> SetWindowLong (hwnd, GWL_STYLE, dwStyle | WS_THICKFRAME | WS_CAPTION
>> | WS_MAXIMIZEBOX | WS_MINIMIZEBOX | WS_SYSMENU);
>> SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
>> SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER |
>> SWP_NOACTIVATE
>> | SWP_FRAMECHANGED);
>> FRAME_UNDECORATED (f) = false;
>> }
>> unblock_input ();
>> }
>>
>> So it should just switch on "undecorated" param and ignore borders (at
>> least I hope). I am not sure where do
>> I have to make change more to get it to work.
>>
>> 2017-01-10 21:39 GMT+01:00 Clément Pit--Claudel <clement.pit <at> gmail.com>:
>>
>>> On 2017-01-10 13:27, Eli Zaretskii wrote:
>>> > Then I suggest to add this to Emacs. That some wm's ignore it is not
>>> > a reason to avoid having the feature for those that don't ignore it.
>>>
>>> Indeed, it would be wonderful!
>>>
>>>
>>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 11 Jan 2017 07:51:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Aha, my last message ended somehow in bad spot in message tree. I
appologize for inconvenience.
2017-01-11 8:48 GMT+01:00 Arthur Miller <arthur.miller.no1 <at> gmail.com>:
> There is a slightly cosmetic issue with above function. When one switches
> back on decorations,
> the frame will not resize properly and minibuffer will be not visible.
> It's there but just
> covered by frame. Just resizing emacs framefixes it.
>
> Adding call to PostMessage(hwnd, WM_SIZE,0,0) in Martins function fixes it.
>
> void
> x_set_undecorated (struct frame *f, Lisp_Object new_value, Lisp_Object
> old_value)
> {
> HWND hwnd = FRAME_W32_WINDOW (f);
> DWORD dwStyle = GetWindowLong (hwnd, GWL_STYLE);
> /*Lisp_Object border_width = Fcdr (Fassq (Qborder_width,
> f->param_alist));*/
> /*Lisp_Object undecorated = Fcdr (Fassq (Qundecorated,
> f->param_alist));*/
>
> block_input ();
> if (!NILP (new_value) && !FRAME_UNDECORATED (f))
> {
> dwStyle = (dwStyle & ~WS_THICKFRAME & ~WS_CAPTION);
> SetWindowLong (hwnd, GWL_STYLE, dwStyle);
> SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
> SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER | SWP_NOACTIVATE
> | SWP_FRAMECHANGED);
> FRAME_UNDECORATED (f) = true;
> }
> else if (!NILP (new_value) && FRAME_UNDECORATED (f))
> {
> SetWindowLong (hwnd, GWL_STYLE, dwStyle | WS_THICKFRAME | WS_CAPTION
> | WS_MAXIMIZEBOX | WS_MINIMIZEBOX | WS_SYSMENU);
> SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
> SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER | SWP_NOACTIVATE
> | SWP_FRAMECHANGED);
> PostMessage(hwnd, WM_SIZE,0,0);
> FRAME_UNDECORATED (f) = false;
> }
> unblock_input ();
> }
>
>
> 2017-01-11 8:24 GMT+01:00 Arthur Miller <arthur.miller.no1 <at> gmail.com>:
>
>> I appologize, I was too fast to answer, I made a bad call from
>> modify-frame-parameters
>> when I tested it. It works like a charm as you say it in english. I have
>> also changed
>> the else-if statement in Martins method to else if (!NILP (new_value) &&
>> FRAME_UNDECORATED (f))
>> (check for !NILP) so I can switch back decorations. It works. Thanks all,
>> it was great
>> exercise to learn a bit of emacs internals and to make a simple hack.
>>
>> 2017-01-11 8:08 GMT+01:00 Arthur Miller <arthur.miller.no1 <at> gmail.com>:
>>
>>> "We call it "Losedows" or "Lose OS", because if you use it, you lose
>>> your freedom.
>>>
>>> We're glad if Emacs gives you a taste of freedom, but a taste is
>>> all it can give you. To escape from Microsoft's power, you need to
>>> stop using Losedows."
>>>
>>> Haha :-) Indeed.
>>>
>>> I do run Arch Linux otherwise, but I do some consulting with programming
>>> databases and GUIs in access & spss and I also play some games
>>> occasionally, so I still need losedows. I know I could run it in wine
>>> and
>>> pass through vga, but I feel a bit too old for that :).
>>>
>>> This was a great excursion in Emacs src code. I added above mention
>>> method to my w32fns.c, added FRAME_DECORATED() macro to frame.h
>>> a boolean_bf undecorated :1, to frame struct, initiated it to false in
>>> "make_frame"
>>> added an entry to frame_parms: {"undecorated", SYMBOL_INDEX
>>> (Qundecorated)},
>>> added connecction to w32_frame_parm_handlers[] to x_set_undecorated at
>>> same
>>> place where symbol is declared in frame_parms (last in the list), added
>>> an
>>> INLINE void fset_undecorated( ... ) to frame.h (not sure if it is
>>> needed), and now
>>> I can change my new param with lisp from emacs, but my connection seem
>>> never to be called.
>>>
>>> By the way, I think world is better without borders, so I have modified
>>> Martin's
>>> x_set_undecorated to
>>>
>>> void
>>> x_set_undecorated (struct frame *f, Lisp_Object new_value, Lisp_Object
>>> old_value)
>>> {
>>> HWND hwnd = FRAME_W32_WINDOW (f);
>>> DWORD dwStyle = GetWindowLong (hwnd, GWL_STYLE);
>>> /*Lisp_Object border_width = Fcdr (Fassq (Qborder_width,
>>> f->param_alist));*/
>>> /*Lisp_Object undecorated = Fcdr (Fassq (Qundecorated,
>>> f->param_alist));*/
>>>
>>> block_input ();
>>> if (!NILP (new_value) && !FRAME_UNDECORATED (f))
>>> {
>>> dwStyle = (dwStyle & ~WS_THICKFRAME & ~WS_CAPTION);
>>> SetWindowLong (hwnd, GWL_STYLE, dwStyle);
>>> SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
>>> SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER |
>>> SWP_NOACTIVATE
>>> | SWP_FRAMECHANGED);
>>> FRAME_UNDECORATED (f) = true;
>>> }
>>> else if (NILP (new_value) && FRAME_UNDECORATED (f))
>>> {
>>> SetWindowLong (hwnd, GWL_STYLE, dwStyle | WS_THICKFRAME |
>>> WS_CAPTION
>>> | WS_MAXIMIZEBOX | WS_MINIMIZEBOX | WS_SYSMENU);
>>> SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
>>> SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER |
>>> SWP_NOACTIVATE
>>> | SWP_FRAMECHANGED);
>>> FRAME_UNDECORATED (f) = false;
>>> }
>>> unblock_input ();
>>> }
>>>
>>> So it should just switch on "undecorated" param and ignore borders (at
>>> least I hope). I am not sure where do
>>> I have to make change more to get it to work.
>>>
>>> 2017-01-10 21:39 GMT+01:00 Clément Pit--Claudel <clement.pit <at> gmail.com>:
>>>
>>>> On 2017-01-10 13:27, Eli Zaretskii wrote:
>>>> > Then I suggest to add this to Emacs. That some wm's ignore it is not
>>>> > a reason to avoid having the feature for those that don't ignore it.
>>>>
>>>> Indeed, it would be wonderful!
>>>>
>>>>
>>>
>>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 11 Jan 2017 08:16:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I am beggin of pardon, but I found that sometimes, just sometimes, even
switching
decorations on leaves some cosmetic issues. I took a screenshot and upload
it to
imgur: http://imgur.com/a/kCW8j . It is same issue as with putting
decorations on.
Adding that PostMessage to send wm_size after the if-else statement solves
it in
all cases.
2017-01-11 8:50 GMT+01:00 Arthur Miller <arthur.miller.no1 <at> gmail.com>:
> Aha, my last message ended somehow in bad spot in message tree. I
> appologize for inconvenience.
>
> 2017-01-11 8:48 GMT+01:00 Arthur Miller <arthur.miller.no1 <at> gmail.com>:
>
>> There is a slightly cosmetic issue with above function. When one switches
>> back on decorations,
>> the frame will not resize properly and minibuffer will be not visible.
>> It's there but just
>> covered by frame. Just resizing emacs framefixes it.
>>
>> Adding call to PostMessage(hwnd, WM_SIZE,0,0) in Martins function fixes
>> it.
>>
>> void
>> x_set_undecorated (struct frame *f, Lisp_Object new_value, Lisp_Object
>> old_value)
>> {
>> HWND hwnd = FRAME_W32_WINDOW (f);
>> DWORD dwStyle = GetWindowLong (hwnd, GWL_STYLE);
>> /*Lisp_Object border_width = Fcdr (Fassq (Qborder_width,
>> f->param_alist));*/
>> /*Lisp_Object undecorated = Fcdr (Fassq (Qundecorated,
>> f->param_alist));*/
>>
>> block_input ();
>> if (!NILP (new_value) && !FRAME_UNDECORATED (f))
>> {
>> dwStyle = (dwStyle & ~WS_THICKFRAME & ~WS_CAPTION);
>> SetWindowLong (hwnd, GWL_STYLE, dwStyle);
>> SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
>> SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER |
>> SWP_NOACTIVATE
>> | SWP_FRAMECHANGED);
>> FRAME_UNDECORATED (f) = true;
>> }
>> else if (!NILP (new_value) && FRAME_UNDECORATED (f))
>> {
>> SetWindowLong (hwnd, GWL_STYLE, dwStyle | WS_THICKFRAME | WS_CAPTION
>> | WS_MAXIMIZEBOX | WS_MINIMIZEBOX | WS_SYSMENU);
>> SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
>> SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER |
>> SWP_NOACTIVATE
>> | SWP_FRAMECHANGED);
>> PostMessage(hwnd, WM_SIZE,0,0);
>> FRAME_UNDECORATED (f) = false;
>> }
>> unblock_input ();
>> }
>>
>>
>> 2017-01-11 8:24 GMT+01:00 Arthur Miller <arthur.miller.no1 <at> gmail.com>:
>>
>>> I appologize, I was too fast to answer, I made a bad call from
>>> modify-frame-parameters
>>> when I tested it. It works like a charm as you say it in english. I have
>>> also changed
>>> the else-if statement in Martins method to else if (!NILP (new_value) &&
>>> FRAME_UNDECORATED (f))
>>> (check for !NILP) so I can switch back decorations. It works. Thanks
>>> all, it was great
>>> exercise to learn a bit of emacs internals and to make a simple hack.
>>>
>>> 2017-01-11 8:08 GMT+01:00 Arthur Miller <arthur.miller.no1 <at> gmail.com>:
>>>
>>>> "We call it "Losedows" or "Lose OS", because if you use it, you lose
>>>> your freedom.
>>>>
>>>> We're glad if Emacs gives you a taste of freedom, but a taste is
>>>> all it can give you. To escape from Microsoft's power, you need to
>>>> stop using Losedows."
>>>>
>>>> Haha :-) Indeed.
>>>>
>>>> I do run Arch Linux otherwise, but I do some consulting with
>>>> programming
>>>> databases and GUIs in access & spss and I also play some games
>>>> occasionally, so I still need losedows. I know I could run it in wine
>>>> and
>>>> pass through vga, but I feel a bit too old for that :).
>>>>
>>>> This was a great excursion in Emacs src code. I added above mention
>>>> method to my w32fns.c, added FRAME_DECORATED() macro to frame.h
>>>> a boolean_bf undecorated :1, to frame struct, initiated it to false in
>>>> "make_frame"
>>>> added an entry to frame_parms: {"undecorated", SYMBOL_INDEX
>>>> (Qundecorated)},
>>>> added connecction to w32_frame_parm_handlers[] to x_set_undecorated at
>>>> same
>>>> place where symbol is declared in frame_parms (last in the list), added
>>>> an
>>>> INLINE void fset_undecorated( ... ) to frame.h (not sure if it is
>>>> needed), and now
>>>> I can change my new param with lisp from emacs, but my connection seem
>>>> never to be called.
>>>>
>>>> By the way, I think world is better without borders, so I have modified
>>>> Martin's
>>>> x_set_undecorated to
>>>>
>>>> void
>>>> x_set_undecorated (struct frame *f, Lisp_Object new_value, Lisp_Object
>>>> old_value)
>>>> {
>>>> HWND hwnd = FRAME_W32_WINDOW (f);
>>>> DWORD dwStyle = GetWindowLong (hwnd, GWL_STYLE);
>>>> /*Lisp_Object border_width = Fcdr (Fassq (Qborder_width,
>>>> f->param_alist));*/
>>>> /*Lisp_Object undecorated = Fcdr (Fassq (Qundecorated,
>>>> f->param_alist));*/
>>>>
>>>> block_input ();
>>>> if (!NILP (new_value) && !FRAME_UNDECORATED (f))
>>>> {
>>>> dwStyle = (dwStyle & ~WS_THICKFRAME & ~WS_CAPTION);
>>>> SetWindowLong (hwnd, GWL_STYLE, dwStyle);
>>>> SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
>>>> SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER |
>>>> SWP_NOACTIVATE
>>>> | SWP_FRAMECHANGED);
>>>> FRAME_UNDECORATED (f) = true;
>>>> }
>>>> else if (NILP (new_value) && FRAME_UNDECORATED (f))
>>>> {
>>>> SetWindowLong (hwnd, GWL_STYLE, dwStyle | WS_THICKFRAME |
>>>> WS_CAPTION
>>>> | WS_MAXIMIZEBOX | WS_MINIMIZEBOX | WS_SYSMENU);
>>>> SetWindowPos (hwnd, HWND_TOP, 0, 0, 0, 0,
>>>> SWP_NOSIZE | SWP_NOMOVE | SWP_NOZORDER |
>>>> SWP_NOACTIVATE
>>>> | SWP_FRAMECHANGED);
>>>> FRAME_UNDECORATED (f) = false;
>>>> }
>>>> unblock_input ();
>>>> }
>>>>
>>>> So it should just switch on "undecorated" param and ignore borders (at
>>>> least I hope). I am not sure where do
>>>> I have to make change more to get it to work.
>>>>
>>>> 2017-01-10 21:39 GMT+01:00 Clément Pit--Claudel <clement.pit <at> gmail.com>
>>>> :
>>>>
>>>>> On 2017-01-10 13:27, Eli Zaretskii wrote:
>>>>> > Then I suggest to add this to Emacs. That some wm's ignore it is not
>>>>> > a reason to avoid having the feature for those that don't ignore it.
>>>>>
>>>>> Indeed, it would be wonderful!
>>>>>
>>>>>
>>>>
>>>
>>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 11 Jan 2017 08:39:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> added an
> INLINE void fset_undecorated( ... ) to frame.h (not sure if it is
> needed
It's only needed for Lisp_Object components.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 11 Jan 2017 08:40:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> There is a slightly cosmetic issue with above function. When one switches
> back on decorations,
> the frame will not resize properly and minibuffer will be not visible. It's
> there but just
> covered by frame. Just resizing emacs framefixes it.
>
> Adding call to PostMessage(hwnd, WM_SIZE,0,0) in Martins function fixes it.
This is not necessary here. And it would be strange since the idea is
that the outer frame size remains unchanged. Hence, any problem would
manifest itself already when you remove the borders by leaving parts of
the display area reserved for the frame not redrawn.
The image you posted in the message you sent just now seems to confirm
that.
But I'm testing this on Windows XP and have not yet pulled the recent
multi-thread Emacs changes.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 11 Jan 2017 09:19:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I took screenshot of just one version, it was problem with both on/off, at
least on my machine.
Just posting wm_size message after the change in your function solves
issues in both cases for me.
2017-01-11 9:39 GMT+01:00 martin rudalics <rudalics <at> gmx.at>:
> > There is a slightly cosmetic issue with above function. When one switches
> > back on decorations,
> > the frame will not resize properly and minibuffer will be not visible.
> It's
> > there but just
> > covered by frame. Just resizing emacs framefixes it.
> >
> > Adding call to PostMessage(hwnd, WM_SIZE,0,0) in Martins function fixes
> it.
>
> This is not necessary here. And it would be strange since the idea is
> that the outer frame size remains unchanged. Hence, any problem would
> manifest itself already when you remove the borders by leaving parts of
> the display area reserved for the frame not redrawn.
>
> The image you posted in the message you sent just now seems to confirm
> that.
>
> But I'm testing this on Windows XP and have not yet pulled the recent
> multi-thread Emacs changes.
>
> martin
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 11 Jan 2017 10:21:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I have a small question: how do I make this take effect in my init file
when I run in server/client mode?
Seems like my client always insist on creating frames around emacs window,
while when I run
emacs "standalone" (for ex emacs --debug-init) it starts undecorated. I
have tried following in my
.emacs:
(add-to-list 'default-frame-alist '(undecorated . 0))
(setq default-frame-alist '((undecorated . 0)))
(setq initial-frame-alist '((undecorated . 0)))
But that does not give any effect at all.
I have following to switch off/on decorations interactively:
(defvar decor 0)
(defun toggle-frame-decor ()
(interactive)
(progn
(modify-frame-parameters (selected-frame) `((undecorated . ,'decor)))
(if (= decor 0)
(setq decor 1)
(setq decor 0))))
(global-set-key [f9] 'toggle-frame-decor)
If I place call to
(toggle-frame-decor)
in .emacs than it works for non-server mode, but not when I run emacsclient
(which I do normally always). I tried to force loading .emacs when severs
starts
with -l ~/.emacs switch, but it didn't worked either.
I admit I am just very uneducated about emacs & elisp and would really
appreciate if a nice
soul could help with my poor education.
2017-01-11 10:17 GMT+01:00 Arthur Miller <arthur.miller.no1 <at> gmail.com>:
> I took screenshot of just one version, it was problem with both on/off, at
> least on my machine.
>
> Just posting wm_size message after the change in your function solves
> issues in both cases for me.
>
> 2017-01-11 9:39 GMT+01:00 martin rudalics <rudalics <at> gmx.at>:
>
>> > There is a slightly cosmetic issue with above function. When one
>> switches
>> > back on decorations,
>> > the frame will not resize properly and minibuffer will be not visible.
>> It's
>> > there but just
>> > covered by frame. Just resizing emacs framefixes it.
>> >
>> > Adding call to PostMessage(hwnd, WM_SIZE,0,0) in Martins function fixes
>> it.
>>
>> This is not necessary here. And it would be strange since the idea is
>> that the outer frame size remains unchanged. Hence, any problem would
>> manifest itself already when you remove the borders by leaving parts of
>> the display area reserved for the frame not redrawn.
>>
>> The image you posted in the message you sent just now seems to confirm
>> that.
>>
>> But I'm testing this on Windows XP and have not yet pulled the recent
>> multi-thread Emacs changes.
>>
>> martin
>>
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 11 Jan 2017 13:51:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
By fthe way, if you want me I can send patch with my changes, but I guess Martin will provide better working code than I, and I have slightly different opinion about borders (I don't care abiut them at all).
Skickat från min Samsung-enhet
-------- Originalmeddelande --------
Från: martin rudalics <rudalics <at> gmx.at>
Datum: 2017-01-11 09:39 (GMT+01:00)
Till: Arthur Miller <arthur.miller.no1 <at> gmail.com>, Clément Pit--Claudel <clement.pit <at> gmail.com>
Kopia: Eli Zaretskii <eliz <at> gnu.org>, 25408 <at> debbugs.gnu.org
Rubrik: Re: bug#25408: Remove Decorations Around Emacs Frame (Windows OS)
> There is a slightly cosmetic issue with above function. When one switches
> back on decorations,
> the frame will not resize properly and minibuffer will be not visible. It's
> there but just
> covered by frame. Just resizing emacs framefixes it.
>
> Adding call to PostMessage(hwnd, WM_SIZE,0,0) in Martins function fixes it.
This is not necessary here. And it would be strange since the idea is
that the outer frame size remains unchanged. Hence, any problem would
manifest itself already when you remove the borders by leaving parts of
the display area reserved for the frame not redrawn.
The image you posted in the message you sent just now seems to confirm
that.
But I'm testing this on Windows XP and have not yet pulled the recent
multi-thread Emacs changes.
martin
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 11 Jan 2017 13:56:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> (add-to-list 'default-frame-alist '(undecorated . 0))
> (setq default-frame-alist '((undecorated . 0)))
> (setq initial-frame-alist '((undecorated . 0)))
>
> But that does not give any effect at all.
"0" is a quite misleading value ;-) See below.
But I think I understand what happens. In fact, I haven't told you the
whole story: In Fx_create_frame I do additionally
tem = x_get_arg (dpyinfo, parameters, Qundecorated, NULL, NULL,
RES_TYPE_BOOLEAN);
FRAME_UNDECORATED (f) = !NILP (tem) && !EQ (tem, Qunbound);
store_frame_param (f, Qundecorated, FRAME_UNDECORATED (f) ? Qt : Qnil);
somewhere _before_ w32_window (f, window_prompting, minibuffer_only)
gets called. And in w32_createwindow I have
else if (FRAME_UNDECORATED (f))
{
f->output_data.w32->dwStyle = ~WS_THICKFRAME & ~WS_CAPTION;
/* If we want a thin border, specify it here. */
if (NUMBERP (border_width) && (XINT (border_width) > 0))
f->output_data.w32->dwStyle =
f->output_data.w32->dwStyle | WS_BORDER;
}
before any other f->output_data.w32->dwStyle assignment and certainly
before the
FRAME_W32_WINDOW (f) = hwnd
= CreateWindow (EMACS_CLASS,
f->namebuf,
f->output_data.w32->dwStyle,
...
call. Just make sure that any time you set f->output_data.w32->dwStyle
you don't overrule a previous assignment. (I haven't sent you a patch
because I have completely redesigned the assignments to this component
and it probably would distract more than provide any help.) This way
(add-to-list 'default-frame-alist '(undecorated . t))
(setq default-frame-alist '((undecorated . t)))
(setq initial-frame-alist '((undecorated . t)))
should all work.
BTW, you can also do
f->output_data.w32->dwStyle = WS_POPUP;
because the only thing Windows forbids in this context is to set
WS_POPUP for an existing overlapped window (IIRC).
> (defvar decor 0)
> (defun toggle-frame-decor ()
> (interactive)
> (progn
> (modify-frame-parameters (selected-frame) `((undecorated . ,'decor)))
You likely mean
(modify-frame-parameters (selected-frame) `((undecorated . ,decor)))
here. And probably you want to do the following calculation
> (if (= decor 0)
> (setq decor 1)
> (setq decor 0))))
before calling ‘modify-frame-parameters’ so the latter will see the new
value. But even this won't work because you want to toggle beween nil
and non-nil so
(devfar decor nil)
and
(setq decor (not decor))
are more appropriate.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 11 Jan 2017 13:58:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> By fthe way, if you want me I can send patch with my changes, but I
> guess Martin will provide better working code than I, and I have
> slightly different opinion about borders (I don't care abiut them at
> all).
To not get a border, set the frame parameter `border-width' to zero.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 11 Jan 2017 15:01:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Aha thanks for clarifications. I didn't dive enough into src so I missed those other funcrions called before a frame is made.
I had from beginnig nil and t as values for my decor var, but I realized I could use 1 and 0 too so I did :). It works fine to switch it off/on manually.
I am away from home untill friday so it will have to wait before I can play more with emacs. Also if you going to merge your code into master on git soon, then I will probably abandon my changes and use yours :).
Skickat från min Samsung-enhet
-------- Originalmeddelande --------
Från: martin rudalics <rudalics <at> gmx.at>
Datum: 2017-01-11 14:55 (GMT+01:00)
Till: Arthur Miller <arthur.miller.no1 <at> gmail.com>
Kopia: Clément Pit--Claudel <clement.pit <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, 25408 <at> debbugs.gnu.org
Rubrik: Re: bug#25408: Remove Decorations Around Emacs Frame (Windows OS)
> (add-to-list 'default-frame-alist '(undecorated . 0))
> (setq default-frame-alist '((undecorated . 0)))
> (setq initial-frame-alist '((undecorated . 0)))
>
> But that does not give any effect at all.
"0" is a quite misleading value ;-) See below.
But I think I understand what happens. In fact, I haven't told you the
whole story: In Fx_create_frame I do additionally
tem = x_get_arg (dpyinfo, parameters, Qundecorated, NULL, NULL,
RES_TYPE_BOOLEAN);
FRAME_UNDECORATED (f) = !NILP (tem) && !EQ (tem, Qunbound);
store_frame_param (f, Qundecorated, FRAME_UNDECORATED (f) ? Qt : Qnil);
somewhere _before_ w32_window (f, window_prompting, minibuffer_only)
gets called. And in w32_createwindow I have
else if (FRAME_UNDECORATED (f))
{
f->output_data.w32->dwStyle = ~WS_THICKFRAME & ~WS_CAPTION;
/* If we want a thin border, specify it here. */
if (NUMBERP (border_width) && (XINT (border_width) > 0))
f->output_data.w32->dwStyle =
f->output_data.w32->dwStyle | WS_BORDER;
}
before any other f->output_data.w32->dwStyle assignment and certainly
before the
FRAME_W32_WINDOW (f) = hwnd
= CreateWindow (EMACS_CLASS,
f->namebuf,
f->output_data.w32->dwStyle,
...
call. Just make sure that any time you set f->output_data.w32->dwStyle
you don't overrule a previous assignment. (I haven't sent you a patch
because I have completely redesigned the assignments to this component
and it probably would distract more than provide any help.) This way
(add-to-list 'default-frame-alist '(undecorated . t))
(setq default-frame-alist '((undecorated . t)))
(setq initial-frame-alist '((undecorated . t)))
should all work.
BTW, you can also do
f->output_data.w32->dwStyle = WS_POPUP;
because the only thing Windows forbids in this context is to set
WS_POPUP for an existing overlapped window (IIRC).
> (defvar decor 0)
> (defun toggle-frame-decor ()
> (interactive)
> (progn
> (modify-frame-parameters (selected-frame) `((undecorated . ,'decor)))
You likely mean
(modify-frame-parameters (selected-frame) `((undecorated . ,decor)))
here. And probably you want to do the following calculation
> (if (= decor 0)
> (setq decor 1)
> (setq decor 0))))
before calling ‘modify-frame-parameters’ so the latter will see the new
value. But even this won't work because you want to toggle beween nil
and non-nil so
(devfar decor nil)
and
(setq decor (not decor))
are more appropriate.
martin
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 11 Jan 2017 16:40:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> I do run Arch Linux otherwise, but I do some consulting with programming
> databases and GUIs in access & spss and I also play some games
> occasionally, so I still need losedows.
1. If I were you, I would stop doing those jobs and stop running those
games, for my freedom's sake. Not only is Losedows proprietary, but
also Access, SPSS and those games. Each one of them does injustice
to whoever runs it.
See https://gnu.org/philosophy/free-software-even-more-important.html.
2. The name "Arch Linux" is a misnomer. It is a variant of the
GNU/Linux system, so in fairness it should be called "Arch GNU/Linux".
We can't make them fix that mistake, but we can choose to not to
repeat it -- so let's call it "Arch GNU/Linux".
3. That distro is not entirely free software.
See https://gnu.org/distros.
4. Thanks for helping development of GNU Emacs.
--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Tue, 07 Feb 2017 05:29:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2017-01-11 03:39, martin rudalics wrote:
> But I'm testing this on Windows XP and have not yet pulled the recent
> multi-thread Emacs changes.
Hey Martin,
Are your changes available in a branch of the repo? I'd be very happy to test them, and some modes like company-mode would benefit significantly (I tried to tackle this in "Could x-show-tip be reimplemented in Elisp? How does one create borderless frames from Elisp?" a while ago).
Thanks a lot!
Clément.
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Tue, 07 Feb 2017 06:54:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> Are your changes available in a branch of the repo?
No. But I hope that I can post a patch by the end of this week.
> I'd be very happy
> to test them, and some modes like company-mode would benefit
> significantly (I tried to tackle this in "Could x-show-tip be
> reimplemented in Elisp? How does one create borderless frames from
> Elisp?" a while ago).
Creating borderless frames and giving them back their border is fairly
trivial. The greater problem is how to synchronize the behavior of such
a frame with that of another one (moving, sizing, focusing, restacking
and the like) and do that consistently across our windows systems.
I've practically solved all these problems but am not yet sure whether
the issue I found in "A GTK-only problem when making frames invisible"
could have a detrimental impact.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Tue, 07 Feb 2017 13:07:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2017-02-07 01:53, martin rudalics wrote:
>> Are your changes available in a branch of the repo?
>
> No. But I hope that I can post a patch by the end of this week.
Great, thanks a lot!
>> I'd be very happy
>> to test them, and some modes like company-mode would benefit
>> significantly (I tried to tackle this in "Could x-show-tip be
>> reimplemented in Elisp? How does one create borderless frames from
>> Elisp?" a while ago).
>
> Creating borderless frames and giving them back their border is fairly
> trivial. The greater problem is how to synchronize the behavior of such
> a frame with that of another one (moving, sizing, focusing, restacking
> and the like) and do that consistently across our windows systems.
>
> I've practically solved all these problems but am not yet sure whether
> the issue I found in "A GTK-only problem when making frames invisible"
> could have a detrimental impact.
Ok; thanks for the clarification!
I'm excited about this feature :)
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sat, 11 Feb 2017 14:28:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>> Are your changes available in a branch of the repo?
>>
>> No. But I hope that I can post a patch by the end of this week.
>
> Great, thanks a lot!
If you are on GNU/Linux or Windows then please apply the attached patch
synch-frames.diff to your current version of master and rebuild. If you
succeeded doing that, start emacs -Q and continue reading.
To remove a frame's decorations, use the frame parameter `undecorated'
as in
(set-frame-parameter nil 'undecorated t)
To give that frame back its decorations use
(set-frame-parameter nil 'undecorated nil)
To make a new frame undecorated use
(make-frame '((undecorated . t)))
To make frames undecorated by default add something like
(custom-set-variables
'(default-frame-alist '((undecorated . t))))
to your .emacs. If everything works as intended and your only interest
was to make frames without decorations, you can finish reading here.
If you didn't succeed removing a frame's decorations and you are on
GNU/Linux, you're window manager probably doesn't honor the Motif window
manager hints. Please post the types of your build and window manager.
At the very least we can provide a list of the window managers that
don't comply. Windows users might experience problems on anything past
XP, I've only tested it there.
Usually, the position of a frame's native rectangle doesn't change when
adding/removing decorations. If you want to change it, use the `left'
and `top' frame parameters.
If you think you need to remove/add individual parts of the decorations
(titlebar, buttons, external borders) post your wishes here. Some
window managers might be able to do that.
The rest of this text is concerned with describing additional features.
If some of them don't work on your system, please tell me, usually they
need a compliant window manager as well.
A first group of parameters is concerned with focusing/switching to
certain frames. To make a frame not show up on the taskbar use the
frame parameter `skip-taskbar' as in
(set-frame-parameter nil 'skip-taskbar t)
This should remove your frame's icon from the taskbar and also disable
the <Alt>-<Tab> functionality to switch to that frame. On some systems
(notably Windows) iconifying such a frame may "roll in" its window at
the bottom of the desktop.
To make a new frame not receive focus initially or when deiconified, use
the frame parameter `no-focus-on-map' as in
(make-frame '((no-focus-on-map . t)))
Usually this works but if you are using a focus follows mouse policy you
might have to specify the `no-accept-focus' parameter as well as in
(make-frame '((no-focus-on-map . t) (no-accept-focus . t)))
The `no-accept-focus' parameter, if non-nil, tries to never give the
frame focus in a "soft" way. Development might not be entirely complete
in this area.
If you want to avoid that C-x 5 o switches to a specific frame, set
that frame's `no-other-frame' parameter as in
(set-frame-parameter nil 'no-other-frame t)
Using a clever combination of the `skip-taskbar', `no-focus-on-map',
`no-accept-focus' and `no-other-frame' you might be able to make a
completely catatonic frame which you can kill only with your task
manager.
If you want to make sure that a specific frame is deleted whenever
another frame is deleted use the `delete-before' parameter. This avoids
confusing Emacs as, for example, when putting `delete-frame' on
`delete-frame-functions'.
To make a frame as small as possible use the `min-width' and
`min-height' parameters. Evaluating
(let ((frame (make-frame
`((tool-bar-lines . 0)
(menu-bar-lines . 0)
(vertical-scroll-bars . nil)
(horizontal-scroll-bars . nil)
(minibuffer . ,(minibuffer-window (selected-frame)))
(left-fringe . 0)
(right-fringe . 0)
(background-color . "yellow")
(undecorated . t)
(border-width . 0)
(width . 1)
(height . 1)
(left . ,(frame-parameter nil 'left))
(top . ,(frame-parameter nil 'top))
(min-width . 0)
(min-height . 0)
(delete-before . ,(selected-frame)))))
(buffer (get-buffer-create "*x*")))
(set-window-buffer (frame-root-window frame) buffer)
(with-current-buffer buffer
(setq mode-line-format nil)))
should give you a blinking cursor at the top left corner of your
selected frame.
The `mouse-wheel-frame' allows to specify mouse wheel scroll
transparency wrt the frame below this one. Use it as in
(make-frame `((undecorated . t)
(no-accept-focus . t)
(mouse-wheel-frame . ,(selected-frame))
(left . ,(/ (frame-pixel-width) 4))
(top . ,(/ (frame-pixel-height) 4))
(width . ,(/ (frame-width) 2))
(height . ,(/ (frame-height) 2))))
Mouse wheel scrolling the window in the new frame should now scroll the
underlying window of the initial frame instead. I'm not sure whether I
will implement mouse click (aka "hit") transparency in a similar way.
A second group of parameters/functions is concerned with maintaining and
investigating the stacking order of frames. The `z-group' parameter
allows to put a frame in a separate group above or (not on Windows)
below all other frames that are not in the same group. For example
(set-frame-parameter nil 'z-group 'above)
will make your frame (semi-)permanently appear above all other windows
on your desktop (including the task bar). The implementation of this
parameter is not entirely complete yet, it's easily possible that I will
replace it by a simple function. My window manager apparently removes
this property when the frame is iconified so I cannot always rely on
it.
Also a frame with this parameter equalling `above' currently appears
above dialogue windows (to select files or fonts). This will be fixed
soon but I'm not yet sure how.
`frame-restack' already is a function. To test it try to play around
with the following forms:
(setq sframe (selected-frame))
(setq nframe (make-frame))
(frame-restack nframe sframe)
(frame-restack sframe nframe)
(frame-restack nframe sframe t)
(frame-restack sframe nframe t)
The function `frame-list-z-order' returns a list of your frames in the
stacking order of your display - bottommost first.
A final group of parameters/functions is concerned with making child
frames. To make a frame a child frame of an existing frame you can use
something like
(set-frame-parameter nil 'parent-frame frame)
where `frame' must be a live frame. This should work as in the
following form
(make-frame `((parent-frame . ,(selected-frame))
(undecorated . t)
(no-accept-focus . t)
(mouse-wheel-frame . ,(selected-frame))
(left . ,(/ (frame-pixel-width) 4))
(top . ,(/ (frame-pixel-height) 4))
(width . ,(/ (frame-width) 2))
(height . ,(/ (frame-height) 2))))
Note that child frames automatically move and (de-)iconify together with
their parent frame without any further intervention from Emacs.
Moreover they are clipped automatically at the borders of their parent.
For normal (non-child) frames there's a new hook `move-frame-functions'
called after a frame was moved so you can also synchronize the movements
of two top-level frames.
Child frames are not listed by `frame-list' but are listed by
`frame-list-z-order'. `frame-child-frames' lists all child frames of a
specific frame.
On GTK neither child frames nor undecorated frames can get a border. If
you want a unified-looking border on any system you can use the new face
`internal-border' and set the frame parameter ‘internal-border-width’ to
some non-zero value for any such frame.
If the functions/parameters described here work sufficiently well, I'll
post a number of toy algorithms that show how to synchronize two frames
in a way that always shows one frame at a specified position on top of
the other.
The current version comes without info and frameset support. I hope
that Juanma can help me with the latter.
martin
[synch-frames.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sat, 11 Feb 2017 21:03:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 2017-02-11 09:27, martin rudalics wrote:
> If you are on GNU/Linux or Windows then please apply the attached patch
> synch-frames.diff to your current version of master and rebuild. If you
> succeeded doing that, start emacs -Q and continue reading.
Thanks! The patch applied cleanly and everything compiled fine.
> To remove a frame's decorations, use the frame parameter `undecorated'
This works great.
> To make a new frame undecorated use
> (make-frame '((undecorated . t)))
This works great too.
> If everything works as intended and your only interest
> was to make frames without decorations, you can finish reading here.
Everything up to that point worked great :)
> Usually, the position of a frame's native rectangle doesn't change when
> adding/removing decorations. If you want to change it, use the `left'
> and `top' frame parameters.
That works fine.
> If you think you need to remove/add individual parts of the decorations
> (titlebar, buttons, external borders) post your wishes here. Some
> window managers might be able to do that.
I haven't needed this yet :)
> The rest of this text is concerned with describing additional features.
> If some of them don't work on your system, please tell me, usually they
> need a compliant window manager as well.
Thanks. Maybe this is a good time to introduce my use case: I'd like to replace company-mode's overlay-based "tooltips" with proper tooltip-like frames. show-x-tooltip almost works for that purpose, but not quite: most importantly, there can at any time only be at most one pop-up.
> To make a frame not show up on the taskbar use the
> frame parameter `skip-taskbar'
✓
> To make a new frame not receive focus initially or when deiconified, use
> the frame parameter `no-focus-on-map'
✓, although if I create a frame with no-focus-on-map I then need a call to raise-frame to raise it — even if its z-group is 'above. Maybe when z-group is "above" the frame should be automatically raised?
> Usually this works but if you are using a focus follows mouse policy you
> might have to specify the `no-accept-focus' parameter as well as in
>
> (make-frame '((no-focus-on-map . t) (no-accept-focus . t)))
✓
> If you want to avoid that C-x 5 o switches to a specific frame, set
> that frame's `no-other-frame' parameter as in
✓
> A second group of parameters/functions is concerned with maintaining and
> investigating the stacking order of frames. The `z-group' parameter
> allows to put a frame in a separate group above or (not on Windows)
> below all other frames that are not in the same group. For example
>
> (set-frame-parameter nil 'z-group 'above)
✓, although it would be nice to automatically raise the frame when x-group is above. I can call raise-frame, but it doesn't work correctly when the frame is invisible (and setting the visibility to t before raising the frame doesn't work either).
> For normal (non-child) frames there's a new hook `move-frame-functions'
> called after a frame was moved so you can also synchronize the movements
> of two top-level frames.
Cool. I should use this to make sure the popup stays around.
> If the functions/parameters described here work sufficiently well, I'll
> post a number of toy algorithms that show how to synchronize two frames
> in a way that always shows one frame at a specified position on top of
> the other.
I think this is wonderful work; thanks so much for doing all this.
I've posted the code I used to test this with company. f you eval this and run M-x company-tooltip--add-advice, completion should use an x frame in addition to its regular overlay-based tooltips. This works very nicely, except for a few problems listed below:
* Creating a frame is rather slow; the following is an excerpt of a profile:
- make-frame 442 29%
- frame-creation-function 440 29%
- apply 440 29%
- #<compiled 0x4862dd> 440 29%
- x-create-frame-with-faces 440 29%
- face-set-after-frame-default 307 20%
- face-spec-recalc 276 18%
- make-face-x-resource-internal 217 14%
- set-face-attributes-from-resources 213 14%
- set-face-attribute-from-resource 190 12%
- face-name 126 8%
+ check-face 118 7%
+ face-spec-reset-face 44 2%
+ face-spec-set-2 7 0%
set-face-attribute 8 0%
normal-erase-is-backspace-setup-frame 2 0%
* Frames with z-group set to 'above are not automatically raised when no-focus-on-map is set, so I need to call x-raise-frame on them; this doesn't work when they are invisible (instead it makes them visible without raising them, it seems).
* Creating a frame / making it visible uses my WM's frame creating animation — is there a way to disable this (x-show-tip doesn't have it)?
Thanks again for all this cool stuff! It would be great to use proper frames for company's completion popups.
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sun, 12 Feb 2017 00:25:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> I've posted the code I used to test this with company.
Of course, I forgot the attachment.
[company-tooltip.el (text/x-emacs-lisp, attachment)]
[smime.p7s (application/pkcs7-signature, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sun, 12 Feb 2017 11:14:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Thanks! The patch applied cleanly and everything compiled fine.
Thanks for testing. Please tell me your build and window manager types.
> ✓, although if I create a frame with no-focus-on-map I then need a
> call to raise-frame to raise it — even if its z-group is 'above.
> Maybe when z-group is "above" the frame should be automatically
> raised?
Not so here (with a GTK 3.4.2 build on Debian running xfwm). Evaluating
(make-frame '((no-focus-on-map . t) (z-group . above)))
makes a new frame on top of the existing one regardless of whether xfwm
is set up to use focus follows mouse or not.
We probably have to investigate that further.
> ✓, although it would be nice to automatically raise the frame when
> x-group is above. I can call raise-frame, but it doesn't work
> correctly when the frame is invisible (and setting the visibility to t
> before raising the frame doesn't work either).
I mentioned that: When a frame is made invisible, its z-group is reset
to nil by the window system or manager. x_set_z_group can't cope with
that because the last line of
x_set_z_group (struct frame *f, Lisp_Object new_value, Lisp_Object old_value)
{
if (!EQ (new_value, old_value))
still assumes that the frame is "above". For the moment try with
(set-frame-parameter frame 'z-group nil)
...
(set-frame-parameter frame 'z-group 'above)
as a workaround. I'm not yet sure whether it's better to (1) have
x_make_frame_invisible and x_iconify_frame reset the z-group parameter
explicitly, (2) change x_set_z_group so it always issues a request to
the window system, or (3) remove the z-group parameter and make the
z-group setting an option of the `frame-restack' function.
Unfortunately, the z-group equivalents in X 11 are a complete mess: You
can put a window simultaneously in the ‘above’ and the ‘below’ groups
and it notwhere says what should prevail and what happens when you later
remove a window from one of these groups (I trioed to avoid this dilemma
with the z-group concept). And restacking may probably remove a window
from these groups and maybe not allow to put it there and so on ...
And why not avoid z-groups at all? Because you cannot simply restack a
frame on top of the "active" frame. If you try (via a foucs-in-hooked
function) you will see that your window system uses up all available
resources because the window system wants to raise the active frame and
Emacs wants to raise the other one. So to put a frame on top of the
"active" frame you have to put that frame in the ‘above’ group.
> * Creating a frame is rather slow; the following is an excerpt of a profile:
>
> - make-frame 442 29%
> - frame-creation-function 440 29%
> - apply 440 29%
> - #<compiled 0x4862dd> 440 29%
> - x-create-frame-with-faces 440 29%
> - face-set-after-frame-default 307 20%
> - face-spec-recalc 276 18%
> - make-face-x-resource-internal 217 14%
> - set-face-attributes-from-resources 213 14%
> - set-face-attribute-from-resource 190 12%
> - face-name 126 8%
> + check-face 118 7%
> + face-spec-reset-face 44 2%
> + face-spec-set-2 7 0%
> set-face-attribute 8 0%
> normal-erase-is-backspace-setup-frame 2 0%
But isn't that the problem I tried to tackle (for tooltip frames) with
the option ‘tooltip-reuse-hidden-frame’? All this face-related stuff is
an ecological disaster IMHO. Here, creating a tooltip frame caused up
to two GC cycles before I added that option.
So as a rule create your frames (lazily) once for each session and hide
them when you don't need them.
> * Frames with z-group set to 'above are not automatically raised when
> no-focus-on-map is set, so I need to call x-raise-frame on them; this
> doesn't work when they are invisible (instead it makes them visible
> without raising them, it seems).
I hope I described the problem and a workaround above. I attach my
functions for testing attached frames so you can see how I handle this
currently.
> * Creating a frame / making it visible uses my WM's frame creating animation — is there a way to disable this (x-show-tip doesn't have it)?
No idea. I can look into that (as a rule I turn off all animations
here). Do you use GTK tooltips or Emacs' native ones?
martin
[synch-frame-x.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 15 Feb 2017 19:50:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
That's great. Are you going to push your patch to git-repo?
When it comes to other platforms than Windows, I have no idea about OS X
since I don't own any macs, but for X11, we have different means to
controll decorations and their looks & behaviour. On X11 we have window
managers that makes it easy to configure (or remove) borders, decorations
etc, so in my humble opinion I don't think you have to spend countless time
to make it work with every possible window manager etc. I didn't even
thought of this on Linux, I only needed it for windows, to make Emacs
behave more like it does on Linux.
2017-02-12 12:13 GMT+01:00 martin rudalics <rudalics <at> gmx.at>:
> > Thanks! The patch applied cleanly and everything compiled fine.
>
> Thanks for testing. Please tell me your build and window manager types.
>
> > ✓, although if I create a frame with no-focus-on-map I then need a
> > call to raise-frame to raise it — even if its z-group is 'above.
> > Maybe when z-group is "above" the frame should be automatically
> > raised?
>
> Not so here (with a GTK 3.4.2 build on Debian running xfwm). Evaluating
>
> (make-frame '((no-focus-on-map . t) (z-group . above)))
>
> makes a new frame on top of the existing one regardless of whether xfwm
> is set up to use focus follows mouse or not.
>
> We probably have to investigate that further.
>
> > ✓, although it would be nice to automatically raise the frame when
> > x-group is above. I can call raise-frame, but it doesn't work
> > correctly when the frame is invisible (and setting the visibility to t
> > before raising the frame doesn't work either).
>
> I mentioned that: When a frame is made invisible, its z-group is reset
> to nil by the window system or manager. x_set_z_group can't cope with
> that because the last line of
>
> x_set_z_group (struct frame *f, Lisp_Object new_value, Lisp_Object
> old_value)
> {
> if (!EQ (new_value, old_value))
>
> still assumes that the frame is "above". For the moment try with
>
> (set-frame-parameter frame 'z-group nil)
> ...
> (set-frame-parameter frame 'z-group 'above)
>
> as a workaround. I'm not yet sure whether it's better to (1) have
> x_make_frame_invisible and x_iconify_frame reset the z-group parameter
> explicitly, (2) change x_set_z_group so it always issues a request to
> the window system, or (3) remove the z-group parameter and make the
> z-group setting an option of the `frame-restack' function.
>
> Unfortunately, the z-group equivalents in X 11 are a complete mess: You
> can put a window simultaneously in the ‘above’ and the ‘below’ groups
> and it notwhere says what should prevail and what happens when you later
> remove a window from one of these groups (I trioed to avoid this dilemma
> with the z-group concept). And restacking may probably remove a window
> from these groups and maybe not allow to put it there and so on ...
>
> And why not avoid z-groups at all? Because you cannot simply restack a
> frame on top of the "active" frame. If you try (via a foucs-in-hooked
> function) you will see that your window system uses up all available
> resources because the window system wants to raise the active frame and
> Emacs wants to raise the other one. So to put a frame on top of the
> "active" frame you have to put that frame in the ‘above’ group.
>
> > * Creating a frame is rather slow; the following is an excerpt of a
> profile:
> >
> > - make-frame 442
> 29%
> > - frame-creation-function 440
> 29%
> > - apply 440
> 29%
> > - #<compiled 0x4862dd> 440
> 29%
> > - x-create-frame-with-faces 440
> 29%
> > - face-set-after-frame-default 307
> 20%
> > - face-spec-recalc 276
> 18%
> > - make-face-x-resource-internal 217
> 14%
> > - set-face-attributes-from-resources 213
> 14%
> > - set-face-attribute-from-resource 190
> 12%
> > - face-name 126
> 8%
> > + check-face 118
> 7%
> > + face-spec-reset-face 44
> 2%
> > + face-spec-set-2 7
> 0%
> > set-face-attribute 8
> 0%
> > normal-erase-is-backspace-setup-frame
> 2 0%
>
> But isn't that the problem I tried to tackle (for tooltip frames) with
> the option ‘tooltip-reuse-hidden-frame’? All this face-related stuff is
> an ecological disaster IMHO. Here, creating a tooltip frame caused up
> to two GC cycles before I added that option.
>
> So as a rule create your frames (lazily) once for each session and hide
> them when you don't need them.
>
> > * Frames with z-group set to 'above are not automatically raised when
> > no-focus-on-map is set, so I need to call x-raise-frame on them; this
> > doesn't work when they are invisible (instead it makes them visible
> > without raising them, it seems).
>
> I hope I described the problem and a workaround above. I attach my
> functions for testing attached frames so you can see how I handle this
> currently.
>
> > * Creating a frame / making it visible uses my WM's frame creating
> animation — is there a way to disable this (x-show-tip doesn't have it)?
>
> No idea. I can look into that (as a rule I turn off all animations
> here). Do you use GTK tooltips or Emacs' native ones?
>
> martin
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Thu, 16 Feb 2017 08:06:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> That's great. Are you going to push your patch to git-repo?
After having resolved some remaining issues, yes.
> When it comes to other platforms than Windows, I have no idea about OS X
> since I don't own any macs, but for X11, we have different means to
> controll decorations and their looks & behaviour. On X11 we have window
> managers that makes it easy to configure (or remove) borders, decorations
> etc, so in my humble opinion I don't think you have to spend countless time
> to make it work with every possible window manager etc.
The concern here is not how to turn off decorations for all windows (or
maybe all windows of a certain application), something which themes most
likely already provide to some extent. The concern is how to control
aspects like appearance, placement, focusing and stacking order of some
specific Emacs frames, without affecting the remaining frames.
Consider the need to display some explanatory information for the
editing activity you are about to accomplish. If you don't want to pop
up a new "normal" window or frame for that purpose, you currently have
two possibilites: Use the echo area or the tooltip frame. Both are
ephemeral and have to be shared with all other applications pursuing a
similar goal.
Hence the need for some sort of minor frames which are OT1H less
ephemeral and can be more easily replicated than tooltips or the echo
area and are OTOH visually and habitually less obtrusive than normal
frames or windows.
Some desirable properties of such minor frames are:
(1) Do not show any window manager decorations provided their visibility
and placement can be controlled by the application.
(2) Do not show them on the taskbar.
(3) Do not focus them when they pop up.
(4) Do not give them focus via mouse movements, mouse wheel scrolling or
accidental mouse clicks.
(5) Allow to attach them to some normal Emacs frame or window. This
means to automatically move, resize and stack them along with that
frame/window without affecting the appearance of any other object on
your display. It may also mean to make them obscure as few as
possible text of the frame they have been attached to.
(6) Apart from (1)--(5) give them the full functionality of "normal"
Emacs frames.
Obviously, (6) is the most difficult part. For example, displaying such
a frame without making it continuously vanish and reappear.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Thu, 16 Feb 2017 13:23:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
If they don't get focus when they pop-up, and not get focus via mouse and
if they also
don't have decorations, what is considered as full functionality of
"normal" frames?
That sounds to me a bit like a popup window. Do you give them focus by
switching
with keyboard, like moving focus to "other window"?
"The concern is how to control
aspects like appearance, placement, focusing and stacking order of some
specific Emacs frames, without affecting the remaining frames."
As you yourself point out, certain WMs does allow you to create rules per
windows. On some
managers one can set rule based on window title bar, window class or class
name,
xid, role etc. I don't know if title bar property can be used if titlebar
exist but is hidden.
Maybe a separate class name could be used for that kind of windows so one
can set
appropriate hints for that frame. Or maybe you are already doing that? Just
an idea,
I haven't looked at your patch to be honest.
I cloned code today from git and compilations is crashing on me, when
dumping lisp code:
(without your patch applied):
Loading /home/arthur/emacs/lisp/international/characters.el (source)...
Wrong type argument: char-table-p, nil
make[1]: *** [Makefile:752: bootstrap-emacs] Error 255
make[1]: Leaving directory '/home/arthur/emacs/src'
make: *** [Makefile:409: src] Error 2
Will be interesting to test it once I manage to compile Emacs.
2017-02-16 9:04 GMT+01:00 martin rudalics <rudalics <at> gmx.at>:
> > That's great. Are you going to push your patch to git-repo?
>
> After having resolved some remaining issues, yes.
>
> > When it comes to other platforms than Windows, I have no idea about OS X
> > since I don't own any macs, but for X11, we have different means to
> > controll decorations and their looks & behaviour. On X11 we have window
> > managers that makes it easy to configure (or remove) borders, decorations
> > etc, so in my humble opinion I don't think you have to spend countless
> time
> > to make it work with every possible window manager etc.
>
> The concern here is not how to turn off decorations for all windows (or
> maybe all windows of a certain application), something which themes most
> likely already provide to some extent. The concern is how to control
> aspects like appearance, placement, focusing and stacking order of some
> specific Emacs frames, without affecting the remaining frames.
>
> Consider the need to display some explanatory information for the
> editing activity you are about to accomplish. If you don't want to pop
> up a new "normal" window or frame for that purpose, you currently have
> two possibilites: Use the echo area or the tooltip frame. Both are
> ephemeral and have to be shared with all other applications pursuing a
> similar goal.
>
> Hence the need for some sort of minor frames which are OT1H less
> ephemeral and can be more easily replicated than tooltips or the echo
> area and are OTOH visually and habitually less obtrusive than normal
> frames or windows.
>
> Some desirable properties of such minor frames are:
>
> (1) Do not show any window manager decorations provided their visibility
> and placement can be controlled by the application.
>
> (2) Do not show them on the taskbar.
>
> (3) Do not focus them when they pop up.
>
> (4) Do not give them focus via mouse movements, mouse wheel scrolling or
> accidental mouse clicks.
>
> (5) Allow to attach them to some normal Emacs frame or window. This
> means to automatically move, resize and stack them along with that
> frame/window without affecting the appearance of any other object on
> your display. It may also mean to make them obscure as few as
> possible text of the frame they have been attached to.
>
> (6) Apart from (1)--(5) give them the full functionality of "normal"
> Emacs frames.
>
> Obviously, (6) is the most difficult part. For example, displaying such
> a frame without making it continuously vanish and reappear.
>
> martin
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Thu, 16 Feb 2017 14:07:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
After checking out a commit previous to
Generate upcase and downcase tables from Unicode data (bug#24603)
<https://github.com/emacs-mirror/emacs/commit/5ec3a58462e99533ea5200de356302181d634d0b>
I was able to build it.
2017-02-16 14:22 GMT+01:00 Arthur Miller <arthur.miller.no1 <at> gmail.com>:
> If they don't get focus when they pop-up, and not get focus via mouse and
> if they also
> don't have decorations, what is considered as full functionality of
> "normal" frames?
> That sounds to me a bit like a popup window. Do you give them focus by
> switching
> with keyboard, like moving focus to "other window"?
>
> "The concern is how to control
> aspects like appearance, placement, focusing and stacking order of some
> specific Emacs frames, without affecting the remaining frames."
>
> As you yourself point out, certain WMs does allow you to create rules per
> windows. On some
> managers one can set rule based on window title bar, window class or class
> name,
> xid, role etc. I don't know if title bar property can be used if titlebar
> exist but is hidden.
>
> Maybe a separate class name could be used for that kind of windows so one
> can set
> appropriate hints for that frame. Or maybe you are already doing that?
> Just an idea,
> I haven't looked at your patch to be honest.
>
> I cloned code today from git and compilations is crashing on me, when
> dumping lisp code:
> (without your patch applied):
>
> Loading /home/arthur/emacs/lisp/international/characters.el (source)...
> Wrong type argument: char-table-p, nil
> make[1]: *** [Makefile:752: bootstrap-emacs] Error 255
> make[1]: Leaving directory '/home/arthur/emacs/src'
> make: *** [Makefile:409: src] Error 2
>
> Will be interesting to test it once I manage to compile Emacs.
>
>
> 2017-02-16 9:04 GMT+01:00 martin rudalics <rudalics <at> gmx.at>:
>
>> > That's great. Are you going to push your patch to git-repo?
>>
>> After having resolved some remaining issues, yes.
>>
>> > When it comes to other platforms than Windows, I have no idea about OS X
>> > since I don't own any macs, but for X11, we have different means to
>> > controll decorations and their looks & behaviour. On X11 we have window
>> > managers that makes it easy to configure (or remove) borders,
>> decorations
>> > etc, so in my humble opinion I don't think you have to spend countless
>> time
>> > to make it work with every possible window manager etc.
>>
>> The concern here is not how to turn off decorations for all windows (or
>> maybe all windows of a certain application), something which themes most
>> likely already provide to some extent. The concern is how to control
>> aspects like appearance, placement, focusing and stacking order of some
>> specific Emacs frames, without affecting the remaining frames.
>>
>> Consider the need to display some explanatory information for the
>> editing activity you are about to accomplish. If you don't want to pop
>> up a new "normal" window or frame for that purpose, you currently have
>> two possibilites: Use the echo area or the tooltip frame. Both are
>> ephemeral and have to be shared with all other applications pursuing a
>> similar goal.
>>
>> Hence the need for some sort of minor frames which are OT1H less
>> ephemeral and can be more easily replicated than tooltips or the echo
>> area and are OTOH visually and habitually less obtrusive than normal
>> frames or windows.
>>
>> Some desirable properties of such minor frames are:
>>
>> (1) Do not show any window manager decorations provided their visibility
>> and placement can be controlled by the application.
>>
>> (2) Do not show them on the taskbar.
>>
>> (3) Do not focus them when they pop up.
>>
>> (4) Do not give them focus via mouse movements, mouse wheel scrolling or
>> accidental mouse clicks.
>>
>> (5) Allow to attach them to some normal Emacs frame or window. This
>> means to automatically move, resize and stack them along with that
>> frame/window without affecting the appearance of any other object on
>> your display. It may also mean to make them obscure as few as
>> possible text of the frame they have been attached to.
>>
>> (6) Apart from (1)--(5) give them the full functionality of "normal"
>> Emacs frames.
>>
>> Obviously, (6) is the most difficult part. For example, displaying such
>> a frame without making it continuously vanish and reappear.
>>
>> martin
>>
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Fri, 17 Feb 2017 07:04:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> If they don't get focus when they pop-up, and not get focus via mouse and
> if they also
> don't have decorations, what is considered as full functionality of
> "normal" frames?
> That sounds to me a bit like a popup window. Do you give them focus by
> switching
> with keyboard, like moving focus to "other window"?
Unless that's forbidden too via the ‘no-other-frame’ parameter ;-)
But the function that created such a frame usually has a handle to it
and can manipulate it like a "normal" frame. And anyone else can find
out about the frame via ‘frame-list’ or ‘frame-child-frames’ and can
manipulate it like a "normal" frame.
> "The concern is how to control
> aspects like appearance, placement, focusing and stacking order of some
> specific Emacs frames, without affecting the remaining frames."
>
> As you yourself point out, certain WMs does allow you to create rules per
> windows. On some
> managers one can set rule based on window title bar, window class or class
> name,
> xid, role etc. I don't know if title bar property can be used if titlebar
> exist but is hidden.
>
> Maybe a separate class name could be used for that kind of windows so one
> can set
> appropriate hints for that frame. Or maybe you are already doing that? Just
> an idea,
> I haven't looked at your patch to be honest.
I'd rather leave it to the application or the end user to pick what they
like most than give them some predefined classes to choose from. This
way they should be able to fine-tune the behavior and appearance of a
separate minibuffer frame, the ediff control panel or the speedbar to
their like.
> I cloned code today from git and compilations is crashing on me, when
> dumping lisp code:
> (without your patch applied):
>
> Loading /home/arthur/emacs/lisp/international/characters.el (source)...
> Wrong type argument: char-table-p, nil
> make[1]: *** [Makefile:752: bootstrap-emacs] Error 255
> make[1]: Leaving directory '/home/arthur/emacs/src'
> make: *** [Makefile:409: src] Error 2
Next time you encounter such a thing please report it immediately (you
apparently were ahead of Glenn by 15 hours). Usually, nobody on this
list builds from a clean repository.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Fri, 17 Feb 2017 07:04:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> After checking out a commit previous to
>
> Generate upcase and downcase tables from Unicode data (bug#24603)
> <https://github.com/emacs-mirror/emacs/commit/5ec3a58462e99533ea5200de356302181d634d0b>
>
> I was able to build it.
If you don't read this list I can inform you as soon as people believe
that master builds again. Have you tried my patch then?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 12 Apr 2017 09:29:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 25408 <at> debbugs.gnu.org (full text, mbox):
I now installed most of the changes from my earlier patch. Minor
changes for an `internal-border' face, `x-focus-frame' and
`select-window' will follow. Also a major documentation rewrite will be
installed in the next days. Till then, the major purpose of installing
was to check whether we get any breakage of existing code.
If people can see anything fishy, please report immediately. Affected
might be among others scroll bars, frame deletion and selection. Also,
most of the new parameters won't work on NS. Hopefully, Alan or Anders
can help us with some of them.
> So as a rule create your frames (lazily) once for each session and hide
> them when you don't need them.
Did you try that in the meantime?
> > * Creating a frame / making it visible uses my WM's frame creating animation — is there a way to disable this (x-show-tip doesn't have it)?
>
> No idea. I can look into that (as a rule I turn off all animations
> here). Do you use GTK tooltips or Emacs' native ones?
For X I have now also provided an `override-redirect' parameter which
should replicate what the tooltip code does. If you still get
animations then I think you will have to explicitly tell the WM (for
example, via the frame title) to turn them off.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 12 Apr 2017 17:40:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 25408 <at> debbugs.gnu.org (full text, mbox):
On Sat, Feb 11, 2017 at 03:27:36PM +0100, martin rudalics wrote:
>
> To remove a frame's decorations, use the frame parameter `undecorated'
> as in
>
> (set-frame-parameter nil 'undecorated t)
>
> To give that frame back its decorations use
>
> (set-frame-parameter nil 'undecorated nil)
>
> To make a new frame undecorated use
>
> (make-frame '((undecorated . t)))
Hi Martin, this is really good.
I’ve got this semi‐working in the NS port, but I have a strange
problem, and I want to check it’s not intentional.
Should an undecorated frame be resizable? ie. if you run something
like
(set-frame-size nil 20 20)
would you expect the frame to resize?
Mine currently resizes if the frame was created with decorations and
they were removed, but not if it was created without them. I suspect
creating it without decorations is breaking some NS → Emacs event
path.
Thanks!
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 12 Apr 2017 19:14:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> Should an undecorated frame be resizable? ie. if you run something
> like
>
> (set-frame-size nil 20 20)
>
> would you expect the frame to resize?
Definitively! Undecorated frames should behave like normal frames -
just without decorations.
> Mine currently resizes if the frame was created with decorations and
> they were removed,
When can you remove the decorations? Does it flicker when you do that?
> but not if it was created without them. I suspect
> creating it without decorations is breaking some NS → Emacs event
> path.
Why do you think so? I never looked into the NS event set but I would
expect to receive the usual map, focus-in and visibility notifications.
Nothing that would allow to derive that the window cannot be resized
any more. Can you add the decorations later, resize the frame and
remove the decorations afterwards?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 12 Apr 2017 19:52:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Apr 12, 2017 at 09:13:15PM +0200, martin rudalics wrote:
> > Should an undecorated frame be resizable? ie. if you run something
> > like
> >
> > (set-frame-size nil 20 20)
> >
> > would you expect the frame to resize?
>
> Definitively! Undecorated frames should behave like normal frames -
> just without decorations.
Excellent, that’s what I wanted to know so I didn’t go chasing after a
behaviour that wasn’t right.
> > Mine currently resizes if the frame was created with decorations and
> > they were removed,
>
> When can you remove the decorations? Does it flicker when you do that?
I mean, it *can* resize after I remove the decorations. There’s no
flickering, it’s all quite smooth.
> > but not if it was created without them. I suspect
> > creating it without decorations is breaking some NS → Emacs event
> > path.
>
> Why do you think so?
The actual macOS window resizes, but the contents of that window
(Emacs) don’t. I’ve attached a screenshot that will hopefully explain
it better.
If I add decorations and remove them again:
(set-frame-parameter nil 'undecorated nil)
(set-frame-parameter nil 'undecorated t)
Then I can resize it fine. So it seems like the decorations are adding
something that allows the resize to work.
I’ve tried turning on NSTRACE, but the output looks identical whether
resizing works or not.
I’ll just keep looking at it. Hopefully I’ll be able to track it down.
--
Alan Third
[Screen Shot 2017-04-12 at 20.46.06.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Thu, 13 Apr 2017 07:11:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 25408 <at> debbugs.gnu.org (full text, mbox):
>> When can you remove the decorations? Does it flicker when you do that?
>
> I mean, it *can* resize after I remove the decorations.
I wanted to know "when" in the sense of "what do you have to wait for"
to remove the decorations? Can you send two requests in a row - a first
one to create a decorated frame and a second one to remove the
decorations - or do you have to wait for a response for the first
request before issuing the second one.
> There’s no
> flickering, it’s all quite smooth.
Then I see no problems with an approach that makes the frame initially
decorated and removes the decorations ASAP.
> The actual macOS window resizes, but the contents of that window
> (Emacs) don’t. I’ve attached a screenshot that will hopefully explain
> it better.
>
> If I add decorations and remove them again:
>
> (set-frame-parameter nil 'undecorated nil)
> (set-frame-parameter nil 'undecorated t)
>
> Then I can resize it fine. So it seems like the decorations are adding
> something that allows the resize to work.
>
> I’ve tried turning on NSTRACE, but the output looks identical whether
> resizing works or not.
Is this in windowDidResize or windowWillResize? I have no idea how the
NS API works. But if the redecorate/reundecorate approach works well, I
wouldn't care too much.
Can you look also into three other things I added:
- Provide a `move-frame-functions' hook.
- Provide "frame restacking" which should work via orderWindow. I
suppose NS has no equivalent for z-groups.
- Provide "child frames" which should work via parentWindow.
I don't know whether NS child windows always behave like NS "drawers" or
may also occlude the parent frame like under X or Windows. Eventually
I'd like to have them both (like Wayland's subsurfaces if I understand
them correctly). Drawers look like a pain when you are in fullscreen
mode - IIUC there's no way to open them "into" a fullscreen frame.
X/Windows child windows are annoying when you are in a normal, fairly
small frame where they get clipped too easily.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Thu, 13 Apr 2017 10:31:01 GMT)
Full text and
rfc822 format available.
Message #122 received at 25408 <at> debbugs.gnu.org (full text, mbox):
On Thu, Apr 13, 2017 at 09:10:26AM +0200, martin rudalics wrote:
> >> When can you remove the decorations? Does it flicker when you do that?
> >
> > I mean, it *can* resize after I remove the decorations.
>
> I wanted to know "when" in the sense of "what do you have to wait for"
> to remove the decorations? Can you send two requests in a row - a first
> one to create a decorated frame and a second one to remove the
> decorations - or do you have to wait for a response for the first
> request before issuing the second one.
I’ve worked it out: the toolbar is considered a ‘decoration’ by Cocoa,
so it is automatically removed when I change a frame to undecorated.
However, when I create a new undecorated frame the frame redrawing
code waits for the toolbar to be drawn, which will never happen.
I think this gives me two options:
1. Get Emacs to disable the toolbar when switching to undecorated
frames.
2. Use a different method of removing the titlebar when the toolbar
is enabled than when the toolbar is disabled. This option will
only work in macOS 10.11 and above.
Option 1 seems preferable to me, although we could add option 2 later.
> Can you look also into three other things I added:
>
> - Provide a `move-frame-functions' hook.
>
> - Provide "frame restacking" which should work via orderWindow. I
> suppose NS has no equivalent for z-groups.
>
> - Provide "child frames" which should work via parentWindow.
>
> I don't know whether NS child windows always behave like NS "drawers" or
> may also occlude the parent frame like under X or Windows. Eventually
> I'd like to have them both (like Wayland's subsurfaces if I understand
> them correctly). Drawers look like a pain when you are in fullscreen
> mode - IIUC there's no way to open them "into" a fullscreen frame.
> X/Windows child windows are annoying when you are in a normal, fairly
> small frame where they get clipped too easily.
I don’t know enough about NS to be able to answer this. I’ll give it a
go and see what happens.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Thu, 13 Apr 2017 11:57:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> I’ve worked it out: the toolbar is considered a ‘decoration’ by Cocoa,
> so it is automatically removed when I change a frame to undecorated.
> However, when I create a new undecorated frame the frame redrawing
> code waits for the toolbar to be drawn, which will never happen.
>
> I think this gives me two options:
>
> 1. Get Emacs to disable the toolbar when switching to undecorated
> frames.
>
> 2. Use a different method of removing the titlebar when the toolbar
> is enabled than when the toolbar is disabled. This option will
> only work in macOS 10.11 and above.
>
> Option 1 seems preferable to me, although we could add option 2 later.
Agreed. What happens in an undecorated frame with `tool-bar-mode'
turned off when you turn on `tool-bar-mode'?
> I don’t know enough about NS to be able to answer this. I’ll give it a
> go and see what happens.
Fine.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sat, 15 Apr 2017 16:30:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 25408 <at> debbugs.gnu.org (full text, mbox):
I’ve done some further reading.
On Thu, Apr 13, 2017 at 09:10:26AM +0200, martin rudalics wrote:
> Can you look also into three other things I added:
>
> - Provide a `move-frame-functions' hook.
>
> - Provide "frame restacking" which should work via orderWindow. I
> suppose NS has no equivalent for z-groups.
If I understand your description right, there is a direct equivalent
for z‐groups: levels. Here’s Apple’s documentation on them:
> The levels you typically use are: NSNormalWindowLevel, which
> specifies the default level; NSFloatingWindowLevel, which specifies
> the level for floating palettes; and NSScreenSaverWindowLevel, which
> specifies the level for a screen saver window. You might also use
> NSStatusWindowLevel for a status window, or NSModalPanelWindowLevel
> for a modal panel.
This is in addition to the basic ‘layers’, which orderWindow deals
with and which only affects windows in the same ‘level’.
> - Provide "child frames" which should work via parentWindow.
>
> I don't know whether NS child windows always behave like NS "drawers" or
> may also occlude the parent frame like under X or Windows. Eventually
> I'd like to have them both (like Wayland's subsurfaces if I understand
> them correctly). Drawers look like a pain when you are in fullscreen
> mode - IIUC there's no way to open them "into" a fullscreen frame.
> X/Windows child windows are annoying when you are in a normal, fairly
> small frame where they get clipped too easily.
It appears that a child window in NS is just a normal window which
moves and closes with its parent. So I think that means it’s more like
X’s child windows, except they don’t get clipped at the parent
window’s edges. They can also end up below the parent window.
I think this is probably what we want, for now at least.
FYI: there are also drawers and something called sheets, which appear
to be some sort of special modal drawer type thing used for error
messages and such.
I’ve pretty much got the undecorated frames sorted with only one major
bug I’m aware of when the frame is nearly the full height of the
screen. I think I may have to ask Anders about that as I can’t
understand the code that keeps the frame on‐screen, and I think it may
be the culprit.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sat, 15 Apr 2017 19:40:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> If I understand your description right, there is a direct equivalent
> for z‐groups: levels. Here’s Apple’s documentation on them:
>
>> The levels you typically use are: NSNormalWindowLevel, which
>> specifies the default level; NSFloatingWindowLevel, which specifies
>> the level for floating palettes; and NSScreenSaverWindowLevel, which
>> specifies the level for a screen saver window. You might also use
>> NSStatusWindowLevel for a status window, or NSModalPanelWindowLevel
>> for a modal panel.
Maybe the last two could be used for emulating the 'above' group. It
would be nice to have a common interface for that.
> This is in addition to the basic ‘layers’, which orderWindow deals
> with and which only affects windows in the same ‘level’.
This should conform with what we have on X and Windows.
> It appears that a child window in NS is just a normal window which
> moves and closes with its parent. So I think that means it’s more like
> X’s child windows, except they don’t get clipped at the parent
> window’s edges. They can also end up below the parent window.
It sounds like NS can do more than Windows and X here. The clipping
issue is a nuisance. Could you try to create one and play around with
it a bit?
> I think this is probably what we want, for now at least.
Certainly.
> FYI: there are also drawers and something called sheets, which appear
> to be some sort of special modal drawer type thing used for error
> messages and such.
>
> I’ve pretty much got the undecorated frames sorted with only one major
> bug I’m aware of when the frame is nearly the full height of the
> screen. I think I may have to ask Anders about that as I can’t
> understand the code that keeps the frame on‐screen, and I think it may
> be the culprit.
On X decorating an undecorated maximized frame can be funny too. There
may be no visible change.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Mon, 17 Apr 2017 14:57:01 GMT)
Full text and
rfc822 format available.
Message #134 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sat, Apr 15, 2017 at 09:39:32PM +0200, martin rudalics wrote:
> > It appears that a child window in NS is just a normal window which
> > moves and closes with its parent. So I think that means it’s more like
> > X’s child windows, except they don’t get clipped at the parent
> > window’s edges. They can also end up below the parent window.
>
> It sounds like NS can do more than Windows and X here. The clipping
> issue is a nuisance. Could you try to create one and play around with
> it a bit?
I’ve attached a partial patch for NS. It should handle undecorated
frames and parent‐child frame relationships. I’ll keep working on the
rest, but thought I’d throw this out there in case anyone can spot
anything obviously wrong.
Anders, I hope it’s OK CCing you in. I think you might appreciate the
following (after applying the patch):
emacs -Q
(set-frame-parameter nil 'undecorated t)
(setq ns-auto-hide-menu-bar t)
(toggle-frame-maximized)
More info at:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25408#77
--
Alan Third
[0001-Add-undecorated-and-parent-frames-to-NS-port.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Mon, 17 Apr 2017 15:45:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 25408 <at> debbugs.gnu.org (full text, mbox):
Looks good to me. I suppose though this won't work with GNUStep so I
can't try it. Two remarks below.
> + * Set frame F's `undecorated' parameter. If non-nil, F's window-system
> + * window is drawn without decorations, title, minimize/maximize boxes
> + * and external borders.
I suppose you want to mention the removal of the toolbar here. If so,
we'll have to mention that in the manual as well. When you re-add the
decorations, does the inner frame move or are the decorations drawn
around an unmoved inner frame?
> + * A child frame's `left' and `top' parameters specify positions
> + * relative to the top-left corner of its parent frame's native
> + * rectangle.
Does the above hold for NS? Does a (set-frame-position child 0 0)
really put child in the upper left corner of its parent? Also we would
have to describe the deviant clipping behavior for NS.
Many thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Mon, 17 Apr 2017 16:22:01 GMT)
Full text and
rfc822 format available.
Message #140 received at 25408 <at> debbugs.gnu.org (full text, mbox):
On Mon, Apr 17, 2017 at 05:43:57PM +0200, martin rudalics wrote:
> Looks good to me. I suppose though this won't work with GNUStep so I
> can't try it. Two remarks below.
I’m not sure about the decoration stuff, but I think, from a quick
glance at the GNUStep docs, the parent/child window stuff should work.
I’ll try and build it under GNUStep at some point to check it works.
I’ve got a GNU/Linux virtual machine around here somewhere...
> > + * Set frame F's `undecorated' parameter. If non-nil, F's window-system
> > + * window is drawn without decorations, title, minimize/maximize boxes
> > + * and external borders.
>
> I suppose you want to mention the removal of the toolbar here. If so,
> we'll have to mention that in the manual as well.
Yes, good point.
> When you re-add the decorations, does the inner frame move or are
> the decorations drawn around an unmoved inner frame?
There are only two situations where the inner frame will move. The
first is if you have the toolbar enabled, when you re‐add the
decorations the toolbar reappears and slides the rest of the frame
down. (Similarly when you remove the toolbar the rest of the frame
slides up.) The other is if the titlebar would be behind the menubar,
then the system moves the whole frame down just enough to keep it
completely visible.
> > + * A child frame's `left' and `top' parameters specify positions
> > + * relative to the top-left corner of its parent frame's native
> > + * rectangle.
>
> Does the above hold for NS? Does a (set-frame-position child 0 0)
> really put child in the upper left corner of its parent?
Most of the time spent implementing the child/parent frames was
getting that working right, so yes, it does.
Now, one thing that may be wrong is that (0 0) is actually the very
top, including the titlebar. I could probably fix that if it’s not
right just by offsetting by the height of the titlebar.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Mon, 17 Apr 2017 17:21:01 GMT)
Full text and
rfc822 format available.
Message #143 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> I’m not sure about the decoration stuff, but I think, from a quick
> glance at the GNUStep docs, the parent/child window stuff should work.
>
> I’ll try and build it under GNUStep at some point to check it works.
> I’ve got a GNU/Linux virtual machine around here somewhere...
Here, building with GNUStep currently fails as follows:
../../src/nsterm.m: In function ‘x_set_offset’:
../../src/nsterm.m:1714:33: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../../src/nsterm.m:1714:33: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../../src/nsterm.m:1714:33: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../../src/nsterm.m:1716:33: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../../src/nsterm.m:1716:33: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../../src/nsterm.m:1716:33: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../../src/nsterm.m: In function ‘x_set_window_size’:
../../src/nsterm.m:1742:7: warning: unused variable ‘tb’ [-Wunused-variable]
../../src/nsterm.m: In function ‘x_set_undecorated’:
../../src/nsterm.m:1822:34: warning: ‘NSWindow’ may not respond to ‘-setStyleMask:’ [enabled by default]
../../src/nsterm.m:1822:34: warning: (Messages without a matching method signature [enabled by default]
../../src/nsterm.m:1822:34: warning: will be assumed to return ‘id’ and accept [enabled by default]
../../src/nsterm.m:1822:34: warning: ‘...’ as arguments.) [enabled by default]
../../src/nsterm.m:1833:34: warning: ‘NSWindow’ may not respond to ‘-setStyleMask:’ [enabled by default]
../../src/nsterm.m: In function ‘ns_read_socket’:
../../src/nsterm.m:4160:21: warning: unused variable ‘specpdl_count’ [-Wunused-variable]
../../src/nsfns.m: In function ‘frame_geometry’:
../../src/nsfns.m:2853:3: error: no ‘visible’ getter found
../../src/nsterm.m: In function ‘-[EmacsView initFrameFromEmacs:]’:
../../src/nsterm.m:6892:30: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../../src/nsterm.m:6894:30: warning: initialization from distinct Objective-C type [enabled by default]
../../src/nsterm.m:6905:12: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../../src/nsterm.m:6905:12: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../../src/nsterm.m:6905:12: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../../src/nsterm.m:6907:12: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../../src/nsterm.m:6907:12: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../../src/nsterm.m:6907:12: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../../src/nsterm.m: In function ‘-[EmacsView windowDidMove:]’:
../../src/nsterm.m:6951:43: warning: comparison of distinct pointer types lacks a cast [enabled by default]
../../src/nsterm.m:6953:9: warning: comparison of distinct pointer types lacks a cast [enabled by default]
make[1]: *** [nsfns.o] Fehler 1
make[1]: *** Warte auf noch nicht beendete Prozesse...
../../src/nsterm.m: In function ‘-[EmacsView updateFrameSize:]’:
../../src/nsterm.m:6467:9: error: no ‘visible’ getter found
../../src/nsterm.m:6472:7: error: no ‘visible’ getter found
../../src/nsterm.m: In function ‘-[EmacsView windowWillResize:toSize:]’:
../../src/nsterm.m:6554:9: error: no ‘visible’ getter found
../../src/nsterm.m: In function ‘x_set_window_size’:
../../src/nsterm.m:1772:7: error: no ‘visible’ getter found
../../src/nsterm.m:1788:5: error: no ‘visible’ getter found
../../src/nsterm.m: In function ‘x_set_offset’:
../../src/nsterm.m:1706:12: error: no ‘visible’ getter found
make[1]: *** [nsterm.o] Fehler 1
make[1]: Leaving directory `/home/martin/emacs-git/trunk/obj-ns/src'
make: *** [src] Fehler 2
No good idea what made it choke. The plethora of warnings is terribly
confusing.
> Now, one thing that may be wrong is that (0 0) is actually the very
> top, including the titlebar. I could probably fix that if it’s not
> right just by offsetting by the height of the titlebar.
No really great deal. If you don't, we'll mention it in the
documentation.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Mon, 17 Apr 2017 18:56:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Apr 17, 2017 at 07:20:20PM +0200, martin rudalics wrote:
> > I’m not sure about the decoration stuff, but I think, from a quick
> > glance at the GNUStep docs, the parent/child window stuff should work.
> >
> > I’ll try and build it under GNUStep at some point to check it works.
> > I’ve got a GNU/Linux virtual machine around here somewhere...
>
> Here, building with GNUStep currently fails as follows:
>
<snip>
>
> No good idea what made it choke. The plethora of warnings is terribly
> confusing.
I think it was the use of the ‘visible’ method on NSToolbar, which it
appears I’ve made up, but which works on Cocoa. I’ve changed it to
look directly at the ‘isVisible’ instance variable.
I also noticed that it doesn’t like NSWindow:setStyleMask, so I’ve
changed that to directly update the relevant instance variable too.
I think some of the warnings are related to comparing an Objective C
object to NULL instead of nil, or vice versa. I can’t see any
difference between them here, and I don’t get any warnings from clang.
New patch attached.
--
Alan Third
[0001-Add-undecorated-and-parent-frames-to-NS-port.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 19 Apr 2017 07:27:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> New patch attached.
Thank you. Building works now. Invoking a "non-installed" emacs gets
me
2017-04-19 09:16:03.808 emacs[5292] FTC_ImageCache_Lookup() failed with error 00000006
2017-04-19 09:16:03.921 emacs[5292] FTC_ImageCache_Lookup() failed with error 00000006
2017-04-19 09:16:03.953 emacs[5292] KeySym NoSymbol not found; disabling GSSecondControlKey
2017-04-19 09:16:03.953 emacs[5292] KeySym NoSymbol not found; disabling GSFirstCommandKey
2017-04-19 09:16:03.953 emacs[5292] KeySym NoSymbol not found; disabling GSSecondCommandKey
which is normal here. If at this time I do within the just started Emacs
(set-frame-parameter nil 'undecorated t)
I get
/home/martin/emacs-git/trunk/obj-ns/src/emacs: Uncaught exception NSInvalidArgumentException, reason: -[EmacsFSWindow setStyleMask:]: unrecognized selector sent to instance 0x30a37d0
Setting the 'parent-frame' parameter of a frame has no impact, neither
when I do it during frame creation not when doing it at any later time.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 19 Apr 2017 11:25:01 GMT)
Full text and
rfc822 format available.
Message #152 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi!
> Anders, I hope it’s OK CCing you in. I think you might appreciate the
> following (after applying the patch):
>
I really appreciate that you are keeping me in the loop!
emacs -Q
>
> (set-frame-parameter nil 'undecorated t)
> (setq ns-auto-hide-menu-bar t)
> (toggle-frame-maximized)
>
This looks very promising! It's a cleaner solution than the one I use today
-- placing the title bar above the top of the screen.
The only issue I've came across was when the bottom edge of a frame was
close to the bottom of the display (or when maximized). When `undocorated'
goes from t to nil, the window shrinks. When positioned in the middle of
the screen, it looks like the frame, for a fraction of a second, increases
its size before returning to it's original shape. My guess is that, when at
the bottom of the screen, the frame gets truncated when the frame is
temporarily increased, and when it tries to return to it's original size,
it shrinks.
I made an attempt at adapting/modernizing my "multicolumn" (
https://github.com/Lindydancer/multicolumn) package (which, among else, can
resize and reposition a frame). Currently, I have hardcoded the title size
for various systems -- on macOS I use "24". However, `frame-geometry' says
that the title height is 22 pixels. I'm not sure how to account for the
missing 2 pixels, any thoughts?
Martin, I also notices that `menu-bar-external' says `nil', but I guess is
should say non-nil, right?
-- Anders
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 19 Apr 2017 12:52:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> I made an attempt at adapting/modernizing my "multicolumn" (
> https://github.com/Lindydancer/multicolumn) package (which, among else, can
> resize and reposition a frame). Currently, I have hardcoded the title size
> for various systems -- on macOS I use "24". However, `frame-geometry' says
> that the title height is 22 pixels. I'm not sure how to account for the
> missing 2 pixels, any thoughts?
The value returned by ‘frame-geometry’ should be correct. Look at all
the occurrences of FRAME_NS_TITLEBAR_HEIGHT in nsterm.m. In contrast
with other platforms, NS uses that value internally all the time.
> Martin, I also notices that `menu-bar-external' says `nil', but I guess is
> should say non-nil, right?
Right. It should say non-nil.
If possible, however, please check the function ‘ns-frame-edges’ for all
values of TYPE whether it handles the menu bar height correctly, i.e.,
ignores it.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 19 Apr 2017 13:52:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 25408 <at> debbugs.gnu.org (full text, mbox):
On Wed, Apr 19, 2017 at 01:24:00PM +0200, Anders Lindgren wrote:
> The only issue I've came across was when the bottom edge of a frame was
> close to the bottom of the display (or when maximized). When `undocorated'
> goes from t to nil, the window shrinks. When positioned in the middle of
> the screen, it looks like the frame, for a fraction of a second, increases
> its size before returning to it's original shape. My guess is that, when at
> the bottom of the screen, the frame gets truncated when the frame is
> temporarily increased, and when it tries to return to it's original size,
> it shrinks.
It appears this was being caused by the recreation of the toolbar when
switching from undecorated to decorated. The toolbar was being added
to the window, then made invisible, but I guess not before the new
toolbar animation kicked in.
I’ve swapped the two lines around and it seems much smoother now.
> I made an attempt at adapting/modernizing my "multicolumn" (
> https://github.com/Lindydancer/multicolumn) package (which, among else, can
> resize and reposition a frame). Currently, I have hardcoded the title size
> for various systems -- on macOS I use "24". However, `frame-geometry' says
> that the title height is 22 pixels. I'm not sure how to account for the
> missing 2 pixels, any thoughts?
I’m sure that 22 pixels is correct. I notice that
internal-border-width defaults to two pixels, could that explain it?
I’ve got an updated patch, but I’ll reply to Martin’s email and attach
it there.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 19 Apr 2017 14:34:01 GMT)
Full text and
rfc822 format available.
Message #161 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Apr 19, 2017 at 09:26:23AM +0200, martin rudalics wrote:
> If at this time I do within the just started Emacs
>
> (set-frame-parameter nil 'undecorated t)
>
> I get
>
> /home/martin/emacs-git/trunk/obj-ns/src/emacs: Uncaught exception NSInvalidArgumentException, reason: -[EmacsFSWindow setStyleMask:]: unrecognized selector sent to instance 0x30a37d0
It turns out that GNUStep doesn’t let you change the decorated state
of an existing window. It should be able to create a new undecorated
window.
> Setting the 'parent-frame' parameter of a frame has no impact, neither
> when I do it during frame creation not when doing it at any later time.
I believe it is setting the parent/child relationship, but in GNUStep
it doesn’t seem to mean the child moves with the parent. I think this
is a bug in GNUStep, but the behaviour isn’t documented yet, so I’m
not sure if it’s intentional.
The child will minimise and close with the parent and moving it to (0
0) will put it in the top left corner of the parent.
Except it doesn’t quite, because there’s a hard‐coded titlebar height
for GNUStep which is guaranteed to be wrong for every WM. At least I
think that’s what going on.
Z‐groups are working, but again in GNUStep it seems a bit hit and miss
as the frames seem to forget their state if you click on their
titlebars.
--
Alan Third
[0001-Add-new-frame-functionality-to-NS-port.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 19 Apr 2017 16:03:02 GMT)
Full text and
rfc822 format available.
Message #164 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> It turns out that GNUStep doesn’t let you change the decorated state
> of an existing window.
OK. It's not important that the GNUStep build is capable of doing
anything useful. It should build and if possible not crash. The only
person currently using it (only for checking whether a change might
break the NS build) is me, I presume.
> It should be able to create a new undecorated
> window.
It does so.
> I believe it is setting the parent/child relationship, but in GNUStep
> it doesn’t seem to mean the child moves with the parent. I think this
> is a bug in GNUStep, but the behaviour isn’t documented yet, so I’m
> not sure if it’s intentional.
>
> The child will minimise and close with the parent and moving it to (0
> 0) will put it in the top left corner of the parent.
It is created initially at the top left corner of the parent frame and
inconifies and deiconifies correctly with its parent.
> Except it doesn’t quite, because there’s a hard‐coded titlebar height
> for GNUStep which is guaranteed to be wrong for every WM. At least I
> think that’s what going on.
The top edge is below the native top edge of the parent by a few pixels,
maybe the two Anders mentioned. Nothing to worry about.
> Z‐groups are working, but again in GNUStep it seems a bit hit and miss
> as the frames seem to forget their state if you click on their
> titlebars.
Don't worry. I just tried to type something and when I reached the
right edge of the window I got an abort as
2017-04-19 17:36:59.480 emacs[4423] Problem posting notification: <NSException: 0x4167070> NAME:NSInvalidArgumentException REASON:-[EmacsImage XBM:width:height:fg:bg:]: unrecognized selector sent to instance 0x3e0bf40 INFO:(null)
/home/martin/emacs-git/trunk/obj-ns/src/emacs: Uncaught exception NSInvalidArgumentException, reason: -[EmacsImage XBM:width:height:fg:bg:]: unrecognized selector sent to instance 0x3ec20a0
As it is, the GNUStep build is certainly not suited for doing anything
useful at the moment.
I think you should install your changes so people can test them.
In the ChangeLog please fix the below:
> (Fx-create_frame): Handle 'z-code', 'parent-frame' and 'undecorated'
Fx_create_frame 'z-group'
Many thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 19 Apr 2017 17:05:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 25408 <at> debbugs.gnu.org (full text, mbox):
On Wed, Apr 19, 2017 at 06:01:52PM +0200, martin rudalics wrote:
> > It turns out that GNUStep doesn’t let you change the decorated state
> > of an existing window.
>
> OK. It's not important that the GNUStep build is capable of doing
> anything useful. It should build and if possible not crash. The only
> person currently using it (only for checking whether a change might
> break the NS build) is me, I presume.
I have had this suspicion. If I can get it working in GNUStep without
too much hassle it’s probably best, though.
> I just tried to type something and when I reached the
> right edge of the window I got an abort as
>
> 2017-04-19 17:36:59.480 emacs[4423] Problem posting notification: <NSException: 0x4167070>
> NAME:NSInvalidArgumentException REASON:-[EmacsImage XBM:width:height:fg:bg:]: unrecognized selector sent to instance
> 0x3e0bf40 INFO:(null)
> /home/martin/emacs-git/trunk/obj-ns/src/emacs: Uncaught exception NSInvalidArgumentException, reason: -[EmacsImage
> XBM:width:height:fg:bg:]: unrecognized selector sent to instance 0x3ec20a0
That was my fault. I think I mashed the keys in the wrong place and
deleted something without realising. I’ve pushed another commit to fix
it.
(I don’t know how I didn’t notice it before now!)
> I think you should install your changes so people can test them.
Done. Thanks for your help.
Oh, I just remembered I’ve not yet done frame-list-z-order. It should
be easy enough, NSApplication has an orderedWindows function which, I
think, should return an ordered array of NSWindow objects.
Should I look into no-focus-on-map and no-accept-focus too?
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Wed, 19 Apr 2017 18:08:01 GMT)
Full text and
rfc822 format available.
Message #170 received at 25408 <at> debbugs.gnu.org (full text, mbox):
>> I just tried to type something and when I reached the
>> right edge of the window I got an abort as
>>
>> 2017-04-19 17:36:59.480 emacs[4423] Problem posting notification: <NSException: 0x4167070>
>> NAME:NSInvalidArgumentException REASON:-[EmacsImage XBM:width:height:fg:bg:]: unrecognized selector sent to instance
>> 0x3e0bf40 INFO:(null)
>> /home/martin/emacs-git/trunk/obj-ns/src/emacs: Uncaught exception NSInvalidArgumentException, reason: -[EmacsImage
>> XBM:width:height:fg:bg:]: unrecognized selector sent to instance 0x3ec20a0
>
> That was my fault. I think I mashed the keys in the wrong place and
> deleted something without realising. I’ve pushed another commit to fix
> it.
Ahh.. it was you. Anyway, works now. And frame restacking works well
too.
There's only one incredible hassle at the moment which must have started
somewhere in 2015. Whenever I mouse scroll a window the menu redraws
itself so it flickers continuously.
> Oh, I just remembered I’ve not yet done frame-list-z-order. It should
> be easy enough, NSApplication has an orderedWindows function which, I
> think, should return an ordered array of NSWindow objects.
Please do that.
> Should I look into no-focus-on-map and no-accept-focus too?
That would be fine. There's also the 'skip-taskbar' parameter but I
have no idea whether NS allows that and whether NS provides Alt-tabbing.
And please have a look into the Elisp manual: Maybe you find something
worth mentioning (the fact that removing decorations removes the tool
bar should certainly go there).
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sat, 06 May 2017 00:07:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 25408 <at> debbugs.gnu.org (full text, mbox):
On 2017-04-12 05:27, martin rudalics wrote:
> I now installed most of the changes from my earlier patch. Minor
> changes for an `internal-border' face, `x-focus-frame' and
> `select-window' will follow. Also a major documentation rewrite will be
> installed in the next days. Till then, the major purpose of installing
> was to check whether we get any breakage of existing code.
>
> If people can see anything fishy, please report immediately. Affected
> might be among others scroll bars, frame deletion and selection. Also,
> most of the new parameters won't work on NS. Hopefully, Alan or Anders
> can help us with some of them.
>
>> So as a rule create your frames (lazily) once for each session and hide
>> them when you don't need them.
>
> Did you try that in the meantime?
Yes :) I just did. It works great.
>> > * Creating a frame / making it visible uses my WM's frame creating animation — is there a way to disable this (x-show-tip doesn't have it)?
>>
>> No idea. I can look into that (as a rule I turn off all animations
>> here). Do you use GTK tooltips or Emacs' native ones?
>
> For X I have now also provided an `override-redirect' parameter which
> should replicate what the tooltip code does. If you still get
> animations then I think you will have to explicitly tell the WM (for
> example, via the frame title) to turn them off.
This works perfectly.
I've run into another small issue: there doesn't seem to be a way to turn off truncation marks in tooltip frames. Is that correct? This bit of xdisp.c seems to take care of that for Emacs' default tip frame; is there a way to emulate this for Lisp-created frames?
/* Get dimensions of truncation and continuation glyphs. These are
displayed as fringe bitmaps under X, but we need them for such
frames when the fringes are turned off. But leave the dimensions
zero for tooltip frames, as these glyphs look ugly there and also
sabotage calculations of tooltip dimensions in x-show-tip. */
#ifdef HAVE_WINDOW_SYSTEM
if (!(FRAME_WINDOW_P (it->f)
&& FRAMEP (tip_frame)
&& it->f == XFRAME (tip_frame)))
#endif
Thanks!
Clément.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sat, 06 May 2017 07:14:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
> Date: Fri, 5 May 2017 20:06:46 -0400
> Cc: 25408 <at> debbugs.gnu.org
>
> I've run into another small issue: there doesn't seem to be a way to turn off truncation marks in tooltip frames. Is that correct? This bit of xdisp.c seems to take care of that for Emacs' default tip frame; is there a way to emulate this for Lisp-created frames?
>
> /* Get dimensions of truncation and continuation glyphs. These are
> displayed as fringe bitmaps under X, but we need them for such
> frames when the fringes are turned off. But leave the dimensions
> zero for tooltip frames, as these glyphs look ugly there and also
> sabotage calculations of tooltip dimensions in x-show-tip. */
> #ifdef HAVE_WINDOW_SYSTEM
> if (!(FRAME_WINDOW_P (it->f)
> && FRAMEP (tip_frame)
> && it->f == XFRAME (tip_frame)))
> #endif
Doing that will have a disadvantage: text will be truncated on
display, but there will be no visual cue for that truncation. Tooltip
frames don't suffer from this problem, because their size is computed
in advance to have the text fit exactly on the line, but AFAIU these
"undecorated" frames are just normal frames in that regard, so they
will be adversely affected.
Therefore, if we are going to allow disabling truncation and
continuation glyphs on such frames, it should be via a frame parameter
which is by default off.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sat, 06 May 2017 07:41:02 GMT)
Full text and
rfc822 format available.
Message #179 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> I've run into another small issue: there doesn't seem to be a way to turn off truncation marks in tooltip frames. Is that correct? This bit of xdisp.c seems to take care of that for Emacs' default tip frame; is there a way to emulate this for Lisp-created frames?
>
> /* Get dimensions of truncation and continuation glyphs. These are
> displayed as fringe bitmaps under X, but we need them for such
> frames when the fringes are turned off. But leave the dimensions
> zero for tooltip frames, as these glyphs look ugly there and also
> sabotage calculations of tooltip dimensions in x-show-tip. */
> #ifdef HAVE_WINDOW_SYSTEM
> if (!(FRAME_WINDOW_P (it->f)
> && FRAMEP (tip_frame)
> && it->f == XFRAME (tip_frame)))
> #endif
Please try the attached patch (I only checked whether it compiles and
builds on Windows). You have to add a non-nil 'no-special-glyphs' frame
parameter to suppress such glyphs.
And please test the new behavior for tooltip frames as well.
Thanks, martin
[no-special-glyphs.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sat, 06 May 2017 09:42:01 GMT)
Full text and
rfc822 format available.
Message #182 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> Please try the attached patch (I only checked whether it compiles and
> builds on Windows). You have to add a non-nil 'no-special-glyphs' frame
> parameter to suppress such glyphs.
Sorry, that patch was complete scrap. Hopefully, I'll come up with a
better one later.
What do those glyphs look like - "\" for continuation and "$" for
truncation?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sat, 06 May 2017 13:28:01 GMT)
Full text and
rfc822 format available.
Message #185 received at 25408 <at> debbugs.gnu.org (full text, mbox):
On 2017-05-06 03:13, Eli Zaretskii wrote:
> Therefore, if we are going to allow disabling truncation and
> continuation glyphs on such frames, it should be via a frame parameter
> which is by default off.
Yes, of course :)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sat, 06 May 2017 13:29:02 GMT)
Full text and
rfc822 format available.
Message #188 received at 25408 <at> debbugs.gnu.org (full text, mbox):
On 2017-05-06 05:41, martin rudalics wrote:
>> Please try the attached patch (I only checked whether it compiles and
>> builds on Windows). You have to add a non-nil 'no-special-glyphs' frame
>> parameter to suppress such glyphs.
>
> Sorry, that patch was complete scrap. Hopefully, I'll come up with a
> better one later.
>
> What do those glyphs look like - "\" for continuation and "$" for
> truncation?
Yup, exactly :) Thanks for your help!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sat, 06 May 2017 14:21:02 GMT)
Full text and
rfc822 format available.
Message #191 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
> Date: Sat, 6 May 2017 09:28:02 -0400
> Cc: 25408 <at> debbugs.gnu.org
>
> On 2017-05-06 05:41, martin rudalics wrote:
> >> Please try the attached patch (I only checked whether it compiles and
> >> builds on Windows). You have to add a non-nil 'no-special-glyphs' frame
> >> parameter to suppress such glyphs.
> >
> > Sorry, that patch was complete scrap. Hopefully, I'll come up with a
> > better one later.
> >
> > What do those glyphs look like - "\" for continuation and "$" for
> > truncation?
>
> Yup, exactly :) Thanks for your help!
Not sure why Martin asked, but to be more accurate: the actual glyphs
are stored in a display-table, and can be changed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sat, 06 May 2017 21:02:02 GMT)
Full text and
rfc822 format available.
Message #194 received at 25408 <at> debbugs.gnu.org (full text, mbox):
On 2017-05-06 10:20, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
>> Date: Sat, 6 May 2017 09:28:02 -0400
>> Cc: 25408 <at> debbugs.gnu.org
>>
>> On 2017-05-06 05:41, martin rudalics wrote:
>>>> Please try the attached patch (I only checked whether it compiles and
>>>> builds on Windows). You have to add a non-nil 'no-special-glyphs' frame
>>>> parameter to suppress such glyphs.
>>>
>>> Sorry, that patch was complete scrap. Hopefully, I'll come up with a
>>> better one later.
>>>
>>> What do those glyphs look like - "\" for continuation and "$" for
>>> truncation?
>>
>> Yup, exactly :) Thanks for your help!
>
> Not sure why Martin asked, but to be more accurate: the actual glyphs
> are stored in a display-table, and can be changed.
Right (though not, AFAICT, fully disabled, right?)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sun, 07 May 2017 02:31:01 GMT)
Full text and
rfc822 format available.
Message #197 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> Cc: rudalics <at> gmx.at, arthur.miller.no1 <at> gmail.com, 25408 <at> debbugs.gnu.org
> From: Clément Pit-Claudel <cpitclaudel <at> gmail.com>
> Date: Sat, 6 May 2017 17:01:14 -0400
>
> > Not sure why Martin asked, but to be more accurate: the actual glyphs
> > are stored in a display-table, and can be changed.
>
> Right (though not, AFAICT, fully disabled, right?)
Right.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sun, 07 May 2017 08:42:02 GMT)
Full text and
rfc822 format available.
Message #200 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>> Please try the attached patch (I only checked whether it compiles and
>>> builds on Windows). You have to add a non-nil 'no-special-glyphs' frame
>>> parameter to suppress such glyphs.
>>
>> Sorry, that patch was complete scrap. Hopefully, I'll come up with a
>> better one later.
>>
>> What do those glyphs look like - "\" for continuation and "$" for
>> truncation?
>
> Yup, exactly :) Thanks for your help!
Please try the revised patch I attached.
Thanks, martin
[no-special-glyphs.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sun, 07 May 2017 08:42:02 GMT)
Full text and
rfc822 format available.
Message #203 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> Not sure why Martin asked,
My initial attempts failed due to a number of silly bugs and I was no
more sure whether Clément and I even meant the same thing.
> but to be more accurate: the actual glyphs
> are stored in a display-table, and can be changed.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sun, 07 May 2017 17:21:02 GMT)
Full text and
rfc822 format available.
Message #206 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 07 May 2017 10:40:50 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 25408 <at> debbugs.gnu.org
>
> Please try the revised patch I attached.
Please test vertical cursor motion in frames with this parameter set,
including when visual-line-mode is turned on. There might be dragons.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sun, 07 May 2017 18:08:01 GMT)
Full text and
rfc822 format available.
Message #209 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> Please test vertical cursor motion in frames with this parameter set,
> including when visual-line-mode is turned on. There might be dragons.
I've seen nothing special here. But if you can think of a specific
location where they might hide please tell me.
Also, IIUC Clément has no intention to make such buffers scrollable,
editable or focusable. So if necessary we can also forbid such actions.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sun, 07 May 2017 18:34:01 GMT)
Full text and
rfc822 format available.
Message #212 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 07 May 2017 20:07:46 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: cpitclaudel <at> gmail.com, arthur.miller.no1 <at> gmail.com,
> 25408 <at> debbugs.gnu.org
>
> > Please test vertical cursor motion in frames with this parameter set,
> > including when visual-line-mode is turned on. There might be dragons.
>
> I've seen nothing special here. But if you can think of a specific
> location where they might hide please tell me.
What happens when the line is full-width, i.e. the last character is
flushed all the way to the right edge of the window? What happens
when you set wrap-prefix to some string value and then turn on
visual-line-mode in a buffer with lines longer than the window width?
> Also, IIUC Clément has no intention to make such buffers scrollable,
> editable or focusable. So if necessary we can also forbid such actions.
??? This is a general-purpose feature, not something created for a
single use case. And I don't quite see how you can forbid cursor
motion without also forbidding a lot of other useful features.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Mon, 08 May 2017 06:49:02 GMT)
Full text and
rfc822 format available.
Message #215 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> What happens when the line is full-width, i.e. the last character is
> flushed all the way to the right edge of the window?
Tested with normal continuation lines, truncated line and visual line
mode and all sorts of window widths. No problems.
> What happens
> when you set wrap-prefix to some string value and then turn on
> visual-line-mode in a buffer with lines longer than the window width?
No special problems found but for one: If the window is narrower than
the wrap-prefix, Emacs may hang with all processor cycles it can get.
But this is easily reproducible here without setting the new parameter.
I use the following recipe: With emacs -Q I evaluate
(let ((frame (make-frame)))
(find-file-noselect "dnd.el")
(set-window-buffer (frame-root-window frame) "dnd.el")
(with-current-buffer (window-buffer (frame-root-window frame))
(setq wrap-prefix "-------------")
(visual-line-mode 1)))
Then I make the new frame as narrow as possible by dragging one of its
borders with the mouse. Now alternatively using (1) <down> to move the
cursor towards the end of the buffer _and_ (2) <wheel-down> to scroll
the buffer end out of view sooner or later hangs my Emacs 25.2 here.
>> Also, IIUC Clément has no intention to make such buffers scrollable,
>> editable or focusable. So if necessary we can also forbid such actions.
>
> ??? This is a general-purpose feature, not something created for a
> single use case. And I don't quite see how you can forbid cursor
> motion without also forbidding a lot of other useful features.
We could treat such frames like tooltip frames. But I currently see no
need for such harsh measures.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Mon, 08 May 2017 14:42:02 GMT)
Full text and
rfc822 format available.
Message #218 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 08 May 2017 08:48:12 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: cpitclaudel <at> gmail.com, arthur.miller.no1 <at> gmail.com,
> 25408 <at> debbugs.gnu.org
>
> > What happens
> > when you set wrap-prefix to some string value and then turn on
> > visual-line-mode in a buffer with lines longer than the window width?
>
> No special problems found but for one: If the window is narrower than
> the wrap-prefix, Emacs may hang with all processor cycles it can get.
> But this is easily reproducible here without setting the new parameter.
This should probably be reported as a separate bug, but if it exists
with previous code, it's unrelated to this feature.
> >> Also, IIUC Clément has no intention to make such buffers scrollable,
> >> editable or focusable. So if necessary we can also forbid such actions.
> >
> > ??? This is a general-purpose feature, not something created for a
> > single use case. And I don't quite see how you can forbid cursor
> > motion without also forbidding a lot of other useful features.
>
> We could treat such frames like tooltip frames. But I currently see no
> need for such harsh measures.
Agreed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sat, 10 Jun 2017 15:39:01 GMT)
Full text and
rfc822 format available.
Message #221 received at 25408 <at> debbugs.gnu.org (full text, mbox):
I forgot that this bug is still open. Is it waiting for me to finish
up the NS stuff?
On Wed, Apr 19, 2017 at 08:07:05PM +0200, martin rudalics wrote:
> > Oh, I just remembered I’ve not yet done frame-list-z-order. It should
> > be easy enough, NSApplication has an orderedWindows function which, I
> > think, should return an ordered array of NSWindow objects.
>
> Please do that.
This is done.
> > Should I look into no-focus-on-map and no-accept-focus too?
>
> That would be fine. There's also the 'skip-taskbar' parameter but I
> have no idea whether NS allows that and whether NS provides Alt-tabbing.
no-accept-focus is done, but no-focus-on-map is harder. I believe I
can get a new frame to not be focused on creation, but I don’t see any
way to prevent a minimized frame from becoming focused when
unminimized.
macOS has alt‐tabbing between applications, but also alt‐` switches
between application windows. I haven’t yet found a way to disable
this.
FWIW, no-accept-focus, as implemented, prevents a frame from *ever*
accepting focus (although it can still accept input, which is
strange!). Rereading your description makes me wonder if I’ve done
that wrong and the current behaviour is closer to no-accept-focus,
no-focus-on-map and skip-taskbar all being on?
I’m not sure I can do it any other way, though.
> And please have a look into the Elisp manual: Maybe you find something
> worth mentioning (the fact that removing decorations removes the tool
> bar should certainly go there).
This is done.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sun, 11 Jun 2017 08:12:02 GMT)
Full text and
rfc822 format available.
Message #224 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> I forgot that this bug is still open. Is it waiting for me to finish
> up the NS stuff?
By no means. You've already accomplished much more than I would have
expected. I still want to check in the ‘no-special-glyphs’ parameter
code mentioned elsewhere in this thread. Then I intend to close this
bug.
>>> Should I look into no-focus-on-map and no-accept-focus too?
>>
>> That would be fine. There's also the 'skip-taskbar' parameter but I
>> have no idea whether NS allows that and whether NS provides Alt-tabbing.
>
> no-accept-focus is done, but no-focus-on-map is harder. I believe I
> can get a new frame to not be focused on creation, but I don’t see any
> way to prevent a minimized frame from becoming focused when
> unminimized.
Don't worry. Unminimizing is different from mapping. The former works
on already mapped frames only, the latter on invisible frames only.
"on-map" stands for "on making the frame visible" which might happen
some time after the frame was created. Once visible you cannot map the
frame until you make it invisible again.
Alt-tabbing and unminimizing OTOH work on visible frames only, you
cannot really unminimize an invisible window (although the window
manager might remember the requested fullscreen status somewhere and
later, when it makes the window visible, apply that state).
‘no-focus-on-map’ behaves well for all platforms and builds I tried so
far. It would be nice to have it for NS builds too. So all that is
afforded by ‘no-focus-on-map’ is that, whenever a frame changes from the
invisible to the visible state, it does not get focus.
> macOS has alt‐tabbing between applications, but also alt‐` switches
> between application windows. I haven’t yet found a way to disable
> this.
There's certainly no need to do that. I wouldn't even know how to type
alt-` with my keyboard layout.
> FWIW, no-accept-focus, as implemented, prevents a frame from *ever*
> accepting focus (although it can still accept input, which is
> strange!). Rereading your description makes me wonder if I’ve done
> that wrong and the current behaviour is closer to no-accept-focus,
> no-focus-on-map and skip-taskbar all being on?
‘no-accept-focus’ is not overly dear to me. I provided it because it
works out of the box on GNU Linux. But the workaround I wrote for
Windows is very harsh and I don't recommend it. The idea is to provide
a behavior similar to tooltips - you cannot focus a tooltip window -
with something like "but you can still focus it via C-x 5 o, if you
need to".
> I’m not sure I can do it any other way, though.
Never mind. If it has some very special behavior and you feel like it,
add a remark about it in the Elisp documentation.
>> And please have a look into the Elisp manual: Maybe you find something
>> worth mentioning (the fact that removing decorations removes the tool
>> bar should certainly go there).
This one still stupefies me because it's a deviation from the other
builds. It certainly should be documented. Did you document that a
fullscreen NS screen doesn't have a toolbar either?
BTW, I meanwhile wrote some code to resize and move undecorated frames
with the mouse. For this purpose I need some mouse pointers indicating
that a frame corner (not a frame edge) can be dragged. Under X I use
XC_top_left_corner, XC_top_right_corner, ... On Windows I use the
IDC_SIZENWSE and IDC_SIZENESW arrows. I have not found any equivalent
for NS. How does NS indicate that the corner of a decorated frame can
be dragged when the mouse is over it?
Thanks for all your work, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sun, 11 Jun 2017 16:36:02 GMT)
Full text and
rfc822 format available.
Message #227 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Jun 11, 2017 at 10:10:44AM +0200, martin rudalics wrote:
> > no-accept-focus is done, but no-focus-on-map is harder. I believe I
> > can get a new frame to not be focused on creation, but I don’t see any
> > way to prevent a minimized frame from becoming focused when
> > unminimized.
>
> Don't worry. Unminimizing is different from mapping. The former works
> on already mapped frames only, the latter on invisible frames only.
> "on-map" stands for "on making the frame visible" which might happen
> some time after the frame was created. Once visible you cannot map the
> frame until you make it invisible again.
>
> Alt-tabbing and unminimizing OTOH work on visible frames only, you
> cannot really unminimize an invisible window (although the window
> manager might remember the requested fullscreen status somewhere and
> later, when it makes the window visible, apply that state).
>
> ‘no-focus-on-map’ behaves well for all platforms and builds I tried so
> far. It would be nice to have it for NS builds too. So all that is
> afforded by ‘no-focus-on-map’ is that, whenever a frame changes from the
> invisible to the visible state, it does not get focus.
Your explanation made it much clearer what was required. I believe
I’ve got it sorted now. I’ve attached a patch.
> >> And please have a look into the Elisp manual: Maybe you find something
> >> worth mentioning (the fact that removing decorations removes the tool
> >> bar should certainly go there).
>
> This one still stupefies me because it's a deviation from the other
> builds. It certainly should be documented. Did you document that a
> fullscreen NS screen doesn't have a toolbar either?
It actually does, it’s just hidden, along with the title‐bar and
menu‐bar. At least that’s how it works on macOS, I’m unsure how
GNUStep deals with full‐screen as it’s using a different mechanism, if
it handles it at all.
I’m struggling to find where this should be documented. Any ideas
which part of the manual covers full‐screen?
> BTW, I meanwhile wrote some code to resize and move undecorated frames
> with the mouse. For this purpose I need some mouse pointers indicating
> that a frame corner (not a frame edge) can be dragged. Under X I use
> XC_top_left_corner, XC_top_right_corner, ... On Windows I use the
> IDC_SIZENWSE and IDC_SIZENESW arrows. I have not found any equivalent
> for NS. How does NS indicate that the corner of a decorated frame can
> be dragged when the mouse is over it?
macOS uses double‐headed diagonal arrows, but they’re undocumented:
https://stackoverflow.com/questions/27242353/cocoa-predefined-resize-mouse-cursor
GNUStep doesn’t implement them and doesn’t seem to have any
equivalent.
On macOS we can actually make undecorated frames resizable quite
easily just by including the resizable style mask. GNUstep doesn’t
like that, of course.
--
Alan Third
[0001-Add-no-focus-on-map-to-NS-build-bug-25408.patch (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Mon, 12 Jun 2017 06:10:02 GMT)
Full text and
rfc822 format available.
Message #230 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> Your explanation made it much clearer what was required. I believe
> I’ve got it sorted now. I’ve attached a patch.
The second part of this comment
/* --------------------------------------------------------------------------
Bring window to foreground and make it active
-------------------------------------------------------------------------- */
seems to be a bit misleading then.
> I’m struggling to find where this should be documented. Any ideas
> which part of the manual covers full‐screen?
The Elisp manual in section 29.4.3.3 Size Parameters.
> macOS uses double‐headed diagonal arrows, but they’re undocumented:
>
> https://stackoverflow.com/questions/27242353/cocoa-predefined-resize-mouse-cursor
In NSCursor.h I can find these
+ (id)_windowResizeNorthWestSouthEastCursor;
+ (id)_windowResizeNorthEastSouthWestCursor;
But there I see also
+ (id)_windowResizeSouthWestCursor;
+ (id)_windowResizeSouthEastCursor;
+ (id)_windowResizeNorthWestCursor;
+ (id)_windowResizeNorthEastCursor;
so NS apparently can implement both, the X and the Windows ones.
> GNUStep doesn’t implement them and doesn’t seem to have any
> equivalent.
>
> On macOS we can actually make undecorated frames resizable quite
> easily just by including the resizable style mask. GNUstep doesn’t
> like that, of course.
I added code for manual mouse-moving and -resizing of frames because
under X there's apparently no support to do that for child frames.
Since the Windows API provides such support I have to find some
substitute on X and want to make that as uniform as possible for other
platforms as well.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Mon, 12 Jun 2017 18:00:02 GMT)
Full text and
rfc822 format available.
Message #233 received at 25408 <at> debbugs.gnu.org (full text, mbox):
On Mon, Jun 12, 2017 at 08:09:03AM +0200, martin rudalics wrote:
> > Your explanation made it much clearer what was required. I believe
> > I’ve got it sorted now. I’ve attached a patch.
>
> The second part of this comment
>
> /* --------------------------------------------------------------------------
> Bring window to foreground and make it active
> -------------------------------------------------------------------------- */
>
> seems to be a bit misleading then.
Very good point. I’ve fixed it and pushed it to master.
Anything else you’d like me to look at here?
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Tue, 13 Jun 2017 07:26:01 GMT)
Full text and
rfc822 format available.
Message #236 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> Very good point. I’ve fixed it and pushed it to master.
Thanks.
> Anything else you’d like me to look at here?
For the moment no. I'll get back to you when I push the remaining
parts of the child frame code.
Thanks again for all the good work, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Thu, 22 Jun 2017 09:12:02 GMT)
Full text and
rfc822 format available.
Message #239 received at 25408 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Anything else you’d like me to look at here?
Attached find the changes I intend to push in the next few days plus a
ChangeLog. You will find this particular change there:
+ f->output_data.ns->left_edge_cursor = [NSCursor resizeLeftRightCursor];
+ f->output_data.ns->top_left_corner_cursor = [NSCursor arrowCursor];
+ f->output_data.ns->top_edge_cursor = [NSCursor resizeUpDownCursor];
+ f->output_data.ns->top_right_corner_cursor = [NSCursor arrowCursor];
+ f->output_data.ns->right_edge_cursor = [NSCursor resizeLeftRightCursor];
+ f->output_data.ns->bottom_right_corner_cursor = [NSCursor arrowCursor];
+ f->output_data.ns->bottom_edge_cursor = [NSCursor resizeUpDownCursor];
+ f->output_data.ns->bottom_left_corner_cursor = [NSCursor arrowCursor];
It would be nice to have something better on NS for the
top_left_corner_cursor, top_right_corner_cursor,
bottom_right_corner_cursor and bottom_left_corner_cursor cases.
If you want to play around with child frames, try the attached file
my-child-frame.el. Any feedback welcome.
Thanks in advance, martin
[child-frames.diff (text/plain, attachment)]
[ChangeLog (text/plain, attachment)]
[my-child-frame.el (application/emacs-lisp, attachment)]
Reply sent
to
martin rudalics <rudalics <at> gmx.at>:
You have taken responsibility.
(Sun, 25 Jun 2017 11:03:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Arthur Miller <arthur.miller.no1 <at> gmail.com>:
bug acknowledged by developer.
(Sun, 25 Jun 2017 11:03:02 GMT)
Full text and
rfc822 format available.
Message #244 received at 25408-done <at> debbugs.gnu.org (full text, mbox):
> I've run into another small issue: there doesn't seem to be a way to
> turn off truncation marks in tooltip frames. Is that correct? This bit
> of xdisp.c seems to take care of that for Emacs' default tip frame; is
> there a way to emulate this for Lisp-created frames?
Truncation glyphs can be now turned off via the 'no-special-glyphs'
frame parameter. Closing this bug.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sun, 25 Jun 2017 14:23:02 GMT)
Full text and
rfc822 format available.
Message #247 received at 25408 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jun 22, 2017 at 11:10:54AM +0200, martin rudalics wrote:
> > Anything else you’d like me to look at here?
>
> Attached find the changes I intend to push in the next few days plus a
> ChangeLog. You will find this particular change there:
>
> + f->output_data.ns->left_edge_cursor = [NSCursor resizeLeftRightCursor];
> + f->output_data.ns->top_left_corner_cursor = [NSCursor arrowCursor];
> + f->output_data.ns->top_edge_cursor = [NSCursor resizeUpDownCursor];
> + f->output_data.ns->top_right_corner_cursor = [NSCursor arrowCursor];
> + f->output_data.ns->right_edge_cursor = [NSCursor resizeLeftRightCursor];
> + f->output_data.ns->bottom_right_corner_cursor = [NSCursor arrowCursor];
> + f->output_data.ns->bottom_edge_cursor = [NSCursor resizeUpDownCursor];
> + f->output_data.ns->bottom_left_corner_cursor = [NSCursor arrowCursor];
>
> It would be nice to have something better on NS for the
> top_left_corner_cursor, top_right_corner_cursor,
> bottom_right_corner_cursor and bottom_left_corner_cursor cases.
Maybe we could add a couple of custom cursors, it looks like there’s a
way to do that. Do we have a standard set of cursor images to use?
> If you want to play around with child frames, try the attached file
> my-child-frame.el. Any feedback welcome.
I’ve just been playing about with your child frame script and I think
I’ve found a few bugs in the NS port:
It appears that making the child frame invisible ‘disconnects’ it from
the parent frame, so the next time it’s made visible it no longer
moves with the parent. I guess I’ll have to make sure that when a
frame is made visible it’s reconnected with it’s parent. Or find a way
to prevent it disconnecting. It seems a really odd thing for it to do.
Resizing the child frame with the mouse doesn’t work, is it supposed
to?
(set-face-background 'internal-border "blue" my-child-frame)
makes me think the child frame should have a blue border, but it
doesn’t. Is that a bug?
Thanks!
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sun, 25 Jun 2017 16:00:02 GMT)
Full text and
rfc822 format available.
Message #250 received at 25408 <at> debbugs.gnu.org (full text, mbox):
> Maybe we could add a couple of custom cursors, it looks like there’s a
> way to do that. Do we have a standard set of cursor images to use?
No idea. IIUC there's no consensus on what is available on the various
OS.
> It appears that making the child frame invisible ‘disconnects’ it from
> the parent frame, so the next time it’s made visible it no longer
> moves with the parent. I guess I’ll have to make sure that when a
> frame is made visible it’s reconnected with it’s parent. Or find a way
> to prevent it disconnecting. It seems a really odd thing for it to do.
Annoying. A similar thing happens with the z-group property on X where
I reinstall it from its stored value whenever the frame becomes visible
(see lines 8108--8111 in xterm.c). I suppose we should do something
similar on NS. And maybe that's not the only property that gets reset
here or there ...
> Resizing the child frame with the mouse doesn’t work, is it supposed
> to?
Definitely. Do you see an internal border? Do you see a changing
cursor at that border when the mouse is over it? And can you move the
frame by dragging its mode or header line?
> (set-face-background 'internal-border "blue" my-child-frame)
>
> makes me think the child frame should have a blue border, but it
> doesn’t. Is that a bug?
It doesn't get the border on Windows right away either. IMHO the face
remapping code is not up to this everywhere, it might even work with GTK
only. Try to set the 'internal-border' face via defcustom and tell me
whether it works.
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sun, 25 Jun 2017 16:24:01 GMT)
Full text and
rfc822 format available.
Message #253 received at 25408-done <at> debbugs.gnu.org (full text, mbox):
On 2017-06-25 07:02, martin rudalics wrote:
>> I've run into another small issue: there doesn't seem to be a way to
>> turn off truncation marks in tooltip frames. Is that correct? This bit
>> of xdisp.c seems to take care of that for Emacs' default tip frame; is
>> there a way to emulate this for Lisp-created frames?
>
> Truncation glyphs can be now turned off via the 'no-special-glyphs'
> frame parameter. Closing this bug.
Thanks for all the hard work!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sat, 15 Jul 2017 21:28:01 GMT)
Full text and
rfc822 format available.
Message #256 received at 25408 <at> debbugs.gnu.org (full text, mbox):
On Sun, Jun 25, 2017 at 05:58:49PM +0200, martin rudalics wrote:
> > It appears that making the child frame invisible ‘disconnects’ it from
> > the parent frame, so the next time it’s made visible it no longer
> > moves with the parent. I guess I’ll have to make sure that when a
> > frame is made visible it’s reconnected with it’s parent. Or find a way
> > to prevent it disconnecting. It seems a really odd thing for it to do.
I’ve pushed a fix for this now.
> > Resizing the child frame with the mouse doesn’t work, is it supposed
> > to?
>
> Definitely. Do you see an internal border? Do you see a changing
> cursor at that border when the mouse is over it? And can you move the
> frame by dragging its mode or header line?
It turned out that there was no NS version of
mouse-absolute-pixel-position, so I’ve created one and suddenly all of
the above things work. :)
I’m slightly worried that there may be issues if the frame is resized
across a screen edge, as it treats each screen as it’s own ‘space’,
starting at (0, 0) at the top left. This is how the existing
set-mouse-absolute-pixel-position works so it makes sense to me to
keep them the same.
It might make more sense to treat multiple screens as one ‘space’,
though. I’m not sure.
--
Alan Third
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#25408; Package
emacs.
(Sun, 16 Jul 2017 08:29:02 GMT)
Full text and
rfc822 format available.
Message #259 received at 25408 <at> debbugs.gnu.org (full text, mbox):
>>> It appears that making the child frame invisible ‘disconnects’ it from
>>> the parent frame, so the next time it’s made visible it no longer
>>> moves with the parent. I guess I’ll have to make sure that when a
>>> frame is made visible it’s reconnected with it’s parent. Or find a way
>>> to prevent it disconnecting. It seems a really odd thing for it to do.
>
> I’ve pushed a fix for this now.
Thanks. One of the largely untested behaviors with frames is what a
frame looks like when it was invisible/iconified for a while, in that
period operations (resizing, moving, reparenting) have been applied to
it and the frame is made normally visible again. I've been struggling a
while with the similar problem how to set a frame's size when it was
fullscreen for a while and in that period a resize request was posted
for it.
> It turned out that there was no NS version of
> mouse-absolute-pixel-position, so I’ve created one and suddenly all of
> the above things work. :)
Fine. Please add a
(declare-function ns-mouse-absolute-pixel-position "nsfns.c")
to frame.el.
> I’m slightly worried that there may be issues if the frame is resized
> across a screen edge, as it treats each screen as it’s own ‘space’,
> starting at (0, 0) at the top left. This is how the existing
> set-mouse-absolute-pixel-position works so it makes sense to me to
> keep them the same.
>
> It might make more sense to treat multiple screens as one ‘space’,
> though. I’m not sure.
Can you give me an example? I never use multiple screens so my ability
to imagine how a mouse behaves there is very limited. There's also the
problem that some systems (Windows, IIRC) consider (0, 0) the top-left
corner of some sort of "primary" screen and allow negative coordinates
while others consider (0, 0) an abstract location at the top-left corner
of all screens.
Thanks, martin
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 13 Aug 2017 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 7 years and 314 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.