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
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
