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

Scott Kostyshak skostysh at lyx.org
Sat Jan 9 01:32:12 UTC 2021


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.

Thank you for helping with this!

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/a01c2a73/attachment-0001.asc>


More information about the lyx-devel mailing list