Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make signal trigger more useful by making pointer data an actual pointer instead of just extra var #450

Closed
unzan opened this Issue Jun 23, 2015 · 6 comments

Comments

Projects
None yet
2 participants
@unzan
Copy link

unzan commented Jun 23, 2015

Apologize if the title isn't clear enough. Currently inside a signal trigger there are only these:

tg_signal: <name-of-the-signal>
tg_signal_data: <any-string>

According to the doc, ${tg_signal_data} can contain "pointer" like in irc_pv_opened signal, but it's useless because unlike modifier trigger (eg, weechat_print modifier) where you get an actual ${buffer} pointer, this one is just a hex string. I can't use ${tg_signal_data} to get property of the new pv buffer that is just opened.There is ${buffer} variable inside signal trigger but it's pointing to current buffer which means for irc_pv_opened signal it's useless.

Can we please improve the signal trigger so that instead of just random useless hex string we get an actual buffer/window/filter/etc pointer?

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Jun 23, 2015

The ${tg_signal_data} in signal irc_pv_opened should be a pointer to the buffer opened, so it's not a random string.

@flashcode flashcode added the question label Jun 23, 2015

@flashcode flashcode self-assigned this Jun 23, 2015

@unzan

This comment has been minimized.

Copy link
Author

unzan commented Jun 23, 2015

But it's not. In /trigger monitor it is listed under extra_vars unlike in modifier trigger where it is listed under pointer (screenshot).

I've also tried setting the signal trigger's command to these three:

/trigger set pv_opened command /print ${tg_signal_data.full_name}
/trigger set pv_opened command /print ${${tg_signal_data}.full_name}
/trigger set pv_opened command /print ${tg_signal_data}.full_name

The first two print empty string and the third one prints something like 0x966f870.full_name. So it's definitely not a pointer.

EDIT: I mean, I understand the hex string is the value of the pointer of the newly opened buffer and not just random string but I can't use it for anything in trigger. I can't get any buffer property using ${tg_signal_data}.

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Jun 23, 2015

It's a buffer pointer, but you can not use it like that, because when adding .full_name, weechat does not know that the pointer is a pointer to a buffer (the pointers sent as data with signals have no "type").
So some things must be changed in the API to allow you to use the pointer (or in trigger plugin for some signals, but it would be better to have something generic for all signals).

@flashcode flashcode added enhancement and removed question labels Jun 23, 2015

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Jun 23, 2015

This is already possible with a specific syntax to force the type "buffer": ${buffer[${tg_signal_data}].full_name}

@unzan

This comment has been minimized.

Copy link
Author

unzan commented Jun 23, 2015

That one is still evaluated to current buffer in here instead of the newly opened buffer. I'm using WeeChat 1.3-dev (git: v1.2-44-g7c1b7df) [compiled on Jun 17 2015 01:41:05] and here's the test trigger I use:

/trigger add pv_opened signal "irc_pv_opened" "" "" "/print -core ${buffer[${tg_signal_data}].full_name}" "ok"

When I'm in #weechat channel and there's a new pv opened, the trigger prints irc.freenode.#weechat instead of irc.freenode.nickname.

@flashcode

This comment has been minimized.

Copy link
Member

flashcode commented Jun 23, 2015

OK, you're right, it doesn't work.
I'll fix evaluation of string to allow a pointer (0x...).

@flashcode flashcode closed this in a79c0fc Jun 23, 2015

@flashcode flashcode added this to the 1.3 milestone Jun 23, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.