On 3/28/20 3:23 PM, racoon wrote: > On 2020-03-28 20:16, Richard Kimberly Heck wrote: >> On 3/28/20 3:00 PM, Richard Kimberly Heck wrote: >>> 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. >> >> Hmm. In some cases, it won't let you paste, but using our >> NoNewLineValidator, it does, and it just removes the CR. >> >> Riki > > Sounds promising, or? I hope there is a way to apply it across the board > to all qLineEdits. Seems like an oversight that Qt hasn't set it as > default.
I committed it. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
