[PATCH] Allow passing frame parameters to emacsclient

[PATCH] Allow passing frame parameters to emacsclient

[Andreas Rottmann]

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

where to send patches [was Re: [PATCH] Allow passing frame parameters to emacsclient]

[Glenn Morris]

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.

Re: where to send patches [was Re: [PATCH] Allow passing frame parameters to emacsclient]

[Andreas Rottmann]

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

Re: where to send patches [was Re: [PATCH] Allow passing frame parameters to emacsclient]

[Stefan Monnier]

> 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

Re: where to send patches

[Glenn Morris]

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?

Re: where to send patches

[Chong Yidong]

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.

Re: where to send patches

[Glenn Morris]

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.

Re: where to send patches

[Stefan Monnier]

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

Re: where to send patches

[Wojciech Meyer]

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