Save on save

Daniel xracoonx at gmx.de
Sat Mar 28 18:55:46 UTC 2020


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).

Might have been more wishful thinking...

Daniel


More information about the lyx-devel mailing list