Save on save

[Richard Kimberly Heck]

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