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

Scott Kostyshak skostysh at lyx.org
Sat Jan 9 03:44:59 UTC 2021


On Fri, Jan 08, 2021 at 09:00:51PM -0500, Richard Kimberly Heck wrote:
> 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.

Ah I forgot about that possibility. In that case we would just have to
figure out the name.

Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20210108/b3725c13/attachment.asc>


More information about the lyx-devel mailing list