On 3/28/20 2:55 PM, Daniel wrote: > On 2020-03-28 19:47, Richard Kimberly Heck wrote: >> On 3/28/20 5:17 AM, Daniel wrote: >>> On 2020-03-28 04:27, Richard Kimberly Heck wrote: >>>> On 3/27/20 2:48 PM, racoon wrote: >>>>> On 2020-03-27 19:25, Richard Kimberly Heck wrote: >>>>>> On 3/27/20 2:21 PM, racoon wrote: >>>>>>> On 2020-03-27 17:52, racoon wrote: >>>>>>>> On 2020-03-27 17:41, Richard Kimberly Heck wrote: >>>>>>>>> On 3/27/20 4:21 AM, Daniel wrote: >>>>>>>>>> On 2020-03-19 15:03, racoon wrote: >>>>>>>>>>> On 2020-03-19 14:53, Richard Kimberly Heck wrote: >>>>>>>>>>>> Yes, you could assign something like "command-sequence >>>>>>>>>>>> self-insert s; >>>>>>>>>>>> char-delete-backward; buffer-write" to Ctrl-S. Undo won't >>>>>>>>>>>> work, >>>>>>>>>>>> because >>>>>>>>>>>> then the document isn't dirty again. >>>>>>>>>>>> >>>>>>>>>>>> Riki >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Unfortunately, when the settings dialog is closed and re-opened >>>>>>>>>>> everything that comes after the first semi-colon is chopped >>>>>>>>>>> off. Is >>>>>>>>>>> that >>>>>>>>>>> a bug? >>>>>>>>>> >>>>>>>>>> Oddly enough, it is possible to use similar command sequences. >>>>>>>>>> So, the >>>>>>>>>> problem isn't general. For example, >>>>>>>>>> >>>>>>>>>> command-sequence self-insert .; space-insert normal >>>>>>>>>> >>>>>>>>>> just works fine (see >>>>>>>>>> https://www.lyx.org/trac/ticket/11798#comment:6). >>>>>>>>>> I don't know what the difference might be. >>>>>>>>> >>>>>>>>> Don't see it here. >>>>>>>>> >>>>>>>>> You can put it manually into your user.bind file if need be. >>>>>>>>> >>>>>>>>> Riki >>>>>>>> >>>>>>>> Thanks, that helped. And I figured out what the problem was. I >>>>>>>> copied >>>>>>>> the command from your email not knowing that my email program had >>>>>>>> inserted a line-break after the first command in the sequence. >>>>>>>> Unfortunately, the input box in the shortcut editor masked this. I >>>>>>>> guess >>>>>>>> it would be better if text pasted into the input box was >>>>>>>> cleaned of >>>>>>>> characters it does not support rather than just hiding them. >>>>>>>> >>>>>>>> Daniel >>>>>>> >>>>>>> >>>>>>> Seems like at least this particular command sequence is not such a >>>>>>> good >>>>>>> idea. I just realized that it wrecks havoc if there is an active >>>>>>> selection of text because the text gets removed. >>>>>> >>>>>> Try adding "escape" first. That clears the selection. Of course, you >>>>>> lose the selection. >>>>>> >>>>>> Riki >>>>> >>>>> Thanks. That works better. Yes, losing the selection isn't perfect. >>>>> >>>>> Btw. the action input field suffers from the same problem as the >>>>> shortcut editor, e.g. it masks line-breaks which make a command fail. >>>> >>>> I don't know if there is any easy solution to this. I think I'd regard >>>> it as a Qt bug. >>>> >>>> Riki >>> >>> Yes, might be a bug. I have checked the input fields in Scribus and >>> they >>> exhibit the same problem. >>> >>> However, as far as I understood, there is a function to determine which >>> characters are valid input. Maybe that helps? Here is an example: >>> >>> https://doc.qt.io/qt-5/qregexpvalidator.html#details >>> >>> Maybe one could set the validator to a regex that does not match any >>> newline (\n) or return (\r)? But I don't know enough about Qt or regex. >> >> It wouldn't really help. That would prevent you from actually saving the >> shortcut, but you'd be totally stumped why. (Well, not you, but most >> users.) >> >> Riki > > Okay, then I seem to have misunderstood what the validator is doing. > > "Sets this line edit to only accept input that the validator, v, will > accept." (https://doc.qt.io/qt-5/qlineedit.html#setValidator) > > That sounded to me as if the *input* would be limited. And I'd hoped > that on paste the characters would be stripped (or the string cut off at > the first occurrence).
Yes, sorry. In that case, it wouldn't let you paste it at all. Maybe that's better, though. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
