Christian Ridderström wrote:
> On Fri, 18 Jul 2003, Angus Leeming wrote:
>>
>> etc) exist. The proposal to the bindings problem was to define an inset
>> that would 'do the right thing'. Ie, it would be given the lfun
>> "buffer-export" and would display the appropriate binding, depending on
>> which binding file was being used.
>
> Hmm if you did mean an inset such as the ERT, then I guess clicking on a
> similar inset could be used to open the relevant dialog.
Why would you want to do that. This is a suggestion to make the
documentation clearer isn't it? The original suggestion had _no_ dialog. It
was not meant to be a user thing but rather was aimed specically at making
the documentation more clear. The inset was generated by writing someething
like this in the minibuffer
insert-lfun-inset line-begin-select
to display "S-Home" if using cua.bind or "S-C-A" if using emacs.bind.
> (I'm assuming that all dialogs/tabs/ can be
> opened using LFUNs, and that it's the same LFUN regardles of what
> frontend that is used).
That's correct. LFUN's are ignorant of the frontend. All dialogs can be
opened with either
dialog-show print
or
dialog-show-new-inset citation
There is no ability at the moment to open the dialog of an existing inset.
I'm minded to replace
dialog-show-new-inset citation
with
dialog-show citation
to open the dialog for a new inset and to add the code for
dialog-show-next-inset citation
to open the dialog for the next citation inset after the current cursor
position.
Note that several dialogs are not actually opened this way. Eg.
case LFUN_HTMLURL: {
InsetCommandParams p("htmlurl");
string const data = InsetCommandMailer::params2string("url",
p);
bv->owner()->getDialogs().show("url", data, 0);
break;
}
case LFUN_URL: {
InsetCommandParams p("url");
string const data = InsetCommandMailer::params2string("url",
p);
bv->owner()->getDialogs().show("url", data, 0);
break;
}
This may well change as the code matures.
--
Angus
