Save on save

[Richard Kimberly Heck]

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