Re: Merge

, and I've spot-checked several commits. But you might want to have a look and make sure I didn't mess anything up. Going forward, this should not be as much of an issue, since commits to 2.4.x will be few. And hopefully, we won't need an emergency release, and I can merge 2.4.1-dev

Re: Merge

pot-checked several commits. But you might want to have a look and > make sure I didn't mess anything up. > > Going forward, this should not be as much of an issue, since commits > to 2.4.x will be few. And hopefully, we won't need an emergency > release, and I can mer

Merge

e I didn't mess anything up. Going forward, this should not be as much of an issue, since commits to 2.4.x will be few. And hopefully, we won't need an emergency release, and I can merge 2.4.1-devel into 2.4.x before long. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org htt

Re: [LyX/master] Merge branch 'features/indexmacros'

On Sat, 24 Dec 2022 at 03:49, Scott Kostyshak wrote: > On Fri, Dec 23, 2022 at 01:00:59AM +0100, Thibaut Cuvelier wrote: > > On Mon, 21 Nov 2022 at 08:56, Kornel Benko wrote: > > > > > Am Sun, 20 Nov 2022 15:23:58 -0500 > > > schrieb Scott Kostyshak : > > > > > > > On Sun, Nov 20, 2022 at 08:24:

Re: [LyX/master] Merge branch 'features/indexmacros'

On Fri, Dec 23, 2022 at 01:00:59AM +0100, Thibaut Cuvelier wrote: > On Mon, 21 Nov 2022 at 08:56, Kornel Benko wrote: > > > Am Sun, 20 Nov 2022 15:23:58 -0500 > > schrieb Scott Kostyshak : > > > > > On Sun, Nov 20, 2022 at 08:24:41PM +0100, Thibaut Cuvelier wrote: > > > > On Sun, 20 Nov 2022 at 1

Re: [LyX/master] Merge branch 'features/indexmacros'

On Mon, 21 Nov 2022 at 08:56, Kornel Benko wrote: > Am Sun, 20 Nov 2022 15:23:58 -0500 > schrieb Scott Kostyshak : > > > On Sun, Nov 20, 2022 at 08:24:41PM +0100, Thibaut Cuvelier wrote: > > > On Sun, 20 Nov 2022 at 16:47, Scott Kostyshak > wrote: > > > > > > > On Sun, Nov 20, 2022 at 04:33:36PM

Re: [LyX/master] Merge branch 'features/indexmacros'

Am Sun, 20 Nov 2022 15:23:58 -0500 schrieb Scott Kostyshak : > On Sun, Nov 20, 2022 at 08:24:41PM +0100, Thibaut Cuvelier wrote: > > On Sun, 20 Nov 2022 at 16:47, Scott Kostyshak wrote: > > > > > On Sun, Nov 20, 2022 at 04:33:36PM +0100, Thibaut Cuvelier wrote: > > > > > When I open the expo

Re: [LyX/master] Merge branch 'features/indexmacros'

On Sun, Nov 20, 2022 at 08:24:41PM +0100, Thibaut Cuvelier wrote: > On Sun, 20 Nov 2022 at 16:47, Scott Kostyshak wrote: > > > On Sun, Nov 20, 2022 at 04:33:36PM +0100, Thibaut Cuvelier wrote: > > > > When I open the exported de Math.xhtml in Chromium, I get: > > > > > > > > "error on line 7159

Re: [LyX/master] Merge branch 'features/indexmacros'

On Sun, 20 Nov 2022 at 16:47, Scott Kostyshak wrote: > On Sun, Nov 20, 2022 at 04:33:36PM +0100, Thibaut Cuvelier wrote: > > > When I open the exported de Math.xhtml in Chromium, I get: > > > > > > "error on line 7159 at column 22: Entity 'imaginary' not defined" > > > > > > > That's unrelated

Re: [LyX/master] Merge branch 'features/indexmacros'

On Sun, Nov 20, 2022 at 04:33:36PM +0100, Thibaut Cuvelier wrote: > > > (I don't get how to configure CTest to use my version of > > > Python, hence it fails in strange ways). > > > > Let's try to figure out how to fix this. > > > > Is it only a problem with the ctests? Meaning, LyX uses your versi

Re: [LyX/master] Merge branch 'features/indexmacros'

; > > > > Thanks! I see the following failures: > > > > > > > > > > > > export/doc/Math_xhtml (Failed) > > > > > > export/doc/de/Additional_xhtml (Failed) > > > > > > export/doc/de/Math_xhtml (Failed) > >

Re: [LyX/master] Merge branch 'features/indexmacros'

e the issue. Scott, let me know if it works for you. > > > > > > > > > > Thanks! I see the following failures: > > > > > > > > > > export/doc/Math_xhtml (Failed) > > > > > export/doc/de/Additional_xhtml (Failed) > > > > > export/d

Re: [LyX/master] Merge branch 'features/indexmacros'

40c5 to master; it > > > should > > > > > solve the issue. Scott, let me know if it works for you. > > > > > > > > Thanks! I see the following failures: > > > > > > > > export/doc/Math_xhtml (Failed) > > > > expo

Re: [LyX/master] Merge branch 'features/indexmacros'

aster; it > > > should > > > > > solve the issue. Scott, let me know if it works for you. > > > > > > > > Thanks! I see the following failures: > > > > > > > > export/doc/Math_xhtml (Failed) > > > > export/doc/de/Additional_x

Re: [LyX/master] Merge branch 'features/indexmacros'

; > > > > > export/doc/Math_xhtml (Failed) > > > export/doc/de/Additional_xhtml (Failed) > > > export/doc/de/Math_xhtml (Failed) > > > export/doc/de/UserGuide_xhtml (Failed) > > > export/doc/es/Math_xhtml (Failed) > > > export/doc/fr/Math_xhtml

Re: [LyX/master] Merge branch 'features/indexmacros'

now if it works for you. > > > > Thanks! I see the following failures: > > > > export/doc/Math_xhtml (Failed) > > export/doc/de/Additional_xhtml (Failed) > > export/doc/de/Math_xhtml (Failed) > > export/doc/de/UserGuide_xhtml (Failed) > &g

Re: [LyX/master] Merge branch 'features/indexmacros'

l (Failed) > export/doc/de/Math_xhtml (Failed) > export/doc/de/UserGuide_xhtml (Failed) > export/doc/es/Math_xhtml (Failed) > export/doc/fr/Math_xhtml (Failed) > export/doc/ja/Math_xhtml (Failed) > export/doc/ru/Math_xhtml (Failed) > > Thibaut, can you look at those? T

Re: [LyX/master] Merge branch 'features/indexmacros'

On Tue, Nov 01, 2022 at 09:12:41AM +0100, Jürgen Spitzmüller wrote: > Am Montag, dem 31.10.2022 um 16:07 -0400 schrieb Scott Kostyshak: > > I get the following: > > > > The following tests FAILED: > > Also after 3c488c22e1d86? The tex2lyx tests all pass now. I sent my message accidentally from m

Re: [LyX/master] Merge branch 'features/indexmacros'

Am Montag, dem 31.10.2022 um 16:07 -0400 schrieb Scott Kostyshak: > I get the following: > > The following tests FAILED: Also after 3c488c22e1d86? -- Jürgen -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel

Re: [LyX/master] Merge branch 'features/indexmacros'

On Tue, Nov 01, 2022 at 12:01:47AM +0100, Thibaut Cuvelier wrote: > On Mon, 31 Oct 2022 at 21:12, Jürgen Spitzmüller wrote: > > > Am Montag, dem 31.10.2022 um 14:58 -0400 schrieb Scott Kostyshak: > > > I get the following warning: > > > > > > /home/scott/lyxbuilds/master- > > > master/repo/src/in

Re: [LyX/master] Merge branch 'features/indexmacros'

On Mon, 31 Oct 2022 at 21:12, Jürgen Spitzmüller wrote: > Am Montag, dem 31.10.2022 um 14:58 -0400 schrieb Scott Kostyshak: > > I get the following warning: > > > > /home/scott/lyxbuilds/master- > > master/repo/src/insets/InsetIndex.cpp:1691:6: error: function > > 'printTree' is not needed and wi

Re: [LyX/master] Merge branch 'features/indexmacros'

On Mon, Oct 31, 2022 at 06:40:15PM +0100, Juergen Spitzmueller wrote: > commit 4e50da3e655b9f8d26f7d5e439d72b219d32279d > Merge: 0df63e3 f4d588c > Author: Juergen Spitzmueller > Date: Mon Oct 31 19:32:52 2022 +0100 > > Merge branch 'features/indexmacros' &

Re: [LyX/master] Merge branch 'features/indexmacros'

Am Montag, dem 31.10.2022 um 14:58 -0400 schrieb Scott Kostyshak: > I get the following warning: > > /home/scott/lyxbuilds/master- > master/repo/src/insets/InsetIndex.cpp:1691:6: error: function > 'printTree' is not needed and will not be emitted [-Werror,- > Wunneeded-internal-declaration] > void

Re: [LyX/master] Merge branch 'features/indexmacros'

On Mon, 31 Oct 2022 at 19:58, Scott Kostyshak wrote: > On Mon, Oct 31, 2022 at 06:40:15PM +0100, Juergen Spitzmueller wrote: > > commit 4e50da3e655b9f8d26f7d5e439d72b219d32279d > > Merge: 0df63e3 f4d588c > > Author: Juergen Spitzmueller > > Date: Mon

Re: [LyX/master] Merge branch 'features/indexmacros'

On Mon, Oct 31, 2022 at 06:40:15PM +0100, Juergen Spitzmueller wrote: > commit 4e50da3e655b9f8d26f7d5e439d72b219d32279d > Merge: 0df63e3 f4d588c > Author: Juergen Spitzmueller > Date: Mon Oct 31 19:32:52 2022 +0100 > > Merge branch 'features/indexmacros' >

Re: Merge files build

There was no big advantage (in speed) anymore. Anyway, if you take care of it, I don't object. Kornel Yes, the only advantage should be speed of build, but it is now similar to normal build even on my 4-core laptop. Perhaps on modern 8-16-32-core machines it can be even slower. Sure

Re: Merge files build

Le 23/11/2020 à 21:10, Yuriy Skalko a écrit : After some changes to sources I've successfully used merged files build of LyX with CMake on MinGW64 (LYX_MERGE_FILES=ON). It is somewhat faster than normal build and resulting LyX executable is 2MB smaller. But in INSTALL.cmake this type of build

Re: Merge files build

Am Mon, 23 Nov 2020 22:10:56 +0200 schrieb Yuriy Skalko : > After some changes to sources I've successfully used merged files build > of LyX with CMake on MinGW64 (LYX_MERGE_FILES=ON). It is somewhat faster > than normal build and resulting LyX executable is 2MB smaller. > > But in INSTALL.cmak

Merge files build

After some changes to sources I've successfully used merged files build of LyX with CMake on MinGW64 (LYX_MERGE_FILES=ON). It is somewhat faster than normal build and resulting LyX executable is 2MB smaller. But in INSTALL.cmake this type of build is marked as deprecated. Why? Are there any pr

Re: Merge CodingRulesAndAdvice into Development.lyx

On Wed, Nov 11, 2020 at 08:38:01PM +0200, Yuriy Skalko wrote: > > I did not look at the patch, but I think you should go ahead and commit. > > What do you think about adding "OUTDATED" to section titles that seem > > like the information could be old and not relevant? > > > > Scott > > I've commi

Re: Merge CodingRulesAndAdvice into Development.lyx

I did not look at the patch, but I think you should go ahead and commit. What do you think about adding "OUTDATED" to section titles that seem like the information could be old and not relevant? Scott I've committed it. I cannot say that full sections are outdated. There are places throughou

Re: Merge CodingRulesAndAdvice into Development.lyx

On Wed, Nov 11, 2020 at 01:50:45PM +0200, Yuriy Skalko wrote: > > > P.S. I've tried to search for some docs on Changers in LyX repository and > > > found this useful document: development/coding/CodingRulesAndAdvice.lyx. > > > Maybe it will be reasonable to merge it

Merge CodingRulesAndAdvice into Development.lyx

P.S. I've tried to search for some docs on Changers in LyX repository and found this useful document: development/coding/CodingRulesAndAdvice.lyx. Maybe it will be reasonable to merge it into lib/doc/Development.lyx so that developer documentation will be in one place? +1 probably would

Re: Merge paragraphs of different non-Default/Plain Layouts

On 2020-07-21 21:13, Daniel wrote: I am always a little stumped that it is not allowed to merge two paragraphs by pressing backspace (delete) at the first (last) position of a paragraph where there is another layout in the previous (next) paragraph. I think I found the passage in the source

Re: Merge paragraphs of different non-Default/Plain Layouts

On Thursday, 23 July 2020 15.40.29 WEST Jean-Marc Lasgouttes wrote: > It seems that LibeOffice keeps the layout of the first paragraph. We > might want to check what office or the apple things do. > > JMarc This seems to be the reasonable way to it, after all we still have undo. Another option w

Re: Merge paragraphs of different non-Default/Plain Layouts

Am 23.07.2020 um 16:40 schrieb Jean-Marc Lasgouttes : > > Le 23/07/2020 à 15:53, Richard Kimberly Heck a écrit : >> On 7/23/20 5:15 AM, Jean-Marc Lasgouttes wrote: >>> Le 23/07/2020 à 06:51, Richard Kimberly Heck a écrit : I agree, though we'll have to see what other people think. Possibly a

Re: Merge paragraphs of different non-Default/Plain Layouts

Le 23/07/2020 à 15:53, Richard Kimberly Heck a écrit : On 7/23/20 5:15 AM, Jean-Marc Lasgouttes wrote: Le 23/07/2020 à 06:51, Richard Kimberly Heck a écrit : I agree, though we'll have to see what other people think. Possibly a preference? Please, no preference. I think it is a LyX idiosyncra

Re: Merge paragraphs of different non-Default/Plain Layouts

On 7/23/20 5:15 AM, Jean-Marc Lasgouttes wrote: > Le 23/07/2020 à 06:51, Richard Kimberly Heck a écrit : >> I agree, though we'll have to see what other people think. Possibly a >> preference? > > Please, no preference. I think it is a LyX idiosyncrasy from day 1. > Feel free to change it. We'll se

Re: Merge paragraphs of different non-Default/Plain Layouts

Le 23/07/2020 à 06:51, Richard Kimberly Heck a écrit : I agree, though we'll have to see what other people think. Possibly a preference? Please, no preference. I think it is a LyX idiosyncrasy from day 1. Feel free to change it. We'll see whether people complain :) JMarc -- lyx-devel mailing

Re: Merge paragraphs of different non-Default/Plain Layouts

paragraph via >>>>>> LFUN_CHAR_BACKWARD_SELECT? Anyway, for me it is hard to say whether >>>>>> this is a reasonable compromise since I still don't know what was >>>>>> the >>>>>> reason for the current behavior one. Can

Re: Merge paragraphs of different non-Default/Plain Layouts

n you see from git who added the comment? Is that person still around to ask? I guess the reason is : assume you have a section and a subsection; you merge using backspace. What is the layout of the only paragraph remaining? Whatever the first one is: section, I'm assuming. I tend to see

Re: Merge paragraphs of different non-Default/Plain Layouts

now what was the >>>> reason for the current behavior one. Can you see from git who added >>>> the comment? Is that person still around to ask? >>> >>> I guess the reason is : assume you have a section and a subsection; >>> you merge using backspac

Re: Merge paragraphs of different non-Default/Plain Layouts

s the reason is : assume you have a section and a subsection; you merge using backspace. What is the layout of the only paragraph remaining? Whatever the first one is: section, I'm assuming. I tend to see this when, e.g., I'm in the first entry of a list, and I decide I don't w

Re: Merge paragraphs of different non-Default/Plain Layouts

ask? > > I guess the reason is : assume you have a section and a subsection; > you merge using backspace. What is the layout of the only paragraph > remaining? Whatever the first one is: section, I'm assuming. I tend to see this when, e.g., I'm in the first entry of a list, a

Re: Merge paragraphs of different non-Default/Plain Layouts

this is a reasonable compromise since I still don't know what was the reason for the current behavior one. Can you see from git who added the comment? Is that person still around to ask? I guess the reason is : assume you have a section and a subsection; you merge using backspace. What i

Re: Merge paragraphs of different non-Default/Plain Layouts

On 2020-07-21 21:43, Richard Kimberly Heck wrote: On 7/21/20 3:13 PM, Daniel wrote: I am always a little stumped that it is not allowed to merge two paragraphs by pressing backspace (delete) at the first (last) position of a paragraph where there is another layout in the previous (next

Re: Merge paragraphs of different non-Default/Plain Layouts

On 7/21/20 3:13 PM, Daniel wrote: > I am always a little stumped that it is not allowed to merge two > paragraphs by pressing backspace (delete) at the first (last) position > of a paragraph where there is another layout in the previous (next) > paragraph. > > I think I found

Merge paragraphs of different non-Default/Plain Layouts

I am always a little stumped that it is not allowed to merge two paragraphs by pressing backspace (delete) at the first (last) position of a paragraph where there is another layout in the previous (next) paragraph. I think I found the passage in the source which sound as if this is an

Merge 2.2.2-staging?

If anyone would like to go ahead and merge 2.2.2-staging into 2.2.x, feel free to do so. I'd do it myself but am about to be away for a week for a conference and may not have the time. Richard

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

Guillaume Munch wrote: > That would be a nice enhancement and would be a proper way to solve the > problem of missing \author lines. Independently from this, the latest > version of my patch solves every critical aspect of the problem (that > can be blamed on LyX rather than version control), and

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

Le 13/11/2015 10:56, Vincent van Ravesteijn a écrit : I believe that 'git' can have custom merge filter/script for certain file types. Maybe the community would like a special LyX-merger script that can be used by the vcs to reduce merge errors as much as possible. That would

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

Le 13/11/2015 03:18, Pavel Sanda a écrit : Georg Baum wrote: Unfortunately there is a good reason for this behaviour: If LyX would not do that, then unused \author lines could easily accumulate: If I accept all changes of my co-author, and he never edits the file again, then his \author line wil

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

be strict, then the current behaviour of throwing away the changes is as bad as the proposed patch, and we should refuse to load the file and force the user to fix the broken merge. Yes. Completely true. Why do we store the author list in the list ? Apparently, the author list is composed of all au

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

you point out. Please find my new patch attached. and we should refuse to load the file and force the user to fix the broken merge. Now my patch is making the issue self-repairing, so maybe what we need is to have a very clear error message so that authors can take their responsibilities.

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

Le 12/11/2015 18:29, Georg Baum a écrit : Guillaume Munch wrote: * Georg, you told us an old story of "FIXME: UNICODE"s being placed in the source when the developers decided that docstring would be the only place where we see Unicode. I am happy to fix these as I go through the code, but I am

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

od thing: It replaces one way of dealing with a corrupt > document with a better one. If we wanted to be strict, then the current > behaviour of throwing away the changes is as bad as the proposed patch, and > we should refuse to load the file and force the user to fix the broken > merg

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

Georg Baum wrote: > Unfortunately there is a good > reason for this behaviour: If LyX would not do that, then unused \author > lines could easily accumulate: If I accept all changes of my co-author, and > he never edits the file again, then his \author line will remain in the file > forever. Th

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

On 11/12/2015 03:15 PM, Georg Baum wrote: > Richard Heck wrote: > >> Like this? > > Basically yes, but I guess including > strfwd.h shoud be enough, and the FIXME shoud of course be removed;-) Yes, indeed. I'll commit it after alpha. Richard

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

Richard Heck wrote: > Like this? Basically yes, but I guess including strfwd.h shoud be enough, and the FIXME shoud of course be removed;-) Georg

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

On 11/12/2015 01:29 PM, Georg Baum wrote: > Guillaume Munch wrote: > >> * Georg, you told us an old story of "FIXME: UNICODE"s being placed in >> the source when the developers decided that docstring would be the only >> place where we see Unicode. I am happy to fix these as I go through the >> cod

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

d patch, and we should refuse to load the file and force the user to fix the broken merge. Unfortunately there is another cause of corrupt merges: LyX files can have many copies of a few identical lines, e.g. (taken from the user guide) \end_layout \end_inset \end_layout \end_inset \en

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

Guillaume Munch wrote: > * Georg, you told us an old story of "FIXME: UNICODE"s being placed in > the source when the developers decided that docstring would be the only > place where we see Unicode. I am happy to fix these as I go through the > code, but I am not sure that I understood what's the

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

Le 12/11/2015 16:07, Vincent van Ravesteijn a écrit : On Thu, Nov 12, 2015 at 4:41 PM, Jean-Marc Lasgouttes wrote: Le 11/11/2015 23:12, Guillaume Munch a écrit : Dear list, The patch below fixes bug #9854. () Find more details in the commit log. I have

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

On Thu, Nov 12, 2015 at 4:41 PM, Jean-Marc Lasgouttes wrote: > Le 11/11/2015 23:12, Guillaume Munch a écrit : >> >> Dear list, >> >> >> The patch below fixes bug #9854. () >> Find more details in the commit log. >> >> I have two questions: >> >> * I had to remo

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

Le 11/11/2015 23:12, Guillaume Munch a écrit : Dear list, The patch below fixes bug #9854. () Find more details in the commit log. I have two questions: * I had to remove a const qualifier in Text::readParToken (see patch below). Do I need to put it back?

Re: [PATCH] Bug #9854 "Dataloss after git merge with change tracking"

On Wed, Nov 11, 2015 at 10:12:42PM +, Guillaume Munch wrote: > Scott, this can wait until after alpha, as you want. Yes, I would prefer that. Thanks for your patience. Scott

[PATCH] Bug #9854 "Dataloss after git merge with change tracking"

From: Guillaume Munch Date: Wed, 11 Nov 2015 21:31:05 + Subject: [PATCH] Fix bug #9854 "Dataloss after git merge with change tracking" A plausible scenario is that change tracking is used together with a versioning system. In this case, parallel modifications might remove an \autho

Re: tabular cell merge bug

On 03/24/2015 06:08 AM, Edwin Leuven wrote: On Mar 24, 2015, at 10:58 , Jean-Marc Lasgouttes wrote: OK, I committed your patch, and as soon as you feel like it, please ask for commit rights. Then you will get to write your commit messages :) thanks, i will The only thing you need to do is s

Re: tabular cell merge bug

On 03/24/2015 05:58 AM, Jean-Marc Lasgouttes wrote: Le 24/03/2015 10:26, Edwin Leuven a écrit : That could be fixed ;-) but i am such a happy lurker ;-) now that i have lyx compiling again i may scratch the occasional itch, or squash a rare bug but i suspect that my contributions will be inc

Re: tabular cell merge bug

On Mar 24, 2015, at 10:58 , Jean-Marc Lasgouttes wrote: > OK, I committed your patch, and as soon as you feel like it, please ask for > commit rights. Then you will get to write your commit messages :) thanks, i will regards, ed.

Re: tabular cell merge bug

Le 24/03/2015 10:26, Edwin Leuven a écrit : That could be fixed ;-) but i am such a happy lurker ;-) now that i have lyx compiling again i may scratch the occasional itch, or squash a rare bug but i suspect that my contributions will be incidental at best… OK, I committed your patch, and as

Re: tabular cell merge bug

On Mar 24, 2015, at 09:54 , Jürgen Spitzmüller wrote: > 2015-03-24 9:31 GMT+01:00 Edwin Leuven > can someone commit? > > Did you lose your commit rights? yes, with the move to git > That could be fixed ;-) but i am such a happy lurker ;-) now that i have lyx compiling again i may scratch the

Re: tabular cell merge bug

2015-03-24 9:31 GMT+01:00 Edwin Leuven > can someone commit? > Did you lose your commit rights? That could be fixed ;-) Jürgen

Re: tabular cell merge bug

On Mar 23, 2015, at 15:40 , Richard Heck wrote: > On 03/23/2015 06:15 AM, Edwin Leuven wrote: >> >> the attached patch fixes it for me… > > Makes sense. can someone commit? i suspect it can also go into branch... regards, ed.

Re: tabular cell merge bug

On 03/23/2015 06:15 AM, Edwin Leuven wrote: Le 17/03/2015 21:26, Edwin Leuven a écrit : first i merge the top-left two cells in a small, say 3x3, table if i then merge this multicolumn cell with the remaining cell in the first row, my table ends up all bonkers the attached patch fixes it for

Re: tabular cell merge bug

Le 17/03/2015 21:26, Edwin Leuven a écrit : > first i merge the top-left two cells in a small, say 3x3, table > > if i then merge this multicolumn cell with the remaining cell in the > first row, my table ends up all bonkers the attached patch fixes it for me… tabularbug.diff

Re: tabular cell merge bug

Le 17/03/2015 21:26, Edwin Leuven a écrit : hi guys, merging cells is buggy here (2.1.3 on a mac) first i merge the top-left two cells in a small, say 3x3, table if i then merge this multicolumn cell with the remaining cell in the first row my table ends up all bonkers see the attached

Re: tabular cell merge bug

Am 19.03.2015 um 14:35 schrieb Edwin Leuven : > hi guys, > > merging cells is buggy here (2.1.3 on a mac) > > first i merge the top-left two cells in a small, say 3x3, table > > if i then merge this multicolumn cell with the remaining cell in the first row > my t

Re: 2 dataloss warnings after merge of remote-tracking branch

Le 13/01/2015 22:49, Georg Baum a écrit : Jean-Marc Lasgouttes wrote: Le 11/01/2015 11:53, Georg Baum a écrit : Because they are on by default in MSVC and off by default in gcc. You can get similar ones with gcc by calling it with -Wconversion (but that outputs many more). gcc 4.9 has -Wfloa

Re: 2 dataloss warnings after merge of remote-tracking branch

Jean-Marc Lasgouttes wrote: > Le 11/01/2015 11:53, Georg Baum a écrit : >> Because they are on by default in MSVC and off by default in gcc. You can >> get similar ones with gcc by calling it with -Wconversion (but that >> outputs many more). > > gcc 4.9 has -Wfloat-conversion. I tried it, but it

Re: 2 dataloss warnings after merge of remote-tracking branch

Le 13/01/2015 13:52, Vincent van Ravesteijn a écrit : I googled it for you: ;) "Note: This class template is deprecated as of C++11. unique_ptr is a new facility with a similar functionality, but with improved security (no fake copy assignments), added features (deleters) and support for arrays.

Re: 2 dataloss warnings after merge of remote-tracking branch

> > Another thing if we use C++11 mode is that auto_ptr is deprecated. Who knows > what to do about that? > I googled it for you: ;) "Note: This class template is deprecated as of C++11. unique_ptr is a new facility with a similar functionality, but with improved security (no fake copy assignment

Re: 2 dataloss warnings after merge of remote-tracking branch

Le 13/01/2015 11:41, Vincent van Ravesteijn a écrit : gcc 4.9 has -Wfloat-conversion. I tried it, but it really gives many warnings (see below) and I am uncomfortable with using it. I wonder though why MSVC only gives a few of them. Did you only attached a part of the output ? There are not so

Re: 2 dataloss warnings after merge of remote-tracking branch

On Tue, Jan 13, 2015 at 11:27 AM, Jean-Marc Lasgouttes wrote: > Le 11/01/2015 11:53, Georg Baum a écrit : >> >> Because they are on by default in MSVC and off by default in gcc. You can >> get similar ones with gcc by calling it with -Wconversion (but that >> outputs >> many more). > > > gcc 4.9 h

Re: 2 dataloss warnings after merge of remote-tracking branch

Le 11/01/2015 11:53, Georg Baum a écrit : Because they are on by default in MSVC and off by default in gcc. You can get similar ones with gcc by calling it with -Wconversion (but that outputs many more). gcc 4.9 has -Wfloat-conversion. I tried it, but it really gives many warnings (see below)

Re: 2 dataloss warnings after merge of remote-tracking branch

Le 13/01/2015 10:31, Vincent van Ravesteijn a écrit : I guess that when you use AntiAliasing, you would be able to actually draw non-integer widths. Don't know how Qt handles it though. The documentation does not mention it. JMarc

Re: 2 dataloss warnings after merge of remote-tracking branch

On Tue, Jan 13, 2015 at 10:14 AM, Jean-Marc Lasgouttes wrote: > Le 13/01/2015 01:22, Uwe Stöhr a écrit : >> >> My change allowed to set the line width to any value you like. As i had >> to set a default width I chose 0.5 because this is already a LaTeX >> default width (if I remember correctly). >

Re: 2 dataloss warnings after merge of remote-tracking branch

Le 13/01/2015 01:22, Uwe Stöhr a écrit : My change allowed to set the line width to any value you like. As i had to set a default width I chose 0.5 because this is already a LaTeX default width (if I remember correctly). Anyway, the thickness must be a float to allow full control of the line widt

Re: 2 dataloss warnings after merge of remote-tracking branch

Am 11.01.2015 um 20:03 schrieb Jean-Marc Lasgouttes: OK, this boils down to the change introduced by Uwe at f01e36b6. Uwe, can you tell us why non integer values are needed? In particular, I do not know where the 0.5 for line_thin comes from. My change allowed to set the line width to any valu

Re: 2 dataloss warnings after merge of remote-tracking branch

Le 11/01/2015 19:56, Jean-Marc Lasgouttes a écrit : Le 11/01/2015 03:14, Richard Heck a écrit : JMarc, does dotted_line_thickness_ need to be a float? Actually, it is a float because we use QPen::setWidthF to set the width as a real. Stephan, do you know whether we really that? We do not do tr

Re: 2 dataloss warnings after merge of remote-tracking branch

Le 11/01/2015 03:14, Richard Heck a écrit : JMarc, does dotted_line_thickness_ need to be a float? Actually, it is a float because we use QPen::setWidthF to set the width as a real. Stephan, do you know whether we really that? We do not do transforms on painters, do we? JMarc

Re: 2 dataloss warnings after merge of remote-tracking branch

Le 11/01/2015 02:20, Uwe Stöhr a écrit : Hello JMarc, after your merge I get these 2 compilation warnings: ..\..\src\RowPainter.cpp(448): warning C4244: 'Argument': conversion of 'float' to 'int', possible dataloss ..\..\src\RowPainter.cpp(450):

Re: 2 dataloss warnings after merge of remote-tracking branch

Le 11/01/2015 03:14, Richard Heck a écrit : JMarc, does dotted_line_thickness_ need to be a float? I do not think so, but then I do not know this code well. There are some additional tricks linked to zoom that cause the value to not exactly be what we think it is. Actually, QFontMetrics alr

Re: 2 dataloss warnings after merge of remote-tracking branch

Le 11/01/2015 11:53, Georg Baum a écrit : Because they are on by default in MSVC and off by default in gcc. You can get similar ones with gcc by calling it with -Wconversion (but that outputs many more). Yes, I tried it, but it is not useful. I have had cases where those warnings showed a rea

Re: 2 dataloss warnings after merge of remote-tracking branch

Richard Heck wrote: > On 01/10/2015 08:20 PM, Uwe Stöhr wrote: >> Hello JMarc, >> >> after your merge I get these 2 compilation warnings: >> >> ..\..\src\RowPainter.cpp(448): warning C4244: 'Argument': conversion >> of 'float' to

Re: 2 dataloss warnings after merge of remote-tracking branch

On 01/10/2015 08:20 PM, Uwe Stöhr wrote: Hello JMarc, after your merge I get these 2 compilation warnings: ..\..\src\RowPainter.cpp(448): warning C4244: 'Argument': conversion of 'float' to 'int', possible dataloss ..\..\src\RowPainter.cpp(450):

2 dataloss warnings after merge of remote-tracking branch

Hello JMarc, after your merge I get these 2 compilation warnings: ..\..\src\RowPainter.cpp(448): warning C4244: 'Argument': conversion of 'float' to 'int', possible dataloss ..\..\src\RowPainter.cpp(450): warning C4244: 'Initialisation': conv

Re: [LyX/master] Merge branch 'master' of git.l

Am 04.06.2013 22:31, schrieb Vincent van Ravesteijn: What was the problem that it worked for me and not for you? Just curious. I windows fix I installed. It destroyed the git's access to the files in the Windws explorer. This problem is Win XP 64bit only, but before I was aware f that I dupli

Re: [LyX/master] Merge branch 'master' of git.l

Op 4 jun. 2013 22:27 schreef "Uwe Stöhr" het volgende: > > Am 01.06.2013 04:24, schrieb Uwe Stöhr: > > >> Lars told me this too but it doesn't work: if rebasing is possible and I press "Start Rebase" I get >> "unrecoverable error occurred" and that is it. I played with this today for a while but r

Re: [LyX/master] Merge branch 'master' of git.l

Am 01.06.2013 04:24, schrieb Uwe Stöhr: Lars told me this too but it doesn't work: if rebasing is possible and I press "Start Rebase" I get "unrecoverable error occurred" and that is it. I played with this today for a while but rebasing does not work, no matter what I do. This is now fixed i

  1   2   3   4   5   >