Re: Joining newlines in paste
On 2023-07-28 13:46, Scott Kostyshak wrote: On Thu, Jul 27, 2023 at 10:28:51PM -0400, Richard Kimberly Heck wrote: On 7/27/23 12:07, Pavel Sanda wrote: On Thu, Apr 22, 2021 at 12:38:32PM -0400, Scott Kostyshak wrote: On Tue, Apr 20, 2021 at 12:15:56AM +0200, Dr Eberhard W Lisse wrote: On 2021-04-19 14:47 , Christoph Schmitz wrote: Am 19.04.2021 um 14:43 schrieb Daniel : On 10/4/21 16:07, Mario D wrote: Paul, Ctrl+Shift+V works just fine for me, thanks! My fault, and I beg your pardon for this, for not having tried the relative option in "Edit -> Paste Special" : I just tried the "Paste from LaTeX", which doesn't work in my case (I am pasting tikz figures, so @rich: I was referring to the second option). Thank you everybody. :) Actually, I am wondering whether preserving newlines should be the default. I don't think one can expect that the default paste command changes the format that way. Instead the "special" option should be paste with removing newlines, I think. -- Daniel [...] I want to second this proposal! I do not know how much work it would be to create a new setting, which would allow users to use whatever method they prefer. If I have to chose between the two options, Daniel's proposal is my preference. Chris Me three :-)-O I also get confused by this and I think new LyX users are especially confused. I also vote for considering a change of the default behavior. Dear all, this is one of my last items on the TODO list for the 2.4 release. Bunch of people expressed their opinion that our default for paste operation should preserve newlines. I do not have strong opinion but agree that in my experience I have to go to Paste Special sub menu quite often to preserve the newlines. Before looking what would need change, is there reasonable unanimous agreement that this should be the default or are there folks who prefer current behaviour which joins the lines by default? I agree that the default should be to preserve newlines. +1 Scott +1 One thing I am wondering about is whether if this change is made, the shortcut Ctrl+Shift+V should be re-assigned to pasting with joined lines (old behaviour). Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Hack to display section symbol
On 7/28/23 19:43, Pavel Sanda wrote: On Fri, Jul 28, 2023 at 04:54:07PM +0200, Richard Kimberly Heck wrote: commit 5cb80b867f4a59c3253487652ba74a29ad5b3f0f Author: Richard Kimberly Heck Date: Thu Jul 27 01:18:55 2023 -0400 Hack to display section symbol --- lib/unicodesymbols |1 - src/BiblioInfo.cpp | 12 2 files changed, 12 insertions(+), 1 deletions(-) Maybe some note in documentation for other users to know about this? Where? It's one of those things that should just work but doesn't because unicodesymbols uses \textsection instead of \S. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Hack to display section symbol
On Fri, Jul 28, 2023 at 04:54:07PM +0200, Richard Kimberly Heck wrote: > commit 5cb80b867f4a59c3253487652ba74a29ad5b3f0f > Author: Richard Kimberly Heck > Date: Thu Jul 27 01:18:55 2023 -0400 > > Hack to display section symbol > --- > lib/unicodesymbols |1 - > src/BiblioInfo.cpp | 12 > 2 files changed, 12 insertions(+), 1 deletions(-) Maybe some note in documentation for other users to know about this? Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Cursor Invisible on Start Up
On 7/10/23 12:14, Jean-Marc Lasgouttes wrote: Le 08/07/2023 à 18:19, Richard Kimberly Heck a écrit : I'm seeing an odd problem now: When I start up LyX, the cursor is not visible. This can also happen sometimes when switching back to LyX from other programs, though I can't see a pattern. I cannot reproduce. I'm actually seeing this now with a lot of Qt programs, so it is not our issue. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Breakdown of remaining 2.4 bugs
On 7/28/23 04:21, Pavel Sanda wrote: On Thu, Jul 27, 2023 at 11:26:09PM -0400, Richard Kimberly Heck wrote: I'd like to add the BufferParam needed for #10049 even though I don't have Your call, though reading through the bug it seems to me that at this stage even the concept is not entirely clear and thus the tentative changes to BufferParams might be wrong/void in the end... That might be right. #12577 - complex code to improve source editor within LyX; only JMarc tried to understand and failed; anyone wants to engage? This is too big for 2.4.0. I've retargeted to 2.4.1. But I'm not really sure about it. I'll have a look at it between now and then. For this particular case I think the question whether we *want* feature. In other words do we want to guarantee support and bugfixing the code we don't understand ourselves? :) Yes, I think that question has been raised before: Is it worth it essentially to embed a code editor in LyX when we can edit externally now? I hate not to use something that so much work went into, but this is a good example of why it's bad to code first and design second. There is more generic question here though. I see that you flagged bunch of bugs with *finished* patches (e.g. #12797) as for 2.4.1/2 and I would argue that it's better to commit them now for the following reasons: - even if we release RC1 today we still have months for the testing because there is no way translations can not be done in two weeks or so - if the bugs should bite us, better they bite us now. Ppl are more ready to accept breakage with 2.4.0(/RC) than in later phases. That sounds reasonable. I'll go back through those again. We need to freeze, then remerge strings and notify translators. I can handle the review of layouttranslation for 2.4. Riki, do you have preference when to proceed? Before RC release or after? Remerge should be committed by you, otherwise we'll spend megabytes in large commits due to different outputs of different polib versions (tested). What did we do last time? Scott, do you remember? I guess my instinct wouldcoding before designing. be to get translations into RC1, since that's one thing we'd want to have checked. I don't think it matters that much, we just need to agree on something. Given what you said, and what Scott said, I'm inclined then to freeze strings shortly and do another release immediately thereafter, planning on one more pre-release once translations have been done, to be followed pretty quickly by actual release. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Breakdown of remaining 2.4 bugs
On Fri, Jul 28, 2023 at 10:21:50AM +0200, Pavel Sanda wrote: > > On Thu, Jul 27, 2023 at 11:26:09PM -0400, Richard Kimberly Heck wrote: > > I was going to write separately about format freeze. Is there anything > > anyone really wants to get in before we do that? > > Not me. > > > I'd like to add the BufferParam needed for #10049 even though I don't have > > Your call, though reading through the bug it seems to me that at this stage > even the concept is not entirely clear and thus the tentative changes to > BufferParams might be wrong/void in the end... > > > >Yuriy/Riki? #12814 - nesting in Outliner; there is a patch, but needs > > >either clarification or review > > > > I've posted a comment there. I think the patch is right. > > Ok, I'll comit then. > > > >Juergen/Enrico? #12831 - Udi proposes changing order how we output LaTeX > > >font options. Has a patch which looks legit to me, but I would like someone > > >to look over and give +1 > > > > It looks sensible to me, but I don't know that stuff well. > > Will wait for other comments. > > > >#12577 - complex code to improve source editor within LyX; only JMarc tried > > >to understand and failed; anyone wants to engage? > > > > This is too big for 2.4.0. I've retargeted to 2.4.1. But I'm not really sure > > about it. I'll have a look at it between now and then. > > For this particular case I think the question whether we *want* feature. In > other > words do we want to guarantee support and bugfixing the code we don't > understand > ourselves? :) > > > There is more generic question here though. I see that you flagged bunch of > bugs with *finished* patches (e.g. #12797) as for 2.4.1/2 and I would argue > that it's better to commit them now for the following reasons: > > - even if we release RC1 today we still have months for the testing because > there is no way translations can not be done in two weeks or so > > - if the bugs should bite us, better they bite us now. Ppl are more ready to > accept breakage with 2.4.0(/RC) than in later phases. > > > > >We need to freeze, then remerge strings and notify translators. I can > > >handle > > >the review of layouttranslation for 2.4. Riki, do you have preference when > > >to proceed? Before RC release or after? Remerge should be committed by > > >you, > > >otherwise we'll spend megabytes in large commits due to different outputs > > >of > > >different polib versions (tested). > > > > What did we do last time? Scott, do you remember? I guess my instinct would > > be to get translations into RC1, since that's one thing we'd want to have > > checked. I don't have a specific memory, other than asking for help regarding the translations. > I don't think it matters that much, we just need to agree on something. > > The advantage having translations in RC1 is that it really looks like > release candidate. The disadvantage is you have to wait considerable time > for its release. I went through updating cs.po and it took me long weeks > to get through it in a lowkey speed. I think month waiting time is bare > minimum, not counting it's midsummer and ppl are on vacation. > > Another thing is that there would be advantage of having some release > just after you declare string freeze. Translators who can't compile LyX > on their own can actually look on the string/feature in the program, > because sometimes it's hard to translate if you don't see the context > of its use... > > Considering all above my suggestion would be to commit all bugs with > finished patches, declare freezes, get one quick release out (it can > be still beta5 not RC, if you prefer) and then wait for translations/ > feedback for last changes... The only showstopper for that is IMHO > to get #12576 done. I like the idea of getting a pre-release out right after file format freeze, and similar to Pavel I don't think the name is important (beta vs RC). Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Joining newlines in paste (was: Pasting latex in a lyx file)
On Thu, Jul 27, 2023 at 10:28:51PM -0400, Richard Kimberly Heck wrote: > > On 7/27/23 12:07, Pavel Sanda wrote: > > On Thu, Apr 22, 2021 at 12:38:32PM -0400, Scott Kostyshak wrote: > > > On Tue, Apr 20, 2021 at 12:15:56AM +0200, Dr Eberhard W Lisse wrote: > > > > On 2021-04-19 14:47 , Christoph Schmitz wrote: > > > > > > Am 19.04.2021 um 14:43 schrieb Daniel : > > > > > > > > > > > > On 10/4/21 16:07, Mario D wrote: > > > > > > > Paul, > > > > > > > Ctrl+Shift+V works just fine for me, thanks! > > > > > > > My fault, and I beg your pardon for this, for not having tried the > > > > > > > relative option in "Edit -> Paste Special" : I just tried the > > > > > > > "Paste > > > > > > > from LaTeX", which doesn't work in my case (I am pasting tikz > > > > > > > figures, so @rich: I was referring to the second option). Thank > > > > > > > you > > > > > > > everybody. :) > > > > > > Actually, I am wondering whether preserving newlines should be the > > > > > > default. I don't think one can expect that the default paste > > > > > > command > > > > > > changes the format that way. Instead the "special" option should be > > > > > > paste with removing newlines, I think. > > > > > > -- > > > > > > Daniel > > > > [...] > > > > > I want to second this proposal! > > > > > > > > > > I do not know how much work it would be to create a new setting, which > > > > > would allow users to use whatever method they prefer. If I have to > > > > > chose between the two options, Daniel's proposal is my preference. > > > > > > > > > > Chris > > > > > > > > > Me three :-)-O > > > I also get confused by this and I think new LyX users are especially > > > confused. > > > I also vote for considering a change of the default behavior. > > Dear all, > > > > this is one of my last items on the TODO list for the 2.4 release. > > > > Bunch of people expressed their opinion that our default for paste operation > > should preserve newlines. I do not have strong opinion but agree that in my > > experience I have to go to Paste Special sub menu quite often to preserve > > the newlines. > > > > Before looking what would need change, is there reasonable unanimous > > agreement > > that this should be the default or are there folks who prefer current > > behaviour > > which joins the lines by default? > > I agree that the default should be to preserve newlines. +1 Scott signature.asc Description: PGP signature -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Save translators time, already used on different places.
On Fri, Jul 28, 2023 at 09:44:57AM +0200, Kornel Benko wrote: > > Well, if RTL languages need it, then the code would need the placeholder > > for > > numbers_[row] in the string. Whether they need it I don't know. > > > > Pavel > > I don't mean the "Equation", but the following " "; Of course. But what's the point of preserving " " when you can't place the number *in front* of the LTR translation? Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Breakdown of remaining 2.4 bugs
On Thu, Jul 27, 2023 at 11:26:09PM -0400, Richard Kimberly Heck wrote: > I was going to write separately about format freeze. Is there anything > anyone really wants to get in before we do that? Not me. > I'd like to add the BufferParam needed for #10049 even though I don't have Your call, though reading through the bug it seems to me that at this stage even the concept is not entirely clear and thus the tentative changes to BufferParams might be wrong/void in the end... > >Yuriy/Riki? #12814 - nesting in Outliner; there is a patch, but needs > >either clarification or review > > I've posted a comment there. I think the patch is right. Ok, I'll comit then. > >Juergen/Enrico? #12831 - Udi proposes changing order how we output LaTeX > >font options. Has a patch which looks legit to me, but I would like someone > >to look over and give +1 > > It looks sensible to me, but I don't know that stuff well. Will wait for other comments. > >#12577 - complex code to improve source editor within LyX; only JMarc tried > >to understand and failed; anyone wants to engage? > > This is too big for 2.4.0. I've retargeted to 2.4.1. But I'm not really sure > about it. I'll have a look at it between now and then. For this particular case I think the question whether we *want* feature. In other words do we want to guarantee support and bugfixing the code we don't understand ourselves? :) There is more generic question here though. I see that you flagged bunch of bugs with *finished* patches (e.g. #12797) as for 2.4.1/2 and I would argue that it's better to commit them now for the following reasons: - even if we release RC1 today we still have months for the testing because there is no way translations can not be done in two weeks or so - if the bugs should bite us, better they bite us now. Ppl are more ready to accept breakage with 2.4.0(/RC) than in later phases. > >We need to freeze, then remerge strings and notify translators. I can handle > >the review of layouttranslation for 2.4. Riki, do you have preference when > >to proceed? Before RC release or after? Remerge should be committed by you, > >otherwise we'll spend megabytes in large commits due to different outputs of > >different polib versions (tested). > > What did we do last time? Scott, do you remember? I guess my instinct would > be to get translations into RC1, since that's one thing we'd want to have > checked. I don't think it matters that much, we just need to agree on something. The advantage having translations in RC1 is that it really looks like release candidate. The disadvantage is you have to wait considerable time for its release. I went through updating cs.po and it took me long weeks to get through it in a lowkey speed. I think month waiting time is bare minimum, not counting it's midsummer and ppl are on vacation. Another thing is that there would be advantage of having some release just after you declare string freeze. Translators who can't compile LyX on their own can actually look on the string/feature in the program, because sometimes it's hard to translate if you don't see the context of its use... Considering all above my suggestion would be to commit all bugs with finished patches, declare freezes, get one quick release out (it can be still beta5 not RC, if you prefer) and then wait for translations/ feedback for last changes... The only showstopper for that is IMHO to get #12576 done. Pavel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Save translators time, already used on different places.
Am Fri, 28 Jul 2023 09:30:17 +0200
schrieb Pavel Sanda :
> On Fri, Jul 28, 2023 at 08:28:55AM +0200, Kornel Benko wrote:
> > > @@ -314,7 +314,7 @@ void InsetMathHull::addToToc(DocIterator const & pit,
> > > bool
> > > output_active, if (!numbered(row))
> > > continue;
> > > if (label_[row]) {
> > > - label_[row]->setPrettyCounter(_("Equation ") +
> > > numbers_[row]);
> > > + label_[row]->setPrettyCounter(_("Equation") + " " +
> > > numbers_[row]); label_[row]->addToToc(pit, output_active, utype, backend);
> > > }
> > > docstring label = nicelabel(row);
> >
> > Does it not affect RTL languages?
>
> Well, if RTL languages need it, then the code would need the placeholder for
> numbers_[row] in the string. Whether they need it I don't know.
>
> Pavel
I don't mean the "Equation", but the following " ";
Kornel
pgpcM0RYZr9pL.pgp
Description: Digitale Signatur von OpenPGP
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: [LyX/master] Save translators time, already used on different places.
On Fri, Jul 28, 2023 at 08:28:55AM +0200, Kornel Benko wrote:
> > @@ -314,7 +314,7 @@ void InsetMathHull::addToToc(DocIterator const & pit,
> > bool
> > output_active, if (!numbered(row))
> > continue;
> > if (label_[row]) {
> > - label_[row]->setPrettyCounter(_("Equation ") +
> > numbers_[row]);
> > + label_[row]->setPrettyCounter(_("Equation") + " " +
> > numbers_[row]); label_[row]->addToToc(pit, output_active, utype, backend);
> > }
> > docstring label = nicelabel(row);
>
> Does it not affect RTL languages?
Well, if RTL languages need it, then the code would need the placeholder for
numbers_[row] in the string. Whether they need it I don't know.
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
