Re: Save on save
On 2020-03-31 17:02, Richard Kimberly Heck wrote: On 3/31/20 10:37 AM, Daniel wrote: On 2020-03-31 12:40, Jürgen Spitzmüller wrote: Am Dienstag, den 31.03.2020, 11:56 +0200 schrieb Daniel: Wouldn't that cause headaches when opening the document on another computer? Or what is a session? Depends on the workflow. If several people work on a document, it might make sense that inset states remain as the individual users set it on their respective machines, as it's a view property (which does not affect the result). Inset state is certainly a liminal category in this respect, and I think there is no one-fits-all solution. Sounds like a job for a preference setting to me. Those are too global. Then someone will complain that they have some documents where they want inset states preserved and others where they don't. There's no perfect solution, and there are diminishing returns to refining it. Sessions can be preserved across machines by 'sharing' the relevant config files. Seems cumbersome to 'share' sessions, e.g always bring not only your document but also the session files with you. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 3/31/20 10:37 AM, Daniel wrote: > On 2020-03-31 12:40, Jürgen Spitzmüller wrote: >> Am Dienstag, den 31.03.2020, 11:56 +0200 schrieb Daniel: >>> Wouldn't that cause headaches when opening the document on another >>> computer? Or what is a session? >> >> Depends on the workflow. If several people work on a document, it might >> make sense that inset states remain as the individual users set it on >> their respective machines, as it's a view property (which does not >> affect the result). >> >> Inset state is certainly a liminal category in this respect, and I >> think there is no one-fits-all solution. > > Sounds like a job for a preference setting to me. Those are too global. Then someone will complain that they have some documents where they want inset states preserved and others where they don't. There's no perfect solution, and there are diminishing returns to refining it. Sessions can be preserved across machines by 'sharing' the relevant config files. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-31 12:40, Jürgen Spitzmüller wrote: Am Dienstag, den 31.03.2020, 11:56 +0200 schrieb Daniel: Wouldn't that cause headaches when opening the document on another computer? Or what is a session? Depends on the workflow. If several people work on a document, it might make sense that inset states remain as the individual users set it on their respective machines, as it's a view property (which does not affect the result). Inset state is certainly a liminal category in this respect, and I think there is no one-fits-all solution. Sounds like a job for a preference setting to me. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Am Dienstag, den 31.03.2020, 11:56 +0200 schrieb Daniel: > Wouldn't that cause headaches when opening the document on another > computer? Or what is a session? Depends on the workflow. If several people work on a document, it might make sense that inset states remain as the individual users set it on their respective machines, as it's a view property (which does not affect the result). Inset state is certainly a liminal category in this respect, and I think there is no one-fits-all solution. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-31 08:01, Jürgen Spitzmüller wrote: Am Montag, den 30.03.2020, 21:14 +0200 schrieb Daniel: Of course, this will leave unfixed the problem that by default LyX does not saved inset states. LyX does save inset states. What it does not do is render the document dirty if an inset state changes. The latter would be too annoying. Yes, sorry that was too short. I was too short on time. I did not mean save as in "ever saves". I meant it as in "saves in every situation". It's just confusing to me that the situation matters. IMHO inset states are not a property of the document but a property of session and should be saved in session. Wouldn't that cause headaches when opening the document on another computer? Or what is a session? It is often important to me whether insets are open or closed when opening documents on other computers. Anyway, patch committed to master. Thanks! Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Am Montag, den 30.03.2020, 21:14 +0200 schrieb Daniel: > Of course, this will leave unfixed the problem that by default LyX > does not saved inset states. LyX does save inset states. What it does not do is render the document dirty if an inset state changes. The latter would be too annoying. IMHO inset states are not a property of the document but a property of session and should be saved in session. Anyway, patch committed to master. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-30 19:12, Pavel Sanda wrote: On Mon, Mar 30, 2020 at 07:11:01PM +0200, Jürgen Spitzmüller wrote: I think that's all overkill. If we push my patch, Daniel can customize his preferred behavior and we others can all keep ours. I tend to agree with this. Pavel Of course, this will leave unfixed the problem that by default LyX does not saved inset states. But I think there is no point in going on about it as long as the developers don't even see it as a problem. Which is fair enough! Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On Mon, Mar 30, 2020 at 07:11:01PM +0200, Jürgen Spitzmüller wrote: > I think that's all overkill. If we push my patch, Daniel can customize > his preferred behavior and we others can all keep ours. I tend to agree with this. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Am Montag, den 30.03.2020, 19:01 +0200 schrieb Pavel Sanda: > We already have 'Save transient properties' concept, so this > could be part of it or just another checkbox if ppl thing this > is important. > The document would be set dirty when this option would be on & > you changed the state of the inset. I think that's all overkill. If we push my patch, Daniel can customize his preferred behavior and we others can all keep ours. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Am Mon, 30 Mar 2020 19:01:58 +0200 schrieb Pavel Sanda : > On Mon, Mar 30, 2020 at 06:43:35PM +0200, Daniel wrote: > > The only alternative, I can think of is enabling Save when an inset is > > changed but don't render the document dirty. But that doesn't seem > > completely different only more narrow. > > > > What did you have in mind? > > We already have 'Save transient properties' concept, so this > could be part of it or just another checkbox if ppl thing this > is important. > The document would be set dirty when this option would be on & > you changed the state of the inset. > > Pavel +1 Kornel pgp0q4v3ADNIa.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On Mon, Mar 30, 2020 at 06:43:35PM +0200, Daniel wrote: > The only alternative, I can think of is enabling Save when an inset is > changed but don't render the document dirty. But that doesn't seem > completely different only more narrow. > > What did you have in mind? We already have 'Save transient properties' concept, so this could be part of it or just another checkbox if ppl thing this is important. The document would be set dirty when this option would be on & you changed the state of the inset. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-30 17:38, Pavel Sanda wrote: On Mon, Mar 30, 2020 at 04:46:33PM +0200, Daniel wrote: Windows, a star next to the title indicates that there are unsaved changes, on macOS a dot in the close button. LyX already provides those. Couldn't you start looking for those instead? Nope, my solution is quite different, I'll just add reversal of this change to my private patchset ;) But the point of my message was to point out that there is also price for the proposed change namely for the use cases where people rely on timestamps as its encouranges useless save. Whether we want to pay it or no depends on what others will think. If I understood correctly this change is being pushed as workaround for completely different problem(s), like storing the state of inset. Why not rather address the problem itself? I though, if many other popular applications have Save always enabled, then that might not be a bad idea. The only alternative, I can think of is enabling Save when an inset is changed but don't render the document dirty. But that doesn't seem completely different only more narrow. What did you have in mind? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Am Montag, den 30.03.2020, 16:46 +0200 schrieb Daniel: > Alternatively, as mentioned that Libre provides a special Save > button symbol rather than disabled. Would that help, Not me. > or is it disabling in particular that is needed? Yes. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On Mon, Mar 30, 2020 at 04:46:33PM +0200, Daniel wrote: > Windows, a star next to the title indicates that there are unsaved changes, > on macOS a dot in the close button. LyX already provides those. Couldn't you > start looking for those instead? Nope, my solution is quite different, I'll just add reversal of this change to my private patchset ;) But the point of my message was to point out that there is also price for the proposed change namely for the use cases where people rely on timestamps as its encouranges useless save. Whether we want to pay it or no depends on what others will think. If I understood correctly this change is being pushed as workaround for completely different problem(s), like storing the state of inset. Why not rather address the problem itself? Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-30 14:24, Pavel Sanda wrote: On Mon, Mar 30, 2020 at 08:46:26AM +0200, Daniel wrote: What is lost if forced save is the default? It depends how exactly it is done. If the icon for save/menu does not look disabled after save, I will tend to press it just "for sure". This gives the file new timestamp and will sooner or later trigger synchronization machinery, because I have most of my work files changes shared across different computers. Sooner or later I will enconter some 'merge' conflict because of this change. Not too often and in solvable way, but still pain in the ass... Pavel I see. There are often standards in operating systems to show whether a file has changes. Many apps don't even have dedicated save buttons these days. On Windows, a star next to the title indicates that there are unsaved changes, on macOS a dot in the close button. LyX already provides those. Couldn't you start looking for those instead? I must confess, that I abandoned all buttons that have a standard shortcut a long time ago from the LyX toolbar. So, I might have become already used to this. Alternatively, as mentioned that Libre provides a special Save button symbol rather than disabled. Would that help, or is it disabling in particular that is needed? I am also wondering whether there is some particular problem with how LyX handles files. Many applications have no disabled save function, still they seem to be gathered towards synchronization minded people, for example, Visual Studio Code. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On Mon, Mar 30, 2020 at 08:46:26AM +0200, Daniel wrote: > What is lost if forced save is the default? It depends how exactly it is done. If the icon for save/menu does not look disabled after save, I will tend to press it just "for sure". This gives the file new timestamp and will sooner or later trigger synchronization machinery, because I have most of my work files changes shared across different computers. Sooner or later I will enconter some 'merge' conflict because of this change. Not too often and in solvable way, but still pain in the ass... Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Le 29/03/2020 à 16:40, Jürgen Spitzmüller a écrit : Am Sonntag, den 29.03.2020, 16:35 +0200 schrieb Jean-Marc Lasgouttes: I would even not object to a patch that saves unconditionally. We could think afterwards about indicating dirty in the icon. We could do that on top of that, if we want. Personally, though, I like the current behavior, so I would like to keep the behavior of buffer-write. I asked google about it. Some food for thought. https://www.joelonsoftware.com/2008/07/01/dont-hide-or-disable-menu-items/ https://ask.libreoffice.org/en/question/65018/why-did-you-change-the-save-button-2016-edition/ http://document-foundation-mail-archive.969070.n3.nabble.com/Minutes-of-the-Design-Hangout-2015-12-11-td4169745.html JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Am Montag, den 30.03.2020, 11:35 +0200 schrieb Daniel: > The forced save I had in mind would still not save when the buffer > is > read only. The "ReadOnly" argument takes care of that, right? Sure. This only circumvents the "has unsaved changes" test. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-29 16:23, Jürgen Spitzmüller wrote: Any objections to the patch attached? Jürgen The forced save I had in mind would still not save when the buffer is read only. The "ReadOnly" argument takes care of that, right? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-30 07:47, Jürgen Spitzmüller wrote: Am Sonntag, den 29.03.2020, 16:56 +0200 schrieb Kornel Benko: Clever (the patch), keeping old behaviour and at the same time allowing a new shortcut. Since we have two shortcuts for buffer-write (at least in cua and mac bind), how about using one of them (F2) for "buffer-write force"? Jürgen I guess it would also need an additional menu entry as well in order for people to get to know about shortcut and make easily use of it. However, a "Save Force" entry or function isn't really something people are familiar with because applications normally only have "Save" even if in many it behaves exactly like a forced save. So people will wonder what this is all about. Making "Save" do the forced save in LyX would also solve a long standing problem with saving the closed/open state of insets: https://www.lyx.org/trac/ticket/2993 The problem is only partially solved by introducing a new menu entry and shortcut because pressing Ctrl|Cmd+S is what many people do if they try to save their changes in a document. And I am sure almost no one checks the status bar whether it worked or not. They will just press the default shortcut, see that the document is not shown as dirty, and think their changes (to insets) are saved. One could already now add a character, remove it, and then save. But the problem is to remember this non-standard procedure in the special circumstance. A non-standard shortcut helps a bit because people might get used to using F2 instead of the standard shortcut. But I am wondering whether this hassle is worth it. Of course people could just change the shortcut in LyX. But I am wondering what would be the better default for the common user. What is lost if forced save is the default? And is it worse to make people who don't like forced save as the default to change the shortcut rather than make people who like forced save as the default to change it? Saving the state of insets seems to me like a common thing LyX users might like to do. What is the downside for the common user? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Am Sonntag, den 29.03.2020, 16:56 +0200 schrieb Kornel Benko: > Clever (the patch), keeping old behaviour and at the same time > allowing a new shortcut. Since we have two shortcuts for buffer-write (at least in cua and mac bind), how about using one of them (F2) for "buffer-write force"? Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 3/29/20 10:56 AM, Kornel Benko wrote: > Am Sun, 29 Mar 2020 16:40:51 +0200 > schrieb Jürgen Spitzmüller : > >> Am Sonntag, den 29.03.2020, 16:35 +0200 schrieb Jean-Marc Lasgouttes: >>> I would even not object to a patch that saves unconditionally. We >>> could >>> think afterwards about indicating dirty in the icon. >> We could do that on top of that, if we want. >> >> Personally, though, I like the current behavior, so I would like to >> keep the behavior of buffer-write. >> >> Jürgen > Clever (the patch), keeping old behaviour and at the same time > allowing a new shortcut. Looks good to me too. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Am Sonntag, den 29.03.2020, 16:56 +0200 schrieb Kornel Benko: > Clever (the patch), keeping old behaviour and at the same time > allowing a new shortcut. Yes, that's the idea :-) Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Am Sun, 29 Mar 2020 16:40:51 +0200 schrieb Jürgen Spitzmüller : > Am Sonntag, den 29.03.2020, 16:35 +0200 schrieb Jean-Marc Lasgouttes: > > I would even not object to a patch that saves unconditionally. We > > could > > think afterwards about indicating dirty in the icon. > > We could do that on top of that, if we want. > > Personally, though, I like the current behavior, so I would like to > keep the behavior of buffer-write. > > Jürgen Clever (the patch), keeping old behaviour and at the same time allowing a new shortcut. My 2c. Kornel pgpEuUc7Gu9XA.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Am Sonntag, den 29.03.2020, 16:35 +0200 schrieb Jean-Marc Lasgouttes: > I would even not object to a patch that saves unconditionally. We > could > think afterwards about indicating dirty in the icon. We could do that on top of that, if we want. Personally, though, I like the current behavior, so I would like to keep the behavior of buffer-write. Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Le 29/03/2020 à 16:23, Jürgen Spitzmüller a écrit : You mean if the document is not dirty? Hit "s", backspace, then save. I.e, make it dirty. Any objections to the patch attached? I would even not object to a patch that saves unconditionally. We could think afterwards about indicating dirty in the icon. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Am Donnerstag, den 19.03.2020, 09:43 -0400 schrieb Richard Kimberly
Heck:
> On 3/19/20 5:43 AM, Daniel wrote:
> > All applications (Libre Writer, Pages, Visual Studio Code,
> > TextEdit,
> > etc.) I tested save my documents whenever I press ctrl|cmd+S or
> > choose
> > Save from the menu. This can be seen, for example, from the
> > modified
> > date being updated.
> >
> > The only exception are MS office (which does not save and not gray
> > out
> > the Save menu) and LyX (which does not save but does at least gray
> > out
> > the Save menu). Is there a particular reason LyX behaves in this
> > way?
> > Is there a way, I can change this behavior and force a save?
>
> You mean if the document is not dirty? Hit "s", backspace, then save.
> I.e, make it dirty.
Any objections to the patch attached?
Jürgen
>
> Riki
>
>
diff --git a/src/LyXAction.cpp b/src/LyXAction.cpp
index a9789ad290..6089e5e8d9 100644
--- a/src/LyXAction.cpp
+++ b/src/LyXAction.cpp
@@ -892,7 +892,8 @@ void LyXAction::init()
* \li Notion: Saves the current buffer to disk, using the filename that
is already associated with the buffer, asking for one if
none is yet assigned.
- * \li Syntax: buffer-write
+ * \li Syntax: buffer-write [force]
+ * \li Params: force: write even if buffer is clean.
* \endvar
*/
{ LFUN_BUFFER_WRITE, "buffer-write", ReadOnly, Buffer },
diff --git a/src/frontends/qt/GuiView.cpp b/src/frontends/qt/GuiView.cpp
index c7a1bd9458..78e0817cdd 100644
--- a/src/frontends/qt/GuiView.cpp
+++ b/src/frontends/qt/GuiView.cpp
@@ -1996,7 +1996,9 @@ bool GuiView::getStatus(FuncRequest const & cmd, FuncStatus & flag)
}
case LFUN_BUFFER_WRITE:
- enable = doc_buffer && (doc_buffer->isUnnamed() || !doc_buffer->isClean());
+ enable = doc_buffer && (doc_buffer->isUnnamed()
+ || (!doc_buffer->isClean()
+ || cmd.argument() == "force"));
break;
//FIXME: This LFUN should be moved to GuiApplication.
signature.asc
Description: This is a digitally signed message part
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
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
Re: Save on save
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. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
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 -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
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 -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
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
Re: Save on save
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 -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
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. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Am Freitag, den 27.03.2020, 14:25 -0400 schrieb Richard Kimberly Heck: > Try adding "escape" first. That clears the selection. Of course, you > lose the selection. How about a simple buffer-mark-dirty lfun for convenience? Jürgen signature.asc Description: This is a digitally signed message part -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
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 -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
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. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
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 -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
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. But it seems any change to the document will likely have an effect cannot be easily reverted by a another command. This does not only concern deleted text but also added tracked changes, e.g. by inserting an inset. So, I guess there is no way to get this without proper implementation, right? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
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 -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
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 -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
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. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-20 19:34, Pavel Sanda wrote: On Fri, Mar 20, 2020 at 07:12:00PM +0100, Daniel wrote: I think such an indication is optional, but might be a good idea. Except for libre office I saw no other application that has this indication. Maybe because the indication in the title is already considered sufficient? As far as I looked on different offices the indication is not there becase the ban saving clean document they way we do. (I understand your problems though.) I understood that Open Office and MS Office do it as LyX. The same for Adobe Reader. I did not see it in Pages and Scribus. Also, I guess it is not a feature that would be particularly useful in office applications only. Inkscape, for example, didn't have it either. Many applications allow for always saving, e.g. Skim and Visual Studio Code, but don't have toolbar icons for save at all. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On Fri, Mar 20, 2020 at 07:12:00PM +0100, Daniel wrote: > I think such an indication is optional, but might be a good idea. Except for > libre office I saw no other application that has this indication. Maybe > because the indication in the title is already considered sufficient? As far as I looked on different offices the indication is not there becase the ban saving clean document they way we do. (I understand your problems though.) Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-20 18:46, Pavel Sanda wrote: On Fri, Mar 20, 2020 at 11:15:11AM -0400, Richard Kimberly Heck wrote: I looked briefly at this. I think we would need to check that Buffer::isClean is not used for otherpurposes, or else introduce some other Buffer::canSave method for this purpose. I guess we would need some new state, which would allow icon to have indication that save is possible but not needed. That's at least what I see with libre office (open office I tested here behave as nowadays lyx). I think such an indication is optional, but might be a good idea. Except for libre office I saw no other application that has this indication. Maybe because the indication in the title is already considered sufficient? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On Fri, Mar 20, 2020 at 11:15:11AM -0400, Richard Kimberly Heck wrote: > I looked briefly at this. I think we would need to check that > Buffer::isClean is not used for otherpurposes, or else introduce some > other Buffer::canSave method for this purpose. I guess we would need some new state, which would allow icon to have indication that save is possible but not needed. That's at least what I see with libre office (open office I tested here behave as nowadays lyx). Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 3/20/20 7:30 AM, Kornel Benko wrote: > Am Fri, 20 Mar 2020 10:19:05 +0100 > schrieb Jean-Marc Lasgouttes : > >> Le 20/03/2020 à 08:11, Daniel a écrit : >>> Save As is a bit complicated as a general replacement for Save. But I >>> can't remember to use it just for some cases. When I make changes to >>> insets that seem important to me I just think I should be able to save >>> them as I save every other document change. It doesn't come to my mind >>> that I am in a special situation. >> The fact that Save is disabled in this case is just a design decision. >> We could easily revert it. > +1 I looked briefly at this. I think we would need to check that Buffer::isClean is not used for otherpurposes, or else introduce some other Buffer::canSave method for this purpose. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Am Fri, 20 Mar 2020 10:19:05 +0100 schrieb Jean-Marc Lasgouttes : > Le 20/03/2020 à 08:11, Daniel a écrit : > > Save As is a bit complicated as a general replacement for Save. But I > > can't remember to use it just for some cases. When I make changes to > > insets that seem important to me I just think I should be able to save > > them as I save every other document change. It doesn't come to my mind > > that I am in a special situation. > > The fact that Save is disabled in this case is just a design decision. > We could easily revert it. +1 > JMarc Kornel pgpSWa055JHPh.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Le 20/03/2020 à 08:11, Daniel a écrit : Save As is a bit complicated as a general replacement for Save. But I can't remember to use it just for some cases. When I make changes to insets that seem important to me I just think I should be able to save them as I save every other document change. It doesn't come to my mind that I am in a special situation. The fact that Save is disabled in this case is just a design decision. We could easily revert it. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-19 23:09, Guenter Milde wrote: On 2020-03-19, Richard Kimberly Heck wrote: On 3/19/20 9:46 AM, racoon wrote: On 2020-03-19 14:43, Richard Kimberly Heck wrote: On 3/19/20 5:43 AM, Daniel wrote: All applications (Libre Writer, Pages, Visual Studio Code, TextEdit, etc.) I tested save my documents whenever I press ctrl|cmd+S or choose Save from the menu. This can be seen, for example, from the modified date being updated. The only exception are MS office (which does not save and not gray out the Save menu) and LyX (which does not save but does at least gray out the Save menu). Is there a particular reason LyX behaves in this way? Is there a way, I can change this behavior and force a save? You mean if the document is not dirty? Hit "s", backspace, then save. I.e, make it dirty. I find it hard to remember doing this. So, I would like to change LyX's Save command to a forced saving. Maybe there is a nice command sequence that renders the document dirty, maybe via some change; undoes the change, if there was one made; saves? 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. I usually use "Save-As" (Shift-Ctrl-S here) in these cases. Günter Save As is a bit complicated as a general replacement for Save. But I can't remember to use it just for some cases. When I make changes to insets that seem important to me I just think I should be able to save them as I save every other document change. It doesn't come to my mind that I am in a special situation. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-19, Richard Kimberly Heck wrote: > On 3/19/20 9:46 AM, racoon wrote: >> On 2020-03-19 14:43, Richard Kimberly Heck wrote: >>> On 3/19/20 5:43 AM, Daniel wrote: >>>> All applications (Libre Writer, Pages, Visual Studio Code, TextEdit, >>>> etc.) I tested save my documents whenever I press ctrl|cmd+S or choose >>>> Save from the menu. This can be seen, for example, from the modified >>>> date being updated. >>>> The only exception are MS office (which does not save and not gray out >>>> the Save menu) and LyX (which does not save but does at least gray out >>>> the Save menu). Is there a particular reason LyX behaves in this way? >>>> Is there a way, I can change this behavior and force a save? >>> You mean if the document is not dirty? Hit "s", backspace, then save. >>> I.e, make it dirty. >> I find it hard to remember doing this. So, I would like to change LyX's >> Save command to a forced saving. >> Maybe there is a nice command sequence that renders the document dirty, >> maybe via some change; undoes the change, if there was one made; saves? > 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. I usually use "Save-As" (Shift-Ctrl-S here) in these cases. Günter -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-19 17:26, Daniel wrote: On 2020-03-19 17:22, Jean-Marc Lasgouttes wrote: Le 19/03/2020 à 15:14, racoon a écrit : (For some reasons my RE posts get a "Is being held until the list moderator can review it for approval.") The reason is that you are not subscribed with this address. I added the other address to the whitelist now. JMarc There must still have been a change with the list settings then because I am using this and only this address since years. I wouldn't even know how to subscribe. Never did, I think. Daniel Ah, I subscribe by selecting the list in Thunderbird. Still, has been the same email address all along... Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-19 17:22, Jean-Marc Lasgouttes wrote: Le 19/03/2020 à 15:14, racoon a écrit : (For some reasons my RE posts get a "Is being held until the list moderator can review it for approval.") The reason is that you are not subscribed with this address. I added the other address to the whitelist now. JMarc There must still have been a change with the list settings then because I am using this and only this address since years. I wouldn't even know how to subscribe. Never did, I think. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Le 19/03/2020 à 15:14, racoon a écrit : (For some reasons my RE posts get a "Is being held until the list moderator can review it for approval.") The reason is that you are not subscribed with this address. I added the other address to the whitelist now. JMarc -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-19 15:21, Scott Kostyshak wrote: On Thu, Mar 19, 2020 at 03:14:00PM +0100, racoon wrote: On 2020-03-19 15:08, Scott Kostyshak wrote: On Thu, Mar 19, 2020 at 09:53:19AM -0400, Richard Kimberly Heck wrote: On 3/19/20 9:46 AM, racoon wrote: On 2020-03-19 14:43, Richard Kimberly Heck wrote: On 3/19/20 5:43 AM, Daniel wrote: All applications (Libre Writer, Pages, Visual Studio Code, TextEdit, etc.) I tested save my documents whenever I press ctrl|cmd+S or choose Save from the menu. This can be seen, for example, from the modified date being updated. The only exception are MS office (which does not save and not gray out the Save menu) and LyX (which does not save but does at least gray out the Save menu). Is there a particular reason LyX behaves in this way? Is there a way, I can change this behavior and force a save? You mean if the document is not dirty? Hit "s", backspace, then save. I.e, make it dirty. Riki I find it hard to remember doing this. So, I would like to change LyX's Save command to a forced saving. Maybe there is a nice command sequence that renders the document dirty, maybe via some change; undoes the change, if there was one made; saves? 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. It's always useful to have a use case for motivation. racoon, what is your use case? I've come across this when I wanted to do something like open a 2.2.x file in 2.3.x and save it just to update the file format. I then commit those changes in git, and then I make a change. That ways I separate out the format update from the change. Scott My use case is that I often change the closed/open state of insets which does not render the document dirty. But I still want LyX to remember these changes. And I often forget to render it artificially dirty before saving. Ah, that makes sense. I now remember having the same issue (closing/opening insets). Bold move: https://www.lyx.org/trac/ticket/2993#comment:13. Feel free to close again. :) Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-19 14:53, Richard Kimberly Heck wrote: On 3/19/20 9:46 AM, racoon wrote: On 2020-03-19 14:43, Richard Kimberly Heck wrote: On 3/19/20 5:43 AM, Daniel wrote: All applications (Libre Writer, Pages, Visual Studio Code, TextEdit, etc.) I tested save my documents whenever I press ctrl|cmd+S or choose Save from the menu. This can be seen, for example, from the modified date being updated. The only exception are MS office (which does not save and not gray out the Save menu) and LyX (which does not save but does at least gray out the Save menu). Is there a particular reason LyX behaves in this way? Is there a way, I can change this behavior and force a save? You mean if the document is not dirty? Hit "s", backspace, then save. I.e, make it dirty. Riki I find it hard to remember doing this. So, I would like to change LyX's Save command to a forced saving. Maybe there is a nice command sequence that renders the document dirty, maybe via some change; undoes the change, if there was one made; saves? 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? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-19 14:43, Richard Kimberly Heck wrote: On 3/19/20 5:43 AM, Daniel wrote: All applications (Libre Writer, Pages, Visual Studio Code, TextEdit, etc.) I tested save my documents whenever I press ctrl|cmd+S or choose Save from the menu. This can be seen, for example, from the modified date being updated. The only exception are MS office (which does not save and not gray out the Save menu) and LyX (which does not save but does at least gray out the Save menu). Is there a particular reason LyX behaves in this way? Is there a way, I can change this behavior and force a save? You mean if the document is not dirty? Hit "s", backspace, then save. I.e, make it dirty. Riki I find it hard to remember doing this. So, I would like to change LyX's Save command to a forced saving. Maybe there is a nice command sequence that renders the document dirty, maybe via some change; undoes the change, if there was one made; saves? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 2020-03-19 15:08, Scott Kostyshak wrote: On Thu, Mar 19, 2020 at 09:53:19AM -0400, Richard Kimberly Heck wrote: On 3/19/20 9:46 AM, racoon wrote: On 2020-03-19 14:43, Richard Kimberly Heck wrote: On 3/19/20 5:43 AM, Daniel wrote: All applications (Libre Writer, Pages, Visual Studio Code, TextEdit, etc.) I tested save my documents whenever I press ctrl|cmd+S or choose Save from the menu. This can be seen, for example, from the modified date being updated. The only exception are MS office (which does not save and not gray out the Save menu) and LyX (which does not save but does at least gray out the Save menu). Is there a particular reason LyX behaves in this way? Is there a way, I can change this behavior and force a save? You mean if the document is not dirty? Hit "s", backspace, then save. I.e, make it dirty. Riki I find it hard to remember doing this. So, I would like to change LyX's Save command to a forced saving. Maybe there is a nice command sequence that renders the document dirty, maybe via some change; undoes the change, if there was one made; saves? 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. It's always useful to have a use case for motivation. racoon, what is your use case? I've come across this when I wanted to do something like open a 2.2.x file in 2.3.x and save it just to update the file format. I then commit those changes in git, and then I make a change. That ways I separate out the format update from the change. Scott My use case is that I often change the closed/open state of insets which does not render the document dirty. But I still want LyX to remember these changes. And I often forget to render it artificially dirty before saving. (For some reasons my RE posts get a "Is being held until the list moderator can review it for approval.") Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
Am Thu, 19 Mar 2020 10:21:04 -0400 schrieb Scott Kostyshak : > On Thu, Mar 19, 2020 at 03:14:00PM +0100, racoon wrote: > > On 2020-03-19 15:08, Scott Kostyshak wrote: > > > On Thu, Mar 19, 2020 at 09:53:19AM -0400, Richard Kimberly Heck wrote: > > > > On 3/19/20 9:46 AM, racoon wrote: > > > > > On 2020-03-19 14:43, Richard Kimberly Heck wrote: > > > > > > On 3/19/20 5:43 AM, Daniel wrote: > > > > > > > All applications (Libre Writer, Pages, Visual Studio Code, > > > > > > > TextEdit, > > > > > > > etc.) I tested save my documents whenever I press ctrl|cmd+S or > > > > > > > choose > > > > > > > Save from the menu. This can be seen, for example, from the > > > > > > > modified > > > > > > > date being updated. > > > > > > > > > > > > > > The only exception are MS office (which does not save and not > > > > > > > gray out > > > > > > > the Save menu) and LyX (which does not save but does at least > > > > > > > gray out > > > > > > > the Save menu). Is there a particular reason LyX behaves in this > > > > > > > way? > > > > > > > Is there a way, I can change this behavior and force a save? > > > > > > > > > > > > You mean if the document is not dirty? Hit "s", backspace, then > > > > > > save. > > > > > > I.e, make it dirty. > > > > > > > > > > > > Riki > > > > > > > > > > > > > > > > > > > > > > I find it hard to remember doing this. So, I would like to change > > > > > LyX's > > > > > Save command to a forced saving. > > > > > > > > > > Maybe there is a nice command sequence that renders the document > > > > > dirty, > > > > > maybe via some change; undoes the change, if there was one made; > > > > > saves? > > > > > > > > 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. > > > > > > It's always useful to have a use case for motivation. racoon, what is > > > your use case? I've come across this when I wanted to do something like > > > open a 2.2.x file in 2.3.x and save it just to update the file format. I > > > then commit those changes in git, and then I make a change. That ways I > > > separate out the format update from the change. > > > > > > Scott > > > > > > > My use case is that I often change the closed/open state of insets which > > does not render the document dirty. But I still want LyX to remember > > these changes. And I often forget to render it artificially dirty before > > saving. > > Ah, that makes sense. I now remember having the same issue > (closing/opening insets). > > > (For some reasons my RE posts get a "Is being held until the list > > moderator can review it for approval.") > > Strange, I think I'm getting your messages. Because you are one of the addresses? I didn't get his email. > I don't know what "RE" > stands for though. > > Scott Subject: Re: ... ? Kornel pgpmygj91Z3O9.pgp Description: Digitale Signatur von OpenPGP -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On Thu, Mar 19, 2020 at 03:14:00PM +0100, racoon wrote: > On 2020-03-19 15:08, Scott Kostyshak wrote: > > On Thu, Mar 19, 2020 at 09:53:19AM -0400, Richard Kimberly Heck wrote: > > > On 3/19/20 9:46 AM, racoon wrote: > > > > On 2020-03-19 14:43, Richard Kimberly Heck wrote: > > > > > On 3/19/20 5:43 AM, Daniel wrote: > > > > > > All applications (Libre Writer, Pages, Visual Studio Code, TextEdit, > > > > > > etc.) I tested save my documents whenever I press ctrl|cmd+S or > > > > > > choose > > > > > > Save from the menu. This can be seen, for example, from the modified > > > > > > date being updated. > > > > > > > > > > > > The only exception are MS office (which does not save and not gray > > > > > > out > > > > > > the Save menu) and LyX (which does not save but does at least gray > > > > > > out > > > > > > the Save menu). Is there a particular reason LyX behaves in this > > > > > > way? > > > > > > Is there a way, I can change this behavior and force a save? > > > > > > > > > > You mean if the document is not dirty? Hit "s", backspace, then save. > > > > > I.e, make it dirty. > > > > > > > > > > Riki > > > > > > > > > > > > > > > > > > I find it hard to remember doing this. So, I would like to change LyX's > > > > Save command to a forced saving. > > > > > > > > Maybe there is a nice command sequence that renders the document dirty, > > > > maybe via some change; undoes the change, if there was one made; saves? > > > > > > 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. > > > > It's always useful to have a use case for motivation. racoon, what is > > your use case? I've come across this when I wanted to do something like > > open a 2.2.x file in 2.3.x and save it just to update the file format. I > > then commit those changes in git, and then I make a change. That ways I > > separate out the format update from the change. > > > > Scott > > > > My use case is that I often change the closed/open state of insets which > does not render the document dirty. But I still want LyX to remember > these changes. And I often forget to render it artificially dirty before > saving. Ah, that makes sense. I now remember having the same issue (closing/opening insets). > (For some reasons my RE posts get a "Is being held until the list > moderator can review it for approval.") Strange, I think I'm getting your messages. I don't know what "RE" stands for though. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On Thu, Mar 19, 2020 at 09:53:19AM -0400, Richard Kimberly Heck wrote: > On 3/19/20 9:46 AM, racoon wrote: > > On 2020-03-19 14:43, Richard Kimberly Heck wrote: > >> On 3/19/20 5:43 AM, Daniel wrote: > >>> All applications (Libre Writer, Pages, Visual Studio Code, TextEdit, > >>> etc.) I tested save my documents whenever I press ctrl|cmd+S or choose > >>> Save from the menu. This can be seen, for example, from the modified > >>> date being updated. > >>> > >>> The only exception are MS office (which does not save and not gray out > >>> the Save menu) and LyX (which does not save but does at least gray out > >>> the Save menu). Is there a particular reason LyX behaves in this way? > >>> Is there a way, I can change this behavior and force a save? > >> > >> You mean if the document is not dirty? Hit "s", backspace, then save. > >> I.e, make it dirty. > >> > >> Riki > >> > >> > > > > I find it hard to remember doing this. So, I would like to change LyX's > > Save command to a forced saving. > > > > Maybe there is a nice command sequence that renders the document dirty, > > maybe via some change; undoes the change, if there was one made; saves? > > 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. It's always useful to have a use case for motivation. racoon, what is your use case? I've come across this when I wanted to do something like open a 2.2.x file in 2.3.x and save it just to update the file format. I then commit those changes in git, and then I make a change. That ways I separate out the format update from the change. Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 3/19/20 9:46 AM, racoon wrote: > On 2020-03-19 14:43, Richard Kimberly Heck wrote: >> On 3/19/20 5:43 AM, Daniel wrote: >>> All applications (Libre Writer, Pages, Visual Studio Code, TextEdit, >>> etc.) I tested save my documents whenever I press ctrl|cmd+S or choose >>> Save from the menu. This can be seen, for example, from the modified >>> date being updated. >>> >>> The only exception are MS office (which does not save and not gray out >>> the Save menu) and LyX (which does not save but does at least gray out >>> the Save menu). Is there a particular reason LyX behaves in this way? >>> Is there a way, I can change this behavior and force a save? >> >> You mean if the document is not dirty? Hit "s", backspace, then save. >> I.e, make it dirty. >> >> Riki >> >> > > I find it hard to remember doing this. So, I would like to change LyX's > Save command to a forced saving. > > Maybe there is a nice command sequence that renders the document dirty, > maybe via some change; undoes the change, if there was one made; saves? 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 -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Save on save
On 3/19/20 5:43 AM, Daniel wrote: > All applications (Libre Writer, Pages, Visual Studio Code, TextEdit, > etc.) I tested save my documents whenever I press ctrl|cmd+S or choose > Save from the menu. This can be seen, for example, from the modified > date being updated. > > The only exception are MS office (which does not save and not gray out > the Save menu) and LyX (which does not save but does at least gray out > the Save menu). Is there a particular reason LyX behaves in this way? > Is there a way, I can change this behavior and force a save? You mean if the document is not dirty? Hit "s", backspace, then save. I.e, make it dirty. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Save on save
All applications (Libre Writer, Pages, Visual Studio Code, TextEdit, etc.) I tested save my documents whenever I press ctrl|cmd+S or choose Save from the menu. This can be seen, for example, from the modified date being updated. The only exception are MS office (which does not save and not gray out the Save menu) and LyX (which does not save but does at least gray out the Save menu). Is there a particular reason LyX behaves in this way? Is there a way, I can change this behavior and force a save? Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
