Feature request: automatic recognition of .cls and .layout in the document directory.

[Stephen Harris]

Hello cyber benbob,

I notice others have asked for your feature request or a variation
of it. Here is a script that you could run from your end, probably
better used from its own directory without spaces, that could be sent
to your friend as a workaround until this feature is added to LyX.

He would need perhaps only Msys to unpack it. In case the .bst files
don't work though, you could include a .bat or script to copy the
necessary files to his /texmf(local) directory. Then he would need to
run texhash or Miktex options Refresh.

So he would have to unpack, and then maybe run a batfile, and
Refresh Latex. I suppose that another script could do all this for
him if the steps above seem difficult for him; so just download the
Lyx*tar.gz to a(root?) directory with the full-featured script file and
run the script. He should be capable of opening an Msys prompt
and typing into the command line if the syntax is provided in an
accompanying email or readme.

Regards,
Stephen
-

#!/bin/sh
# This script creates a tar archive with a lyx file and all included files
# (graphics and so on). The tar archive can be compressed with bzip2 or 
gzip.

#
# Author: Marcin Bukat
# email : [EMAIL PROTECTED]
# This script is a FREE software
# Use at Your own risk
#
# Modified by Enrico Forestieri <[EMAIL PROTECTED]> to:
# - make it also work on solaris
# - recusively collect included files pulled in by \input{}
# - allow for spaces in path names (but not carets ;-)
# - account for multiple bibtex files
# - avoid duplicate inclusions
# - only collect files which are in the same subtree as the lyx file
#
# Note: to allow for a space in path names I had to disallow another char.
# By default this is the caret '^' but it can be changed through an option.

#Prints usage instructions
usage ()
{
   echo "Usage: `basename $0` [-c ] [-o ] [-j|-z] 
path/to/file.lyx"

   echo "Options:"
   echo "-c  specify the forbidden char in path names"
   echo "-o  specify the output directory"
   echo "-j  compress with bzip2"
   echo "-z  compress with gzip"
   exit
}

#Recursively gather files
gatherFiles ()
{
LYXNAME=$1
DIRNAME=`dirname "$1"`

#Check if the bibtex .bst/.bib files are in the working directory to pack 
them

for file in `cat "$LYXNAME"|grep BibTeX|\
   sed 's/.*\[\(.*\)\].*{\(.*\)}.*/\1,\2/'|tr ', ' ' ,'`
do
   file=`echo $file|tr ',' ' '`
   if [ -f "$DIRNAME/$file.bst" -o  -f "$DIRNAME/$file.bib" ]; then
   cd "`eval dirname \\\"$DIRNAME/$file\\\"`"
   reldir=`pwd|sed -e "[EMAIL PROTECTED](.*\)@\1@" -e "[EMAIL 
PROTECTED]/\(.*\)@\1@"`
   if [ -n "$reldir" ]; then reldir=$reldir/; fi
   file=`basename "$file"`
   cd "$WORKDIR"
   if [ -f "$reldir$file.bst" ]; then
   INCFILES="\"$reldir$file.bst\"n$INCFILES"
   elif [ -f "$reldir$file.bib" ]; then
   INCFILES="\"$reldir$file.bib\"n$INCFILES"
   fi
   fi
done

# Gather figure files.
# Watch out for carriage returns and delete them (done by the last tr).
for file in `cat "$LYXNAME"|egrep "^[[:space:]]*filename "|\
   sed 's/.*filename *\(.*\)/\1/'|tr " " "$FC"|tr -d "\r"`
do
   file=`echo $file|tr "$FC" " "`
   if [ -f "$DIRNAME/$file" ]; then
   cd "`eval dirname \\\"$DIRNAME/$file\\\"`"
   reldir=`pwd|sed -e "[EMAIL PROTECTED](.*\)@\1@" -e "[EMAIL 
PROTECTED]/\(.*\)@\1@"`
   if [ -n "$reldir" ]; then reldir=$reldir/; fi
   file=`basename "$file"`
   cd "$WORKDIR"
   if [ -f "$reldir$file" ]; then
   INCFILES="\"$reldir$file\"n$INCFILES"
   fi
   fi
done

# Gather input files.
# If file.pstex_t is \input{}ed then add file.pstex to the list, too.
for file in `cat "$LYXNAME"|grep input\{|\
   sed 's/.*\\input{ *\(.*\) *}.*/\1/'|tr " " "$FC"`
do
   file=`echo $file|tr "$FC" " "`
   if [ -f "$DIRNAME/$file" ]; then
   cd "`eval dirname \\\"$DIRNAME/$file\\\"`"
   reldir=`pwd|sed -e "[EMAIL PROTECTED](.*\)@\1@" -e "[EMAIL 
PROTECTED]/\(.*\)@\1@"`
   if [ -n "$reldir" ]; then reldir=$reldir/; fi
   file=`basename "$file"`
   cd "$WORKDIR"
   if [ -f "$reldir$file" ]; then
   INCFILES="\"$reldir$file\"n$INCFILES"
   EXT=`echo $file | sed 's/.*\.\(.*\)/\1/'`
   if [ "x$EXT" = "xpstex_t" ]; then
   bname=`basename "$file" .pstex_t`
   INCFILES="\"$reldir$bname.pstex\"n$INCFILES"
   elif [ "x$EXT" = "xlyx" ]; then
   bname=`basename "$file"`
   gatherFiles "$reldir$file"
   fi
   fi
   fi
done
}

#Creates archive
archive ()
{
ARCHNAME=`basename "$LYXFILENAME" lyx`tar
case "$1" in
   -j)
   COMPRESS="bzip2"
   ARCHNAME="$ARCHNAME.bz2"
   ;;
   -z)
   COMPRESS="gzip"
   ARCHNAME="$ARCHNAME.gz"
   ;;
*)
   COMPRESS="cat"
esac

cd "$WORKDIR"
WORKDIR=`pwd`

gatherFiles "$LYXFILENAME"

INCFILES=`eval printf $INCFILES | sort | uniq | xargs -i%s echo "\"%

Re: One more patch

[Martin Vermeer]

On Fri, Feb 24, 2006 at 02:02:09PM +0100, Joost Verburg wrote:
> Martin Vermeer wrote:

...
 
> The area could also overlap a bit with the left side of the ( bracket. 
> Try clicking between two ordinary characters, say a and b (ab). Clicking 
> on the left side of b still gets the cursor between a and b.
> 
> The same thing applies to clicking on the right side of the last 
> bracket. There are a few pixels between the bracket and the position 
> where you can click to get the mouse there. If the bracket is the last 
> part of the equation there is only about 1 pixel left to click on.

This should improve things (untested)

- Martin
 
Index: math_nestinset.C
===
--- math_nestinset.C(revision 13276)
+++ math_nestinset.C(working copy)
@@ -1029,7 +1029,10 @@
if (dist_min == 0) {
// hit inside cell
for (pos_type i = 0, n = ar.size(); i < n; ++i)
-   if (ar[i]->covers(x, y))
+   // Provide an extra inert sliver to get in-between:
+   if (ar[i]->covers(x, y) 
+   && x >= ar[i]->xo() + 3
+   && x <= ar[i]->xo() + ar[i]->width() - 3)
return ar[i].nucleus()->editXY(cur, x, y);
}
return this;


pgpBIaFMDHcue.pgp
Description: PGP signature

Re: LyX 1.4: Reproducable Crash [more math bug examples]

[Martin Vermeer]

On Fri, Feb 24, 2006 at 02:21:04PM +0100, Georg Baum wrote:
> Jean-Marc Lasgouttes wrote:
> 
> >> "Georg" == Georg Baum
> >> <[EMAIL PROTECTED]>
> >> writes:
> > 
> > Georg> Jean-Marc Lasgouttes wrote:
> >>> So let's fix the crashes and release.
> > 
> > Georg> Yes please. BTW, what do you think of bug 2316? I am a bit
> > Georg> unsure if it should go in 1.4.0 or not. PRO: LyX can produce
> > Georg> invalid files without a fix. CON: It still needs testing, and I
> > Georg> don't want to delay a release at all.
> > 
> > You mean it can produce invalid LaTeX files, right?
> 
> No, AFAIK that is not possible since it has a hand crafted char by char
> latex output. I mean invalid .lyx files.
> 
> > A quick workaround 
> > would be the part of your patch that handles output of LyXFont when
> > language is latex_language. This is something that makes sense anyway.
> 
> That would actually not be enough, because the language can be set to
> something else without the other parts of the fix, and that other language
> would then be written.
> 
> > It seems to me from your discussions with Martin that the complete fix
> > is not very clear yet :)
> 
> I think it is clear now. A combination of Martins and my patches would fix
> all problems. What is missing now is the actual patch and testing.

I believe that, in your latest patch, simply moving the
text_.current_font etc.  stanza to doDispatch/default (as in my latest),
will produce a working and robust patch.

- Martin



pgpDOtqllHQ36.pgp
Description: PGP signature

Re: Problem with INSTALL.Win32 -

[Enrico Forestieri]

Abdelrazak Younes <[EMAIL PROTECTED]> writes:

> For Msys/mingw binaries, I might be able to help if needed. Packaging is 
> something else... Uwe might propose something and Angus might come out 
> of his retirement . I can see some well positioned outsiders (Enrico? 
> Michael?).

It is my intention to provide a cygwin package. I have already done that
in the past for distributing LyX to my colleagues and I have no problem
sharing it.

-- 
Enrico

Re: LyX, BibTeX and dependencies

[Lars Gullik Bjønnes]

Herbert Voss <[EMAIL PROTECTED]> writes:

| > I cannot really remember why it ended up like it is now, but I
| > suspect
| > that there is some issues with the .aux file.
| > I though latex gave a message that thre is unresolved citations? We
| > should trigger on that and do another latex run.
| 
| gives an endless loop when the \cite{foo} points to a _non existing_
| bibtex entry

No... we have a max iterations of 5 I think. (just because of this
issue)

-- 
Lgb

Re: LyX/Mac bundle changes

[Bennett Helm]

On Feb 24, 2006, at 10:06 AM, Jean-Marc Lasgouttes wrote:


"Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:


Bennett> As I noted in a different thread, I've placed a slightly
Bennett> revised version of the LyX/Mac metadata importer here:
Bennett> .

Bennett> Once again, I think this is ready to go in to 1.4.0, though
Bennett> comments would be welcome. (Source files can be found here:
Bennett> .)


You mean that you want to include the compiled importer in LyX source?
But we do not have it currently, do we?


Yes -- it's a part of the LyX.app bundle, located in development/ 
MacOSX/LyX.app/Contents/Library/Spotlight/.


(Note my question in the other thread : should the source for this  
(as an XCode project) go into the LyX source? I'd be happier if  
others more knowledgeable than I reviewed it. ... Sorry if I  
shouldn't have created a new thread for this)



Bennett> Along with the change, I decided to look again at the
Bennett> Info.plist file that is a part of the LyX/Mac application
Bennett> bundle, and found a minor tweak was necessary for
Bennett> consistency; trivial patch attached.

I applied it.


Thanks.

Bennett

Re: LyX, BibTeX and dependencies

[Herbert Voss]

Lars Gullik Bjønnes wrote:

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| I noticed today that bibtex-supported citations do not work (giving
| [?]) when doing the first View>DVI. The reason is simple: LyX runs
| latex, then bibtex, then latex again. Therefore, since bibliography is
| at the end of the document, the \cite macros do not see the correct
| values from BibTeX's .bbl file.
| 
| A natural way of doing this would be to see whether the .aux file has

| changed. It turns out that this aux file is explicitely not tracked:
| 
| 	// (2) foundfile is in the tmpdir

|   // insert it into head
|   if (fs::exists(onlyfile)) {
|   static regex unwanted("^.*\\.(aux|log|dvi|bbl|ind|glo)$");
|   if (regex_match(onlyfile, unwanted)) {
|   lyxerr[Debug::DEPEND]
|   << "We don't want "
|   << onlyfile
|   << " in the dep file"
|   << endl;
| 
| Is there a reason for doing this? Is it a remnant from the time when

| we compared modification times only?
| 
| Now that we have CRC, looking for updated aux file seems to be the

| best way to see whether LaTeX should be re-run.
| 
| Am I missing something?


I cannot really remember why it ended up like it is now, but I suspect
that there is some issues with the .aux file.

I though latex gave a message that thre is unresolved citations? We
should trigger on that and do another latex run.


gives an endless loop when the \cite{foo} points to a _non existing_
bibtex entry

Herbert

Re: Problem with INSTALL.Win32 -

[Abdelrazak Younes]

Jean-Marc Lasgouttes a écrit :

"Joost" == Joost Verburg <[EMAIL PROTECTED]> writes:


Joost> However, the Windows build scripts also do not work in the
Joost> current state. The reason is that automake 1.9 is not yet
Joost> available for Windows. Currently I can only get it to compile
Joost> using automake in a Cygwin environment and a modified build
Joost> script that doesn't call automake.

So, what is the situation wrt windows?


Building of svn version with current MSYS DTK is not possible because of 
old automake. But I guess that automake is not required for building a 
released candidate.
Reading the user list, I see that some people managed to use Cygwin for 
that task too (using Qtwin port without X). So it's up to the packager 
to choose that way of the other.



Who is planning to provide
binaries?


For Msys/mingw binaries, I might be able to help if needed. Packaging is 
something else... Uwe might propose something and Angus might come out 
of his retirement ;-). I can see some well positioned outsiders (Enrico? 
Michael?).


Abdel.

Re: Can't make a working lyx-1.4 on amd64 anymore - what could be wrong?

[Felix-Antoine Bourbonnais]

>> libc6 2.3.6-1
>> libstdc++6 4.0.2-9
>> libqt3-mt 3:3.3.5-3
>>  
>>
> What compiler do you use? I use gcc-4.0.3 which has been fine
> for lots of earlier lyxes.

g++-4.0 4.0.2-9 [g++ (GCC) 4.0.3 20060212 (prerelease) (Debian 4.0.2-9)]
gcc-4.0 4.0.2-9 [gcc (GCC) 4.0.3 20060212 (prerelease) (Debian 4.0.2-9)]
libstdc++5-3.3-dev 1:3.3.6-12
libstdc++6-4.0-dev 4.0.2-9
libstdc++6-dev 3.4.5-2

-- 
Félix-Antoine Bourbonnais



signature.asc
Description: OpenPGP digital signature

Re: LyX, BibTeX and dependencies

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| I noticed today that bibtex-supported citations do not work (giving
| [?]) when doing the first View>DVI. The reason is simple: LyX runs
| latex, then bibtex, then latex again. Therefore, since bibliography is
| at the end of the document, the \cite macros do not see the correct
| values from BibTeX's .bbl file.
| 
| A natural way of doing this would be to see whether the .aux file has
| changed. It turns out that this aux file is explicitely not tracked:
| 
|   // (2) foundfile is in the tmpdir
|   // insert it into head
|   if (fs::exists(onlyfile)) {
|   static regex unwanted("^.*\\.(aux|log|dvi|bbl|ind|glo)$");
|   if (regex_match(onlyfile, unwanted)) {
|   lyxerr[Debug::DEPEND]
|   << "We don't want "
|   << onlyfile
|   << " in the dep file"
|   << endl;
| 
| Is there a reason for doing this? Is it a remnant from the time when
| we compared modification times only?
| 
| Now that we have CRC, looking for updated aux file seems to be the
| best way to see whether LaTeX should be re-run.
| 
| Am I missing something?

I cannot really remember why it ended up like it is now, but I suspect
that there is some issues with the .aux file.

I though latex gave a message that thre is unresolved citations? We
should trigger on that and do another latex run.

-- 
Lgb

Re: Strange Subversion error

[Felix-Antoine Bourbonnais]

>> Full disk?
> 
> No, very unlikely as I kept going by checking out another copy to a
> different directory without deleteing the first one.
> 

Try the command svn cleanup on your working copy. Maybe it can help.

-- 
Félix-Antoine Bourbonnais




signature.asc
Description: OpenPGP digital signature

LyX, BibTeX and dependencies

[Jean-Marc Lasgouttes]

I noticed today that bibtex-supported citations do not work (giving
[?]) when doing the first View>DVI. The reason is simple: LyX runs
latex, then bibtex, then latex again. Therefore, since bibliography is
at the end of the document, the \cite macros do not see the correct
values from BibTeX's .bbl file.

A natural way of doing this would be to see whether the .aux file has
changed. It turns out that this aux file is explicitely not tracked:

// (2) foundfile is in the tmpdir
// insert it into head
if (fs::exists(onlyfile)) {
static regex unwanted("^.*\\.(aux|log|dvi|bbl|ind|glo)$");
if (regex_match(onlyfile, unwanted)) {
lyxerr[Debug::DEPEND]
<< "We don't want "
<< onlyfile
<< " in the dep file"
<< endl;

Is there a reason for doing this? Is it a remnant from the time when
we compared modification times only?

Now that we have CRC, looking for updated aux file seems to be the
best way to see whether LaTeX should be re-run.

Am I missing something?

JMarc

Re: Strange Subversion error

[Georg Baum]

Lars Gullik Bjønnes wrote:

> [EMAIL PROTECTED] writes:
> 
> | If no cares about the problem I'll just delete this working copy of the
> | source.
> 
> I would like to know what the problem is, but I think it lies on your
> end. I do not have many ideas on what it could be though.

I have had a similar effect in the past after I interrupted an update with
Ctrl-C because I noticed that I did not really want to update. svn did not
like that interruption at all, but copying over the broken files from
another checkout worked.


Georg

Re: LyX/Mac bundle changes

[Jean-Marc Lasgouttes]

> "Bennett" == Bennett Helm <[EMAIL PROTECTED]> writes:

Bennett> As I noted in a different thread, I've placed a slightly
Bennett> revised version of the LyX/Mac metadata importer here:
Bennett> .
Bennett> Once again, I think this is ready to go in to 1.4.0, though
Bennett> comments would be welcome. (Source files can be found here:
Bennett> .)

You mean that you want to include the compiled importer in LyX source?
But we do not have it currently, do we?

Bennett> Along with the change, I decided to look again at the
Bennett> Info.plist file that is a part of the LyX/Mac application
Bennett> bundle, and found a minor tweak was necessary for
Bennett> consistency; trivial patch attached.

I applied it.

JMarc

LyX/Mac bundle changes

[Bennett Helm]

As I noted in a different thread, I've placed a slightly revised  
version of the LyX/Mac metadata importer here: . Once again, I think  
this is ready to go in to 1.4.0, though comments would be welcome.  
(Source files can be found here: .)


Along with the change, I decided to look again at the Info.plist file  
that is a part of the LyX/Mac application bundle, and found a minor  
tweak was necessary for consistency; trivial patch attached.


Bennett



mac-Info.plist.diff
Description: Binary data

Re: LyX 1.4: Reproducable Crash [more math bug examples]

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

| I propose that we keep the patch as it is now (it fixes the crash and 
| improves a lot mouse positioning) and keep the other
| experimentations for later.

Lars> I agree.

Somehow, I knew you would...

I applied the patch. Only you can resolve the last remaining bug now
:)

JMarc

Re: RELEASE-NOTES

[Jean-Marc Lasgouttes]

> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:

>> - Instant preview figures are sometimes displaced
>> http://bugzilla.lyx.org/show_bug.cgi?id=2167

Bo> I still think the patch for 2167 should be applied. The displaced
Bo> preview figures will be an instant annoyance to users, especially
Bo> when this feature (instant preview) is available in 1.3.x and the
Bo> figures was placed just fine.

It is applied now.

JMarc

Re: LyX 1.4: Reproducable Crash [more math bug examples]

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
| 
| Martin> if you change
| 
| Martin>   if (it != begin()
| 
| Martin> into
| 
| Martin>   if (it != begin() && currx >= targetx
| 
| Martin> I expect Joost will find it behaving slightly better in the
| Martin> situation he complained about. It won't fix everything though.
| 
| I propose that we keep the patch as it is now (it fixes the crash and
| improves a lot mouse positioning) and keep the other experimentations
| for later.
| 
| OK? Lars?

I agree.

-- 
Lgb

Re: [PATCH] for 2167

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

| To be more precise, I propose to apply the following patch.
| 
| Lars?

Lars> If this fixes the problem, then ok.

Yes, I tested it. Committed.

JMarc

Re: LyX 1.4: Reproducable Crash [more math bug examples]

[Lars Gullik Bjønnes]

Joost Verburg <[EMAIL PROTECTED]> writes:

| I'm currently doing some extensive testing with Martin's latest patch.
| Personally I think not being able to position the cursor with the
| mouse between brackets and other things is a major usability bug.
| 
| Now LyX 1.4 has a math toolbar Windows users are finally able to use
| it in a convenient way like other common math editors (MathType etc.).

That is not the convenient way, it is only the way they are used to
doing it. The conveient way IMHO is to use the keyboard and latex
match commands. That is where the real power of mathed lies.

-- 
Lgb

Re: Strange Subversion error

[Lars Gullik Bjønnes]

[EMAIL PROTECTED] writes:

| If no cares about the problem I'll just delete this working copy of the
| source.

I would like to know what the problem is, but I think it lies on your
end. I do not have many ideas on what it could be though.

-- 
Lgb

Re: New Spotlight metadata importer for LyX/Mac

[Bennett Helm]

On Feb 23, 2006, at 12:49 PM, [EMAIL PROTECTED] wrote:


...

Incidentally, the last importer had a generic bundle identifier which
caused (at least I think) the indexer to repeadedly crash. I can't  
check
the new importer right now, but if you forgot (again) to give it a  
unique

bundle ID, I would do so =)


Aha! That explains the crashes. I've made the change and placed a new  
version of the binary here: . I've also put the source files for the  
XCode project on the wiki here: . If you can, please check to make  
sure I haven't made any other stupid mistakes.


Bennett


I've got a new version of the Spotlight metadata importer for LyX/
Mac, largely copied (with permission) from Norm Gall's LaTeX metadata
importer (). The main improvement over my old code is that the new
version will find not just the text of the file but also the author
and title fields; I've also compiled it as a universal binary (for
PowerPC and Intel Macs). I've tested it pretty extensively (at least
on PowerPC; I don't have access to an Intel Mac) and think it's ready
to go in for 1.4.0.

The file can be found at  and should be unzipped and placed within the
LyX/Mac application bundle at development/MacOSX/LyX.app/Contents/
Library/Spotlight/, replacing the existing binary.

At this point, I'm wondering what to do with the source code for
this, which I'd be more than happy for others to look at and improve.
It's an XCode project, so it doesn't make much sense to include it
with the LyX source (does it?). Shall I just throw it up on the wiki,
linked off the LyXonMac page?

Bennett

Re: [PATCH] for 2167 (was: Re: RELEASE-NOTES)

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| > "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| 
| > "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
| >>> - Instant preview figures are sometimes displaced
| >>> http://bugzilla.lyx.org/show_bug.cgi?id=2167
| 
| Bo> I still think the patch for 2167 should be applied. The displaced
| Bo> preview figures will be an instant annoyance to users, especially
| Bo> when this feature (instant preview) is available in 1.3.x and the
| Bo> figures was placed just fine.
| 
| Jean-Marc> I agree. We should keep the other part of the patch for
| Jean-Marc> later.
| 
| To be more precise, I propose to apply the following patch.
| 
| Lars?

If this fixes the problem, then ok.

-- 
Lgb

Re: Strange Subversion error

[christian . ridderstrom]

On 24 Feb 2006, Lars Gullik Bjønnes wrote:

> [EMAIL PROTECTED] writes:
> 
> | Hi
> | 
> | I just tried to update my checked out copy of the source... what's this:
> | 
> | black01:lyx-devel>svn update
> | svn: Can't open 'm4/.svn/tmp/text-base/intmax.m4.svn-base.tmp': No such 
> | file or directory
> | 
> | 
> | I'm guessing this shouldn't really happen, but I'll just delete it and 
> | keep going.
> 
> Full disk?

No, very unlikely as I kept going by checking out another copy to a
different directory without deleteing the first one.

I tried again just now in case:

black01:lyx-devel>svn update
svn: Can't open 'src/.svn/tmp/text-base/pspell.C.svn-base.tmp': No such 
file or directory

black01:lyx-devel>df -h .
FilesystemSize  Used Avail Use% Mounted on
/dev/sda2  16G  7.5G  7.2G  52% /

This doesn't really matter to me, but maybe it'd be good to find out what 
the problem is...

As for the file 'src/.svn/tmp/text-base/pspell.C.svn-base.tmp', there is 
no such file:
black01:.svn>pwd; ls -lRa
/tmp/chr-lyx/lyx-devel/src/.svn
.:
total 92
drwxrwxr-x   2 chr mmkstaff  4096 Feb 24 14:59 ./
drwxrwxr-x  10 chr mmkstaff 12288 Feb 12 16:07 ../
-r--r--r--   1 chr mmkstaff   190 Feb 12 14:34 dir-props
-r--r--r--   1 chr mmkstaff 65038 Feb 21 21:31 entries
-r--r--r--   1 chr mmkstaff 2 Feb 12 14:34 format

If no cares about the problem I'll just delete this working copy of the
source.

regards
/Christian

-- 
Christian Ridderström, +46-8-768 39 44   http://www.md.kth.se/~chr

Re: LyX 1.4: Reproducable Crash [more math bug examples]

[Georg Baum]

Jean-Marc Lasgouttes wrote:

>> "Georg" == Georg Baum
>> <[EMAIL PROTECTED]>
>> writes:
> 
> Georg> Jean-Marc Lasgouttes wrote:
>>> So let's fix the crashes and release.
> 
> Georg> Yes please. BTW, what do you think of bug 2316? I am a bit
> Georg> unsure if it should go in 1.4.0 or not. PRO: LyX can produce
> Georg> invalid files without a fix. CON: It still needs testing, and I
> Georg> don't want to delay a release at all.
> 
> You mean it can produce invalid LaTeX files, right?

No, AFAIK that is not possible since it has a hand crafted char by char
latex output. I mean invalid .lyx files.

> A quick workaround 
> would be the part of your patch that handles output of LyXFont when
> language is latex_language. This is something that makes sense anyway.

That would actually not be enough, because the language can be set to
something else without the other parts of the fix, and that other language
would then be written.

> It seems to me from your discussions with Martin that the complete fix
> is not very clear yet :)

I think it is clear now. A combination of Martins and my patches would fix
all problems. What is missing now is the actual patch and testing.


Georg

[PATCH] for 2167 (was: Re: RELEASE-NOTES)

[Jean-Marc Lasgouttes]

> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>>> - Instant preview figures are sometimes displaced
>>> http://bugzilla.lyx.org/show_bug.cgi?id=2167

Bo> I still think the patch for 2167 should be applied. The displaced
Bo> preview figures will be an instant annoyance to users, especially
Bo> when this feature (instant preview) is available in 1.3.x and the
Bo> figures was placed just fine.

Jean-Marc> I agree. We should keep the other part of the patch for
Jean-Marc> later.

To be more precise, I propose to apply the following patch.

Lars?

JMarc

Index: lib/ChangeLog
===
--- lib/ChangeLog	(revision 13268)
+++ lib/ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2006-02-24  Enrico Forestieri  <[EMAIL PROTECTED]>
+
+	* scripts/legacy_lyxpreview2ppm.py (extract_metrics_info): 
+	* scripts/lyxpreview2bitmap.py (extract_metrics_info): fix
+	computation when either ascent or descent is 0. (bug 2167)
+
 2006-02-19  Enrico Forestieri  <[EMAIL PROTECTED]>
 
 	* scripts/lyxpreview2bitmap.py: fix script to work with recent versions
Index: lib/scripts/lyxpreview2bitmap.py
===
--- lib/scripts/lyxpreview2bitmap.py	(revision 13268)
+++ lib/scripts/lyxpreview2bitmap.py	(working copy)
@@ -103,7 +103,7 @@
 ascent  = string.atof(match.group(2))
 
 frac = 0.5
-if ascent > 0 and descent > 0:
+if ascent >= 0 and descent >= 0:
 if abs(ascent + descent) > 0.1:
 frac = ascent / (ascent + descent)
 
Index: lib/scripts/legacy_lyxpreview2ppm.py
===
--- lib/scripts/legacy_lyxpreview2ppm.py	(revision 13268)
+++ lib/scripts/legacy_lyxpreview2ppm.py	(working copy)
@@ -95,7 +95,7 @@
 descent = string.atoi(match.group(3))
 
 frac = 0.5
-if ascent > 0 and descent > 0:
+if ascent >= 0 and descent >= 0:
 ascent = float(ascent) + tp_ascent
 descent = float(descent) - tp_descent
 

Re: LyX 1.4: Reproducable Crash [more math bug examples]

[Jean-Marc Lasgouttes]

> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:

Georg> Jean-Marc Lasgouttes wrote:
>> So let's fix the crashes and release.

Georg> Yes please. BTW, what do you think of bug 2316? I am a bit
Georg> unsure if it should go in 1.4.0 or not. PRO: LyX can produce
Georg> invalid files without a fix. CON: It still needs testing, and I
Georg> don't want to delay a release at all.

You mean it can produce invalid LaTeX files, right? A quick workaround
would be the part of your patch that handles output of LyXFont when
language is latex_language. This is something that makes sense anyway.

It seems to me from your discussions with Martin that the complete fix
is not very clear yet :)

JMarc

Re: One more patch

[Joost Verburg]

Martin Vermeer wrote:

On Fri, 2006-02-24 at 12:45 +0100, Jean-Marc Lasgouttes wrote:

"Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:

Martin> BTW Jean-Marc, this works, but would it perhaps be better to
Martin> make MathNestInset inherit (from InsetBase) and modify
Martin> covers(x,y)?

What is the idea BTW? That nestinsets have a margin around them? So it
depends why one uses covers() (real area covered vs. mouse accesible
area).


It seems to be only used (in text2 and nestinset) to detect whether the
mouse has hit it (and then respond accordingly). It is thus certainly
possible to have the "mouse sensitive area" differ from the drawn area
of the inset.

I only want an "inert zone" on the left edge of 2 pixels wide. Then, if
you click there, you will not descend into the inset, but the cursor
will end up -- on current slice depth -- on the inset's left side. That
solves the ")(" problem.

- Martin



This new patch is great, things are really becoming better!

It looks like it fixes all issues, it only needs a bit of fine-tuning. I 
think the area that is currently 2 pixels should be larger. If possible, 
it should be the complete area between the brackets. Currently you have 
to click very close to ( in order to get cursor between ) and (.


The area could also overlap a bit with the left side of the ( bracket. 
Try clicking between two ordinary characters, say a and b (ab). Clicking 
on the left side of b still gets the cursor between a and b.


The same thing applies to clicking on the right side of the last 
bracket. There are a few pixels between the bracket and the position 
where you can click to get the mouse there. If the bracket is the last 
part of the equation there is only about 1 pixel left to click on.


Joost

Re: [PATCH] fix crash with case-changing LFUNs at end of paragraph

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

| Lars, may I apply?

Lars> Yes.

Done.

JMarc

Re: Fwd: Re: Another way to an assert

[Jean-Marc Lasgouttes]

> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:

| Lars, can I apply that?

Lars> Ok.

Done.

JMarc

Re: Fix for 2316 in bugzilla

[Georg Baum]

Martin Vermeer wrote:

> So, if you create an ERT and start typing, OK. But if you then delete
> all the text in the ERT, and start typing again, init() will not be
> executed again. Anything that in the meantime changes
> text_.current_font / text_.real_current_font (these are very ephemeral!)
> will lead to the new text getting the wrong language. E.g., creating a
> new paragraph will use the buffer language.

Now I see. I was not aware that text_.current_font / text_.real_current_font
could change at all. Thanks for the explanation. The "correct fix" is of
course to make these data members private and ensure that they can't be
changed from outside.


Georg

Re: Fwd: Re: Another way to an assert

[Lars Gullik Bjønnes]

Juergen Spitzmueller <[EMAIL PROTECTED]> writes:

| > "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| 
| Juergen> Jean-Marc Lasgouttes wrote:
| >> Am I right that this is the fix?
| 
| Juergen> Yes. Very fast!
| 
| :)
| 
| Lars, can I apply that?

Ok.

-- 
Lgb

Re: Fix for 2316 in bugzilla

[Martin Vermeer]

On Fri, 2006-02-24 at 13:00 +0100, Georg Baum wrote:
> Martin Vermeer wrote:
> 
> > On Fri, 2006-02-24 at 11:43 +0100, Georg Baum wrote:
> >> Martin Vermeer wrote:
> >> > My patch places a
> >> > current_cursor stanza into doDispatch/default for this. If you do this,
> >> > you can again dump the corresponding stanza in init().
> >> 
> >> I don't understand the reason for putting it there. Why change the font
> >> for every invocation of doDispatch and not once in the constructor? Can
> >> it be changed from outside?
> > 
> > What happens is that the current cursor font is set to latex_language.
> 
> You do set the fonts of text_. LCursor::getFont() then somehow has access to
> these.
> 
> > When you then type a character, it will go through the dispatch chain to
> > the inner LyXText, and will be inserted with this font(*)... unless it
> > is surrounded by text having a different language, as you correctly
> > observe above(+). But if we have closed all holes, that can never
> > happen.
> 
> What I still do not understand is why you set the text_ fonts in doDispatch,
> and if it could make a difference if they were set in init().

The difference is that doDispatch is traversed every time you insert a
character. init() only upon inset construction.

So, if you create an ERT and start typing, OK. But if you then delete
all the text in the ERT, and start typing again, init() will not be
executed again. Anything that in the meantime changes
text_.current_font / text_.real_current_font (these are very ephemeral!)
will lead to the new text getting the wrong language. E.g., creating a
new paragraph will use the buffer language.

> I am currently trying to understand the theory. I will actually try out your
> patch later (when I have reinstalled my laptop. The harddisk died, but
> fortunately the last backup was not too old (10 days), and the stuff that
> was changed after that backup could still be read).

Oops.

- Martin



signature.asc
Description: This is a digitally signed message part

Re: Strange Subversion error

[Lars Gullik Bjønnes]

[EMAIL PROTECTED] writes:

| Hi
| 
| I just tried to update my checked out copy of the source... what's this:
| 
| black01:lyx-devel>svn update
| svn: Can't open 'm4/.svn/tmp/text-base/intmax.m4.svn-base.tmp': No such 
| file or directory
| 
| 
| I'm guessing this shouldn't really happen, but I'll just delete it and 
| keep going.

Full disk?

-- 
Lgb

Re: [PATCH] fix crash with case-changing LFUNs at end of paragraph

[Lars Gullik Bjønnes]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

| 1. new document
| 2. M-c Right (or any other case changing lfun)
| 3. Crash.
| 
| and of course
| 
| 4. patch attached.
| 
| The real fix is the last hunk (setCursor tries to go to a place that
| does not exist). The rest (which is trivial) fixes the logic of
| cursorRightOneWord so that it goes to the beginning to the next word
| (vs. end of current word). This is what OO.o does.
| 
| Please test.
| 
| Lars, may I apply?

Yes.

-- 
Lgb

Re: One more patch

[Martin Vermeer]

On Fri, 2006-02-24 at 12:45 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> 
> Martin> BTW Jean-Marc, this works, but would it perhaps be better to
> Martin> make MathNestInset inherit (from InsetBase) and modify
> Martin> covers(x,y)?
> 
> What is the idea BTW? That nestinsets have a margin around them? So it
> depends why one uses covers() (real area covered vs. mouse accesible
> area).

It seems to be only used (in text2 and nestinset) to detect whether the
mouse has hit it (and then respond accordingly). It is thus certainly
possible to have the "mouse sensitive area" differ from the drawn area
of the inset.

I only want an "inert zone" on the left edge of 2 pixels wide. Then, if
you click there, you will not descend into the inset, but the cursor
will end up -- on current slice depth -- on the inset's left side. That
solves the ")(" problem.

- Martin



signature.asc
Description: This is a digitally signed message part

Re: LyX 1.4: Reproducable Crash [more math bug examples]

[Georg Baum]

Jean-Marc Lasgouttes wrote:

> So let's fix the crashes and release.

Yes please. BTW, what do you think of bug 2316? I am a bit unsure if it
should go in 1.4.0 or not.
PRO: LyX can produce invalid files without a fix.
CON: It still needs testing, and I don't want to delay a release at all.

> PS: of course, I just said I think the instant preview fix should go
> in, but this one is both embarrassing and with  clear fix.

I agree, too.


Georg

Re: Fix for 2316 in bugzilla

[Georg Baum]

Martin Vermeer wrote:

> On Fri, 2006-02-24 at 11:43 +0100, Georg Baum wrote:
>> Martin Vermeer wrote:
>> > My patch places a
>> > current_cursor stanza into doDispatch/default for this. If you do this,
>> > you can again dump the corresponding stanza in init().
>> 
>> I don't understand the reason for putting it there. Why change the font
>> for every invocation of doDispatch and not once in the constructor? Can
>> it be changed from outside?
> 
> What happens is that the current cursor font is set to latex_language.

You do set the fonts of text_. LCursor::getFont() then somehow has access to
these.

> When you then type a character, it will go through the dispatch chain to
> the inner LyXText, and will be inserted with this font(*)... unless it
> is surrounded by text having a different language, as you correctly
> observe above(+). But if we have closed all holes, that can never
> happen.

What I still do not understand is why you set the text_ fonts in doDispatch,
and if it could make a difference if they were set in init().
I am currently trying to understand the theory. I will actually try out your
patch later (when I have reinstalled my laptop. The harddisk died, but
fortunately the last backup was not too old (10 days), and the stuff that
was changed after that backup could still be read).


Georg

Re: LyX 1.4: Reproducable Crash [more math bug examples]

[Jean-Marc Lasgouttes]

> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes:

Joost> I'm currently doing some extensive testing with Martin's latest
Joost> patch. Personally I think not being able to position the cursor
Joost> with the mouse between brackets and other things is a major
Joost> usability bug.

I agree it is an usability bug. I want it fixed in 1.4.1. 

However, the bug you reported (the crash) is a perfect example of the
things we are going to receive after 1.4.0 release. The sooner we
release, the sooner we get all these nasty bug reports.

Not being able to click at some point is very annoying, sure, but it
is not comparable to crashing LyX.

So let's fix the crashes and release.

JMarc

PS: of course, I just said I think the instant preview fix should go
in, but this one is both embarrassing and with  clear fix.

Re: LyX 1.4: Reproducable Crash [more math bug examples]

[Jean-Marc Lasgouttes]

> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:

Martin> If you say so... what did you say the bug number was?

1918.

JMarc

Re: One more patch

[Jean-Marc Lasgouttes]

> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:

Martin> BTW Jean-Marc, this works, but would it perhaps be better to
Martin> make MathNestInset inherit (from InsetBase) and modify
Martin> covers(x,y)?

What is the idea BTW? That nestinsets have a margin around them? So it
depends why one uses covers() (real area covered vs. mouse accesible
area).

JMarc

Re: LyX 1.4: Reproducable Crash [more math bug examples]

[Joost Verburg]

Jean-Marc Lasgouttes wrote:

"Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:


Martin> if you change

Martin>  if (it != begin()

Martin> into

Martin>  if (it != begin() && currx >= targetx

Martin> I expect Joost will find it behaving slightly better in the
Martin> situation he complained about. It won't fix everything though.

I propose that we keep the patch as it is now (it fixes the crash and
improves a lot mouse positioning) and keep the other experimentations
for later.

OK? Lars?

JMarc



I'm currently doing some extensive testing with Martin's latest patch. 
Personally I think not being able to position the cursor with the mouse 
 between brackets and other things is a major usability bug.


Now LyX 1.4 has a math toolbar Windows users are finally able to use it 
in a convenient way like other common math editors (MathType etc.). It 
would be a pity if that is broken by this bug since it looks like it can 
be fixed easily.


Joost

Re: LyX 1.4: Reproducable Crash [more math bug examples]

[Martin Vermeer]

On Fri, 2006-02-24 at 12:20 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> 
> Martin> if you change
> 
> Martin>   if (it != begin()
> 
> Martin> into
> 
> Martin>   if (it != begin() && currx >= targetx
> 
> Martin> I expect Joost will find it behaving slightly better in the
> Martin> situation he complained about. It won't fix everything though.
> 
> I propose that we keep the patch as it is now (it fixes the crash and
> improves a lot mouse positioning) and keep the other experimentations
> for later.
> 
> OK? Lars?

If you say so... what did you say the bug number was?

- Martin



signature.asc
Description: This is a digitally signed message part

Re: One more patch

[Jean-Marc Lasgouttes]

> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:

Martin> With the attached patch added, you will be even able to do
Martin> that :-)

Martin> BTW Jean-Marc, this works, but would it perhaps be better to
Martin> make MathNestInset inherit (from InsetBase) and modify
Martin> covers(x,y)?

Could you open a specific bug for that? We are not going to fix all
mouse bugs right now, anyway...

JMarc

Re: RELEASE-NOTES

[Jean-Marc Lasgouttes]

> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:

>> - Instant preview figures are sometimes displaced
>> http://bugzilla.lyx.org/show_bug.cgi?id=2167

Bo> I still think the patch for 2167 should be applied. The displaced
Bo> preview figures will be an instant annoyance to users, especially
Bo> when this feature (instant preview) is available in 1.3.x and the
Bo> figures was placed just fine.

I agree. We should keep the other part of the patch for later.

JMarc

Re: RELEASE-NOTES

[Abdelrazak Younes]

Georg Baum a écrit :

Abdelrazak Younes wrote:


Abdelrazak Younes a écrit :

Michael Gerz a écrit :

- Bookmarks and links to LaTeX errors are broken after paragraph
deletion/insertion
 http://bugzilla.lyx.org/show_bug.cgi?id=2284

For this one, Lyx open the document, the second line is selected and a
nice "Lyx Parse Error" dialog says:

Unknown token: \syntaxerror \end_layout

Click on OK and you can continue editing.


Of course. The purpose of this report was to show that the paragraph ids are
wrong, and that this matters for the error dialog.


This is very nice compared to some other tools that says the file is 
corrupted and that's it. What's also nice is that I don't remember 
putting time into porting this error dialog but it just _work_! :-)


Thanks,
Abdel.

Re: Fix for 2316 in bugzilla

[Martin Vermeer]

On Fri, 2006-02-24 at 11:43 +0100, Georg Baum wrote:
> Martin Vermeer wrote:
> 
> > Hmmm... does this cover the case where you create an ERT, insert some
> > text, delete this text again and insert some new text?
> 
> I don't remember if I tried that (will try later)

Please do ;-)

> , but I think that it
> covers that case. My theory is: The font of newly inserted text at the end
> of a paragraph is the font of the last dummy font change in that paragraph.

Yes

> New paragraphs inherit the font of the owning LyXText.

I am skeptical of this.

>  Text inserted in the
> middle of a paragraph gets of course the font that is active there.
> If this theory is correct, then my patch will always work.
> 
> > My patch places a 
> > current_cursor stanza into doDispatch/default for this. If you do this,
> > you can again dump the corresponding stanza in init().
> 
> I don't understand the reason for putting it there. Why change the font for
> every invocation of doDispatch and not once in the constructor? Can it be
> changed from outside?

What happens is that the current cursor font is set to latex_language.
When you then type a character, it will go through the dispatch chain to
the inner LyXText, and will be inserted with this font(*)... unless it
is surrounded by text having a different language, as you correctly
observe above(+). But if we have closed all holes, that can never
happen.

- Martin

(*) This works, I tested. If it didn't work, the init() stanza wouldn't
work either.

(+) I'm not actually sure of this... (real_)current_font may take
priority anyway.



signature.asc
Description: This is a digitally signed message part

Re: [PATCH] fix crash with case-changing LFUNs at end of paragraph

[Jean-Marc Lasgouttes]

> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:

Jean-Marc> The real fix is the last hunk (setCursor tries to go to a
Jean-Marc> place that does not exist). The rest (which is trivial)
Jean-Marc> fixes the logic of cursorRightOneWord so that it goes to
Jean-Marc> the beginning to the next word (vs. end of current word).
Jean-Marc> This is what OO.o does.

This is now bug 2323.

JMarc

Re: LyX 1.4: Reproducable Crash [more math bug examples]

[Jean-Marc Lasgouttes]

> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:

Martin> if you change

Martin> if (it != begin()

Martin> into

Martin> if (it != begin() && currx >= targetx

Martin> I expect Joost will find it behaving slightly better in the
Martin> situation he complained about. It won't fix everything though.

I propose that we keep the patch as it is now (it fixes the crash and
improves a lot mouse positioning) and keep the other experimentations
for later.

OK? Lars?

JMarc

Re: Minor patch for INSTALL, s/CVS/Subversion/

[Jean-Marc Lasgouttes]

> "christian" == christian ridderstrom <[EMAIL PROTECTED]> writes:

christian> Hi, here's a minor patch for INSTALL which changes CVS
christian> references into Subverison references.

Thanks.

christian> Are these version requirements correct btw?

christian>If you have checked this out from Subversion, you need
christian> to have: * automake >= 1.9 * autoconf >= 2.52 * gettext >=
christian> 0.12

I think so.

JMarc

Re: Problem with INSTALL.Win32 -

[Jean-Marc Lasgouttes]

> "Joost" == Joost Verburg <[EMAIL PROTECTED]> writes:

Joost> However, the Windows build scripts also do not work in the
Joost> current state. The reason is that automake 1.9 is not yet
Joost> available for Windows. Currently I can only get it to compile
Joost> using automake in a Cygwin environment and a modified build
Joost> script that doesn't call automake.

So, what is the situation wrt windows? Who is planning to provide
binaries? How?

JMarc

Re: Problem with INSTALL.Win32 -

[Jean-Marc Lasgouttes]

> "christian" == christian ridderstrom <[EMAIL PROTECTED]> writes:

christian> Hi, I think INSTALL.Win32 is seriously out of date and
christian> needs to be looked over by someonw who knows this stuff...
christian> Here's a patch where I'm *guessing* - it should *not* be
christian> applied as it is.

Well, it seems to make sense. Could some windows person comment?

christian> PS. The patch seems difficult for me to read, so if there's
christian> some magical options I need to give to 'svn diff', please
christian> let me know!

No, it's OK.

JMarc

Re: The file NEWS is ok regarding CVS vs Subversion

[Jean-Marc Lasgouttes]

> "christian" == christian ridderstrom <[EMAIL PROTECTED]> writes:

christian> However, I wonder: Should this file contain a paragraph
christian> saying that as of LyX 1.4.0pre??? the version control
christian> system has been changed to Subversion? It's not strictly
christian> related to LyX versions, but maybe it's useful anyway?

I do not think it is relevant.

JMarc

Re: RELEASE-NOTES

[Jean-Marc Lasgouttes]

> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:

Michael> Absolutely! And Abdel's patch would remove the other two bugs
Michael> + speed up + ?.

Abdel's patch is not going in 1.4.0. The code as not been seriously
reviewed and nobody besides Abdel did test it.

This said, assuming that it has been well tested and it is in a shape
that satisfies Lars, it _may_ go in 1.4.1.

JMarc

Re: RELEASE-NOTES

[Georg Baum]

Abdelrazak Younes wrote:

> Abdelrazak Younes a écrit :
>> Michael Gerz a écrit :
>>> - Bookmarks and links to LaTeX errors are broken after paragraph
>>> deletion/insertion
>>>  http://bugzilla.lyx.org/show_bug.cgi?id=2284
> 
> For this one, Lyx open the document, the second line is selected and a
> nice "Lyx Parse Error" dialog says:
> 
> Unknown token: \syntaxerror \end_layout
> 
> Click on OK and you can continue editing.

Of course. The purpose of this report was to show that the paragraph ids are
wrong, and that this matters for the error dialog.


Georg

Re: RELEASE-NOTES

[Jean-Marc Lasgouttes]

> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:

Abdelrazak> Abdelrazak Younes a écrit :
>> Michael Gerz a écrit :
>>> - Bookmarks and links to LaTeX errors are broken after paragraph
>>> deletion/insertion http://bugzilla.lyx.org/show_bug.cgi?id=2284
>>> http://bugzilla.lyx.org/show_bug.cgi?id=2242

Abdelrazak> I cannot reproduce bug 2242 with my patch :-) 

That is to be expected, indeed.

JMarc

Re: Problem with INSTALL.Win32 -

[Joost Verburg]

[EMAIL PROTECTED] wrote:

Hi,

I think INSTALL.Win32 is seriously out of date and needs to be looked over
by someonw who knows this stuff... Here's a patch where I'm *guessing* -
it should *not* be applied as it is.


INSTALL.Win32 is indeed outdated. It also points to the old kde-cygwin.

However, the Windows build scripts also do not work in the current 
state. The reason is that automake 1.9 is not yet available for Windows. 
Currently I can only get it to compile using automake in a Cygwin 
environment and a modified build script that doesn't call automake.


Joost

Re: Fix for 2316 in bugzilla

[Georg Baum]

Martin Vermeer wrote:

> Hmmm... does this cover the case where you create an ERT, insert some
> text, delete this text again and insert some new text?

I don't remember if I tried that (will try later), but I think that it
covers that case. My theory is: The font of newly inserted text at the end
of a paragraph is the font of the last dummy font change in that paragraph.
New paragraphs inherit the font of the owning LyXText. Text inserted in the
middle of a paragraph gets of course the font that is active there.
If this theory is correct, then my patch will always work.

> My patch places a 
> current_cursor stanza into doDispatch/default for this. If you do this,
> you can again dump the corresponding stanza in init().

I don't understand the reason for putting it there. Why change the font for
every invocation of doDispatch and not once in the constructor? Can it be
changed from outside?


Georg

Re: Can't make a working lyx-1.4 on amd64 anymore - what could be wrong?

[Georg Baum]

Angus Leeming wrote:

> Helge Hafting <[EMAIL PROTECTED]> writes:
>> How can I know what compiler was used for a library?
>> I tried   strings /usr/lib/libstdc++.so.6.0.7 | grep GCC
>> and got
>> GCC_3.3
>> GCC_3.0
>> So, 3.0 or 3.3?

This test is not suitable to find out which compiler was used. It rather
finds some versioned symbols that are there for compatibility with older
compilers. In fact, if you get GCC_3.3 that means that something newer was
used to compile this lib, either gcc 3.4 or later.
A better test is

dpkg -S /usr/lib/libstdc++.so.6.0.7

that should print the package name and version number of the libstdc++
package.

>> And gcc 4.0 worked fine for such a long time - strange.
> 
> I'd imagine that g++ 4.0 would come with its own libstdc++, no?
> 
> However, in general you should use the same g++ compiler as was used to
> compile those libraries that were compiled with a c++ compiler. In our
> case the biggie is libqt. (Unless you want to build Qt yourself for use
> with LyX.)

The default qt was built with gcc 4.0:
http://pdo.debian.net/unstable/libs/libqt3-mt

> Putting all that to one side, however, didn't Debian unstable go through a
> painful upgrade a few months ago. All their libraries should now be
> compatible with the default g++ compiler, whichever version that is. (I
> forget :()

It is 4.0. See here: http://pdo.debian.net/unstable/devel/gcc

I suggest to do the dpkg -S test with all libraries that are listed in 'ldd
lyx'.


Georg

Re: Can't make a working lyx-1.4 on amd64 anymore - what could be wrong?

[Angus Leeming]

Helge Hafting <[EMAIL PROTECTED]> writes:
> How can I know what compiler was used for a library?
> I tried   strings /usr/lib/libstdc++.so.6.0.7 | grep GCC
> and got
> GCC_3.3
> GCC_3.0
> So, 3.0 or 3.3?   
> And gcc 4.0 worked fine for such a long time - strange.

I'd imagine that g++ 4.0 would come with its own libstdc++, no?

However, in general you should use the same g++ compiler as was used to compile
those libraries that were compiled with a c++ compiler. In our case the biggie
is libqt. (Unless you want to build Qt yourself for use with LyX.)

So, I'd repeat the trick above on libqt. What you're looking for is ABI
compatability between the compiler that was used to compile the library and the
compiler that you're proposing to use to compile LyX. Certainly g++ 3.0 is not
ABI compatible with g++ 4.0. You'll have to do some research for g++ 3.3.

Putting all that to one side, however, didn't Debian unstable go through a
painful upgrade a few months ago. All their libraries should now be compatible
with the default g++ compiler, whichever version that is. (I forget :()

Angus

Re: Can't make a working lyx-1.4 on amd64 anymore - what could be wrong?

[Helge Hafting]

Felix-Antoine Bourbonnais wrote:


Georg Baum wrote:
 


Helge Hafting wrote:


   


I use lyx-1.4 on two linux machines, one i386 and one amd64. Recently,
I have been unable to run the compiled lyx on amd64.
Documents display fine, but lyx usually dies on the first attempt
to change the document. (Keypress, paste, insert->something)
 


A quick test shows no problems here on amd64 (SuSE 10).

   



I'm using LyX 1.4.0svn on a AMD64 with Debian Unstable and all is
working fine.

libc6 2.3.6-1
libstdc++6 4.0.2-9
libqt3-mt 3:3.3.5-3
 


What compiler do you use? I use gcc-4.0.3 which has been fine
for lots of earlier lyxes.

Looking at library versions, I found that libstdc++ and
libgcc1 were indeed wrong versions, they were for gcc 4.1.
So I downgraded them to the same versions as you have here.
Unfortunately, that did not help.  I recompiled lyx
and have exactly the same problem still.

How can I know what compiler was used for a library?
I tried   strings /usr/lib/libstdc++.so.6.0.7 | grep GCC
and got
GCC_3.3
GCC_3.0
So, 3.0 or 3.3?  :-( 
And gcc 4.0 worked fine for such a long time - strange.


Helge Hafting

Re: RELEASE-NOTES

[Abdelrazak Younes]

Abdelrazak Younes a écrit :

Michael Gerz a écrit :
- Bookmarks and links to LaTeX errors are broken after paragraph 
deletion/insertion

 http://bugzilla.lyx.org/show_bug.cgi?id=2284
 http://bugzilla.lyx.org/show_bug.cgi?id=2242


I cannot reproduce bug 2242 with my patch :-)
But maybe I haven't tested enough...

The first time I use bookmark... Very nifty feature!

Abdel.



Michael Gerz a écrit :
Absolutely! And Abdel's patch would remove the other two bugs + speed 
up + ?.


Hello Michael,

Did you verify this? That would be a nice butterfly effect :-)

Abdel.

Re: RELEASE-NOTES

[Abdelrazak Younes]

Abdelrazak Younes a écrit :

Michael Gerz a écrit :
- Bookmarks and links to LaTeX errors are broken after paragraph 
deletion/insertion

 http://bugzilla.lyx.org/show_bug.cgi?id=2284


For this one, Lyx open the document, the second line is selected and a 
nice "Lyx Parse Error" dialog says:


Unknown token: \syntaxerror \end_layout

Click on OK and you can continue editing.

Abdel.



 http://bugzilla.lyx.org/show_bug.cgi?id=2242


Michael Gerz a écrit :
Absolutely! And Abdel's patch would remove the other two bugs + speed 
up + ?.


Hello Michael,

Did you verify this? That would be a nice butterfly effect :-)

Abdel.

Re: RELEASE-NOTES

[Abdelrazak Younes]

Michael Gerz a écrit :
- Bookmarks and links to LaTeX errors are broken after paragraph 
deletion/insertion

 http://bugzilla.lyx.org/show_bug.cgi?id=2284
 http://bugzilla.lyx.org/show_bug.cgi?id=2242


Michael Gerz a écrit :
Absolutely! And Abdel's patch would remove the other two bugs + speed up 
+ ?.


Hello Michael,

Did you verify this? That would be a nice butterfly effect :-)

Abdel.

Re: Can LyX 1.4.0 really be built on OS2???

[Jean-Marc Lasgouttes]

> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:

Michael> [EMAIL PROTECTED] wrote:
>> Can LyX 1.4.0 really be built on OS2? If not, perhaps that file
>> should be changed to say that or simply removed.

Michael> No way! The file should be removed.

The file is there for reference, but it is not distributed anymore.

JMarc

Re: Fix for 2316 in bugzilla

[Martin Vermeer]

On Thu, 2006-02-23 at 21:44 +0100, Georg Baum wrote:
> Am Donnerstag, 23. Februar 2006 18:39 schrieb Martin Vermeer:
> > On Thu, Feb 23, 2006 at 06:29:05PM +0100, Jean-Marc Lasgouttes wrote:
> > > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> > > 
> > > >> I did not try the other part.
> > > 
> > > Martin> But that's the actual bug fix! This part is just cosmetic (and
> > > Martin> I have no strong feelings on it, except that the blue line
> > > Martin> might be confusing for some users.)
> > > 
> > > I know :) But I do not have much time right now. And it is for 1.4.1,
> > > right?
> > 
> > No, I would say it's for 1.4.0: we have to prevent a format change.
> 
> I would not call it a format change. I would rather say that LyX can 
> produce invalid files currently. These invalid files can only be fixed 
> with a text editor, not from within LyX.
> 
> > Current 1.4.0svn writes out ERT insets in the buffer language rather
> > than latex_language, but the user doesn't notice until it's too late.
> > 
> > (Georg: correct me if I am wrong on this)
> 
> What you describe is correct, but the fix is not. If fonts in the 
> constructor are changed they should be changed in init(), so that it is 
> done in all constructors. Unfortunately even this is not enough. Load the 
> attached file, and change the document language to english. You will see 
> that everything (including the ERT contents) has the blue underline.
> The reason is that the default paragraph language is the buffer language, 
> and this is used in read() because there is no explicit language set.
> I extended your patch, now the language of ERT content is always forced to 
> "latex".
> I don't like this special language, and I don't like all these silly 
> attempts to enforce "no text parameters" in ERT insets, but I don't see a 
> better fix right now.
> One other possibility would be to always enforce buffer langauge, but that 
> would be mnore fragile, because one would always need to touch all ERT 
> insets when it changes.
> ERT contents should really be stored in a std::string in the long term, 
> but that would be too risky to do now.

Hmmm... does this cover the case where you create an ERT, insert some
text, delete this text again and insert some new text? My patch places a
current_cursor stanza into doDispatch/default for this. If you do this,
you can again dump the corresponding stanza in init().

Your read() stuff looks like it is needed and correct.

- Martin



signature.asc
Description: This is a digitally signed message part

Re: Fix for 2316 in bugzilla

[Georg Baum]

Am Donnerstag, 23. Februar 2006 18:39 schrieb Martin Vermeer:
> On Thu, Feb 23, 2006 at 06:29:05PM +0100, Jean-Marc Lasgouttes wrote:
> > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> > 
> > >> I did not try the other part.
> > 
> > Martin> But that's the actual bug fix! This part is just cosmetic (and
> > Martin> I have no strong feelings on it, except that the blue line
> > Martin> might be confusing for some users.)
> > 
> > I know :) But I do not have much time right now. And it is for 1.4.1,
> > right?
> 
> No, I would say it's for 1.4.0: we have to prevent a format change.

I would not call it a format change. I would rather say that LyX can 
produce invalid files currently. These invalid files can only be fixed 
with a text editor, not from within LyX.

> Current 1.4.0svn writes out ERT insets in the buffer language rather
> than latex_language, but the user doesn't notice until it's too late.
> 
> (Georg: correct me if I am wrong on this)

What you describe is correct, but the fix is not. If fonts in the 
constructor are changed they should be changed in init(), so that it is 
done in all constructors. Unfortunately even this is not enough. Load the 
attached file, and change the document language to english. You will see 
that everything (including the ERT contents) has the blue underline.
The reason is that the default paragraph language is the buffer language, 
and this is used in read() because there is no explicit language set.
I extended your patch, now the language of ERT content is always forced to 
"latex".
I don't like this special language, and I don't like all these silly 
attempts to enforce "no text parameters" in ERT insets, but I don't see a 
better fix right now.
One other possibility would be to always enforce buffer langauge, but that 
would be mnore fragile, because one would always need to touch all ERT 
insets when it changes.
ERT contents should really be stored in a std::string in the long term, 
but that would be too risky to do now.


Georg


2316.lyx
Description: application/lyx
Index: src/insets/insetert.h
===
--- src/insets/insetert.h	(Revision 13270)
+++ src/insets/insetert.h	(Arbeitskopie)
@@ -31,9 +31,11 @@ class InsetERT : public InsetCollapsable
 public:
 	///
 	InsetERT(BufferParams const &, CollapseStatus status = Open);
+#if 0
 	///
 	InsetERT(BufferParams const &,
 		 Language const *, std::string const & contents, CollapseStatus status);
+#endif
 	///
 	~InsetERT();
 	///
@@ -41,6 +43,8 @@ public:
 	///
 	void write(Buffer const & buf, std::ostream & os) const;
 	///
+	void read(Buffer const & buf, LyXLex & lex);
+	///
 	std::string const editMessage() const;
 	///
 	bool insetAllowed(InsetBase::Code code) const;
Index: src/insets/insetert.C
===
--- src/insets/insetert.C	(Revision 13270)
+++ src/insets/insetert.C	(Arbeitskopie)
@@ -58,6 +58,8 @@ void InsetERT::init()
 	font.decSize();
 	font.setColor(LColor::latex);
 	setLabelFont(font);
+	text_.current_font.setLanguage(latex_language);
+	text_.real_current_font.setLanguage(latex_language);
 
 	setInsetName("ERT");
 }
@@ -83,23 +85,19 @@ auto_ptr InsetERT::doClone() 
 }
 
 
+#if 0
 InsetERT::InsetERT(BufferParams const & bp,
 		   Language const *, string const & contents, CollapseStatus status)
 	: InsetCollapsable(bp, status)
 {
-	//LyXFont font(LyXFont::ALL_INHERIT, lang);
-	LyXFont font;
-	getDrawFont(font);
-	string::const_iterator cit = contents.begin();
-	string::const_iterator end = contents.end();
-	pos_type pos = 0;
-	for (; cit != end; ++cit)
-		paragraphs().begin()->insertChar(pos++, *cit, font);
+	LyXFont font(LyXFont::ALL_INHERIT, latex_language);
+	paragraphs().begin()->insert(0, contents, font);
 
 	// the init has to be after the initialization of the paragraph
 	// because of the label settings (draw_label for ert insets).
 	init();
 }
+#endif
 
 
 InsetERT::~InsetERT()
@@ -115,6 +113,30 @@ void InsetERT::write(Buffer const & buf,
 }
 
 
+void InsetERT::read(Buffer const & buf, LyXLex & lex)
+{
+	InsetCollapsable::read(buf, lex);
+
+	// Force default font
+	// This avoids paragraphs in buffer language that would have a
+	// foreign language after a document langauge change, and it ensures
+	// that all new text in ERT gets the "latex" language, since new text
+	// inherits the language from the last position of the existing text.
+	// As a side effect this makes us also robust against bugs in LyX
+	// that might lead to font changes in ERT in .lyx files.
+	LyXFont font(LyXFont::ALL_INHERIT, latex_language);
+	ParagraphList::iterator par = paragraphs().begin();
+	ParagraphList::iterator const end = paragraphs().end();
+	while (par != end) {
+		pos_type siz = par->size();
+		for (pos_type i = 0; i <= siz; ++i) {
+			par->setFont(i, font);
+		}
+		++par;
+	}
+}
+
+
 string const InsetERT::editMessage() const
 {
 	return _("Opened ERT Inset");
@@ -222,8