Re: Breakdown of remaining 2.4 bugs
On 2023-08-12 11:17, Daniel wrote: On 2023-07-28 17:46, Richard Kimberly Heck wrote: On 7/28/23 04:21, Pavel Sanda wrote: On Thu, Jul 27, 2023 at 11:26:09PM -0400, Richard Kimberly Heck wrote: #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. I don't get the code first, design second thing because being able to edit externally was possible before I started to work on that. So, obviously, I took that into consideration (see below). I think it is more about asking the developers whether they like such a feature or not. I provided some opportunity for this, including on the list. But don't worry about my feelings or the work that went into. As I have said before, I will use my patches locally anyway. But it seems like a good idea for a couple of reasons. Yes, it is true that one can use an external editor. But for small edits, such as commenting out a part of the code, this seems to be unnecessary cumbersome. This patch is not supposed to substitute a full blown editor. It is really just to provide minimal help for small edits. Otherwise, why not just remove any possibility of editing of code inside LyX? I don't think it's a good idea because, for example, the external editing feature is too cumbersome for this. But the reasoning against the patch presented above seems to lead there. Another reason is that to get support for commenting out of LyX's own layout code is nothing that someone who is not a code editor specialist will be able to accomplish easily. And I think it should not be taken for granted that (almost) all LyX users are code editor wizards. In summary, I think there will always be people that prefer to edit code inside of LyX, at least sometimes. And for those some *minimal* code editing support is very helpful. Daniel I forgot about the support and bugfix part: It surprises me a bit that no one understands the code since there is stuff that is much harder to understand in LyX. But in any case, I have been around for ages now. I am not going anywhere. So, I don't understand why you don't leave support and bugfixes for a part of LyX that is really isolated from other parts and has only effects that are immediately visible, i.e. there are no non-obvious effects when the user is using the feature, to someone else then (even if that person is not strictly a member of "we"). -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Customization ctests now failing on master
Am Samstag, dem 12.08.2023 um 12:18 +0300 schrieb Udicoudco: > > Another possible patch attached Yes, this is neat, but I wanted to avoid changing the package loading order if not absolutely necessary. -- Jürgen -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Customization ctests now failing on master
Am Freitag, dem 11.08.2023 um 23:11 +0300 schrieb Udicoudco: > Jürgen, your code should work, you just forgot > to change the category code of @. > See the patch prettyref-detokenize.patch. Ouch %-/ Thanks! > But I think we should note it could potentially > change the behaviour of the package, If you'll > export the file newfile1.lyx after applying prettyref- > detokenize.patch, > you will get different results if the language of the document > is english or french. I see. Yes, this is an issue to consider. > I propose a different approach. see the patch prettyref.patch. So let's go with this one. > I'm not sure what is the best way to stream strings into the latex > source, so feel free to change things, and if you have the patience > to explain what I should have done, I'll appreciate it :) I think the approach is sane enough. Since we haven't heard many reports about this bug recently, the case seems to be rather seldom (I suppose French users avoid prettyref). -- Jürgen -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
Re: Customization ctests now failing on master
On Fri, Aug 11, 2023 at 11:11 PM Udicoudco wrote:
> I propose a different approach. see the patch prettyref.patch.
Another possible patch attached
> lyx-devel mailing list
> lyx-devel@lists.lyx.org
> http://lists.lyx.org/mailman/listinfo/lyx-devel
diff --git a/src/LaTeXFeatures.cpp b/src/LaTeXFeatures.cpp
index 0e678ea62a..457d7236ac 100644
--- a/src/LaTeXFeatures.cpp
+++ b/src/LaTeXFeatures.cpp
@@ -1107,7 +1107,6 @@ char const * simplefeatures[] = {
"pifont",
// subfig is handled in BufferParams.cpp
"varioref",
- "prettyref",
"refstyle",
/*For a successful cooperation of the `wrapfig' package with the
`float' package you should load the `wrapfig' package *after*
@@ -1286,10 +1285,16 @@ string const LaTeXFeatures::getPackages() const
// Babel languages with activated colon (such as French) break
// with prettyref. Work around that.
- if (!runparams_.isFullUnicode() && useBabel()
- && mustProvide("prettyref") && contains(getActiveChars(), ':')) {
- packages << "% Make prettyref compatible with babel active colon\n"
- << "\\def\\prettyref#1{\\expandafter\\@prettyref\\detokenize{#1:}}\n";
+ bool const fix_prettyref = (!runparams_.isFullUnicode() && useBabel()
+ && contains(getActiveChars(), ':'));
+
+ if (mustProvide("prettyref")) {
+ if (fix_prettyref)
+ packages << "% Make prettyref compatible with babel active colon\n"
+ << "\\edef\\LyXFixForPrettyRef{\\the\\catcode`:}\\catcode`:=13\n";
+ packages << "\\usepackage{prettyref}\n";
+ if (fix_prettyref)
+ packages << "\\catcode`:=\\LyXFixForPrettyRef\\relax\n";
}
if (mustProvide("changebar")) {
--
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 2023-07-28 17:46, Richard Kimberly Heck wrote: On 7/28/23 04:21, Pavel Sanda wrote: On Thu, Jul 27, 2023 at 11:26:09PM -0400, Richard Kimberly Heck wrote: #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. I don't get the code first, design second thing because being able to edit externally was possible before I started to work on that. So, obviously, I took that into consideration (see below). I think it is more about asking the developers whether they like such a feature or not. I provided some opportunity for this, including on the list. But don't worry about my feelings or the work that went into. As I have said before, I will use my patches locally anyway. But it seems like a good idea for a couple of reasons. Yes, it is true that one can use an external editor. But for small edits, such as commenting out a part of the code, this seems to be unnecessary cumbersome. This patch is not supposed to substitute a full blown editor. It is really just to provide minimal help for small edits. Otherwise, why not just remove any possibility of editing of code inside LyX? I don't think it's a good idea because, for example, the external editing feature is too cumbersome for this. But the reasoning against the patch presented above seems to lead there. Another reason is that to get support for commenting out of LyX's own layout code is nothing that someone who is not a code editor specialist will be able to accomplish easily. And I think it should not be taken for granted that (almost) all LyX users are code editor wizards. In summary, I think there will always be people that prefer to edit code inside of LyX, at least sometimes. And for those some *minimal* code editing support is very helpful. Daniel -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
