Re: tab through eqnarray environment - bug in 1.6rc1?
James Sutherland wrote: Has anyone noticed that in 1.6rc1 using the tab key to skip through the three fields in the eqnarray environment does not function properly? Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... This is a known problem that we intend to fix before 1.6.0. The problem is that the completion framework monopolize the tab key for requesting completion. We need to find a good key in replacement for tab but we didn't reach a consensus yet. Feel free to suggest something. Abdel.
Re: tab through eqnarray environment - bug in 1.6rc1?
On 29.08.08, Abdelrazak Younes wrote: James Sutherland wrote: Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... This is a known problem that we intend to fix before 1.6.0. The problem is that the completion framework monopolize the tab key for requesting completion. Just courious: * even if the completion feature is switched off? * is the Tab binding hard-coded or configurable? We need to find a good key in replacement for tab but we didn't reach a consensus yet. Feel free to suggest something. In my favourite text editor, I use Ctrl-A for completion and Tab for indenting. But IMO, there is need for configurable adaptive keybindings: user configurable: This is already possible (via the *.bind files and since 1.6 also via GUI) adaptive: smart bindings that take into account the context, e.g. the same key should be configurable to different lfuns in math and text mode. There are simply too few keys for too many actions, so we should avoid bindings that result in command disabled. Günter
Re: tab through eqnarray environment - bug in 1.6rc1?
On Aug 29, 2008, at 1:42 AM, Abdelrazak Younes wrote: James Sutherland wrote: Has anyone noticed that in 1.6rc1 using the tab key to skip through the three fields in the eqnarray environment does not function properly? Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... This is a known problem that we intend to fix before 1.6.0. The problem is that the completion framework monopolize the tab key for requesting completion. We need to find a good key in replacement for tab but we didn't reach a consensus yet. Feel free to suggest something. Abdel. For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields and Shift-Tab for reverse-cycling. This maintains the current reverse-cycling key bindings and is only a minor change for forward-cycling. James
Re: tab through eqnarray environment - bug in 1.6rc1?
On Aug 29, 2008, at 1:42 AM, Abdelrazak Younes wrote: James Sutherland wrote: Has anyone noticed that in 1.6rc1 using the tab key to skip through the three fields in the eqnarray environment does not function properly? Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... This is a known problem that we intend to fix before 1.6.0. The problem is that the completion framework monopolize the tab key for requesting completion. We need to find a good key in replacement for tab but we didn't reach a consensus yet. Feel free to suggest something. Abdel. For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. and Shift-Tab for reverse-cycling. This maintains the current reverse-cycling key bindings and is only a minor change for forward-cycling. James
Re: tab through eqnarray environment - bug in 1.6rc1?
For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. Isn't that Ctrl-` ? And Alt-Tab (on Mac, Command-Tab) is for application switching.
Re: tab through eqnarray environment - bug in 1.6rc1?
On Aug 29, 2008, at 1:42 AM, Abdelrazak Younes wrote: James Sutherland wrote: Has anyone noticed that in 1.6rc1 using the tab key to skip through the three fields in the eqnarray environment does not function properly? Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... This is a known problem that we intend to fix before 1.6.0. The problem is that the completion framework monopolize the tab key for requesting completion. We need to find a good key in replacement for tab but we didn't reach a consensus yet. Feel free to suggest something. Abdel. For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. btw it works for you? ctrl+tab makes no action here, athough the binding is correct and buffer-next lfun from command buffer works too. pavel
Re: tab through eqnarray environment - bug in 1.6rc1?
For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. btw it works for you? ctrl+tab makes no action here, athough the binding is correct and buffer-next lfun from command buffer works too. pavel I don't think that Ctrl-Tab has any bound functionality at the moment. I was suggesting it as a possible standard binding for cycling through eqnarray environment fields. In previous versions of LyX (prior to 1.6), this was accomplished by the Tab key, but Tab now is bound for word completion.
Re: tab through eqnarray environment - bug in 1.6rc1?
For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. btw it works for you? ctrl+tab makes no action here, athough the binding is correct and buffer-next lfun from command buffer works too. pavel I don't think that Ctrl-Tab has any bound functionality at the moment. I yes in 1.6 it is bound to next-buffer. pavel
Re: tab through eqnarray environment - bug in 1.6rc1?
On Aug 29, 2008, at 7:43 AM, Pavel Sanda wrote: For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. btw it works for you? ctrl+tab makes no action here, athough the binding is correct and buffer-next lfun from command buffer works too. pavel I don't think that Ctrl-Tab has any bound functionality at the moment. I yes in 1.6 it is bound to next-buffer. pavel Okay - perhaps this is a Mac nuance. On Mac, Command-Tab (bound to next-buffer command) switches between applications, and I thought that on other platforms (Windows/Linux) this was Alt-Tab. Again, on Mac, Command-` switches between documents (I assume this is Alt-`on Windows/Linux). On Mac, Ctrl-Tab is not bound to anything. These statements apply to 1.6 and 1.6rc1. James
Re: tab through eqnarray environment - bug in 1.6rc1?
On Aug 29, 2008, at 7:43 AM, Pavel Sanda wrote: For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. btw it works for you? ctrl+tab makes no action here, athough the binding is correct and buffer-next lfun from command buffer works too. pavel I don't think that Ctrl-Tab has any bound functionality at the moment. I yes in 1.6 it is bound to next-buffer. pavel Okay - perhaps this is a Mac nuance. On Mac, Command-Tab (bound to next-buffer command) switches between applications, and I thought that on other platforms (Windows/Linux) this was Alt-Tab. yes this is mac specific. while we are at it, could some mac user make for me lyx 1.6 screenshot like this one http://www.lyx.org/images/about/aqua.png ? try to do as much sexy picture as possible, i'm trying to rework screenshots page. pavel
Re: tab through eqnarray environment - bug in 1.6rc1?
For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. Isn't that Ctrl-` ? Not on Windows and on KDE AFAIK. And Alt-Tab (on Mac, Command-Tab) is for application switching. Yes, same on Windows and KDE. Abdel.
Re: tab through eqnarray environment - bug in 1.6rc1?
On Aug 29, 2008, at 7:43 AM, Pavel Sanda wrote: For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. btw it works for you? ctrl+tab makes no action here, athough the binding is correct and buffer-next lfun from command buffer works too. pavel I don't think that Ctrl-Tab has any bound functionality at the moment. I yes in 1.6 it is bound to next-buffer. pavel Okay - perhaps this is a Mac nuance. On Mac, Command-Tab (bound to next-buffer command) switches between applications, and I thought that on other platforms (Windows/Linux) this was Alt-Tab. yes this is mac specific. pavel
Re: tab through eqnarray environment - bug in 1.6rc1?
On Fri, Aug 29, 2008 at 9:57 AM, Pavel Sanda [EMAIL PROTECTED] wrote: Okay - perhaps this is a Mac nuance. On Mac, Command-Tab (bound to next-buffer command) switches between applications, and I thought that on other platforms (Windows/Linux) this was Alt-Tab. yes this is mac specific. It is, but it is a general regression on Mac: there is something very odd about the tab key with 1.6. For example, in mac.bind, opttab is supposed to switch between buffers in the same window; currently it does not work. (Note by the way that Ctrl is unavailable for any keybinding: a limitation of Qt.) Bennett
Re: tab through eqnarray environment - bug in 1.6rc1?
G. Milde wrote: On 29.08.08, Abdelrazak Younes wrote: James Sutherland wrote: Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... This is a known problem that we intend to fix before 1.6.0. The problem is that the completion framework monopolize the tab key for requesting completion. Just courious: * even if the completion feature is switched off? This is hard-coded right now so yes, I think so, not sure though. * is the Tab binding hard-coded or configurable? hard-coded :-/ We need to find a good key in replacement for tab but we didn't reach a consensus yet. Feel free to suggest something. In my favourite text editor, I use Ctrl-A for completion and Tab for indenting. But IMO, there is need for configurable adaptive keybindings: user configurable: This is already possible (via the *.bind files and since 1.6 also via GUI) adaptive: smart bindings that take into account the context, e.g. the same key should be configurable to different lfuns in math and text mode. There are simply too few keys for too many actions, so we should avoid bindings that result in command disabled. Right. We try to do that with Tab related keys. Abdel.
Re: tab through eqnarray environment - bug in 1.6rc1?
James Sutherland wrote: Has anyone noticed that in 1.6rc1 using the tab key to skip through the three fields in the eqnarray environment does not function properly? Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... This is a known problem that we intend to fix before 1.6.0. The problem is that the completion framework monopolize the tab key for requesting completion. We need to find a good key in replacement for tab but we didn't reach a consensus yet. Feel free to suggest something. Abdel.
Re: tab through eqnarray environment - bug in 1.6rc1?
On 29.08.08, Abdelrazak Younes wrote: James Sutherland wrote: Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... This is a known problem that we intend to fix before 1.6.0. The problem is that the completion framework monopolize the tab key for requesting completion. Just courious: * even if the completion feature is switched off? * is the Tab binding hard-coded or configurable? We need to find a good key in replacement for tab but we didn't reach a consensus yet. Feel free to suggest something. In my favourite text editor, I use Ctrl-A for completion and Tab for indenting. But IMO, there is need for configurable adaptive keybindings: user configurable: This is already possible (via the *.bind files and since 1.6 also via GUI) adaptive: smart bindings that take into account the context, e.g. the same key should be configurable to different lfuns in math and text mode. There are simply too few keys for too many actions, so we should avoid bindings that result in command disabled. Günter
Re: tab through eqnarray environment - bug in 1.6rc1?
On Aug 29, 2008, at 1:42 AM, Abdelrazak Younes wrote: James Sutherland wrote: Has anyone noticed that in 1.6rc1 using the tab key to skip through the three fields in the eqnarray environment does not function properly? Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... This is a known problem that we intend to fix before 1.6.0. The problem is that the completion framework monopolize the tab key for requesting completion. We need to find a good key in replacement for tab but we didn't reach a consensus yet. Feel free to suggest something. Abdel. For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields and Shift-Tab for reverse-cycling. This maintains the current reverse-cycling key bindings and is only a minor change for forward-cycling. James
Re: tab through eqnarray environment - bug in 1.6rc1?
On Aug 29, 2008, at 1:42 AM, Abdelrazak Younes wrote: James Sutherland wrote: Has anyone noticed that in 1.6rc1 using the tab key to skip through the three fields in the eqnarray environment does not function properly? Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... This is a known problem that we intend to fix before 1.6.0. The problem is that the completion framework monopolize the tab key for requesting completion. We need to find a good key in replacement for tab but we didn't reach a consensus yet. Feel free to suggest something. Abdel. For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. and Shift-Tab for reverse-cycling. This maintains the current reverse-cycling key bindings and is only a minor change for forward-cycling. James
Re: tab through eqnarray environment - bug in 1.6rc1?
For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. Isn't that Ctrl-` ? And Alt-Tab (on Mac, Command-Tab) is for application switching.
Re: tab through eqnarray environment - bug in 1.6rc1?
On Aug 29, 2008, at 1:42 AM, Abdelrazak Younes wrote: James Sutherland wrote: Has anyone noticed that in 1.6rc1 using the tab key to skip through the three fields in the eqnarray environment does not function properly? Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... This is a known problem that we intend to fix before 1.6.0. The problem is that the completion framework monopolize the tab key for requesting completion. We need to find a good key in replacement for tab but we didn't reach a consensus yet. Feel free to suggest something. Abdel. For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. btw it works for you? ctrl+tab makes no action here, athough the binding is correct and buffer-next lfun from command buffer works too. pavel
Re: tab through eqnarray environment - bug in 1.6rc1?
For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. btw it works for you? ctrl+tab makes no action here, athough the binding is correct and buffer-next lfun from command buffer works too. pavel I don't think that Ctrl-Tab has any bound functionality at the moment. I was suggesting it as a possible standard binding for cycling through eqnarray environment fields. In previous versions of LyX (prior to 1.6), this was accomplished by the Tab key, but Tab now is bound for word completion.
Re: tab through eqnarray environment - bug in 1.6rc1?
For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. btw it works for you? ctrl+tab makes no action here, athough the binding is correct and buffer-next lfun from command buffer works too. pavel I don't think that Ctrl-Tab has any bound functionality at the moment. I yes in 1.6 it is bound to next-buffer. pavel
Re: tab through eqnarray environment - bug in 1.6rc1?
On Aug 29, 2008, at 7:43 AM, Pavel Sanda wrote: For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. btw it works for you? ctrl+tab makes no action here, athough the binding is correct and buffer-next lfun from command buffer works too. pavel I don't think that Ctrl-Tab has any bound functionality at the moment. I yes in 1.6 it is bound to next-buffer. pavel Okay - perhaps this is a Mac nuance. On Mac, Command-Tab (bound to next-buffer command) switches between applications, and I thought that on other platforms (Windows/Linux) this was Alt-Tab. Again, on Mac, Command-` switches between documents (I assume this is Alt-`on Windows/Linux). On Mac, Ctrl-Tab is not bound to anything. These statements apply to 1.6 and 1.6rc1. James
Re: tab through eqnarray environment - bug in 1.6rc1?
On Aug 29, 2008, at 7:43 AM, Pavel Sanda wrote: For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. btw it works for you? ctrl+tab makes no action here, athough the binding is correct and buffer-next lfun from command buffer works too. pavel I don't think that Ctrl-Tab has any bound functionality at the moment. I yes in 1.6 it is bound to next-buffer. pavel Okay - perhaps this is a Mac nuance. On Mac, Command-Tab (bound to next-buffer command) switches between applications, and I thought that on other platforms (Windows/Linux) this was Alt-Tab. yes this is mac specific. while we are at it, could some mac user make for me lyx 1.6 screenshot like this one http://www.lyx.org/images/about/aqua.png ? try to do as much sexy picture as possible, i'm trying to rework screenshots page. pavel
Re: tab through eqnarray environment - bug in 1.6rc1?
For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. Isn't that Ctrl-` ? Not on Windows and on KDE AFAIK. And Alt-Tab (on Mac, Command-Tab) is for application switching. Yes, same on Windows and KDE. Abdel.
Re: tab through eqnarray environment - bug in 1.6rc1?
On Aug 29, 2008, at 7:43 AM, Pavel Sanda wrote: For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. btw it works for you? ctrl+tab makes no action here, athough the binding is correct and buffer-next lfun from command buffer works too. pavel I don't think that Ctrl-Tab has any bound functionality at the moment. I yes in 1.6 it is bound to next-buffer. pavel Okay - perhaps this is a Mac nuance. On Mac, Command-Tab (bound to next-buffer command) switches between applications, and I thought that on other platforms (Windows/Linux) this was Alt-Tab. yes this is mac specific. pavel
Re: tab through eqnarray environment - bug in 1.6rc1?
On Fri, Aug 29, 2008 at 9:57 AM, Pavel Sanda [EMAIL PROTECTED] wrote: Okay - perhaps this is a Mac nuance. On Mac, Command-Tab (bound to next-buffer command) switches between applications, and I thought that on other platforms (Windows/Linux) this was Alt-Tab. yes this is mac specific. It is, but it is a general regression on Mac: there is something very odd about the tab key with 1.6. For example, in mac.bind, opttab is supposed to switch between buffers in the same window; currently it does not work. (Note by the way that Ctrl is unavailable for any keybinding: a limitation of Qt.) Bennett
Re: tab through eqnarray environment - bug in 1.6rc1?
G. Milde wrote: On 29.08.08, Abdelrazak Younes wrote: James Sutherland wrote: Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... This is a known problem that we intend to fix before 1.6.0. The problem is that the completion framework monopolize the tab key for requesting completion. Just courious: * even if the completion feature is switched off? This is hard-coded right now so yes, I think so, not sure though. * is the Tab binding hard-coded or configurable? hard-coded :-/ We need to find a good key in replacement for tab but we didn't reach a consensus yet. Feel free to suggest something. In my favourite text editor, I use Ctrl-A for completion and Tab for indenting. But IMO, there is need for configurable adaptive keybindings: user configurable: This is already possible (via the *.bind files and since 1.6 also via GUI) adaptive: smart bindings that take into account the context, e.g. the same key should be configurable to different lfuns in math and text mode. There are simply too few keys for too many actions, so we should avoid bindings that result in command disabled. Right. We try to do that with Tab related keys. Abdel.
Re: tab through eqnarray environment - bug in 1.6rc1?
James Sutherland wrote: Has anyone noticed that in 1.6rc1 using the tab key to skip through the three fields in the eqnarray environment does not function properly? Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... This is a known problem that we intend to fix before 1.6.0. The problem is that the completion framework monopolize the tab key for requesting completion. We need to find a good key in replacement for tab but we didn't reach a consensus yet. Feel free to suggest something. Abdel.
Re: tab through eqnarray environment - bug in 1.6rc1?
On 29.08.08, Abdelrazak Younes wrote: > James Sutherland wrote: >> Shift-Tab cycles in reverse as it has in the past, but Tab does not >> cycle forward... > This is a known problem that we intend to fix before 1.6.0. The problem > is that the completion framework monopolize the tab key for requesting > completion. Just courious: * even if the completion feature is switched off? * is the Tab binding hard-coded or configurable? > We need to find a good key in replacement for tab but we > didn't reach a consensus yet. Feel free to suggest something. In my favourite text editor, I use Ctrl-A for completion and Tab for indenting. But IMO, there is need for "configurable adaptive" keybindings: user configurable: This is already possible (via the *.bind files and since 1.6 also via GUI) adaptive: "smart" bindings that take into account the context, e.g. the same key should be configurable to different lfuns in math and text mode. There are simply too few keys for too many actions, so we should avoid bindings that result in "command disabled". Günter
Re: tab through eqnarray environment - bug in 1.6rc1?
On Aug 29, 2008, at 1:42 AM, Abdelrazak Younes wrote: James Sutherland wrote: Has anyone noticed that in 1.6rc1 using the tab key to skip through the three fields in the eqnarray environment does not function properly? Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... This is a known problem that we intend to fix before 1.6.0. The problem is that the completion framework monopolize the tab key for requesting completion. We need to find a good key in replacement for tab but we didn't reach a consensus yet. Feel free to suggest something. Abdel. For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields and Shift-Tab for reverse-cycling. This maintains the current reverse-cycling key bindings and is only a minor change for forward-cycling. James
Re: tab through eqnarray environment - bug in 1.6rc1?
On Aug 29, 2008, at 1:42 AM, Abdelrazak Younes wrote: James Sutherland wrote: Has anyone noticed that in 1.6rc1 using the tab key to skip through the three fields in the eqnarray environment does not function properly? Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... This is a known problem that we intend to fix before 1.6.0. The problem is that the completion framework monopolize the tab key for requesting completion. We need to find a good key in replacement for tab but we didn't reach a consensus yet. Feel free to suggest something. Abdel. For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. and Shift-Tab for reverse-cycling. This maintains the current reverse-cycling key bindings and is only a minor change for forward-cycling. James
Re: tab through eqnarray environment - bug in 1.6rc1?
For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. Isn't that Ctrl-` ? And Alt-Tab (on Mac, Command-Tab) is for application switching.
Re: tab through eqnarray environment - bug in 1.6rc1?
>> >> On Aug 29, 2008, at 1:42 AM, Abdelrazak Younes wrote: >> >>> James Sutherland wrote: Has anyone noticed that in 1.6rc1 using the tab key to skip through the three fields in the eqnarray environment does not function properly? Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... >>> >>> This is a known problem that we intend to fix before 1.6.0. The problem >>> is that the completion framework monopolize the tab key for requesting >>> completion. We need to find a good key in replacement for tab but we >>> didn't reach a consensus yet. Feel free to suggest something. >>> >>> Abdel. >>> >>> >> For convenience, I would suggest Ctrl-Tab for forward-cycling through >> eqnarray fields > > Can't do that as Ctrl-Tab is reserved to document switching. btw it works for you? ctrl+tab makes no action here, athough the binding is correct and buffer-next lfun from command buffer works too. pavel
Re: tab through eqnarray environment - bug in 1.6rc1?
For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. btw it works for you? ctrl+tab makes no action here, athough the binding is correct and buffer-next lfun from command buffer works too. pavel I don't think that Ctrl-Tab has any bound functionality at the moment. I was suggesting it as a possible standard binding for cycling through eqnarray environment fields. In previous versions of LyX (prior to 1.6), this was accomplished by the Tab key, but Tab now is bound for word completion.
Re: tab through eqnarray environment - bug in 1.6rc1?
For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields >>> >>> Can't do that as Ctrl-Tab is reserved to document switching. >> >> btw it works for you? ctrl+tab makes no action here, athough the binding >> is correct >> and buffer-next lfun from command buffer works too. >> pavel > > I don't think that Ctrl-Tab has any bound functionality at the moment. I yes in 1.6 it is bound to next-buffer. pavel
Re: tab through eqnarray environment - bug in 1.6rc1?
On Aug 29, 2008, at 7:43 AM, Pavel Sanda wrote: For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. btw it works for you? ctrl+tab makes no action here, athough the binding is correct and buffer-next lfun from command buffer works too. pavel I don't think that Ctrl-Tab has any bound functionality at the moment. I yes in 1.6 it is bound to next-buffer. pavel Okay - perhaps this is a Mac nuance. On Mac, Command-Tab (bound to "next-buffer" command) switches between applications, and I thought that on other platforms (Windows/Linux) this was Alt-Tab. Again, on Mac, Command-` switches between documents (I assume this is Alt-`on Windows/Linux). On Mac, Ctrl-Tab is not bound to anything. These statements apply to <1.6 and 1.6rc1. James
Re: tab through eqnarray environment - bug in 1.6rc1?
> > On Aug 29, 2008, at 7:43 AM, Pavel Sanda wrote: > > > >> > >> For convenience, I would suggest Ctrl-Tab for forward-cycling through > >> eqnarray fields > > > > Can't do that as Ctrl-Tab is reserved to document switching. > > btw it works for you? ctrl+tab makes no action here, athough the binding > is correct > and buffer-next lfun from command buffer works too. > pavel > >>> > >>> I don't think that Ctrl-Tab has any bound functionality at the moment. I > >> > >> yes in 1.6 it is bound to next-buffer. > >> pavel > > > > Okay - perhaps this is a Mac nuance. On Mac, Command-Tab (bound to > > "next-buffer" command) switches between applications, and I thought that on > > other platforms (Windows/Linux) this was Alt-Tab. > > yes this is mac specific. while we are at it, could some mac user make for me lyx 1.6 screenshot like this one http://www.lyx.org/images/about/aqua.png ? try to do as much sexy picture as possible, i'm trying to rework screenshots page. pavel
Re: tab through eqnarray environment - bug in 1.6rc1?
For convenience, I would suggest Ctrl-Tab for forward-cycling through eqnarray fields Can't do that as Ctrl-Tab is reserved to document switching. Isn't that Ctrl-` ? Not on Windows and on KDE AFAIK. And Alt-Tab (on Mac, Command-Tab) is for application switching. Yes, same on Windows and KDE. Abdel.
Re: tab through eqnarray environment - bug in 1.6rc1?
> On Aug 29, 2008, at 7:43 AM, Pavel Sanda wrote: > >> >> For convenience, I would suggest Ctrl-Tab for forward-cycling through >> eqnarray fields > > Can't do that as Ctrl-Tab is reserved to document switching. btw it works for you? ctrl+tab makes no action here, athough the binding is correct and buffer-next lfun from command buffer works too. pavel >>> >>> I don't think that Ctrl-Tab has any bound functionality at the moment. I >> >> yes in 1.6 it is bound to next-buffer. >> pavel > > Okay - perhaps this is a Mac nuance. On Mac, Command-Tab (bound to > "next-buffer" command) switches between applications, and I thought that on > other platforms (Windows/Linux) this was Alt-Tab. yes this is mac specific. pavel
Re: tab through eqnarray environment - bug in 1.6rc1?
On Fri, Aug 29, 2008 at 9:57 AM, Pavel Sanda <[EMAIL PROTECTED]> wrote: > > Okay - perhaps this is a Mac nuance. On Mac, Command-Tab (bound to > > "next-buffer" command) switches between applications, and I thought that > on > > other platforms (Windows/Linux) this was Alt-Tab. > > yes this is mac specific. It is, but it is a general regression on Mac: there is something very odd about the key with 1.6. For example, in mac.bind, is supposed to switch between buffers in the same window; currently it does not work. (Note by the way that is unavailable for any keybinding: a limitation of Qt.) Bennett
Re: tab through eqnarray environment - bug in 1.6rc1?
G. Milde wrote: On 29.08.08, Abdelrazak Younes wrote: James Sutherland wrote: Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... This is a known problem that we intend to fix before 1.6.0. The problem is that the completion framework monopolize the tab key for requesting completion. Just courious: * even if the completion feature is switched off? This is hard-coded right now so yes, I think so, not sure though. * is the Tab binding hard-coded or configurable? hard-coded :-/ We need to find a good key in replacement for tab but we didn't reach a consensus yet. Feel free to suggest something. In my favourite text editor, I use Ctrl-A for completion and Tab for indenting. But IMO, there is need for "configurable adaptive" keybindings: user configurable: This is already possible (via the *.bind files and since 1.6 also via GUI) adaptive: "smart" bindings that take into account the context, e.g. the same key should be configurable to different lfuns in math and text mode. There are simply too few keys for too many actions, so we should avoid bindings that result in "command disabled". Right. We try to do that with Tab related keys. Abdel.
tab through eqnarray environment - bug in 1.6rc1?
Has anyone noticed that in 1.6rc1 using the tab key to skip through the three fields in the eqnarray environment does not function properly? Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... James
tab through eqnarray environment - bug in 1.6rc1?
Has anyone noticed that in 1.6rc1 using the tab key to skip through the three fields in the eqnarray environment does not function properly? Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... James
tab through eqnarray environment - bug in 1.6rc1?
Has anyone noticed that in 1.6rc1 using the tab key to skip through the three fields in the eqnarray environment does not function properly? Shift-Tab cycles in reverse as it has in the past, but Tab does not cycle forward... James
