* [PATCH] Allow passing frame parameters to emacsclient
@ 2011-02-26 17:32 Andreas Rottmann
2011-03-07 21:44 ` where to send patches [was Re: [PATCH] Allow passing frame parameters to emacsclient] Glenn Morris
0 siblings, 1 reply; 9+ messages in thread
From: Andreas Rottmann @ 2011-02-26 17:32 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]
Hi!
This is the first patch I submit for Emacs, so I hope I followed all the
rules :-). I initially submitted a now-stale version of the patch as a
bugreport[0] -- I assume I should close this, as patches are to be
submitted and discussed on this mailinglist (or bug-gnu-emacs@gnu.org),
right?
Another thing: the patch is relatively small, but I guess it might be
over the no-copyright-assignment-needed limit; if this is the case,
please tell me so I can request papers from FSF for Emacs (and Org-Mode,
while I'm at it). I have already signed papers for Guile, but I guess I
need to do this again for Emacs(?).
A description and rationale for the feature as well as ChangeLog entries
are in the patch headers, see below. As for my personal use-case: I'd
like to create new frames using emacsclient for Email (Gnus) and IRC
(rcirc) and have my window manager (awesome[1]) put these frames on a
fixed tag (= virtual desktop). The attached patch makes this possible
by allowing to influence e.g. the frame name at frame creation time.
You could do that before using "--eval", but that would set the
properties only after the frame has already been created.
[0] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5864
[1] http://awesome.naquadah.org/
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: frame-params.diff --]
[-- Type: text/x-diff, Size: 7633 bytes --]
From: Andreas Rottmann <a.rottmann@gmx.at>
Subject: Allow passing frame parameters to emacsclient
Adds a new option `--frame-parameters' to emacsclient, which allows to
set the frame parameter alist for the to-be-created frame.
This feature is useful for window managers that allow matching on X
properties. Without this patch, it is not possible to influence those
at /frame creation time/, they could only be set after the frame was
already created. This is too late for windowmanagers who match the X
properties at frame creation time.
* lib-src/emacsclient.c (frame_parameters): New global variable.
(longopts): New entry "frame-parameters" with short option alias
'F'.
(decode_options): Process frame-parameters option.
(main): Send value of frame-parameters option to emacs if we are
constructing a new frame.
* lisp/servel.el (server-create-window-system-frame): Add new optional
argument `parameters' which allows setting additional frame
parameters.
(server-process-filter): Handle "-frame-parameters" command, and
pass its value to `server-create-window-system-frame'
* doc/emacs/misc.texi (Invoking emacsclient): Document the
"--frame-parameters" option.
* doc/man/emacsclient.1: Ditto.
---
doc/emacs/misc.texi | 5 +++++
doc/man/emacsclient.1 | 3 +++
etc/NEWS | 4 ++++
lib-src/emacsclient.c | 16 ++++++++++++++++
lisp/server.el | 23 ++++++++++++++++++++---
5 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/doc/emacs/misc.texi b/doc/emacs/misc.texi
index d7143d1..99e5fbf 100644
--- a/doc/emacs/misc.texi
+++ b/doc/emacs/misc.texi
@@ -1622,6 +1622,11 @@ text-only terminal frame (@pxref{Frames}). If you omit a filename
argument while supplying the @samp{-c} option, the new frame displays
the @samp{*scratch*} buffer (@pxref{Buffers}).
+@item -F
+@itemx --frame-parameters=@var{alist}
+Set the parameters for a newly-created graphical frame. @xref{Frame
+Parameters}.
+
@item -d @var{display}
@itemx --display=@var{display}
Tell Emacs to open the given files on the X display @var{display}
diff --git a/doc/man/emacsclient.1 b/doc/man/emacsclient.1
index cae4d76..4843053 100644
--- a/doc/man/emacsclient.1
+++ b/doc/man/emacsclient.1
@@ -58,6 +58,9 @@ daemon mode and emacsclient will try to connect to it.
.B -c, \-\-create-frame
create a new frame instead of trying to use the current Emacs frame
.TP
+.B \-F, \-\-frame-parameters=ALIST
+set the parameters of a newly-created frame.
+.TP
.B \-d, \-\-display=DISPLAY
tell the server to display the files on the given display.
.TP
diff --git a/etc/NEWS b/etc/NEWS
index cfb7889..0c904bc 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -71,6 +71,10 @@ from load-path. -Q now implies this.
client frame in parent X window ID, via XEmbed. This works like the
--parent-id argument to Emacs.
++++
+*** New emacsclient argument --frame-parameters can be used to set the
+frame parameters of a newly-created graphical frame.
+
*** If emacsclient shuts down as a result of Emacs signalling an
error, its exit status is 1.
diff --git a/lib-src/emacsclient.c b/lib-src/emacsclient.c
index 836891a..e76e8bf 100644
--- a/lib-src/emacsclient.c
+++ b/lib-src/emacsclient.c
@@ -157,6 +157,10 @@ const char *server_file = NULL;
/* PID of the Emacs server process. */
int emacs_pid = 0;
+/* If non-NULL, a string that should form a frame parameter alist to
+ be used for the new frame */
+const char *frame_parameters = NULL;
+
static void print_help_and_exit (void) NO_RETURN;
static void fail (void) NO_RETURN;
@@ -171,6 +175,7 @@ struct option longopts[] =
{ "nw", no_argument, NULL, 't' },
{ "create-frame", no_argument, NULL, 'c' },
{ "alternate-editor", required_argument, NULL, 'a' },
+ { "frame-parameters", required_argument, NULL, 'F' },
#ifndef NO_SOCKETS_IN_FILE_SYSTEM
{ "socket-name", required_argument, NULL, 's' },
#endif
@@ -592,6 +597,10 @@ decode_options (int argc, char **argv)
print_help_and_exit ();
break;
+ case 'F':
+ frame_parameters = optarg;
+ break;
+
default:
message (TRUE, "Try `%s --help' for more information\n", progname);
exit (EXIT_FAILURE);
@@ -1622,6 +1631,13 @@ main (int argc, char **argv)
send_to_emacs (emacs_socket, " ");
}
+ if (frame_parameters && !current_frame)
+ {
+ send_to_emacs (emacs_socket, "-frame-parameters ");
+ quote_argument (emacs_socket, frame_parameters);
+ send_to_emacs (emacs_socket, " ");
+ }
+
/* If using the current frame, send tty information to Emacs anyway.
In daemon mode, Emacs may need to occupy this tty if no other
frame is available. */
diff --git a/lisp/server.el b/lisp/server.el
index df8cae0..2a883bd 100644
--- a/lisp/server.el
+++ b/lisp/server.el
@@ -728,7 +728,11 @@ Server mode runs a process that accepts commands from the
frame))
-(defun server-create-window-system-frame (display nowait proc parent-id)
+(defun server-create-window-system-frame (display
+ nowait
+ proc
+ parent-id
+ &optional parameters)
(add-to-list 'frame-inherited-parameters 'client)
(if (not (fboundp 'make-frame-on-display))
(progn
@@ -743,7 +747,8 @@ Server mode runs a process that accepts commands from the
;; killing emacs on that frame.
(let* ((params `((client . ,(if nowait 'nowait proc))
;; This is a leftover, see above.
- (environment . ,(process-get proc 'env))))
+ (environment . ,(process-get proc 'env))
+ ,@parameters))
(display (or display
(frame-parameter nil 'display)
(getenv "DISPLAY")
@@ -825,6 +830,9 @@ The following commands are accepted by the server:
`-current-frame'
Forbid the creation of new frames.
+`-frame-parameters ALIST'
+ Set the parameters of the created frame.
+
`-nowait'
Request that the next frame created should not be
associated with this client.
@@ -933,6 +941,7 @@ The following commands are accepted by the client:
commands
dir
use-current-frame
+ frame-parameters ;parameters for newly created frame
tty-name ; nil, `window-system', or the tty name.
tty-type ; string.
files
@@ -953,6 +962,13 @@ The following commands are accepted by the client:
;; -current-frame: Don't create frames.
(`"-current-frame" (setq use-current-frame t))
+ ;; -frame-parameters: Set frame parameters
+ (`"-frame-parameters"
+ (lexical-let ((alist (pop args-left)))
+ (if coding-system
+ (setq alist (decode-coding-string alist coding-system)))
+ (setq frame-parameters (car (read-from-string alist)))))
+
;; -display DISPLAY:
;; Open X frames on the given display instead of the default.
(`"-display"
@@ -1068,7 +1084,8 @@ The following commands are accepted by the client:
(if display (server-select-display display)))
((eq tty-name 'window-system)
(server-create-window-system-frame display nowait proc
- parent-id))
+ parent-id
+ frame-parameters))
;; When resuming on a tty, tty-name is nil.
(tty-name
(server-create-tty-frame tty-name tty-type proc))))
--
tg: (498f0e8..) t/frame-params (depends on: master)
[-- Attachment #3: Type: text/plain, Size: 68 bytes --]
Kind Regards, Rotty
--
Andreas Rottmann -- <http://rotty.yi.org/>
^ permalink raw reply related [flat|nested] 9+ messages in thread
* where to send patches [was Re: [PATCH] Allow passing frame parameters to emacsclient]
2011-02-26 17:32 [PATCH] Allow passing frame parameters to emacsclient Andreas Rottmann
@ 2011-03-07 21:44 ` Glenn Morris
2011-03-07 22:29 ` Andreas Rottmann
2011-03-08 2:05 ` Stefan Monnier
0 siblings, 2 replies; 9+ messages in thread
From: Glenn Morris @ 2011-03-07 21:44 UTC (permalink / raw)
To: Andreas Rottmann; +Cc: emacs-devel
Andreas Rottmann wrote:
> This is the first patch I submit for Emacs, so I hope I followed all the
> rules :-). I initially submitted a now-stale version of the patch as a
> bugreport[0] -- I assume I should close this, as patches are to be
> submitted and discussed on this mailinglist (or bug-gnu-emacs@gnu.org),
> right?
Thank you for writing a patch, and I'm sorry no-one has really replied
about it yet, but why not just followup to your original report with a
revised version? How is anyone reading the report supposed to know a
newer version exists?
I forwarded the revised version to the report.
I strongly advise everybody sending in patches that add features or fix
bugs to send them to bug-gnu-emacs (which should really be thought of as
the bug and/or feature list). I feel like I've said this a lot, so
people either disagree or aren't noticing. So I'll probably stop saying
it. Forwarding things there is a bit of a chore, and I may not always
bother.
I know emacs-devel has more traffic, but I'm not sure that indicates much.
The bug-gnu-emacs list is coupled with a tracking system that makes
patches much easier to locate, even years later. I'm not aware of anyone
searching emacs-devel for old patches to apply. Maybe people are using
the "keep in their INBOX" method of tracking things though.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: where to send patches [was Re: [PATCH] Allow passing frame parameters to emacsclient]
2011-03-07 21:44 ` where to send patches [was Re: [PATCH] Allow passing frame parameters to emacsclient] Glenn Morris
@ 2011-03-07 22:29 ` Andreas Rottmann
2011-03-08 2:05 ` Stefan Monnier
1 sibling, 0 replies; 9+ messages in thread
From: Andreas Rottmann @ 2011-03-07 22:29 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
Glenn Morris <rgm@gnu.org> writes:
> Andreas Rottmann wrote:
>
>> This is the first patch I submit for Emacs, so I hope I followed all the
>> rules :-). I initially submitted a now-stale version of the patch as a
>> bugreport[0] -- I assume I should close this, as patches are to be
>> submitted and discussed on this mailinglist (or bug-gnu-emacs@gnu.org),
>> right?
>
> Thank you for writing a patch, and I'm sorry no-one has really replied
> about it yet, but why not just followup to your original report with a
> revised version? How is anyone reading the report supposed to know a
> newer version exists?
>
Yeah, my bad. I was a bit confused about where to send the patch.
> I forwarded the revised version to the report.
>
Thanks! There's a minor conflict in NEWS now, I'll attach an updated
revision of the patch to the bug report.
> I strongly advise everybody sending in patches that add features or
> fix bugs to send them to bug-gnu-emacs (which should really be thought
> of as the bug and/or feature list). I feel like I've said this a lot,
> so people either disagree or aren't noticing.
>
I'll certainly send future patches to bug-gnu-emacs. If this is the
clear preference, perhaps etc/CONTRIBUTE should be changed to mention
only bug-gnu-emacs.
> So I'll probably stop saying it. Forwarding things there is a bit of a
> chore, and I may not always bother. I know emacs-devel has more
> traffic, but I'm not sure that indicates much.
>
> The bug-gnu-emacs list is coupled with a tracking system that makes
> patches much easier to locate, even years later. I'm not aware of anyone
> searching emacs-devel for old patches to apply. Maybe people are using
> the "keep in their INBOX" method of tracking things though.
Regards & thanks again, Rotty
--
Andreas Rottmann -- <http://rotty.yi.org/>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: where to send patches [was Re: [PATCH] Allow passing frame parameters to emacsclient]
2011-03-07 21:44 ` where to send patches [was Re: [PATCH] Allow passing frame parameters to emacsclient] Glenn Morris
2011-03-07 22:29 ` Andreas Rottmann
@ 2011-03-08 2:05 ` Stefan Monnier
2011-03-09 19:50 ` where to send patches Glenn Morris
1 sibling, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2011-03-08 2:05 UTC (permalink / raw)
To: Glenn Morris; +Cc: Andreas Rottmann, emacs-devel
> I strongly advise everybody sending in patches that add features or fix
> bugs to send them to bug-gnu-emacs (which should really be thought of as
> the bug and/or feature list).
Agreed. It occurred to me that we could even tweak M-x report-emacs-bug
so that it notices when the report includes something that looks like
a patch, and adds the corresponding debbugs tag.
Stefan
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: where to send patches
2011-03-08 2:05 ` Stefan Monnier
@ 2011-03-09 19:50 ` Glenn Morris
2011-03-09 20:24 ` Chong Yidong
2011-03-10 2:26 ` Stefan Monnier
0 siblings, 2 replies; 9+ messages in thread
From: Glenn Morris @ 2011-03-09 19:50 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Andreas Rottmann, emacs-devel
Stefan Monnier wrote:
> Agreed. It occurred to me that we could even tweak M-x report-emacs-bug
> so that it notices when the report includes something that looks like
> a patch, and adds the corresponding debbugs tag.
People like to use this damn [PATCH] convention, so some time ago I
tweaked debbugs.gnu.org to recognize that in the same way as "Tags:
patch".
I did think about adding "Severity: normal" to the M-x report-emacs-bug
boilerplate, and inviting people to adjust it if they wished. But maybe
it makes reporting more complicated for little gain?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: where to send patches
2011-03-09 19:50 ` where to send patches Glenn Morris
@ 2011-03-09 20:24 ` Chong Yidong
2011-03-09 20:31 ` Glenn Morris
2011-03-10 2:26 ` Stefan Monnier
1 sibling, 1 reply; 9+ messages in thread
From: Chong Yidong @ 2011-03-09 20:24 UTC (permalink / raw)
To: Glenn Morris; +Cc: Andreas Rottmann, Stefan Monnier, emacs-devel
Glenn Morris <rgm@gnu.org> writes:
> I did think about adding "Severity: normal" to the M-x report-emacs-bug
> boilerplate, and inviting people to adjust it if they wished. But maybe
> it makes reporting more complicated for little gain?
It should be for Emacs developers to decide bug severity, not the
reporters.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: where to send patches
2011-03-09 20:24 ` Chong Yidong
@ 2011-03-09 20:31 ` Glenn Morris
0 siblings, 0 replies; 9+ messages in thread
From: Glenn Morris @ 2011-03-09 20:31 UTC (permalink / raw)
To: Chong Yidong; +Cc: Andreas Rottmann, Stefan Monnier, emacs-devel
Chong Yidong wrote:
>> I did think about adding "Severity: normal" to the M-x report-emacs-bug
>> boilerplate, and inviting people to adjust it if they wished. But maybe
>> it makes reporting more complicated for little gain?
>
> It should be for Emacs developers to decide bug severity, not the
> reporters.
Ultimately, yes, but people can suggest what they think the severity
should be. Minor for a doc typo, wishlist for a feature (anything with
"feature request" etc in the subject is automatically classified as
wishlist), important for a crash, etc. They have been able to do this
for as long as we have been using debbugs. But I agree that it is not
hugely helpful by itself.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: where to send patches
2011-03-09 19:50 ` where to send patches Glenn Morris
2011-03-09 20:24 ` Chong Yidong
@ 2011-03-10 2:26 ` Stefan Monnier
2011-03-20 23:06 ` Wojciech Meyer
1 sibling, 1 reply; 9+ messages in thread
From: Stefan Monnier @ 2011-03-10 2:26 UTC (permalink / raw)
To: Glenn Morris; +Cc: Andreas Rottmann, emacs-devel
>> Agreed. It occurred to me that we could even tweak M-x report-emacs-bug
>> so that it notices when the report includes something that looks like
>> a patch, and adds the corresponding debbugs tag.
> People like to use this damn [PATCH] convention, so some time ago I
> tweaked debbugs.gnu.org to recognize that in the same way as "Tags:
> patch".
That's good, but I think we should try and recognize the patch itself as
well, since many people don't put any [PATCH] in the subject either.
> I did think about adding "Severity: normal" to the M-x report-emacs-bug
> boilerplate, and inviting people to adjust it if they wished. But maybe
> it makes reporting more complicated for little gain?
Indeed, I think the gain would be very small. Especially since it's not
obvious for the reporter to know what other severities are valid.
Stefan
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: where to send patches
2011-03-10 2:26 ` Stefan Monnier
@ 2011-03-20 23:06 ` Wojciech Meyer
0 siblings, 0 replies; 9+ messages in thread
From: Wojciech Meyer @ 2011-03-20 23:06 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Andreas Rottmann, emacs-devel
Hi Stefan,
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Agreed. It occurred to me that we could even tweak M-x report-emacs-bug
>>> so that it notices when the report includes something that looks like
>>> a patch, and adds the corresponding debbugs tag.
>> People like to use this damn [PATCH] convention, so some time ago I
>> tweaked debbugs.gnu.org to recognize that in the same way as "Tags:
>> patch".
>
> That's good, but I think we should try and recognize the patch itself as
> well, since many people don't put any [PATCH] in the subject either.
Another point is that some VCS allow to format the patch automatically
along with an e-mail and put [PATCH] in the e-mail's subject header. I
would say that git-send-mail and git-format-patch do this. I am not sure
if bzr does it. Many people use format-patch and just paste it to the
e-mail subject. The chapter in the manual describes the process well
however it's not saying anything about the subject of the e-mail.
Thanks,
Wojciech
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-03-20 23:06 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-26 17:32 [PATCH] Allow passing frame parameters to emacsclient Andreas Rottmann
2011-03-07 21:44 ` where to send patches [was Re: [PATCH] Allow passing frame parameters to emacsclient] Glenn Morris
2011-03-07 22:29 ` Andreas Rottmann
2011-03-08 2:05 ` Stefan Monnier
2011-03-09 19:50 ` where to send patches Glenn Morris
2011-03-09 20:24 ` Chong Yidong
2011-03-09 20:31 ` Glenn Morris
2011-03-10 2:26 ` Stefan Monnier
2011-03-20 23:06 ` Wojciech Meyer
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).