Guillaume Munch wrote:
> I think the ideal solution should involve no keep option at all.
> Branches should be automatically collapsed if they have been
> automatically opened. The information of which branch has been opened by
> hand should be stored in the buffer (but not saved). This would
Looking over the code, it looks like much of the problem is that Python 2
has print as a statement, while Python 3 has print as a function. Since
we're supporting only Python 2.7 from the 2.x series, we could add an
import statement to use print as a function in order to avoid checking the
version
On 2016-05-04 20:39:54 +, Scott Kostyshak said:
3. A Python3 compatibility issue at [5]. I don't know whether the best
short-run approach is to ensure that we use Python2 to call the script or to
fix the script to be compatible with Python3. I CC'ed José to see if he has
some wisdom to
Am 08.05.2016 um 22:36 schrieb Georg Baum:
3) A translator sends a .po file with unix line ends
4) A translator sends a .po file with windows line ends
The question is how can I check this?
For cases 1) and 3) a commit is OK, for cases 2) and 4) a commit would
produce a huge pseudo diff.
I think compression has been enabled by mistake.
Le 09/05/2016 00:25, Uwe Stöhr a écrit :
commit 41e928b2e50e372e46926972a9b183dc0607f3f0
Author: Uwe Stöhr
Date: Mon May 9 01:24:02 2016 +0200
German UserGuide.lyx: tons of typographic fixes sent in by an unknown user
Le 06/05/2016 12:46, Pavel Sanda a écrit :
Guillaume Munch wrote:
Dear list
I propose to remove the "Keep" checkbox in the outliner panel. The
panel would behave as if always checked.
Hold on, it does not look like that here. When I set depth 2 in
outliner, open user guide and cruise down in
Le 06/05/2016 21:09, Scott Kostyshak a écrit :
On Wed, May 04, 2016 at 11:19:56PM +0100, Guillaume Munch wrote:
Le 04/05/2016 21:39, Scott Kostyshak a écrit :
What am I missing?
#10068: Files distributed with lyx should not contain parbreak and
latexpar
Am Sonntag, 8. Mai 2016 um 22:12:36, schrieb Georg Baum
> Kornel,
>
> while investigating the .po file line end problem I noticed that the .pot
> file generation with cmake does first write windows line ends and then a
> converter is called to create unix line
Hi,
the following is mainly for developers on windows, since others won't
see any difference.
.pot files are now always created with unix line ends in the latest
2.3-staging branch. This should fix the stray '\r' characters that
appeared in .po files after string remerge on windows. unix
Kornel,
while investigating the .po file line end problem I noticed that the .pot
file generation with cmake does first write windows line ends and then a
converter is called to create unix line ends.
I would like to simplify this in 2.3-staging (see attached). OK?
Georgdiff --git
On Sat, May 7, 2016 at 3:32 AM, Stephan Witt wrote:
>
> Sorry, I should have mentioned the name. They are named org.lyx.LyX*
>
> But I’m not sure if these are the only locations where Qt stores internal
> state.
>
> Stephan
Moving org.lyx* out of that directory does not cure
Am Sonntag, 8. Mai 2016 um 10:29:22, schrieb Georg Baum
> Kornel Benko wrote:
>
> > Sorry, I do not see how this would mix anything.
> > Wouldn't the line endings be corrected on commit?
>
> After commit, yes. But I want to avoid that simply running a .po update
Kornel Benko wrote:
> Sorry, I do not see how this would mix anything.
> Wouldn't the line endings be corrected on commit?
After commit, yes. But I want to avoid that simply running a .po update step
without commit changes line endings, since this could be confusing, and git
would also warn on
Am Sonntag, 8. Mai 2016 um 09:42:31, schrieb Georg Baum
> Kornel Benko wrote:
>
> > Introducing .gitattributes makes specifying line-endings for *.po files
> > acceptable too IMHO. (As you already proposed at
> >
Kornel Benko wrote:
> Introducing .gitattributes makes specifying line-endings for *.po files
> acceptable too IMHO. (As you already proposed at
> https://www.mail-archive.com/lyx-devel@lists.lyx.org/msg193484.html)
Yes, but this would only fix one part of the problem. The other one would be
to
Am 07.05.2016 um 17:06 schrieb Guillaume Munch :
>
> Which version of qt is this for? Here on Ubuntu we are still stuck with
> 5.5.1 for a little while. More generally what qt version is going to be
> supported by 2.3 ?
This is not needed for Qt 5.5.1 too.
But I think the plan is
16 matches
Mail list logo