Nice, thanks :-) -----Message d'origine----- De : Harbs [mailto:harbs.li...@gmail.com] Envoyé : mardi 3 septembre 2013 14:28 À : dev@flex.apache.org Objet : Re: Shift Enter in TLF
Yup. That's how it works. On Mac, Command Z invokes undo and both Command Y and Command/Shift Z now invoke redo. On Windows it's only Control Z (undo) and Control Y (redo) in my tests. On Sep 3, 2013, at 3:12 PM, Frédéric THOMAS wrote: > Windows users should redo with CTRL+Y > > -----Message d'origine----- > De : Harbs [mailto:harbs.li...@gmail.com] Envoyé : mardi 3 septembre > 2013 14:11 À : dev@flex.apache.org Objet : Re: Shift Enter in TLF > > Okay. I pushed my changes out. > > I added a flag in Configuration with three levels. Default is always > soft returns, but it could be changed by the user both at the class > level (using > tlf_internal) and in the individual configuration object. I don't know > if the user needs that level of control, but it was not a big deal to > offer it, so I figured why not... > > I also added Command+Shift Z for redo. It seems to work on Mac and do > nothing on Windows (which I think is the proper behavior there). > > On Sep 3, 2013, at 7:00 AM, Alex Harui wrote: > >> >> >> On 9/2/13 1:03 PM, "Harbs" <harbs.li...@gmail.com> wrote: >> >>> I've done both the shift return and command+shift z for redo. I've >>> tested on Mac. I'll try to test on Windows before I commit. >>> >>> Question: How should shift-return behave within lists? Should they >>> behave like regular paragraphs where it only inserts a soft return, >>> or should it create a hard return without creating a new list item? >>> >>> I'm coming from InDesign where a new paragraph is always a new list item. >>> Unless you break the list completely, you need a soft return to >>> break a list item. I'd like to mimic the InDesign paradigm. Any objections? >>> Does it need an option to change the behavior? If yes, would >>> IConfiguration be a good place to set that? >> I don't know enough to have an opinion. If you are making >> significant changes to existing behavior, a flag would be nice, but not required. >> >> -Alex >> >
