On 11.05.2011 07:26, Stephan Witt wrote:
Am 11.05.2011 um 00:02 schrieb Peter Kümmel:
On 10.05.2011 10:07, Kornel wrote:
Am Dienstag, 10. Mai 2011 schrieb Peter Kümmel:
...
Done.
Kornel
Good. Found a small issue when compiling with msvc.
Peter
I have a patch for enabling compil
On 24/04/2011 8:13 PM, Diego Queiroz wrote:
Everything is working like a charm.
I also included the Requires natbib, which forces the inclusion of natbib in
the UI.
That is, I force the inclusion of natbib then I say that I'm already
providing it. lol
The last thing I wasn't able to avoid is the
On Wed, May 11, 2011 at 7:51 AM, Diego Queiroz wrote:
>> ..which is why we should use general-purpose file backup systems for
>> the important stuff. See Dropbox and SpiderOak, both free and easy to
>> install and use.
>> Liviu
>
> These services won't help in this specific case, since you just lo
>
> ..which is why we should use general-purpose file backup systems for
> the important stuff. See Dropbox and SpiderOak, both free and easy to
> install and use.
> Liviu
>
These services won't help in this specific case, since you just lose the
unsaved content in memory.
Anyway...
---
Diego Qu
Am 11.05.2011 um 00:02 schrieb Peter Kümmel:
> On 10.05.2011 10:07, Kornel wrote:
>> Am Dienstag, 10. Mai 2011 schrieb Peter Kümmel:
>> ...
Done.
Kornel
>>>
>>> Good. Found a small issue when compiling with msvc.
>>>
>>> Peter
>>
>> I have a patch for enabling compiled
Hi,
Recently I've been working on the sweave module in LyX and discussing
with Jean-Marc and Gregor, and I was suggested to send emails to this
mailing list to get more people involved in the discussion.
One issue that we need to solve is the style Sweave.sty. This is not a
standard LaTeX package
"Uwe Stöhr" wrote in message
news:4dc9f19f.3030...@web.de...
Btw., can you please send me the hunspell.lib, iconv.lib and intl.lib
files?
Currently I cannot compile LyX against hunspell for that reason and i can
also not use the new versions of intl and iconv you ship with your
installer.
If p
"Uwe Stöhr" wrote in message
news:4dc9f4fd.9020...@web.de...
So - maybe full offline installation wasn't all that convenient, but
it was at least possible - please don't cut off this way.
We won't cut that of. But note, to have a fully functional LaTeX
installation, you at least once nee
"Uwe Stöhr" wrote in message
news:4dc9f3f7.90...@web.de...
OK, there was indeed a problem with my MiKTeX installation residues in the
registry. now the installation runs through as expected, but there are
thing we should improve:
a. When LyX is installed together with MiKTeX we need to set an
On Wed, May 11, 2011 at 5:30 AM, Diego Queiroz wrote:
> Actually, it is not a total data loss.
> In extreme cases, you can recover the data using a text editor and manually
> extracting it from the emergency file.
> Which is not good though...
>
..which is why we should use general-purpose file ba
Actually, it is not a total data loss.
In extreme cases, you can recover the data using a text editor and manually
extracting it from the emergency file.
Which is not good though...
---
Diego Queiroz
On 10/05/2011 10:27 PM, Uwe Stöhr wrote:
Am 10.05.2011 21:01, schrieb Joost Verburg:
"Uwe Stöhr" wrote in message
news:4dc9150a.9060...@web.de...
Am 10.05.2011 02:08, schrieb Uwe Stöhr:
Seems to be a problem of the MiKTeX repositories: LyX's first run of
configure.py runs through
without inst
I just found this bug:
http://www.lyx.org/trac/ticket/7547
Sadly I found it using the worst method: working with the thesis... :(
Be aware.
---
Diego Queiroz
On Wed, 11 May 2011 04:31:25 +0200
Uwe Stöhr wrote:
> My plan is to do the same as for Aspell in my installer: You can at
> any time download and install all dictionaries.
The important thing there would be to allow for separation of the
'download' and 'install' steps (I mean: download, move
Am 10.05.2011 10:07, schrieb Michal:
I think having to keep the installer around to be able to add
languages is not a good thing. Ideally perhaps we would install a
little app to download dictionaries? I don't have time to work on
this now but it's something we could look into in the future.
Am 10.05.2011 21:01, schrieb Joost Verburg:
"Uwe Stöhr" wrote in message news:4dc9150a.9060...@web.de...
Am 10.05.2011 02:08, schrieb Uwe Stöhr:
Seems to be a problem of the MiKTeX repositories: LyX's first run of
configure.py runs through
without installing any LaTeX-package. That's why I co
Am 10.05.2011 19:10, schrieb Joost Verburg:
I didn't noticed yet that in cases like this, the installer language will also
be German, so
setting the GUI language in the installer is no advantage. I think to remember
that I introduced
this feature for an installer of LyX 1.4.x when setting the
Having skimmed through http://trac-hacks.org/wiki/WikiStart, here's a
list of interesting plugins:
For branch management:
--
http://trac-hacks.org/wiki/BranchTimelinePlugin
-- A filter for timeline based on svn branch
http://trac-hacks.org/wiki/BatchModifyPlugin
http://trac
On 10.05.2011 22:53, Pavel Sanda wrote:
Peter Kümmel wrote:
boost and intl is not our code, but it is source code ->
src/3rdparty/boost
src/3rdparty/intl
src/cygwin
i would expect that src/ contains "our" code, but no hard opinion.
At least we should not have boost and intl at
On 10.05.2011 10:07, Kornel wrote:
Am Dienstag, 10. Mai 2011 schrieb Peter Kümmel:
...
Done.
Kornel
Good. Found a small issue when compiling with msvc.
Peter
I have a patch for enabling compiled lyx to run from anywhere without need
to have sysdir defined.
If everything fails (rel
Peter Kümmel wrote:
> sourcedoc is for development documentation->
> doc/sourcedoc
> doc/coding
why not development/ ?
p
Enrico Forestieri wrote:
> > that was the second check you forced me to do :)
>
> Sorry?
"doublecheck" in mails above. p
Peter Kümmel wrote:
> boost and intl is not our code, but it is source code ->
> src/3rdparty/boost
> src/3rdparty/intl
> src/cygwin
i would expect that src/ contains "our" code, but no hard opinion.
> po is ui needed at compile time ->
> src/po
please no. git has no way how to a
"Uwe Stöhr" wrote in message
news:4dc9150a.9060...@web.de...
Am 10.05.2011 02:08, schrieb Uwe Stöhr:
Seems to be a problem of the MiKTeX repositories: LyX's first run of
configure.py runs through without installing any LaTeX-package. That's why
I couldn't see in this case no feedback from the
Am Dienstag, 10. Mai 2011 schrieb Peter Kümmel:
> On 10.05.2011 10:50, Jean-Marc Lasgouttes wrote:
> > Le 07/05/11 13:32, Peter Kümmel a écrit :
> >> I think we couldn't do much here. cmake tries to re-use the path to the
> >> sources which
> >> contain "../.." and replaces them by "__/__".
> >>
>
On 10.05.2011 10:08, Kornel wrote:
Am Dienstag, 10. Mai 2011 schrieb Stephan Witt:
Am 09.05.2011 um 23:54 schrieb Kornel:
Am Montag, 9. Mai 2011 schrieb Peter Kümmel:
On 09.05.2011 23:26, Kornel wrote:
Am Montag, 9. Mai 2011 schrieb Peter Kümmel:
Let us delete development/cmake/CMakeLists.tx
On 10.05.2011 10:50, Jean-Marc Lasgouttes wrote:
Le 07/05/11 13:32, Peter Kümmel a écrit :
I think we couldn't do much here. cmake tries to re-use the path to the
sources which
contain "../.." and replaces them by "__/__".
But it's internal to cmake. Why is it a problem to you?
I find this ug
On 10.05.2011 19:32, Jean-Marc Lasgouttes wrote:
Le 10/05/11 19:29, Peter Kümmel a écrit :
The idea was not to pollute the src dirs because much more than
CMakeLists.txt
is needed. But I think we could move the CMakeLists.txt into the source
dirs and
all other files in development/cmake.
Or ev
On 10/05/2011 9:39 AM, Michel Lavaud wrote:
Le 10/05/2011 13:46, Richard Heck a écrit :
I would find it an improvement if, in the "Plan" window, the sequence
chapter / section/ etc. currently opened remained opened when opening
another chapter or section, etc.
Isn't this what the "Keep" butto
On 10.05.2011 19:32, Jean-Marc Lasgouttes wrote:
Le 10/05/11 19:29, Peter Kümmel a écrit :
The idea was not to pollute the src dirs because much more than
CMakeLists.txt
is needed. But I think we could move the CMakeLists.txt into the source
dirs and
all other files in development/cmake.
Or ev
On 05/10/2011 01:20 PM, Jürgen Spitzmüller wrote:
> Richard Heck wrote:
>> I want to know which bugs have been fixed already in trunk but not yet
>> in branch, and I want some way also to mark which of these are eligible
>> for branch and which are not. This seems like a useful thing for the
>> bra
Le 10/05/11 19:29, Peter Kümmel a écrit :
The idea was not to pollute the src dirs because much more than
CMakeLists.txt
is needed. But I think we could move the CMakeLists.txt into the source
dirs and
all other files in development/cmake.
Or even in ./cmake (and ./config could be renamed to ./
On 10.05.2011 10:47, Jean-Marc Lasgouttes wrote:
Le 10/05/11 10:42, Kornel a écrit :
Am Dienstag, 10. Mai 2011 schrieb Abdelrazak Younes:
> Why don't you put also all CMakeLists.txtin src/, frontends/ etc?
We (Peter and me) wanted to keep the files in extra tree.
Why do you want to do that?
On 05/10/2011 12:21 PM, Julien Rioux wrote:
> On 10/05/2011 12:10 PM, Richard Heck wrote:
>> On 05/10/2011 11:37 AM, Stephan Witt wrote:
>>> Am 10.05.2011 um 17:27 schrieb Vincent van Ravesteijn:
There are
plenty of cases where a bug gets fixed in trunk first, and then we
wait
t
Richard Heck wrote:
> I want to know which bugs have been fixed already in trunk but not yet
> in branch, and I want some way also to mark which of these are eligible
> for branch and which are not. This seems like a useful thing for the
> branch maintainer to know, and what I really want is to hav
On 05/10/2011 12:47 PM, Vincent van Ravesteijn wrote:
>> Sorry I read quickly. I agree with your concerns about not changing the bug
>> tracker workflow based on the fact that the current setup doesn't allow
>> complicated queries. There are technical ways for these complicated queries
>> to be per
Il 10/05/2011 16:38, Edwin Leuven ha scritto:
Tommaso Cucinotta wrote:
For c), it's a
complete rewrite, so I'm not considering it for now :-).
but this is the only way to go no?
that depends on your vision of "only". For now, we have a feature
that perhaps is not implemented in the best/most-
"Uwe Stöhr" wrote in message
news:4dc9150a.9060...@web.de...
I tried to resolve the known issues in the new 2.0 version of the
Metafile 2 EPS converter.
Joost fixed this yesterday.
I made some more improvements to metafile2eps today. I'll prepare updated
installers.
7. It is not possible
>
> Sorry I read quickly. I agree with your concerns about not changing the bug
> tracker workflow based on the fact that the current setup doesn't allow
> complicated queries. There are technical ways for these complicated queries
> to be performed. They involve one of
>
It's just that I don't se
>
> I am not able to fully understand the part
> "the directory is defined in the compilation process and there's no way to
> achieve this without changing the code".
>
>
Open LyX and select Help > About.
There you can see what directory LyX is using to store user files.
On Windows, this folder i
On Tue, May 10, 2011 at 6:21 PM, Julien Rioux wrote:
> On 10/05/2011 12:10 PM, Richard Heck wrote:
>
>> On 05/10/2011 11:37 AM, Stephan Witt wrote:
>>
>>> Am 10.05.2011 um 17:27 schrieb Vincent van Ravesteijn:
>>>
There are
plenty of cases where a bug gets fixed in trunk first, and then
On 10/05/2011 12:20 PM, Stephan Witt wrote:
Am 10.05.2011 um 18:10 schrieb Julien Rioux:
On 10/05/2011 11:55 AM, Richard Heck wrote:
On 05/10/2011 11:20 AM, Vincent van Ravesteijn wrote:
2. Bugs fixed in trunk with some intention that they should be fixed in
branch should be keyword'ed fixedi
On 10/05/2011 12:21 PM, Vincent van Ravesteijn wrote:
The need is generated by my inability to do queries I need to do.
Again, I don't know what query you want to do.
Vincent
The query that Richard is after is fixedintrunk but not fixedinbranch
I understand that. But as I said, I d
On Tue, May 10, 2011 at 6:10 PM, Richard Heck wrote:
> On 05/10/2011 11:27 AM, Vincent van Ravesteijn wrote:
> > On Tue, May 10, 2011 at 3:21 PM, Richard Heck
> wrote:
> >
> >> On 05/10/2011 08:50 AM, Abdelrazak Younes wrote:
> >>> On 05/10/2011 02:12 PM, Richard Heck wrote:
> On 05/10/201
On 10/05/2011 12:10 PM, Richard Heck wrote:
On 05/10/2011 11:37 AM, Stephan Witt wrote:
Am 10.05.2011 um 17:27 schrieb Vincent van Ravesteijn:
There are
plenty of cases where a bug gets fixed in trunk first, and then we wait
to commit to branch until we see how that goes.
In the development mo
>
>
>>>
>>> The need is generated by my inability to do queries I need to do.
>>>
>>
>>
>> Again, I don't know what query you want to do.
>>
>> Vincent
>>
>>
> The query that Richard is after is fixedintrunk but not fixedinbranch
>
> I understand that. But as I said, I don't see why you need t
Am 10.05.2011 um 18:10 schrieb Julien Rioux:
> On 10/05/2011 11:55 AM, Richard Heck wrote:
>> On 05/10/2011 11:20 AM, Vincent van Ravesteijn wrote:
> 2. Bugs fixed in trunk with some intention that they should be fixed in
> branch should be keyword'ed fixedintrunk, as now, and the mileston
On 10/05/2011 2:29 AM, Stephan Witt wrote:
Am 09.05.2011 um 23:15 schrieb Pavel Sanda:
Richard Heck wrote:
Jurgen liked having the keyword because it made it easier to tell what
bugs had been fixed for the next release. I suppose your suggestion,
closing them with the milestone, probably serve
On 10/05/2011 11:55 AM, Richard Heck wrote:
On 05/10/2011 11:20 AM, Vincent van Ravesteijn wrote:
2. Bugs fixed in trunk with some intention that they should be fixed in
branch should be keyword'ed fixedintrunk, as now, and the milestone
should be set either to the next maintenance release or to
>
> >>
> > Please don't mass move these bugs to 2.0.x. Most of them don't deserve
> > such a milestone.
> >
> We should go through them one by one and decide what to do with them,
> then. I'd welcome the help, from anyone. These are the bugs that need
> checking:
>
> http://www.lyx.org/trac/query?
On 05/10/2011 11:27 AM, Vincent van Ravesteijn wrote:
> On Tue, May 10, 2011 at 3:21 PM, Richard Heck wrote:
>
>> On 05/10/2011 08:50 AM, Abdelrazak Younes wrote:
>>> On 05/10/2011 02:12 PM, Richard Heck wrote:
On 05/10/2011 06:58 AM, Vincent van Ravesteijn wrote:
>> Third, when we switc
On 05/10/2011 11:37 AM, Stephan Witt wrote:
> Am 10.05.2011 um 17:27 schrieb Vincent van Ravesteijn:
>> There are
>> plenty of cases where a bug gets fixed in trunk first, and then we wait
>> to commit to branch until we see how that goes.
>>
>> In the development model I propose, we fix a bug in
Am 10.05.2011 um 17:50 schrieb Vincent van Ravesteijn:
>
> So, if a bug is attacked in a branch and this lasts a while you need to
> remerge
> the BRANCH_2_0_X regularly into your bug fixing branch(es), right?
>
> Stephan
>
>
> No. There is no reason to merge BRANCH_2_0_X into a topic branc
On 10/05/2011 11:20 AM, Vincent van Ravesteijn wrote:
1. Bugs fixed in trunk and branch should be closed, with the milestone
set to the next maintenance release.
Objection: people don't search closed bugs, and if they do, they probably
end up with so many bugs that might or might not be rela
On 10/05/2011 4:53 AM, Pavel Sanda wrote:
Stephan Witt wrote:
I always had the problem searching the "open" issues, aka not "fixedintrunk".
I couldn't come up with a report, e. g. find all os=macosx but not fixed issues.
yes, he knows only OR of keywords. pavel
It's fixed in trac 0.12. You
On 05/10/2011 11:20 AM, Vincent van Ravesteijn wrote:
>>> 2. Bugs fixed in trunk with some intention that they should be fixed in
>>> branch should be keyword'ed fixedintrunk, as now, and the milestone
>>> should be set either to the next maintenance release or to 2.0.x. (This
>>> is pretty much as
>
>
> So, if a bug is attacked in a branch and this lasts a while you need to
> remerge
> the BRANCH_2_0_X regularly into your bug fixing branch(es), right?
>
> Stephan
No. There is no reason to merge BRANCH_2_0_X into a topic branch. If no
merge
conflicts arise, the two can live happily next to
On 05/10/2011 10:17 AM, Jürgen Spitzmüller wrote:
> Richard Heck wrote:
>> I'll have to think about this. The current policy of committing first to
>> trunk makes a lot of sense, as far as keeping branch stable. There are
>> plenty of cases where a bug gets fixed in trunk first, and then we wait
>>
On 05/10/2011 10:17 AM, Jürgen Spitzmüller wrote:
> Richard Heck wrote:
>> I'll have to think about this. The current policy of committing first to
>> trunk makes a lot of sense, as far as keeping branch stable. There are
>> plenty of cases where a bug gets fixed in trunk first, and then we wait
>>
Am 10.05.2011 um 17:27 schrieb Vincent van Ravesteijn:
> There are
> plenty of cases where a bug gets fixed in trunk first, and then we wait
> to commit to branch until we see how that goes.
>
> In the development model I propose, we fix a bug in a topic branch.
> This branch will regularly be me
On Tue, May 10, 2011 at 3:21 PM, Richard Heck wrote:
> On 05/10/2011 08:50 AM, Abdelrazak Younes wrote:
> > On 05/10/2011 02:12 PM, Richard Heck wrote:
> >> On 05/10/2011 06:58 AM, Vincent van Ravesteijn wrote:
> Third, when we switch to git, bugs will be fixed in branch first,
> then
>
>
> >> 1. Bugs fixed in trunk and branch should be closed, with the milestone
> >> set to the next maintenance release.
> >>
> > Objection: people don't search closed bugs, and if they do, they probably
> > end up with so many bugs that might or might not be related.
> >
> But we already have thi
Tommaso Cucinotta wrote:
> For c), it's a
> complete rewrite, so I'm not considering it for now :-).
but this is the only way to go no?
c is also more likely to happen without a and b, so maybe we should
allow only real fixes and not ad-hoc workarounds (enrico would call it
bloat i suspect) for
On Tue, May 10, 2011 at 02:07:39PM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > only an environment variable is
> > added before launching converters.
>
> yep thats what i meant; went only smoothly though those parts
> and saw new code around startscript/process fucntions.
> looking a
Hi all,
I just updated my previous patch that allows to abort a long Advanced
F&R operation to the trunk of 1 or 2 days ago:
http://www.lyx.org/trac/attachment/ticket/7217/lyx-findadv-abort.patch
This works by "polling" the GUI events and, if the ESC key was pressed,
abort it (with some ms
Richard Heck wrote:
> I'll have to think about this. The current policy of committing first to
> trunk makes a lot of sense, as far as keeping branch stable. There are
> plenty of cases where a bug gets fixed in trunk first, and then we wait
> to commit to branch until we see how that goes. Of cour
On 05/10/2011 04:12 PM, Abdelrazak Younes wrote:
On 05/10/2011 03:19 PM, Guenter Milde wrote:
(compared to the following steps and to image
conversions), could we consider not to clone the buffer but do the
initial export before starting a new thread?
See above. There is no point in using th
On 05/10/2011 03:19 PM, Guenter Milde wrote:
On 2011-05-10, Abdelrazak Younes wrote:
On 05/10/2011 11:15 AM, Guenter Milde wrote:
On 2011-05-09, Richard Heck wrote:
As, generally, the LyX -> first-non-native-format (latex, html, text)
export is fast
Export to latex is not fast. It seems to b
Le 10/05/2011 13:46, Richard Heck a écrit :
>> I would find it an improvement if, in the "Plan" window, the sequence
>> chapter / section/ etc. currently opened remained opened when opening
>> another chapter or section, etc.
>>
> Isn't this what the "Keep" button does?
>
Sorry, my question was
On 05/10/2011 08:50 AM, Abdelrazak Younes wrote:
> On 05/10/2011 02:12 PM, Richard Heck wrote:
>> On 05/10/2011 06:58 AM, Vincent van Ravesteijn wrote:
Third, when we switch to git, bugs will be fixed in branch first,
then these changes get merged into master automatically.
>> This i
On 2011-05-10, Abdelrazak Younes wrote:
> On 05/10/2011 11:15 AM, Guenter Milde wrote:
>> On 2011-05-09, Richard Heck wrote:
>> As, generally, the LyX -> first-non-native-format (latex, html, text)
>> export is fast
> Export to latex is not fast. It seems to be fast on Linux because the
> proce
Am Dienstag, 10. Mai 2011 schrieb Stephan Witt:
> Am 10.05.2011 um 13:26 schrieb Kornel:
> > Can you see the freshly compiled library somewhere in
> > /Users/stephan/cvs/lyx/lyx-build/cmake/lyx-devel/lib/...?
>
> Unfortunately not.
>
> % ls /Users/stephan/cvs/lyx/lyx-build/cmake/lyx-devel/lib/De
On 05/10/2011 02:12 PM, Richard Heck wrote:
On 05/10/2011 06:58 AM, Vincent van Ravesteijn wrote:
Third, when we switch to git, bugs will be fixed in branch first, then these
changes get merged into master automatically.
This is a separate issue, but surely this isn't true. Bugs will get
fixe
Am 10.05.2011 um 13:26 schrieb Kornel:
> Can you see the freshly compiled library somewhere in
> /Users/stephan/cvs/lyx/lyx-build/cmake/lyx-devel/lib/...?
Unfortunately not.
% ls /Users/stephan/cvs/lyx/lyx-build/cmake/lyx-devel/lib/Debug/
libboost_regex.alibfrontend_qt4.a libgra
On 05/10/2011 06:58 AM, Vincent van Ravesteijn wrote:
>> Third, when we switch to git, bugs will be fixed in branch first, then these
>> changes get merged into master automatically.
>>
This is a separate issue, but surely this isn't true. Bugs will get
fixed in git branches and merged into trunk,
On 05/10/2011 06:58 AM, Vincent van Ravesteijn wrote:
>> So here's a new proposal, modeled on your suggestions:
>>
>> 1. Bugs fixed in trunk and branch should be closed, with the milestone
>> set to the next maintenance release.
>>
> Objection: people don't search closed bugs, and if they do, they
Enrico Forestieri wrote:
> only an environment variable is
> added before launching converters.
yep thats what i meant; went only smoothly though those parts
and saw new code around startscript/process fucntions.
looking again, there is always path.empty()?, so it should
be ok... that was the sec
On 05/10/2011 03:56 AM, Michel Lavaud wrote:
> On 04.05.2011 00:50, Vincent van Ravesteijn wrote:
>> Hi everyone,
>>
>> As a typical start of a new release cycle I want to poll
>> - what features are a must in the next release;
>> - what work do you think you will be doing;
>> - what do you hope to
Am Dienstag, 10. Mai 2011 schrieb Stephan Witt:
> Am 10.05.2011 um 12:11 schrieb Kornel:
> > Am Dienstag, 10. Mai 2011 schrieb Stephan Witt:
...
This I don't understand. I didn't see a segment name ...
> {standard input}:38:Expected comma after segment-name
> Command /Developer/usr/bin/gcc-4.2 fai
>
> So here's a new proposal, modeled on your suggestions:
>
> 1. Bugs fixed in trunk and branch should be closed, with the milestone
> set to the next maintenance release.
>
Objection: people don't search closed bugs, and if they do, they probably
end up with so many bugs that might or might not
>
> [ticket-custom]
>
> fixedintrunk = checkbox
> fixedintrunk.label = Will be fixed in the next major version
> fixedintrunk.value = 0
>
> fixedinbranch = checkbox
> fixedinbranch.label = Will be fixed in the next minor version
> fixedinbranch.value = 0
>
> and then some other magic for the checkb
On Mon, May 9, 2011 at 10:43 PM, Richard Heck wrote:
>
> Would anyone object to my creating a new resolution in trac that we
> could use instead of using the keyword fixedinbranch? I'd propose:
> FixedForBranch, as the resolution.
>
> Why? Well, (i) bugs fixed in branch are fixed and are only awa
Am 10.05.2011 um 12:11 schrieb Kornel:
> Am Dienstag, 10. Mai 2011 schrieb Stephan Witt:
> > Sorry, didn't work too.
> >
> > % cmake -DLYX_RELEASE=ON -DLYX_EXTERNAL_LIBINTL=OFF -DLYX_NLS=ON
> > CompileC
> > .../cmake/lyx-devel/intl/lyx.build/Debug/intl.build/Objects-normal/i386/in
> > tl-exports.
Am 10.05.2011 02:08, schrieb Uwe Stöhr:
5. The latest version of the metafile2eps printer gives an error message when
it is first used:
When I compile a LyX file containing a wmf-image, I get the error message that
the printer could
not be successfully be initialized. For all further uses of t
On 05/10/2011 10:46 AM, Jean-Marc Lasgouttes wrote:
Le 10/05/11 10:08, Kornel a écrit :
Should we enable it?
My take is yes. Developpers should test all coe. If it is unbearable
then either
a) someone finds the energy to fix it
b) people configure with NLS=OFF, but they know it is wrong to
On 05/10/2011 11:27 AM, Jean-Marc Lasgouttes wrote:
Le 10/05/11 11:01, Kornel a écrit :
Nothing recomended here. The only recomendation is, that the build
should
not be in source tree.
But we want keep the cmake-files together.
I think keeping them with the source is better if you want peop
On 05/10/2011 11:15 AM, Guenter Milde wrote:
On 2011-05-09, Richard Heck wrote:
Discussion in the "Math Macros in Child Documents" thread has revealed a
problem with how we clone buffers with parents. The set up is this: You
have a master that defines a macro, and a child that uses it. If you t
Am Dienstag, 10. Mai 2011 schrieb Stephan Witt:
> Sorry, didn't work too.
>
> % cmake -DLYX_RELEASE=ON -DLYX_EXTERNAL_LIBINTL=OFF -DLYX_NLS=ON
> CompileC
> .../cmake/lyx-devel/intl/lyx.build/Debug/intl.build/Objects-normal/i386/in
> tl-exports.o intl/intl-exports.c normal i386 c com.apple.compiler
Am 10.05.2011 um 11:44 schrieb Liviu Andronic:
> On Tue, May 10, 2011 at 11:41 AM, Pavel Sanda wrote:
>> Jürgen Spitzmüller wrote:
>>> requested behaviour would be wrong) and (b) a problem of the speller
>>> backend,
>>> not LyX.
>>
>> maybe its matter of creating bug for debian to use hunspell
Am 10.05.2011 um 11:14 schrieb Kornel:
> Am Dienstag, 10. Mai 2011 schrieb Stephan Witt:
> > Am 10.05.2011 um 10:08 schrieb Kornel:
> > > Should we enable it?
> >
> > I tried it and it didn't work.
> >
> > CompileC
> > .../cmake/lyx-devel/src/support/lyx.build/Debug/support.build/Objects-norm
>
Pavel Sanda wrote:
> Jürgen Spitzmüller wrote:
> > requested behaviour would be wrong) and (b) a problem of the speller
> > backend, not LyX.
>
> maybe its matter of creating bug for debian to use hunspell by default?
> if i understood correctly hunspell would solve it.
IIRC some distributions
On Tue, May 10, 2011 at 11:41 AM, Pavel Sanda wrote:
> Jürgen Spitzmüller wrote:
>> requested behaviour would be wrong) and (b) a problem of the speller backend,
>> not LyX.
>
> maybe its matter of creating bug for debian to use hunspell by default?
>
Couldn't we ship LyX with hunspell pre-selecte
On Tue, May 10, 2011 at 11:39:21AM +0200, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > > i would be more careful about the
> > > systemcall part, it looks quite invasive and in very sensitive area of
> > > code.
> >
> > Uh? What do you mean?
>
> to double check anything which touches Syste
Jürgen Spitzmüller wrote:
> requested behaviour would be wrong) and (b) a problem of the speller backend,
> not LyX.
maybe its matter of creating bug for debian to use hunspell by default?
if i understood correctly hunspell would solve it.
pavel
Enrico Forestieri wrote:
> > i would be more careful about the
> > systemcall part, it looks quite invasive and in very sensitive area of code.
>
> Uh? What do you mean?
to double check anything which touches SystemCallXXX::
pavel
On Tue, May 10, 2011 at 11:06:17AM +0200, Pavel Sanda wrote:
> Richard Heck wrote:
> >> To conclude, note that even if the patch may seem large, it is really
> >> simple and not invasive, such that it can be safely backported to branch.
> >>
> > What's the policy as regards preference changes? We
Le 10/05/11 11:01, Kornel a écrit :
Nothing recomended here. The only recomendation is, that the build should
not be in source tree.
But we want keep the cmake-files together.
I think keeping them with the source is better if you want people to
update them.
JMarc
Lagaffe Gaston wrote:
> I've tested Lyx 2.0 on another computer running Debian Testing. The
> on-the-fly spell checking worked, that is a welcomed new feature.
> However, there is still this problem with proper nouns starting with an
> upper case that are detected as incorrect in any language (eng
On Tue, May 10, 2011 at 11:15 AM, Lagaffe Gaston
wrote:
> - Original Message
>
>> From: Liviu Andronic
>> To: Lagaffe Gaston
>> Cc: lyx-devel@lists.lyx.org
>> Sent: Mon, May 9, 2011 9:37:42 PM
>> Subject: Re: Spell checker false positives (nouns with upper case...)
>>
>> On Mon, May 9,
On 2011-05-09, Richard Heck wrote:
> Discussion in the "Math Macros in Child Documents" thread has revealed a
> problem with how we clone buffers with parents. The set up is this: You
> have a master that defines a macro, and a child that uses it. If you try
> to compile just the child, it works i
1 - 100 of 117 matches
Mail list logo
