[LyX/master] Tab binding: outline-in before depth-increment

Richard Kimberly Heck rikiheck at lyx.org
Sat Jan 9 02:00:51 UTC 2021


On 1/8/21 8:32 PM, Scott Kostyshak wrote:
> On Fri, Jan 08, 2021 at 08:05:00PM -0500, Richard Kimberly Heck wrote:
>> On 1/8/21 5:59 PM, Scott Kostyshak wrote:
>>> On Fri, Sep 11, 2020 at 02:30:00PM -0400, Scott Kostyshak wrote:
>>>> On Thu, Sep 10, 2020 at 12:22:03PM -0400, Richard Kimberly Heck wrote:
>>>>> On 9/10/20 11:52 AM, Scott Kostyshak wrote:
>>>>>> On Thu, May 16, 2019 at 07:54:41PM +0200, Scott Kostyshak wrote:
>>>>>>> commit 9ab9f2b1acb8bc1a40d5a69737b43d09b7f7a597
>>>>>>> Author: Scott Kostyshak <skostysh at lyx.org>
>>>>>>> Date:   Thu May 16 13:58:18 2019 -0400
>>>>>>>
>>>>>>>     Tab binding: outline-in before depth-increment
>>>>>>>     
>>>>>>>     Same for BackTab. The outline-in was originally (31398779)
>>>>>>>     introduced to the command-sequence at the end. Probably it was
>>>>>>>     placed at the end to be conservative (i.e., so that it would only
>>>>>>>     change behavior where there was a no-op before).
>>>>>>>     
>>>>>>>     This fixes #11576.
>>>>>>> ---
>>>>>>>  lib/bind/site.bind |    4 ++--
>>>>>>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/lib/bind/site.bind b/lib/bind/site.bind
>>>>>>> index 4c3c609..615c685 100644
>>>>>>> --- a/lib/bind/site.bind
>>>>>>> +++ b/lib/bind/site.bind
>>>>>>> @@ -27,10 +27,10 @@ Format 5
>>>>>>>  \bind "Up"         "up"
>>>>>>>  \bind "Down"       "down"
>>>>>>>  
>>>>>>> -\bind "Tab"        "command-alternatives completion-accept;cell-forward;tab-insert;depth-increment;outline-in"
>>>>>>> +\bind "Tab"        "command-alternatives completion-accept;cell-forward;tab-insert;outline-in;depth-increment"
>>>>>>>  \bind "C-Tab"      "cell-split"
>>>>>>>  \bind "~S-ISO_Left_Tab"    "cell-backward"
>>>>>>> -\bind "~S-BackTab" "command-alternatives cell-backward;tab-delete;depth-decrement;outline-out"
>>>>>>> +\bind "~S-BackTab" "command-alternatives cell-backward;tab-delete;outline-out;depth-decrement"
>>>>>> This commit introduced a regression (also in stable). To reproduce:
>>>>>>
>>>>>> 1. open the attached file.
>>>>>> 2. convert the "standard" layout to "frame" (it will be nested).
>>>>>> 3. try to unnest the frame with shift+tab.
>>>>>>
>>>>>> Result: on 2.3.x and master, it becomes a subsubsection. On 2.3.0, it
>>>>>> has the expected (to me) result of unnesting the frame.
>>>>>>
>>>>>> The reason for the 2.3.x behavior is because of the change of order of
>>>>>> the command alternatives in this commit. outline-out succeeds. From what
>>>>>> I understand, outline-out succeeds because in the Frame layout, the
>>>>>> TocLevel is set.
>>>>>>
>>>>>> If we revert this commit, we reintroduce #11576.
>>>>>>
>>>>>> I don't know much about layouts so I'm not sure what the best approach
>>>>>> is. 
>>>>> One possible solution would be a new layout tag: ProhibitNesting, off by
>>>>> default.
>>>> From the little that I understand, that would be great and would prevent
>>>> the user from getting into situations they likely don't want (e.g.,
>>>> having a section nested in a frame).
>>> I think adding the layout tag would be ideal. However, I don't have the time to look into that.
>>>
>>> Should I revert the commit and reintroduce #11576?
>> Tell me what layout tag you need. I can add it very easily.
> It would be nice to get someone else's feedback (Jürgen?) before you
> work on it. I see a few possibilities:
>
> 1. A tag that does not allow layouts to nest other layouts of the same
>    type.
>
> 2. A tag that does not allow a layout to be nested at all.
>
> 3. A tag that is similar to the "AutoNests" tag, where we can list all
>    of the layouts that a layout should not nest (or should not be nested by?).
>
> (3) is the most general so my initial guess is that's the way to go. I
> like your name for the tag that you proposed earlier, ProhibitNesting.

Note that we can separate two tasks here: getting the tag itself into
the code and then actually making it do something. There have been times
we did the former without doing the latter because we were too close to
release and didn't have time but didn't want to wait for another major
release, either.

Tags are cheap, so we can add more than one if need be.

Riki





More information about the lyx-devel mailing list