I haven't used branches all that much but I am using them at the moment.
Something that has become an irritant is the way the pop-up panel with
the branch name and branch and inset status too often covers the point
where I want to enter text. At present the panel is positioned below and
t
On Tue, Apr 01, 2025 at 10:34:32AM -0400, Richard Kimberly Heck wrote:
> On 3/31/25 4:19 PM, Scott Kostyshak wrote:
> > On Tue, Apr 01, 2025 at 08:39:51AM +1300, Andrew Parsloe wrote:
> > > I haven't used branches all that much but I am using them at the moment.
> > &
On 3/31/25 4:19 PM, Scott Kostyshak wrote:
On Tue, Apr 01, 2025 at 08:39:51AM +1300, Andrew Parsloe wrote:
I haven't used branches all that much but I am using them at the moment.
Something that has become an irritant is the way the pop-up panel with the
branch name and branch and inset s
On Tue, Apr 01, 2025 at 08:39:51AM +1300, Andrew Parsloe wrote:
> I haven't used branches all that much but I am using them at the moment.
> Something that has become an irritant is the way the pop-up panel with the
> branch name and branch and inset status too often covers the
; True, my theory is that some developers don't use branches because
> > > > having to use the features repo is just a bit more of an inconvenience
> > > > than using the main repo. I'm not so confident in my theory though.
> > >
> > > Why is it less
On Mon, Mar 03, 2025 at 03:29:31PM +0100, Scott Kostyshak wrote:
> On Mon, Mar 03, 2025 at 03:19:08PM +0100, Jean-Marc Lasgouttes wrote:
> > Le 03/03/2025 ? 15:12, Scott Kostyshak a écrit :
> > > True, my theory is that some developers don't use branches because
> >
On Mon, Mar 03, 2025 at 03:19:08PM +0100, Jean-Marc Lasgouttes wrote:
> Le 03/03/2025 à 15:12, Scott Kostyshak a écrit :
> > True, my theory is that some developers don't use branches because
> > having to use the features repo is just a bit more of an inconvenience
> >
Le 03/03/2025 à 15:12, Scott Kostyshak a écrit :
True, my theory is that some developers don't use branches because
having to use the features repo is just a bit more of an inconvenience
than using the main repo. I'm not so confident in my theory though.
Why is it less convenient? I
he ctests?". I think in these cases there will
be responses and testing. If by chance there is not, they should feel
free to merge.
> We have features repo https://git.lyx.org/gitweb/?p=features.git;a=summary
> where longer-term projects can go in unique branch. Is it so much more
&g
Is it so much more
difficult to merge from there if you prefer to work with unique
branches?
We actually have even personal repos but they were so unused that
I hid them from the web view...
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
https://lists.lyx.org/mailman/listinfo/lyx-devel
On Sun, Mar 02, 2025 at 09:40:00PM +0100, Pavel Sanda wrote:
> On Sun, Mar 02, 2025 at 05:16:23PM +0100, Scott Kostyshak wrote:
> > Is it OK to push branches to our main repository?
> >
> > We have a features repository (https://wiki.lyx.org/Devel/LyXGit#toc4),
> >
On Sun, Mar 02, 2025 at 05:16:23PM +0100, Scott Kostyshak wrote:
> Is it OK to push branches to our main repository?
>
> We have a features repository (https://wiki.lyx.org/Devel/LyXGit#toc4),
> but I'm talking about more short-lived branches. It would be more
> convenient if
Is it OK to push branches to our main repository?
We have a features repository (https://wiki.lyx.org/Devel/LyXGit#toc4),
but I'm talking about more short-lived branches. It would be more
convenient if we can make those on the main remote, but I forget if we
have a policy against that for
On Sat, 2025-02-08 at 13:20 +0100, Jean-Marc Lasgouttes wrote:
> Or maybe
> lyx -x "command-sequence branch-activate mybranch ; buffer-save" myfile.lyx
Thank you. :-)
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
https://lists.lyx.org/mailman/listinfo/lyx-devel
12:51:02 GMT+01:00, Jean-Marc Lasgouttes
> a écrit :
>>
>>
>>Le 8 février 2025 12:40:00 GMT+01:00, "José Matos" a
>>écrit :
>>>Hi,
>>> I am interested in being able to select branches from the command line,
>>>turning them on or off
Something like
lyx -x "branch-activate mybranch" myfile.lyx
JMarc
Le 8 février 2025 12:51:02 GMT+01:00, Jean-Marc Lasgouttes
a écrit :
>
>
>Le 8 février 2025 12:40:00 GMT+01:00, "José Matos" a
>écrit :
>>Hi,
>> I am interested in being a
Le 8 février 2025 12:40:00 GMT+01:00, "José Matos" a écrit
:
>Hi,
> I am interested in being able to select branches from the command line,
>turning them on or off.
>
>Is it possible?
Yes ;)
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
https://lists.lyx
Hi,
I am interested in being able to select branches from the command line,
turning them on or off.
Is it possible?
I tried the man page but it does not refer branches at all.
Best regards,
--
José Abílio
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
https://lists.lyx.org/mailman
On Sat, 2024-10-05 at 16:53 +, Richard Kimberly Heck wrote:
> commit 478d59f5ddd1cda62883e4ef7ae06d5ad4ea9f72
> Author: Juergen Spitzmueller
> Date: Sat Oct 5 14:15:19 2024 +0200
>
> Adhere to semantic background color with default branches
>
> This fixes
I have created two new branches: 2.4.x and 2.4.1-devel.
The 2.4.x branch will be the basis for the 2.4.0 release and then become
the stable branch. From this point forward, NOTHING (except translation
updates) should be committed to that branch without a +1 from another
developer on this list
lString is "", not
"UNDEFINED".
The goal is to be able to show in a special way the branches that are
undefined. So this label should stay in some way.
JMarc
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Sorry, should be fixed.
Riki
Thanks for the quick fix!
Seems your original patch also works good if we remove default
labelstring_ value (from_ascii("UNDEFINED")) in InsetLayout.h. And
Customization.lyx also says that default LabelString is "", not "UNDEFINED".
Yuriy
--
lyx-devel mailing
On 11/17/23 13:48, Yuriy Skalko wrote:
I can easily see someone using "_" in a branch name and then
wondering why the InsetLayout doesn't work. Like I did. Pushed. Also
fixed the label string issue.
Riki
Hi Riki,
After this update the insets for normal branches (without cust
I can easily see someone using "_" in a branch name and then wondering why the
InsetLayout doesn't work. Like I did. Pushed. Also fixed the label string issue.
Riki
Hi Riki,
After this update the insets for normal branches (without custom
InsetLayout) are shown with l
t with several different
note-apparatuses for completely different target audiences.
I think that with complex enough commands you could do pretty crazy
stuff with different on-off branch combinations :)
Absolutely. I was thinking about Flex insets that could be on or off,
but it turns out we alrea
On Thu, Nov 16, 2023 at 02:17:57PM -0500, Richard Kimberly Heck wrote:
> Found the problem: The use of right_note, with the underscore, seems not to
> work.
My bad :) I replaced in the email the branch names so they have some meaning in
english and did not know that "_" will break it...
> We se
On 11/16/23 13:43, Richard Kimberly Heck wrote:
On 11/16/23 09:22, Pavel Sanda wrote:
On Thu, Nov 16, 2023 at 02:00:29PM +0100, Jean-Marc Lasgouttes wrote:
I do not have time for a detailed comment, but you should really
take a hard
look at branches. They are an incredibly useful tool.
I
Le 19/11/2022 à 11:38, Jürgen Spitzmüller a écrit :
Am Freitag, dem 18.11.2022 um 17:33 +0100 schrieb Jean-Marc Lasgouttes:
What can you do to help?
* have look at the diff in src to spot what I broke
Looks good from what I can tell.
Thanks for checking.
* and look at KILLQT4 annotations t
Am Freitag, dem 18.11.2022 um 17:33 +0100 schrieb Jean-Marc Lasgouttes:
> What can you do to help?
> * have look at the diff in src to spot what I broke
Looks good from what I can tell.
> * and look at KILLQT4 annotations to see whethe rsome of them are in
> your ballpark
> * look for things to
Le 18/11/2022 à 18:03, Scott Kostyshak a écrit :
What can you do to help?
* have look at the diff in src to spot what I broke
* and look at KILLQT4 annotations to see whethe rsome of them are in your
ballpark
* look for things to do in TODO.killqt4
I think this was meant for Jürgen, but to be c
On Fri, Nov 18, 2022 at 05:33:43PM +0100, Jean-Marc Lasgouttes wrote:
> Le 17/11/2022 à 07:34, Jürgen Spitzmüller a écrit :
> > Am Mittwoch, dem 16.11.2022 um 11:11 -0500 schrieb Scott Kostyshak:
> > > Does anyone object then to supporting only Qt5 for
> > > 2.4.0 (and forward)?
> >
> > No. I thin
Le 17/11/2022 à 07:34, Jürgen Spitzmüller a écrit :
Am Mittwoch, dem 16.11.2022 um 11:11 -0500 schrieb Scott Kostyshak:
Does anyone object then to supporting only Qt5 for
2.4.0 (and forward)?
No. I think now is the time to do it.
I created a new branch killqt4 that removes #ifdefs in src and
Am Mittwoch, dem 16.11.2022 um 11:11 -0500 schrieb Scott Kostyshak:
> Does anyone object then to supporting only Qt5 for
> 2.4.0 (and forward)?
No. I think now is the time to do it.
--
Jürgen
signature.asc
Description: This is a digitally signed message part
--
lyx-devel mailing list
lyx-deve
On Wed, Nov 16, 2022 at 06:03:04PM +0100, Jean-Marc Lasgouttes wrote:
> Le 16/11/2022 à 17:57, Scott Kostyshak a écrit :
> > I don't know. What do others think? Do we go all-in and drop Qt4 and do
> > all the clean up now to simplify the code? That would indeed feel nice.
> >
> > Or do we leave it
Le 16/11/2022 à 17:57, Scott Kostyshak a écrit :
I don't know. What do others think? Do we go all-in and drop Qt4 and do
all the clean up now to simplify the code? That would indeed feel nice.
Or do we leave it as is, and just officially not support Qt4, so that if
some (from what I understand,
On Wed, Nov 16, 2022 at 05:51:30PM +0100, Jean-Marc Lasgouttes wrote:
> Le 16/11/2022 à 17:11, Scott Kostyshak a écrit :
> > On Wed, Nov 16, 2022 at 02:37:18PM +0100, Thibaut Cuvelier wrote:
> >
> > > Well, if barely anyone tests with Qt 4 (I'm only using Qt 5.15), it's
> > > already unsupported i
Le 16/11/2022 à 17:11, Scott Kostyshak a écrit :
On Wed, Nov 16, 2022 at 02:37:18PM +0100, Thibaut Cuvelier wrote:
Well, if barely anyone tests with Qt 4 (I'm only using Qt 5.15), it's
already unsupported in practice and making the necessary changes would be
(1) cumbersome and (2) a waste of re
On Wed, Nov 16, 2022 at 02:37:18PM +0100, Thibaut Cuvelier wrote:
> Well, if barely anyone tests with Qt 4 (I'm only using Qt 5.15), it's
> already unsupported in practice and making the necessary changes would be
> (1) cumbersome and (2) a waste of resources (little gain in supporting
> versions
On Mon, 14 Nov 2022 at 19:38, Scott Kostyshak wrote:
> On Tue, Oct 18, 2022 at 10:51:34AM -0400, Scott Kostyshak wrote:
> > On Tue, Oct 18, 2022 at 03:12:40PM +0200, Pavel Sanda wrote:
> > > On Fri, Oct 07, 2022 at 05:05:43PM +0200, Jean-Marc Lasgouttes wrote:
> > > > Still, I am wondering why we
On Tue, Oct 18, 2022 at 10:51:34AM -0400, Scott Kostyshak wrote:
> On Tue, Oct 18, 2022 at 03:12:40PM +0200, Pavel Sanda wrote:
> > On Fri, Oct 07, 2022 at 05:05:43PM +0200, Jean-Marc Lasgouttes wrote:
> > > Still, I am wondering why we insist on supporting Qt4 for 2.4.0
> > > (especially
> > > co
Le 11/11/2022 à 01:32, Thibaut Cuvelier a écrit :
On Thu, 10 Nov 2022 at 20:38, Scott Kostyshak <mailto:skost...@lyx.org>> wrote:
Should we delete branches from the features repo that have been merged
to master? I don't know our policy on this, but it's hard to f
On Thu, 10 Nov 2022 at 20:38, Scott Kostyshak wrote:
> Should we delete branches from the features repo that have been merged
> to master? I don't know our policy on this, but it's hard to figure out
> which branches on the features repo are still relevant (i.e., not yet
>
Should we delete branches from the features repo that have been merged
to master? I don't know our policy on this, but it's hard to figure out
which branches on the features repo are still relevant (i.e., not yet
merged). In the worst case scenario, e.g., where we need to revert the
mer
On Tue, Oct 18, 2022 at 06:27:00PM +0200, Jean-Marc Lasgouttes wrote:
> >That was decided when we planned to release 2.4 at the end of 2019.
> >It's clear we won't be able to push 2.4 even for next debian stable
> >and I think we can relax Qt4 support and move on.
>
> What do you mean by "relax" ?
Le 18/10/2022 à 15:12, Pavel Sanda a écrit :
On Fri, Oct 07, 2022 at 05:05:43PM +0200, Jean-Marc Lasgouttes wrote:
Still, I am wondering why we insist on supporting Qt4 for 2.4.0 (especially
considering that we will have to continue this game for 2+ years after
that).
That was decided when we
On Tue, Oct 18, 2022 at 03:12:40PM +0200, Pavel Sanda wrote:
> On Fri, Oct 07, 2022 at 05:05:43PM +0200, Jean-Marc Lasgouttes wrote:
> > Still, I am wondering why we insist on supporting Qt4 for 2.4.0 (especially
> > considering that we will have to continue this game for 2+ years after
> > that).
On Fri, Oct 07, 2022 at 05:05:43PM +0200, Jean-Marc Lasgouttes wrote:
> Still, I am wondering why we insist on supporting Qt4 for 2.4.0 (especially
> considering that we will have to continue this game for 2+ years after
> that).
That was decided when we planned to release 2.4 at the end of 2019.
Still, I am wondering why we insist on supporting Qt4 for 2.4.0 (especially considering that we will have to continue this game for 2+ years after that).
I join to your wondering. And here is the patch to at least clean
conditional code portions for Qt < 4.8.
Yuriy
From ba021353090922642e0e2
You can use
branchCO->itemData(branchCO->currentIndex()).toString()
This works in Qt 4 and upwards.
Thanks, Jürgen! This way even dedicated Qt4 users will be able to enjoy
this update :)
Committed.
Yuriy
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listin
Am Freitag, dem 07.10.2022 um 18:02 +0300 schrieb Yuriy Skalko:
> Now with "(master)" suffix in combobox labels we cannot use them
> directly as branch names. Is is OK to disable this for Qt4
> alltogether,
> as README says that LyX is only compilable on Qt4?
You can use
branchCO->itemData(bran
Le 07/10/2022 à 17:02, Yuriy Skalko a écrit :
Now with "(master)" suffix in combobox labels we cannot use them
directly as branch names. Is is OK to disable this for Qt4 alltogether,
as README says that LyX is only compilable on Qt4?
This seems like an acceptable solution, if the code is simpl
ames. Is is OK to disable this for Qt4 alltogether,
as README says that LyX is only compilable on Qt4?
Yuriy
From 716cc9991d1025614424b7ceaa6761ab0f817083 Mon Sep 17 00:00:00 2001
From: Yuriy Skalko
Date: Fri, 7 Oct 2022 17:41:46 +0300
Subject: [PATCH] Show branches from master document in branch inset dialog
---
src/fro
Le 06/10/2022 à 19:39, Yuriy Skalko a écrit :
Hello all,
Currently in LyX you can insert into child documents the insets for
branches defined in master document only. But it is impossible to change
the branch afterwards for such inset because master branches are not
shown in the "B
Am Freitag, dem 07.10.2022 um 09:43 +0200 schrieb Jürgen Spitzmüller:
> branchCO->addItem(
> toqstr(bformat( _("%1$s[[branch]]
> (%2$s)[[master]]"),
> toqstr(branch), qt_("master";
that should be _("master") of course.
--
Jürgen
signature.asc
Description: This is a digit
Am Donnerstag, dem 06.10.2022 um 20:39 +0300 schrieb Yuriy Skalko:
> Hello all,
>
> Currently in LyX you can insert into child documents the insets for
> branches defined in master document only. But it is impossible to
> change
> the branch afterwards for such inset because m
Hello all,
Currently in LyX you can insert into child documents the insets for
branches defined in master document only. But it is impossible to change
the branch afterwards for such inset because master branches are not
shown in the "Branch Settings" dialog.
The attached patch
Am Sat, 30 Apr 2022 14:24:13 +0200
schrieb Jürgen Spitzmüller :
> Am Samstag, dem 30.04.2022 um 11:27 +0200 schrieb Kornel Benko:
> > The naming is not very fortunate yet, so please proceed.
>
> Done. I leave the documentation work to you.
>
Pure try at aec76ace.
Kornel
--
lyx-deve
Am Samstag, dem 30.04.2022 um 11:27 +0200 schrieb Kornel Benko:
> The naming is not very fortunate yet, so please proceed.
Done. I leave the documentation work to you.
--
Jürgen
signature.asc
Description: This is a digitally signed message part
--
lyx-devel mailing list
lyx-devel@lists.lyx.or
Am Sat, 30 Apr 2022 11:07:19 +0200
schrieb Jürgen Spitzmüller :
> Am Samstag, dem 30.04.2022 um 10:42 +0200 schrieb Kornel Benko:
> > Apparently the search needs some more description.
> > Make a testcase:
> > Document lang = German
> > Insert 'a'
> > select some 'a' and change its lang to
Am Samstag, dem 30.04.2022 um 10:42 +0200 schrieb Kornel Benko:
> Apparently the search needs some more description.
> Make a testcase:
> Document lang = German
> Insert 'a'
> select some 'a' and change its lang to English
> Open findadv dialog
> insert 'a'
> find ...
> You will see,
Am Sat, 30 Apr 2022 10:13:09 +0200
schrieb Jürgen Spitzmüller :
> Am Freitag, dem 29.04.2022 um 19:31 +0200 schrieb Kornel Benko:
> > Only a small change seems to to be enough (FindAndReplace.cpp:470)
> >
> > FindAndReplaceOptions opt(find_buf_name, casesensitive,
> > matchword,
> > -
Am Freitag, dem 29.04.2022 um 19:31 +0200 schrieb Kornel Benko:
> Only a small change seems to to be enough (FindAndReplace.cpp:470)
>
> FindAndReplaceOptions opt(find_buf_name, casesensitive,
> matchword,
> - !backwards, expandmacros,
> ignoreformat,
> +
Am Sat, 30 Apr 2022 09:38:03 +0200
schrieb Kornel Benko :
> Am Sat, 30 Apr 2022 09:06:13 +0200
> schrieb Jürgen Spitzmüller :
>
> > Am Freitag, dem 29.04.2022 um 20:06 +0200 schrieb Kornel Benko:
> > > Maybe we should also rename 'Ignore formatting' to 'Handle formatted
> > > search'.
> >
Am Sat, 30 Apr 2022 09:06:13 +0200
schrieb Jürgen Spitzmüller :
> Am Freitag, dem 29.04.2022 um 20:06 +0200 schrieb Kornel Benko:
> > Maybe we should also rename 'Ignore formatting' to 'Handle formatted
> > search'.
>
> Apart from that, does it do what you expect?
>
Yes it does.
Could we add
Am Freitag, dem 29.04.2022 um 20:06 +0200 schrieb Kornel Benko:
> Maybe we should also rename 'Ignore formatting' to 'Handle formatted
> search'.
Apart from that, does it do what you expect?
--
Jürgen
signature.asc
Description: This is a digitally signed message part
--
lyx-devel mailing list
Am Fri, 29 Apr 2022 19:31:23 +0200
schrieb Kornel Benko :
> Am Fri, 29 Apr 2022 17:09:05 +0200
> schrieb Jürgen Spitzmüller :
>
> > Am Freitag, dem 29.04.2022 um 17:02 +0200 schrieb Kornel Benko:
> > > The meaning of 'Ignore formatting' is reversed.
> > >
> > > If 'Ignore formatting' is _not_
Am Fri, 29 Apr 2022 17:09:05 +0200
schrieb Jürgen Spitzmüller :
> Am Freitag, dem 29.04.2022 um 17:02 +0200 schrieb Kornel Benko:
> > The meaning of 'Ignore formatting' is reversed.
> >
> > If 'Ignore formatting' is _not_ checked, then all subsequent
> > selections should be enabled.
> >
> > Tha
Am Freitag, dem 29.04.2022 um 17:02 +0200 schrieb Kornel Benko:
> The meaning of 'Ignore formatting' is reversed.
>
> If 'Ignore formatting' is _not_ checked, then all subsequent
> selections should be enabled.
>
> That is, only in formatted search we can select what is to be ignored
> or not.
S
Am Fri, 29 Apr 2022 16:20:29 +0200
schrieb Jürgen Spitzmüller :
> Am Freitag, dem 01.04.2022 um 09:35 +0200 schrieb Jürgen Spitzmüller:
> > I have a GUI ready, but it doesn't work. I am not sure I understand
> > how
> > this is supposed to be used. If I have a text file with "test
> > \textbf{test
Am Freitag, dem 01.04.2022 um 09:35 +0200 schrieb Jürgen Spitzmüller:
> I have a GUI ready, but it doesn't work. I am not sure I understand
> how
> this is supposed to be used. If I have a text file with "test
> \textbf{test} test" and search for "test", the bold string is found
> no
> matter what
On Sat, Apr 02, 2022 at 05:07:34PM +0200, Kornel Benko wrote:
> Am Sat, 2 Apr 2022 10:49:17 -0400
> schrieb Scott Kostyshak :
> > On current master I get the following:
> >
> > const’: /home/scott/lyxbuilds/master/repo/src/lyxfind.cpp:3868:42: error:
> > comparison of
> > integer expressions of
Am Sat, 2 Apr 2022 10:49:17 -0400
schrieb Scott Kostyshak :
> On Sat, Apr 02, 2022 at 12:22:44PM +0200, Kornel Benko wrote:
> > Am Sat, 02 Apr 2022 12:06:12 +0200
> > schrieb Jürgen Spitzmüller :
> >
> > > Am Samstag, dem 02.04.2022 um 11:57 +0200 schrieb Jürgen Spitzmüller:
> > > > I'll have
On Sat, Apr 02, 2022 at 12:22:44PM +0200, Kornel Benko wrote:
> Am Sat, 02 Apr 2022 12:06:12 +0200
> schrieb Jürgen Spitzmüller :
>
> > Am Samstag, dem 02.04.2022 um 11:57 +0200 schrieb Jürgen Spitzmüller:
> > > I'll have a look.
> >
> > Better?
> >
> > Jürgen
>
> Definitely better. Thanks.
Am Sat, 02 Apr 2022 12:06:12 +0200
schrieb Jürgen Spitzmüller :
> Am Samstag, dem 02.04.2022 um 11:57 +0200 schrieb Jürgen Spitzmüller:
> > I'll have a look.
>
> Better?
>
> Jürgen
Definitely better. Thanks.
Kornel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.
Am Samstag, dem 02.04.2022 um 11:57 +0200 schrieb Jürgen Spitzmüller:
> I'll have a look.
Better?
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
Am Sat, 02 Apr 2022 11:57:55 +0200
schrieb Jürgen Spitzmüller :
> Am Samstag, dem 02.04.2022 um 11:48 +0200 schrieb Kornel Benko:
> > No, normally we get in latex
> >
> > \begin{comment}
> > aexbc
> > \end{comment}
> >
> > now this is only the case if searching in non output (means no output
> >
Am Samstag, dem 02.04.2022 um 11:48 +0200 schrieb Kornel Benko:
> No, normally we get in latex
>
> \begin{comment}
> aexbc
> \end{comment}
>
> now this is only the case if searching in non output (means no output
> in pdf IMO)
So you are talking about InsetNoteParams::Comment, not
InsetNoteParam
Am Sat, 02 Apr 2022 11:44:34 +0200
schrieb Jürgen Spitzmüller :
> Am Samstag, dem 02.04.2022 um 11:24 +0200 schrieb Kornel Benko:
> > InsetNoteParams::Note is now not part of latex output when not
> > searched.
>
> Isn't that how it should be?
>
> Jürgen
>
No, normally we get in latex
\begi
Am Samstag, dem 02.04.2022 um 11:24 +0200 schrieb Kornel Benko:
> InsetNoteParams::Note is now not part of latex output when not
> searched.
Isn't that how it should be?
Jürgen
signature.asc
Description: This is a digitally signed message part
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
Am Sat, 02 Apr 2022 11:21:02 +0200
schrieb Jürgen Spitzmüller :
> Am Samstag, dem 02.04.2022 um 11:15 +0200 schrieb Kornel Benko:
> > Perfect! Please commit.
>
> Done.
>
> Jürgen
I was too fast.
InsetNoteParams::Note is now not part of latex output when not searched.
Needs an amend.
Am Samstag, dem 02.04.2022 um 11:15 +0200 schrieb Kornel Benko:
> Perfect! Please commit.
Done.
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
Am Sat, 02 Apr 2022 10:52:20 +0200
schrieb Jürgen Spitzmüller :
> Am Samstag, dem 02.04.2022 um 09:38 +0200 schrieb Kornel Benko:
> > But they do not appear in latex output, thus are never accessible by
> > searchadv.
>
> Like so (untested)?
>
> In any case, I think the testing should be done
Am Samstag, dem 02.04.2022 um 09:38 +0200 schrieb Kornel Benko:
> But they do not appear in latex output, thus are never accessible by
> searchadv.
Like so (untested)?
In any case, I think the testing should be done in InsetNote::latex(),
not InsetText::latex().
Jürgen
diff --git a/src/insets/In
Am Sat, 02 Apr 2022 07:46:23 +0200
schrieb Jürgen Spitzmüller :
> Am Freitag, dem 01.04.2022 um 20:17 +0200 schrieb Kornel Benko:
> > > I think there is no need to restrict it to comment. Otherwise no
> > > objection.
> >
> > Do you have some ideas what else could be included?
>
> LyX Notes.
Am Freitag, dem 01.04.2022 um 20:17 +0200 schrieb Kornel Benko:
> > I think there is no need to restrict it to comment. Otherwise no
> > objection.
>
> Do you have some ideas what else could be included?
LyX Notes.
Jürgen
signature.asc
Description: This is a digitally signed message part
--
Am Fri, 01 Apr 2022 19:21:47 +0200
schrieb Jürgen Spitzmüller :
> Am Freitag, dem 01.04.2022 um 18:08 +0200 schrieb Kornel Benko:
> > Apropos, do you have objections in regard of the patch in
> > InsetText.cpp?
>
> I think there is no need to restrict it to comment. Otherwise no
> objection.
D
Am Freitag, dem 01.04.2022 um 18:08 +0200 schrieb Kornel Benko:
> Apropos, do you have objections in regard of the patch in
> InsetText.cpp?
I think there is no need to restrict it to comment. Otherwise no
objection.
Jürgen
signature.asc
Description: This is a digitally signed message part
--
Am Fri, 1 Apr 2022 16:08:53 +0200
schrieb Kornel Benko :
> Am Fri, 01 Apr 2022 16:02:05 +0200
> schrieb Jürgen Spitzmüller :
>
> > Am Freitag, dem 01.04.2022 um 15:59 +0200 schrieb Kornel Benko:
> > > What is missing is the search in comments only.
> >
> > Do we really need this?
> >
> >
Am Fri, 01 Apr 2022 16:02:05 +0200
schrieb Jürgen Spitzmüller :
> Am Freitag, dem 01.04.2022 um 15:59 +0200 schrieb Kornel Benko:
> > What is missing is the search in comments only.
>
> Do we really need this?
>
> Jürgen
>
It would be consistent with other features, like searching for red te
Am Freitag, dem 01.04.2022 um 15:59 +0200 schrieb Kornel Benko:
> What is missing is the search in comments only.
Do we really need this?
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/li
Am Fri, 1 Apr 2022 13:52:15 +0200
schrieb Kornel Benko :
> Am Fri, 01 Apr 2022 11:35:58 +0200
> schrieb Jürgen Spitzmüller :
>
> > Am Freitag, dem 01.04.2022 um 11:33 +0200 schrieb Kornel Benko:
> > > This will take a while :(
> >
> > No problem.
> >
> > Jürgen
>
> Now at least one can
Am Fri, 01 Apr 2022 11:35:58 +0200
schrieb Jürgen Spitzmüller :
> Am Freitag, dem 01.04.2022 um 11:33 +0200 schrieb Kornel Benko:
> > This will take a while :(
>
> No problem.
>
> Jürgen
Now at least one can search the string inside a comment, but
the feature is ignored.
This will need more w
Am Freitag, dem 01.04.2022 um 11:33 +0200 schrieb Kornel Benko:
> This will take a while :(
No problem.
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
result if "search-ignore non-output-content"
> > is set to false or true. In both cases, the inset is found.
>
> Ah, yes. So far 'search-ignore non-output-content' only applies to branches.
>
> > But anyway, my concern would rather be: how do I find a str
ses, the inset is found.
Ah, yes. So far 'search-ignore non-output-content' only applies to branches.
> But anyway, my concern would rather be: how do I find a string _inside_
> this inset?
ERROR found. Have to check.
> Jürgen
Kornel
--
lyx-devel mailing list
lyx-d
Am Freitag, dem 01.04.2022 um 11:07 +0200 schrieb Kornel Benko:
> Attached example.
But this gives the same result if "search-ignore non-output-content"
is set to false or true. In both cases, the inset is found.
But anyway, my concern would rather be: how do I find a string _inside_
this inset?
non-output-content false". I thought it would enable searching
in things such as notes, comments, inactive branches. If it enables
_typing_ search strings in such insets, I fail to see why that should
be useful.
Jürgen
signature.asc
Description: This is a digitally signed message part
--
l
Am Fri, 1 Apr 2022 11:03:31 +0200
schrieb Kornel Benko :
> Am Fri, 01 Apr 2022 10:48:45 +0200
> schrieb Jürgen Spitzmüller :
>
> > Am Freitag, dem 01.04.2022 um 10:10 +0200 schrieb Kornel Benko:
> > > ATM, it works like this:
> > > Any feature deselected with the lfun is ignored no matter what
Am Fri, 01 Apr 2022 10:48:45 +0200
schrieb Jürgen Spitzmüller :
> Am Freitag, dem 01.04.2022 um 10:10 +0200 schrieb Kornel Benko:
> > ATM, it works like this:
> > Any feature deselected with the lfun is ignored no matter what is in
> > the search window.
>
> I still do not understand. How can I
Am Freitag, dem 01.04.2022 um 10:10 +0200 schrieb Kornel Benko:
> ATM, it works like this:
> Any feature deselected with the lfun is ignored no matter what is in
> the search window.
I still do not understand. How can I make AdvSearch search in a note?
"search-ignore non-output-content false" does
1 - 100 of 1020 matches
Mail list logo
