Why not processing emacsclient's command line arguments with user defined functions?

Why not processing emacsclient's command line arguments with user defined functions?

[Constantin Kulikov]

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

For the emacs server we have command-switch-alist and
command-line-functions:
http://www.gnu.org/software/emacs/manual/html_node/elisp/Command_002dLine-Arguments.html

Why not apply that to emacsclient's "unrecognized" arguments?

// It could also solve this and alike(and it'l be useful for my personal
needs too):
http://emacs.1067599.n5.nabble.com/PATCH-add-emacsclient-support-to-open-with-file-linum-syntax-tp383378.html

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

Re: Why not processing emacsclient's command line arguments with user defined functions?

[Jorge Alberto Garcia]

On Sat, Jan 16, 2016 at 10:57 AM, Constantin Kulikov
<zxnotdead@gmail.com> wrote:
> For the emacs server we have command-switch-alist and
> command-line-functions:
> http://www.gnu.org/software/emacs/manual/html_node/elisp/Command_002dLine-Arguments.html
>
> Why not apply that to emacsclient's "unrecognized" arguments?
>
Can you elaborate ?

> // It could also solve this and alike(and it'l be useful for my personal
> needs too):
> http://emacs.1067599.n5.nabble.com/PATCH-add-emacsclient-support-to-open-with-file-linum-syntax-tp383378.html

Re: Why not processing emacsclient's command line arguments with user defined functions?

[Constantin Kulikov]

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

> Can you elaborate

What to eleborate here? You want a new feature for emacsclient so you go
and patch C source. Tomorrow you'l want a new commandline option.
So why no one here think about general solutions?

Emacslisp solution is always better than C. (Hooks, hooks must be
everywhere in emacs)

How it could be implemented:
(I'd say that we can use the same command-line-functions and
command-switch-alist but it could break backward compatibility, so it'll
better to use a new variables I think -- emacs-client-argumet-string or
something.)

1. emacsclient searches for 'connection related' arguments because they are
needed to know how to connect to the daemon.
2. emacsclient sends the full arguments string to the server.
3. server calls user(and predefined) hooks which must examine and do
manipulations on that string.

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

Re: Why not processing emacsclient's command line arguments with user defined functions?

[Jorge Alberto Garcia]

On Mon, Jan 18, 2016 at 1:10 AM, Constantin Kulikov <zxnotdead@gmail.com> wrote:
>> Can you elaborate
>
> What to eleborate here? You want a new feature for emacsclient so you go and
> patch C source. Tomorrow you'l want a new commandline option.

Hi !
This specific feature works at the same layer that the current
+line:col option; implemented at emacsclient.c,

> So why no one here think about general solutions?
>
I agree on having an infrastructure to handle command line options, this patch
uses what is available right now.

> Emacslisp solution is always better than C. (Hooks, hooks must be everywhere
> in emacs)
If you mean an elisp hook is usually better than C, I would agree.

>
> How it could be implemented:
> (I'd say that we can use the same command-line-functions and
> command-switch-alist but it could break backward compatibility, so it'll
> better to use a new variables I think -- emacs-client-argumet-string or
> something.)
>
Thanks I didn't  knew about this.

> 1. emacsclient searches for 'connection related' arguments because they are
> needed to know how to connect to the daemon.
> 2. emacsclient sends the full arguments string to the server.
> 3. server calls user(and predefined) hooks which must examine and do
> manipulations on that string.


Feel free to send a proposal,
If a new implementation is better,  I would be happy to use it on next
emacs release.

>