Richard Heck wrote:
> Well, complete isn't always enabled---not in the middle of a word---but
> it's almost always enabled, so you do have this problem.
in fact i don't have this problem, since i use completion-accept ;)
it seems we both agree upon this solution, but i would like to listen
others
Pavel Sanda wrote:
Richard Heck wrote:
I guess I saw this the other way around: BOTH completion AND next-cell
should work in tables.
and both bound to tab?
Yes. And this does work if what's bound is completion-accept. If you
bind it to complete, then it works much less well.
Othe
Richard Heck wrote:
> I guess I saw this the other way around: BOTH completion AND next-cell
> should work in tables.
and both bound to tab?
> Otherwise, you, the user, have to remember that
> completion has no binding in tables. This is very unintuitive, and it is
> especially nasty with mat
Bo Peng wrote:
By the way---this isn't necessarily for you, Pavel---I've noticed some
oddities in the shortcut dialog while working on this. First, it seems
bindings from site.bind don't show up in the dialog. They should, at least
so you know what they are. Attempts to overwrite these bindings s
Pavel Sanda wrote:
Richard Heck wrote:
wouldn't binding tab to the table movement
_on_the_first_place_in_lfuns_list solve this? completion-accept was pushed
mainly because i use completion
in a bit different fashion and don't want to force anybody on it.
But then whatever complet
On Tue, Sep 23, 2008 at 8:06 PM, Bennett Helm <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 23, 2008 at 9:00 PM, Bo Peng <[EMAIL PROTECTED]> wrote:
>>
>> I can have a look at the code at the end of this week if needed.
>
> Bo - while you're at it, can you have a look at:
> http://bugzilla.lyx.org/show_b
On Tue, Sep 23, 2008 at 9:00 PM, Bo Peng <[EMAIL PROTECTED]> wrote:
> I can have a look at the code at the end of this week if needed.
Bo - while you're at it, can you have a look at:
http://bugzilla.lyx.org/show_bug.cgi?id=4544
Thanks. (Sorry to hijack the thread)
Bennett
>> yes, then we could do that. But note that there'd be no way to manage the
>> order of the bindings then, and no indication of what they are. So I'm
>> inclined not to allow "adding" a binding via the shortcut panel unless
>> those problems are solved. And maybe we could also disallow rebinding a
Richard Heck wrote:
>> wouldn't binding tab to the table movement
>> _on_the_first_place_in_lfuns_list solve this? completion-accept was pushed
>> mainly because i use completion
>> in a bit different fashion and don't want to force anybody on it.
>>
>>
> But then whatever completion thing is
Pavel Sanda wrote:
Richard Heck wrote:
The attached patch is a start on this. It does work, in the sense that
you can have both completion-accept and cell-forward bound to Tab, and
this works in tables.
"completion-accept" is added from me and works in a different way then
"co
Richard Heck wrote:
>>> The attached patch is a start on this. It does work, in the sense that
>>> you can have both completion-accept and cell-forward bound to Tab, and
>>> this works in tables.
>>>
>>
>> "completion-accept" is added from me and works in a different way then
>> "complete"
Jean-Marc Lasgouttes wrote:
rgheck <[EMAIL PROTECTED]> writes:
So what about the second part of my question? I ask because we will have
to keep the semantics of these things in the future, and therefore need
it to be sound.
It would overwrite them both. I think that makes sense, sema
rgheck <[EMAIL PROTECTED]> writes:
>> So what about the second part of my question? I ask because we will have
>> to keep the semantics of these things in the future, and therefore need
>> it to be sound.
> It would overwrite them both. I think that makes sense, semantically.
You mean that only t
Pavel Sanda wrote:
Richard Heck wrote:
The attached patch is a start on this. It does work, in the sense that you
can have both completion-accept and cell-forward bound to Tab, and this
works in tables.
"completion-accept" is added from me and works in a different way then
"complete"
Jean-Marc Lasgouttes wrote:
rgheck <[EMAIL PROTECTED]> writes:
What is the difference between \bind and \addbind when a binding already
exists? What does \bind do when 2 bindings already exist?
\bind overrides the old binding. That is the extant behavior, and I'd
guess some people
rgheck <[EMAIL PROTECTED]> writes:
>> What is the difference between \bind and \addbind when a binding already
>> exists? What does \bind do when 2 bindings already exist?
>>
> \bind overrides the old binding. That is the extant behavior, and I'd
> guess some people rely upon it. \addbind adds a
Jean-Marc Lasgouttes wrote:
rgheck <[EMAIL PROTECTED]> writes:
-\bind "Tab""cell-forward"
+\bind "Tab""completion-accept"
+\addbind "Tab" "cell-forward"
What is the difference between \bind and \addbind when a binding already
exists? What does \bind do when 2 bindin
Richard Heck wrote:
>
> The attached patch is a start on this. It does work, in the sense that you
> can have both completion-accept and cell-forward bound to Tab, and this
> works in tables.
"completion-accept" is added from me and works in a different way then
"complete"
which was bound to ta
rgheck <[EMAIL PROTECTED]> writes:
> -\bind "Tab""cell-forward"
> +\bind "Tab""completion-accept"
> +\addbind "Tab" "cell-forward"
What is the difference between \bind and \addbind when a binding already
exists? What does \bind do when 2 bindings already exist?
JMarc
The attached patch is a start on this. It does work, in the sense that
you can have both completion-accept and cell-forward bound to Tab, and
this works in tables.
The problem is that it is entirely unclear how to integrate this with
the shortcut editing UI. Ideas are welcome.
Richard
Ind
20 matches
Mail list logo
