Re: LyX 1.5 crash while scrolling

[Juergen Spitzmueller]

Georg Baum wrote:
 This smells like a boost thing. Does it happen also if you compile against
 system boost? Do you have that at all? 

No, I haven't installed that currently. Anyway, I think SuSE 10 ships the same 
version than LyX 1.5 (1.33.1).

 Or maybe with the boost directory 
 of 1.4?

How can I compile against that?
What is the procedure anyway? Does it use system boost if it finds it and 
--with-included-boost is not used?

Jürgen

Re: [patch] remove wheel mouse ui from qt2

[Georg Baum]

Juergen Spitzmueller wrote:

 The attached patch finally eliminates the gui element.
 I did not touch qt4, since Abdel is reorganizing the Prefs dialog
 currently. Abdel, while you are at it, could you please remove the wheel
 mouse spinbox?
 
 OK to apply to branch and trunk?

I would think so. Since the system wheel setting is obeyed now it is only
logical to remove this setting in the same release (1.4.1).
It would be nice if you could lookup whether gtk uses this setting at all,
and make a comment in lyxrc.h stating which frontedns actually use
wheel_jump.


Georg

Re: LyX 1.5 crash while scrolling

[Georg Baum]

Juergen Spitzmueller wrote:

 Georg Baum wrote:
 Or maybe with the boost directory
 of 1.4?
 
 How can I compile against that?

I think it would work if you temporarily exchange the boost subdirectory of
LyX with that of 1.4, but I am not sure. Of course you should rerun
autogen.sh etc. and do a full rebuild, because normal file date based
dependency tracking will not work.

 What is the procedure anyway? Does it use system boost if it finds it and
 --with-included-boost is not used?

No, you have to explicitly request --without-included-boost.


Georg

Re: [Pre-Patch] Was: Feature request: Remember the editing location when a file is closed.

[Georg Baum]

Martin Vermeer wrote:

 On Wed, 2006-03-22 at 23:19 -0600, Bo Peng wrote:
 Dear list,
 
 It does not look so difficult to implement this feature so I tried to
 implement it by myself. Attached is my patch. Since I rarely submit a
 patch here so I am afraid that there might be many problems (format,
 logic, bugs). Please have a look and give me some feedbacks.
 
 Format looks OK. The logic is a bit ad-hoc, but that comes with the
 territory.
 
 Others may give detailed feedback on the code.
 
 Many files have been modified:
 
 src/BufferView_pimpl.C
 When a new buffer is loaded, it tries to get last cursor position from
 ref().lastfiles(). When a file is going to be closed, current location
 is saved as bookmark 0, and to ref().lastfiles(). A side effect of
 this is that a file can be re-opened (and to the same location) from
 bookmark 0.

I think that this is a very sensible approach. I would avoid to store this
information in the lyx file itself (privacy). Currently ezxchanging .lyx
files is safe because they don't carry aany hidden information, and I would
like it to stay like that.

 src/lastfiles.C:
 I do not want to change the Files structure so I use a map to store
 position information. lastfile format is changed to id, pos
 filename if position information is available, and filename if not.
 
 Would it be easier to always have the id, pos filename format? And id
 = pos = 0 if no valid info exists, so current behaviour is reproduced?

I agree.

 1. Will invalid paragraph id, pos crash lyx? I mean, if a file is
 saved (with id, pos saved locally), and is modified externally (get a
 revised copy from others), id, pos will no longer be valid and goto
 bookmark 0 will fail.

This should be explicitly handled after the file is read: Check for invalid
bookmarks, and delete them.

 This is a file format change and lyx2lyx must be made to handle it.

Why? I dont' see a format change.

 2. Save position does not seem to work when I quit lyx by closing the
 lyx window. Only close-buffer will do. Where should I handle the close
 event?
 
 Don't bother. That's not the way to leave LyX.

I disagree. I once had to tutor a lab course where a program was used that
did strange things if it was closed via thw close button. It was very hard
to get the students used to that. IMO the close button should t=do exactly
the same as File-Quit. Everything else would confuse users.


Georg

Re: A Cygwin related patch

[Georg Baum]

Enrico Forestieri wrote:

 The attached patch fixes the bug reported here:
 http://thread.gmane.org/gmane.editors.lyx.general/29227
 
 In my intention this is the first of a series of patches aimed at
 polishing the Cygwin target, which I think is lagging behind. Please, tell
 me if this ok with you. I have no problem in maintaining the Cygwin target
 but my time is limited so I cannot guarantee a continuous commitment. I
 will do it time permitting. There should be no big problems, as I think
 the Cygwin users will not be more than those I can count with only one of
 my hands ;-)

This patch looks good. I don't like the other one, because the code in
filetools.C is more complicated, and in this one it is more clear because
of cygwin_path_fix().

 Do you prefer that I file this one on bugzilla?

I think it is there already: http://bugzilla.lyx.org/show_bug.cgi?id=2409 Or
do you fix something else?


Georg

Re: [PATCH] better support for classes that do not define a ToC

[Jose' Matos]

On Wednesday 22 March 2006 20:06, Georg Baum wrote:
 I think you should put that in. Even if we are going to fix the xurrent
 problems it will LyX make more robust wrt incomoplete layout files, which
 is a Good Thing (TM).

  I agree, otherwise layouts looks like black magic for users. Really. :-)
 
 Georg

-- 
José Abílio

Re: Feature request: Remember the editing location when a file is closed.

[Jean-Marc Lasgouttes]

 christian == christian ridderstrom [EMAIL PROTECTED] writes:

christian On Wed, 22 Mar 2006, Bo Peng wrote:
 Dear list,
 
 I am not sure if others will like this idea. When I edit a long
 file, it may be troublesome to locate and continue from where I was
 working on, after the file is re-opened. I would be happy if lyx
 can automatically goes to the page at which lyx was closed.
 
 I can think of two ways to do this:
 
 1. (More intrusive). Remember the location under .lyx and jump to
 it when a lyx file is opened. I think this is what vim is doing.

christian For good or worse, this also means that when working with
christian someone else on the same file (that's sent back and forth,
christian or under version control), you'll open it up where the
christian other person left off...

Not if the data is saved in .lyx/ directory.

 2. (Less intrusive). Save bookmark with the lyx file. A user can
 save bookmark, close the file, and go to the bookmark after the
 file is re-opened.

christian Maybe file a bugzilla report? Or if you're brave, discss
christian which of the options would be best on the user's list :-)

I would not be surprised to see that this bug already exists.

JMarc

Re: Feature request: Remember the editing location when a file is closed.

[Jose' Matos]

On Wednesday 22 March 2006 22:44, [EMAIL PROTECTED] wrote:
 On Wed, 22 Mar 2006, Bo Peng wrote:
  Dear list,
 
  I am not sure if others will like this idea. When I edit a long file,
  it may be troublesome to locate and continue from where I was working
  on, after the file is re-opened. I would be happy if lyx can
  automatically goes to the page at which lyx was closed.
 
  I can think of two ways to do this:
 
  1. (More intrusive). Remember the location under .lyx and jump to it
  when a lyx file is opened. I think this is what vim is doing.

 For good or worse, this also means that when working with someone else on
 the same file (that's sent back and forth, or under version control),
 you'll open it up where the other person left off...

  Lars suggested that those values could be saved on .lyx directory. That 
would serve both purposes. :-)

  2. (Less intrusive). Save bookmark with the lyx file. A user can save
  bookmark, close the file, and go to the bookmark after the file is
  re-opened.

 Maybe file a bugzilla report? Or if you're brave, discss which of the
 options would be best on the user's list :-)

  This feature is orthogonal to the one above. Should bookmarks be persistent?

 /C

-- 
José Abílio

Re: [patch] remove wheel mouse ui from qt2

[Jean-Marc Lasgouttes]

 Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:

Juergen The attached patch finally eliminates the gui element. I did
Juergen not touch qt4, since Abdel is reorganizing the Prefs dialog
Juergen currently. Abdel, while you are at it, could you please
Juergen remove the wheel mouse spinbox?

Juergen OK to apply to branch and trunk?

Definitely yes :)

JMarc

Re: Feature request: Remember the editing location when a file is closed.

[christian . ridderstrom]

On Thu, 23 Mar 2006, Jean-Marc Lasgouttes wrote:

  I can think of two ways to do this:
  
  1. (More intrusive). Remember the location under .lyx and jump to
  it when a lyx file is opened. I think this is what vim is doing.
 
 christian For good or worse, this also means that when working with
 christian someone else on the same file (that's sent back and forth,
 christian or under version control), you'll open it up where the
 christian other person left off...
 
 Not if the data is saved in .lyx/ directory.

Oops... I put my reply under the wrong solution. Just in case it's not
obvious to everybody, my comment should refer to when saving the bookmarks 
to the .lyx-file, not the .lyx-directory.

  2. (Less intrusive). Save bookmark with the lyx file. A user can
  save bookmark, close the file, and go to the bookmark after the
  file is re-opened.

/C

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

Re: [patch] remove wheel mouse ui from qt2

[Juergen Spitzmueller]

Georg Baum wrote:
 I would think so. Since the system wheel setting is obeyed now it is only
 logical to remove this setting in the same release (1.4.1).
 It would be nice if you could lookup whether gtk uses this setting at all,
 and make a comment in lyxrc.h stating which frontedns actually use
 wheel_jump.

I cannot compile gtk.
I have committed the changes to qt2.

Jürgen

Re: A Cygwin related patch

[Enrico Forestieri]

Martin Vermeer [EMAIL PROTECTED] writes:
 
 On Wed, Mar 22, 2006 at 09:29:35PM +, Enrico Forestieri wrote:
  The attached patch fixes the bug reported here:
  http://thread.gmane.org/gmane.editors.lyx.general/29227
  
  In my intention this is the first of a series of patches aimed at polishing
  the Cygwin target, which I think is lagging behind. Please, tell me if this
  ok with you. I have no problem in maintaining the Cygwin target but my time
  is limited so I cannot guarantee a continuous commitment. I will do it time
  permitting. There should be no big problems, as I think the Cygwin users
  will not be more than those I can count with only one of my hands 
 
 You would be amazed by the true number of LyX/Windows users...

I have no doubt, but somehow I have the idea that LyX/Cygwin users are
a niche. However, I maybe wrong.

 Unfortunately I am unable / cannot be bothered to work on that, but I am
 really happy somebody does. LyX adoption benefits greatly by having the
 option of cross-platform collaborative authoring. And some people are
 stuck on Windows.
 
 BTW some of us are hit by symptoms like compulsive hand washing after
 touching Windows. Another reason for admiring you 

I am not any different... I can bear Windows only because of cygwin. With
it, my working environment is not any different from some *nix flavor ;-)

-- 
Enrico

Re: [patch] remove wheel mouse ui from qt2

[Abdelrazak Younes]

Juergen Spitzmueller a écrit :

The attached patch finally eliminates the gui element.
I did not touch qt4, since Abdel is reorganizing the Prefs dialog currently. 


I am done for now with the Prefs reorg. Feel free to modify it (or even 
better process to phase 2 of my reorg ;-)).


I will working on the Citation/AddCitation dialog from now on. Please 
retain any modification on this before I apply my cleanup probably this 
week-end.



Abdel, while you are at it, could you please remove the wheel mouse spinbox?


Done, patch attached (not tested).
I will apply that once I get some spare time to compile and test (if you 
don't beat me at this :-)).


Abdel.



 * src/frontends/qt2/QPrefsDialog.C
 (QPrefsDialog::QPrefsDialog):
 (void QPrefsDialog::apply):
 (void QPrefsDialog::update):
 * src/frontends/qt2/ui/QPrefUI.ui:  remove wheel mouse spin box
(bug 783).

Index: QPrefsDialog.C
===
--- QPrefsDialog.C  (revision 13453)
+++ QPrefsDialog.C  (working copy)
@@ -394,7 +394,6 @@
connect(uiModule-uiFileED, SIGNAL(textChanged(const QString)), this, 
SLOT(change_adaptor()));
connect(uiModule-bindFileED, SIGNAL(textChanged(const QString)), 
this, SLOT(change_adaptor()));
connect(uiModule-cursorFollowsCB, SIGNAL(toggled(bool)), this, 
SLOT(change_adaptor()));
-   connect(uiModule-wheelMouseSB, SIGNAL(valueChanged(int)), this, 
SLOT(change_adaptor()));
connect(uiModule-autoSaveSB, SIGNAL(valueChanged(int)), this, 
SLOT(change_adaptor()));
connect(uiModule-autoSaveCB, SIGNAL(toggled(bool)), this, 
SLOT(change_adaptor()));
connect(uiModule-lastfilesSB, SIGNAL(valueChanged(int)), this, 
SLOT(change_adaptor()));
@@ -1121,7 +1120,6 @@
rc.ui_file = internal_path(uiModule-uiFileED-text());
rc.bind_file = internal_path(uiModule-bindFileED-text());
rc.cursor_follows_scrollbar = uiModule-cursorFollowsCB-isChecked();
-   rc.wheel_jump = uiModule-wheelMouseSB-value();
rc.autosave = uiModule-autoSaveSB-value() * 60;
rc.make_backup = uiModule-autoSaveCB-isChecked();
rc.num_lastfiles = uiModule-lastfilesSB-value();
@@ -1416,7 +1414,6 @@
uiModule-uiFileED-setText(external_path(rc.ui_file));
uiModule-bindFileED-setText(external_path(rc.bind_file));
uiModule-cursorFollowsCB-setChecked(rc.cursor_follows_scrollbar);
-   uiModule-wheelMouseSB-setValue(rc.wheel_jump);
// convert to minutes
int mins(rc.autosave / 60);
if (rc.autosave  !mins)
Index: ui/QPrefUi.ui
===
--- ui/QPrefUi.ui   (revision 13453)
+++ ui/QPrefUi.ui   (working copy)
@@ -1,300 +1,274 @@
-ui version=4.0 stdsetdef=1 
-  author/author
-  comment/comment
-  exportmacro/exportmacro
-  classQPrefUi/class
-  widget class=QWidget name=QPrefUI 
-property name=geometry 
-  rect
-x0/x
-y0/y
-width416/width
-height441/height
-  /rect
-/property
-property name=sizePolicy 
-  sizepolicy
-hsizetype1/hsizetype
-vsizetype1/vsizetype
-horstretch0/horstretch
-verstretch0/verstretch
-  /sizepolicy
-/property
-property name=windowTitle 
-  string/
-/property
-layout class=QVBoxLayout 
-  property name=margin 
-number11/number
-  /property
-  property name=spacing 
+ui version=4.0 
+ author/author
+ comment/comment
+ exportmacro/exportmacro
+ classQPrefUI/class
+ widget class=QWidget name=QPrefUI 
+  property name=geometry 
+   rect
+x0/x
+y0/y
+width416/width
+height441/height
+   /rect
+  /property
+  property name=sizePolicy 
+   sizepolicy
+hsizetype1/hsizetype
+vsizetype1/vsizetype
+horstretch0/horstretch
+verstretch0/verstretch
+   /sizepolicy
+  /property
+  property name=windowTitle 
+   string/
+  /property
+  layout class=QVBoxLayout 
+   property name=margin 
+number11/number
+   /property
+   property name=spacing 
+number6/number
+   /property
+   item
+layout class=QGridLayout 
+ property name=margin 
+  number0/number
+ /property
+ property name=spacing 
+  number6/number
+ /property
+ item row=1 column=2 
+  widget class=QPushButton name=bindFilePB 
+   property name=text 
+stringBamp;rowse.../string
+   /property
+  /widget
+ /item
+ item row=0 column=0 
+  widget class=QLabel name=uiFileLA 
+   property name=text 
+stringamp;User interface file:/string
+   /property
+   property name=buddy 
+cstringuiFileED/cstring
+   /property
+  /widget
+ /item
+ item row=1 column=0 
+  widget class=QLabel name=bindFileLA 
+   property name=text 
+stringamp;Bind file:/string
+   /property
+   

Re: A Cygwin related patch

[Enrico Forestieri]

Georg Baum [EMAIL PROTECTED] writes:
 
 Enrico Forestieri wrote:
 
  The attached patch fixes the bug reported here:
  http://thread.gmane.org/gmane.editors.lyx.general/29227
  
  In my intention this is the first of a series of patches aimed at
  polishing the Cygwin target, which I think is lagging behind. Please, tell
  me if this ok with you. I have no problem in maintaining the Cygwin target
  but my time is limited so I cannot guarantee a continuous commitment. I
  will do it time permitting. There should be no big problems, as I think
  the Cygwin users will not be more than those I can count with only one of
  my hands 
 
 This patch looks good. I don't like the other one, because the code in
 filetools.C is more complicated, and in this one it is more clear because
 of cygwin_path_fix().

Really? I had thought the second one was more cleaner. Actually I had to
figure out that when latex_path() is called for generating the argument
of [EMAIL PROTECTED] it is assumed that a trailing / is present, and the second
patch makes this clear not only for cygwin. On the other hand,
external_path() is almost a no-op for the other OSes, so I don't it is
such an overhead. So, what shall I use?

  Do you prefer that I file this one on bugzilla?
 
 I think it is there already: http://bugzilla.lyx.org/show_bug.cgi?id=2409 Or
 do you fix something else?

Funny, it was not there when I started working on the bug ;-)

-- 
Enrico

Re: A Cygwin related patch

[Jean-Marc Lasgouttes]

 Enrico == Enrico Forestieri [EMAIL PROTECTED] writes:

Enrico Really? I had thought the second one was more cleaner.
Enrico Actually I had to figure out that when latex_path() is called
Enrico for generating the argument of [EMAIL PROTECTED] it is assumed that
Enrico a trailing / is present, and the second patch makes this clear
Enrico not only for cygwin. 

Why shall we assume that? I do not really understand this explicit
check for a trailing slash. I think it should be elsewhere.

JMarc

Re: configure failure... (latest CVS) missing file?

[Jean-Marc Lasgouttes]

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


Lars This is the correct fix.


I applied it.

JMarc

Re: A Cygwin related patch

[Georg Baum]

Enrico Forestieri wrote:

 Really? I had thought the second one was more cleaner. Actually I had to
 figure out that when latex_path() is called for generating the argument
 of [EMAIL PROTECTED] it is assumed that a trailing / is present, and the 
 second
 patch makes this clear not only for cygwin.

[EMAIL PROTECTED] must always be an absolute path (otherwise it would not work
TeX-wise), but why should that matter in LyX?

 On the other hand, 
 external_path() is almost a no-op for the other OSes, so I don't it is
 such an overhead. So, what shall I use?

The overhead does not matter at all here. We have had a lot of path problems
on the different windows flavors. Angus worked hard to resolve these, and
implemented the external/internal path distiction.
If we want to avoid more problems we must keep this distinction and be
always explicit whether a path is external or intrnal.
In the long run we should not juggle with paths as strings, but always use a
path class with external() and internal() methods. This will make the
distinction more clear.

I am not really sure how things work on cygwin. Can we always assume that
all external paths are either windows or posix style? Or do we need posix
paths in some cases and windows paths in others?

 Funny, it was not there when I started working on the bug ;-)

It should have been there a long time ago, but finally somebody did not only
complain on lyx-users and added it.


Georg

Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents

[Helge Hafting]

John McCabe-Dansted wrote:


John If LyX locked files which were open in a still running LyX
John process, that would have saved me some confusion.

Yes, but I am sure this can cause a lot of confusion too...
   



I am not sure why this would cause confusion. You could have a dialog
box warning that Another LyX window has this file open and offer
some of the following alternatives:

* Do not open.
 


fine


* Open read only.
 


fine


* Open anyway.
 


fine, assume the user sorts it out after being warned


* Attempt to kill other LyX window.
 


How?  Killing the process is no good, that process may have
several unsaved documents open.  And it might belong
to another user anyway.

Helge Hafting

Re: [patch] remove wheel mouse ui from qt2

[Georg Baum]

Juergen Spitzmueller wrote:

 I cannot compile gtk.

You don't need to compile it in order to find out whether wheel_jump is used
or not :-)
Anyway, I looked now myself and will commit the attached patch.


GeorgIndex: src/lyxrc.h
===
--- src/lyxrc.h	(Revision 13460)
+++ src/lyxrc.h	(Arbeitskopie)
@@ -238,6 +238,7 @@ public:
 	/// Zoom factor for screen fonts
 	unsigned int zoom;
 	/// parameter for button_4 and button_5 (scrollwheel)
+	/// Only used by the xforms frontend
 	unsigned int wheel_jump;
 	/// Screen font sizes in points for each font size
 	std::string font_sizes[10];

Re: bug 2313: Save should be disabled for unchanged documents

[John McCabe-Dansted]

* Open anyway.
fine, assume the user sorts it out after being warned

Letting the user Open anyway after being warned still seems a lot
better than not warning the user at all. I thought that not letting
the user open the file rw may not be popular in certain quarters...
this was the only reason I could think of that  locking could be
accused of adding confusion.

* Attempt to kill other LyX window.
How?  Killing the process is no good, that process may have
several unsaved documents open.  And it might belong
to another user anyway.

I was thinking of firefox which has a habit of leaving stale processes
around, locking the ~/.firefox directory.  Probably not really useful
for LyX.

On 3/23/06, Helge Hafting [EMAIL PROTECTED] wrote:
 John McCabe-Dansted wrote:

 John If LyX locked files which were open in a still running LyX
 John process, that would have saved me some confusion.
 
 Yes, but I am sure this can cause a lot of confusion too...
 
 
 
 I am not sure why this would cause confusion. You could have a dialog
 box warning that Another LyX window has this file open and offer
 some of the following alternatives:
 
 * Do not open.
 
 
 fine

 * Open read only.
 
 
 fine

 * Open anyway.
 
 
 fine, assume the user sorts it out after being warned

 * Attempt to kill other LyX window.
 
 
 How?  Killing the process is no good, that process may have
 several unsaved documents open.  And it might belong
 to another user anyway.

 Helge Hafting



--
John C. McCabe-Dansted
Master's Student

Re: A Cygwin related patch

[Enrico Forestieri]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
 
  Enrico == Enrico Forestieri [EMAIL PROTECTED] writes:
 
 Enrico Really? I had thought the second one was more cleaner.
 Enrico Actually I had to figure out that when latex_path() is called
 Enrico for generating the argument of \input at path it is assumed that
 Enrico a trailing / is present, and the second patch makes this clear
 Enrico not only for cygwin. 
 
 Why shall we assume that? I do not really understand this explicit
 check for a trailing slash. I think it should be elsewhere.

I saw that the [EMAIL PROTECTED] argument always has a double / appended.
In my eyes this was not wrong because I remember that in kpathsea a
double / signals to also search for subdirectories.

Your post rang an alarm bell for me and I checked the [EMAIL PROTECTED] syntax
and indeed it is not the same as for kpathsea. A single / should be
appended to the path, but it seems that two do not hurt.

Now, as a / was later added to the path, in my mind a / should have
already been in the path. And indeed this is the case: whenever
latex_path() is called to generate the argument of [EMAIL PROTECTED] the
path which is passed always has a / appended.

As I think that one should not fix what is not broken, in my patch I
used that to distinguish when latex_path should generate the argument
of [EMAIL PROTECTED] such that to act on this case only. Not only, as in
cygwin external_path() can remove the trailing slash, I also paid
attention to readd it...

So I now know that the trailing slash is not there on purpose. However,
it is a good flag for signaling latex_path() that a path for [EMAIL PROTECTED]
is to be generated.

Now I think I have two choices:

1) Find in the sources where latex_path() is called for [EMAIL PROTECTED], in
   order to enforce the trailing slash as a flag for this case, and then
   modify the patch such as to later remove it in latex_path().

2) Check if the path passed to latex_path() is a directory. If it is,
   assume that this is the [EMAIL PROTECTED] case and act accordingly.

What do you think is the better choice?

-- 
Enrico

Re: A Cygwin related patch

[Enrico Forestieri]

Georg Baum [EMAIL PROTECTED] writes:
 
 Enrico Forestieri wrote:
 
  Really? I had thought the second one was more cleaner. Actually I had to
  figure out that when latex_path() is called for generating the argument
  of \input at path it is assumed that a trailing / is present, and the
  second patch makes this clear not only for cygwin.
 
 \input at path must always be an absolute path (otherwise it would not
 work TeX-wise), but why should that matter in LyX?

Trailing, not heading /. But it seems I was misunderstanding the code.
See my other post.

  On the other hand, 
  external_path() is almost a no-op for the other OSes, so I don't it is
  such an overhead. So, what shall I use?
 
 The overhead does not matter at all here. We have had a lot of path problems
 on the different windows flavors. Angus worked hard to resolve these, and
 implemented the external/internal path distiction.
 If we want to avoid more problems we must keep this distinction and be
 always explicit whether a path is external or intrnal.
 In the long run we should not juggle with paths as strings, but always use a
 path class with external() and internal() methods. This will make the
 distinction more clear.

Ok

 I am not really sure how things work on cygwin. Can we always assume that
 all external paths are either windows or posix style? Or do we need posix
 paths in some cases and windows paths in others?

The latter. On cygwin, depending on a checkbox status, external_path()
generates posix or windows style paths. This is because if you use
MikTeX you need win-style paths. The configure script checks what kind
of paths are needed and then sets the boolean \cygwin_path_fix_needed
in lyxrc.defaults. But then you can override it by a checkbox (which,
btw, is misnamed as it does the contrary of what its name implies).

-- 
Enrico

Re: A Cygwin related patch

[Georg Baum]

Enrico Forestieri wrote:

 Trailing, not heading /. But it seems I was misunderstanding the code.

And I was misunderstanding your post :-(

 I am not really sure how things work on cygwin. Can we always assume that
 all external paths are either windows or posix style? Or do we need posix
 paths in some cases and windows paths in others?
 
 The latter. On cygwin, depending on a checkbox status, external_path()
 generates posix or windows style paths. This is because if you use
 MikTeX you need win-style paths. The configure script checks what kind
 of paths are needed and then sets the boolean \cygwin_path_fix_needed
 in lyxrc.defaults. But then you can override it by a checkbox (which,
 btw, is misnamed as it does the contrary of what its name implies).

What I meant was: Do we need for one setting of cygwin_path_fix_needed both
windos/posix styles, or does cygwin_path_fix_needed simply switch
external_path() between the windows and posix version?


Georg

Re: [Pre-Patch] Was: Feature request: Remember the editing location when a file is closed.

[Bo Peng]

  src/lastfiles.C:
  I do not want to change the Files structure so I use a map to store
  position information. lastfile format is changed to id, pos
  filename if position information is available, and filename if not.

 Would it be easier to always have the id, pos filename format? And id
 = pos = 0 if no valid info exists, so current behaviour is reproduced?

With that I want to have a smooth transition to people that already
have a .lyx/lastfile. I is enough though, to always write in name
format, but also handle name when read.


  1. Will invalid paragraph id, pos crash lyx? I mean, if a file is
  saved (with id, pos saved locally), and is modified externally (get a
  revised copy from others), id, pos will no longer be valid and goto
  bookmark 0 will fail.

 This is a file format change and lyx2lyx must be made to handle it.

Is $HOME/.lyx/lastfile also handled by lyx2lyx?

 +// not found, return invalid id number
 +   else {
 +   id = -1;
 +   pos = 0;
 +   }

 Please don't do this ;-)

 It won't be needed if we change and handle the new file format.

There is a problem with my current approach. LastFiles::readFile only
read num_files entries. If an older file is re-opened, the position
information will not be available. That is why I currently use this
'info not found' approach. It should be better to load all position
information regardless of num_files.


  2. Save position does not seem to work when I quit lyx by closing the
  lyx window. Only close-buffer will do. Where should I handle the close
  event?

 Don't bother. That's not the way to leave LyX.

Many people do this anyway.

  3. Is saved_positions[0] really unused?

 No, it's used in at least two other places.

 1) To save the main document position to return to when opening a child
 2) To save the return (ref) position when jumping to a label.

 Neither interferes with your use, I think.

That means the first menu entry will/should be disabled after such operations.

Bo

Re: [PATCH] update vs repaint

[Jean-Marc Lasgouttes]

 Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

Jean-Marc There was a consensus that this patch is the right thing to
Jean-Marc do, even though it might not speed things up per se. I
Jean-Marc tested it and propose to apply to trunk and branch.

I applied it.

JMarc

Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents

[Jean-Marc Lasgouttes]

 Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

Jean-Marc Anyway, I have an additional patch for this bug. Anyone
Jean-Marc disagrees?

Applied.

JMarc

[PATCH] bug 2217: getting out of mathed is slow

[Jean-Marc Lasgouttes]

I would like to apply the following to branch and trunk. Any
objection?

To recap, what it does is restrict bruteFind to search only in the
paragraphs that are in the coordcache. The old code searched through
the whole document but acted only on the paragraphs in the coordcache
(the test for CUR_INSIDE).

Any objection?

JMarc

[PATCH] bug 675: cannot insert a graphics in a caption

[Jean-Marc Lasgouttes]

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

As discussed in the bug, this fixes the bug by making graphics in
caption generate proper latex (with \protect).

It is then up to the user to realize that the graphics is in the wrong
place (note that there may be proper reason for inserting a graphics
in a caption).

I tested it and it works.

I will apply tomorrow if nobody complains.

JMarc

Index: insetgraphics.C
===
--- insetgraphics.C	(revision 13276)
+++ insetgraphics.C	(working copy)
@@ -748,9 +748,15 @@
 	string after;
 	// Do we want subcaptions?
 	if (params().subcaption) {
+		if (runparams.moving_arg)
+			before += \\protect;
 		before += \\subfigure[ + params().subcaptionText + ]{;
 		after = '}';
 	}
+
+	if (runparams.moving_arg)
+		before += \\protect;
+	
 	// We never use the starred form, we use the clip option instead.
 	before += \\includegraphics;
 

Re: [Pre-Patch] Was: Feature request: Remember the editing location when a file is closed.

[Bo Peng]

An updated patch that loads all position information while keeping
only num_files Files entries.

Question: is 0 a valid paragraph ID? I currently use -1 to indicate invalid ID.

Bo
Index: src/BufferView_pimpl.C
===
--- src/BufferView_pimpl.C	(revision 13463)
+++ src/BufferView_pimpl.C	(working copy)
@@ -293,6 +293,14 @@
 
 	setBuffer(b);
 	bv_-showErrorList(_(Parse));
+
+	// load position when the file was last closed
+	int id;
+	lyx::pos_type pos; 
+	LyX::ref().lastfiles().loadFilePosition(s, id, pos);
+	// if id is valid ...
+	if( id = 0 )
+		saved_positions[0] = Position(s, id, pos);
 
 	if (tolastfiles)
 		LyX::ref().lastfiles().newFile(b-fileName());
@@ -767,7 +775,14 @@
 	saved_positions[i] = Position(buffer_-fileName(),
   cursor_.paragraph().id(),
   cursor_.pos());
-	if (i  0)
+	// if i == 0, (called when this buffer is closed), 
+	// save current position to lastfile
+	if (i == 0) {
+		LyX::ref().lastfiles().saveFilePosition(buffer_-fileName(),
+cursor_.paragraph().id(), 
+cursor_.pos());
+}
+	else
 		owner_-message(bformat(_(Saved bookmark %1$d), i));
 }
 
Index: src/lastfiles.C
===
--- src/lastfiles.C	(revision 13463)
+++ src/lastfiles.C	(working copy)
@@ -19,6 +19,11 @@
 #include fstream
 #include iterator
 
+// file_pos is a map to save position of cursor when a file is closed.
+#include map
+#include sstream
+#include utility
+
 namespace fs = boost::filesystem;
 
 using std::copy;
@@ -26,10 +31,16 @@
 using std::find;
 using std::getline;
 using std::string;
+using std::map;
+using std::pair;
 using std::ifstream;
 using std::ofstream;
 using std::ostream_iterator;
 
+// store file position information to a map to avoid changing the 
+// dequeue structure Files
+typedef mapstring, pairint, lyx::pos_type  file_pos;
+file_pos filePositions;
 
 LastFiles::LastFiles(string const  filename, bool st, unsigned int num)
 	: dostat(st)
@@ -59,10 +70,31 @@
 	ifstream ifs(filename.c_str());
 	string tmp;
 
-	while (getline(ifs, tmp)  files.size()  num_files) {
+	while (getline(ifs, tmp)) {
+		// id, position filename\n
+		if (tmp[0] == ''  tmp.find('', 1) != string::npos ) {
+			std::istringstream itmp(tmp);
+			string fname;
+			int id;
+			lyx::pos_type pos;
+			itmp.ignore(1);  // ignore 
+			itmp  id;
+			itmp.ignore(2);  // ignore , 
+			itmp  pos;
+			itmp.ignore(2);  // ingore  
+			itmp  fname;
+			filePositions[fname] = pairint, lyx::pos_type(id, pos);
+			tmp = fname;
+		}
+		// 'tmp' is now the last part of id, pos file or a line 
+		// without . The latter case provides a smooth transition 
+		// for people who have the old lastfile format
 		if (dostat  !fs::exists(tmp))
-continue;
-		files.push_back(tmp);
+			continue;
+		// while loading all position information, 
+		// keep num_files files entries
+		if (files.size()  num_files )
+			files.push_back(tmp);
 	}
 }
 
@@ -71,8 +103,19 @@
 {
 	ofstream ofs(filename.c_str());
 	if (ofs) {
-		copy(files.begin(), files.end(),
-		 ostream_iteratorstring(ofs, \n));
+		for (const_iterator file=files.begin(); file != files.end(); ++file) {
+			// has position information, save in the format of 
+			// id, pos filename
+			file_pos::iterator entry = filePositions.find(*file);
+			if (entry != filePositions.end() )
+ofs(*entry).second.first  ,   
+	(*entry).second.second *file  endl;
+			// this will only happen during the transition from the
+			// old to new lastfile format
+			else
+ofs  -1, 0   *file  endl;
+		}
+		ofs.close();
 	} else
 		lyxerr  LyX: Warning: unable to save LastFiles: 
 		filename  endl;
@@ -90,7 +133,27 @@
 		files.pop_back();
 }
 
+void LastFiles::saveFilePosition(string const fname, int id, lyx::pos_type pos ) const
+{
+	filePositions[fname] = pairint, lyx::pos_type(id, pos);
+}
 
+void LastFiles::loadFilePosition(string const fname, int id, lyx::pos_type pos ) const
+{
+	file_pos::iterator entry = filePositions.find(fname);
+	// has position information, return it.
+	if( entry != filePositions.end() ) {
+		id = (*entry).second.first;
+		pos = (*entry).second.second;
+	}
+	// not found, return invalid id number. This will happen 
+	// in the cases when a new file (not in lastfile) is opened.
+	else {
+		id = -1;
+		pos = 0;
+	}
+}
+
 string const LastFiles::operator[](unsigned int i) const
 {
 	if (i  files.size())
Index: src/lyxfunc.C
===
--- src/lyxfunc.C	(revision 13463)
+++ src/lyxfunc.C	(working copy)
@@ -1880,6 +1880,8 @@
 
 void LyXFunc::closeBuffer()
 {
+	// save current position to lastfile
+	view()-savePosition(0);
 	if (bufferlist.close(owner-buffer(), true)  !quitting) {
 		if (bufferlist.empty()) {
 			// need this otherwise SEGV may occur while
Index: src/lastfiles.h
===
--- 

Re: Feature request: Remember the editing location when a file is closed.

[Lars Gullik Bjønnes]

Jose' Matos [EMAIL PROTECTED] writes:

| On Wednesday 22 March 2006 22:44, [EMAIL PROTECTED] wrote:
|  On Wed, 22 Mar 2006, Bo Peng wrote:
|   Dear list,
|  
|   I am not sure if others will like this idea. When I edit a long file,
|   it may be troublesome to locate and continue from where I was working
|   on, after the file is re-opened. I would be happy if lyx can
|   automatically goes to the page at which lyx was closed.
|  
|   I can think of two ways to do this:
|  
|   1. (More intrusive). Remember the location under .lyx and jump to it
|   when a lyx file is opened. I think this is what vim is doing.
| 
|  For good or worse, this also means that when working with someone else on
|  the same file (that's sent back and forth, or under version control),
|  you'll open it up where the other person left off...
| 
|   Lars suggested that those values could be saved on .lyx directory. That 
| would serve both purposes. :-)

Both bookmarks and 'old-location' should be saved in .lyx, not in the
lyx file.

-- 
Lgb

Re: [PATCH] bug 2217: getting out of mathed is slow

[Martin Vermeer]

On Thu, Mar 23, 2006 at 03:08:16PM +0100, Jean-Marc Lasgouttes wrote:
 
 I would like to apply the following to branch and trunk. Any
 objection?
 
 To recap, what it does is restrict bruteFind to search only in the
 paragraphs that are in the coordcache. The old code searched through
 the whole document but acted only on the paragraphs in the coordcache
 (the test for CUR_INSIDE).
 
 Any objection?

If this invisible patch is the latest you posted on bugzilla, no.

- Martin
 


pgpITbzl6M8QK.pgp
Description: PGP signature

Re: [Pre-Patch] Was: Feature request: Remember the editing location when a file is closed.

[Lars Gullik Bjønnes]

Bo Peng [EMAIL PROTECTED] writes:

| Dear list,
| 
| It does not look so difficult to implement this feature so I tried to
| implement it by myself. Attached is my patch. Since I rarely submit a
| patch here so I am afraid that there might be many problems (format,
| logic, bugs). Please have a look and give me some feedbacks.
| 
| Many files have been modified:
| 
| src/BufferView_pimpl.C
| When a new buffer is loaded, it tries to get last cursor position from
| ref().lastfiles(). When a file is going to be closed, current location
| is saved as bookmark 0, and to ref().lastfiles(). A side effect of
| this is that a file can be re-opened (and to the same location) from
| bookmark 0.

I am not sure if I like lastfiles to be the files that store this
info. One of the reason is that we only store a very limited number of
files there... lastpostion info should hold more files.

I'd prefere if there was a separate file for this information.

bookmark0? where is that stored? if it in the lyx document, then
please no.

Also I think bookmarks and lastplace should be kept a part and not be
connected at all.

| src/lastfiles.C:
| I do not want to change the Files structure so I use a map to store
| position information. lastfile format is changed to id, pos
| filename if position information is available, and filename if not.
| The biggest changes are to read/write lastfile. I hope that I have not
| broken anything here.

With a new file with its own format, this is not a problem. Also
please have a look at how emacs does this. (.emacs-places)
 
| src/lyxfunc.C:
|save cursor position when the buffer is closed.
| 
| lib/ui/stdmenus.ui:
|add a menu item with an awkard name.

What do you need the menuitem for?
 
| I am worrying about two problem though:
| 
| 1. Will invalid paragraph id, pos crash lyx? I mean, if a file is
| saved (with id, pos saved locally), and is modified externally (get a
| revised copy from others), id, pos will no longer be valid and goto
| bookmark 0 will fail.

Please do not use paragraph id it is not stable. Perhaps use the
cursor stack info instead.
 
| 2. Save position does not seem to work when I quit lyx by closing the
| lyx window. Only close-buffer will do. Where should I handle the close
| event?

That would be a more general bug.

| 3. Is saved_positions[0] really unused?

Where is it found?

-- 
Lgb

Re: [PATCH] bug 675: cannot insert a graphics in a caption

[Martin Vermeer]

On Thu, Mar 23, 2006 at 03:24:55PM +0100, Jean-Marc Lasgouttes wrote:
 
 http://bugzilla.lyx.org/show_bug.cgi?id=675
 
 As discussed in the bug, this fixes the bug by making graphics in
 caption generate proper latex (with \protect).
 
 It is then up to the user to realize that the graphics is in the wrong
 place (note that there may be proper reason for inserting a graphics
 in a caption).
 
 I tested it and it works.
 
 I will apply tomorrow if nobody complains.

Great.

Note that this will allow graphics in all layouts with NeedProtect = 1,
also Part, Chapter and Section.

- Martin



pgpLEjo75JDUm.pgp
Description: PGP signature

Re: A Cygwin related patch

[Lars Gullik Bjønnes]

Georg Baum [EMAIL PROTECTED] writes:

| Enrico Forestieri wrote:
| 
|  The attached patch fixes the bug reported here:
|  http://thread.gmane.org/gmane.editors.lyx.general/29227
|  
|  In my intention this is the first of a series of patches aimed at
|  polishing the Cygwin target, which I think is lagging behind. Please, tell
|  me if this ok with you. I have no problem in maintaining the Cygwin target
|  but my time is limited so I cannot guarantee a continuous commitment. I
|  will do it time permitting. There should be no big problems, as I think
|  the Cygwin users will not be more than those I can count with only one of
|  my hands ;-)
| 
| This patch looks good. I don't like the other one, because the code in
| filetools.C is more complicated, and in this one it is more clear because
| of cygwin_path_fix().

I feel the exact opposite. the cygwin_path_fix pollutes the portable
code, pollutes the not cygwin files

The second patch is the nice one IMO.


-- 
Lgb

Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents

[Lars Gullik Bjønnes]

Helge Hafting [EMAIL PROTECTED] writes:

| John McCabe-Dansted wrote:
| 
| John If LyX locked files which were open in a still running LyX
| John process, that would have saved me some confusion.
| 
| Yes, but I am sure this can cause a lot of confusion too...
| 
| 
| I am not sure why this would cause confusion. You could have a dialog
| box warning that Another LyX window has this file open and offer
| some of the following alternatives:
| 
| * Do not open.
| 
| fine
| 
| * Open read only.
| 
| fine
| 
| * Open anyway.
| 
| fine, assume the user sorts it out after being warned

Please have a look at how emacs does this.
(I am in favor of the 'when in doubt do as emacs' camp.)

-- 
Lgb

Re: A Cygwin related patch

[Georg Baum]

Lars Gullik Bjønnes wrote:

 I feel the exact opposite. the cygwin_path_fix pollutes the portable
 code, pollutes the not cygwin files

But it makes it explicit why external_path() is needed. 

 The second patch is the nice one IMO.

Now I don't like either anymore. The problem of both fixes is that they use
a trailing '/' as flag whether external_path() is needed or not. This will
strike back sooner or later.


Georg

Re: [Pre-Patch] Was: Feature request: Remember the editing location when a file is closed.

[Lars Gullik Bjønnes]

Bo Peng [EMAIL PROTECTED] writes:

| An updated patch that loads all position information while keeping
| only num_files Files entries.
| 
| Question: is 0 a valid paragraph ID? I currently use -1 to indicate
| invalid ID.

As said, I'd prefere a separate file in .lyx/; but even if I didn't:

| Index: src/BufferView_pimpl.C
| ===
| --- src/BufferView_pimpl.C(revision 13463)
| +++ src/BufferView_pimpl.C(working copy)
| @@ -293,6 +293,14 @@
|  
|   setBuffer(b);
|   bv_-showErrorList(_(Parse));
| +
| + // load position when the file was last closed
| + int id;
| + lyx::pos_type pos; 
| + LyX::ref().lastfiles().loadFilePosition(s, id, pos);

I must admit that I prefere to not use in/out parameters.
I like tupples though :-)  (boost::tuple)

| + // if id is valid ...
| + if( id = 0 )
| + saved_positions[0] = Position(s, id, pos);

I think we should just have a switch. LyX wide per user where (lyxrc)
the decides where the lastposition info should be used or not.

| + if (i == 0) {
| + LyX::ref().lastfiles().saveFilePosition(buffer_-fileName(),
| + cursor_.paragraph().id(), 
| + cursor_.pos());

Using paragraph id is icky. Please use offsets into the paragraphlist
instead. You should be able to get that from the cursor.

| Index: src/lastfiles.C
| ===
| --- src/lastfiles.C   (revision 13463)
| +++ src/lastfiles.C   (working copy)
| @@ -26,10 +31,16 @@
|  using std::find;
|  using std::getline;
|  using std::string;
| +using std::map;
| +using std::pair;
|  using std::ifstream;
|  using std::ofstream;
|  using std::ostream_iterator;
|  
| +// store file position information to a map to avoid changing the 
| +// dequeue structure Files
| +typedef mapstring, pairint, lyx::pos_type  file_pos;
| +file_pos filePositions;

This is a no-go. This information must be in the LastFiles object
(class).

| Index: src/lastfiles.h
| ===
| --- src/lastfiles.h   (revision 13463)
| +++ src/lastfiles.h   (working copy)
| @@ -56,6 +59,18 @@
|   @param file the file we write the lastfiles list to.
|   */
|   void writeFile(std::string const  file) const;
| + /** add cursor position to the fname entry in the lastfile
| + @param fname file entry for which to save position information
| + @param id id of the paragraph of the location when the file is 
closed.
| + @param pos position of the cursor when the file is closed.
| + */
| + void LastFiles::saveFilePosition(std::string const fname, int id, 
lyx::pos_type pos) const;
| + /** load saved cursor position to the fname entry in the lastfile
| + @param fname file entry for which to load position information
| + @param id id of the paragraph of the location when the file is 
closed.
| + @param pos position of the cursor when the file is closed.
| + */
| + void LastFiles::loadFilePosition(std::string const fname, int id, 
lyx::pos_type pos ) const;
|   /** Return file #n# in the lastfiles list.
|   @param n number in the list to get
|   */

Using ClassName::Func in the class decl. is a syntax error. Just use
'Func' instead.


-- 
Lgb

Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents

[Jean-Marc Lasgouttes]

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

Lars Please have a look at how emacs does this. (I am in favor of the
Lars 'when in doubt do as emacs' camp.)

It uses a ~/.emacs-places file which contains a list of files and
offsets.

JMarc

Re: A Cygwin related patch

[Jean-Marc Lasgouttes]

 Georg == Georg Baum [EMAIL PROTECTED] writes:

Georg Now I don't like either anymore. The problem of both fixes is
Georg that they use a trailing '/' as flag whether external_path() is
Georg needed or not. This will strike back sooner or later.

Sure, this is not good. Is the problem that latex_path() needs
different syntax depending on whether the file name is used inside a
.tex file or as command argument?

What is the problem exactly?

JMarc

Re: [PATCH] bug 2217: getting out of mathed is slow

[Jean-Marc Lasgouttes]

 Martin == Martin Vermeer [EMAIL PROTECTED] writes:

Martin On Thu, Mar 23, 2006 at 03:08:16PM +0100, Jean-Marc Lasgouttes
Martin wrote:
  I would like to apply the following to branch and trunk. Any
 objection?
 
 To recap, what it does is restrict bruteFind to search only in the
 paragraphs that are in the coordcache. The old code searched
 through the whole document but acted only on the paragraphs in the
 coordcache (the test for CUR_INSIDE).
 
 Any objection?

Martin If this invisible patch is the latest you posted on bugzilla,
Martin no.

OK, since you insist, I'll attach it :)

JMarc

Index: insetgraphics.C
===
--- insetgraphics.C	(revision 13276)
+++ insetgraphics.C	(working copy)
@@ -748,9 +748,15 @@
 	string after;
 	// Do we want subcaptions?
 	if (params().subcaption) {
+		if (runparams.moving_arg)
+			before += \\protect;
 		before += \\subfigure[ + params().subcaptionText + ]{;
 		after = '}';
 	}
+
+	if (runparams.moving_arg)
+		before += \\protect;
+	
 	// We never use the starred form, we use the clip option instead.
 	before += \\includegraphics;
 

Re: [PATCH] bug 2217: getting out of mathed is slow

[Jean-Marc Lasgouttes]

 Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:

Jean-Marc OK, since you insist, I'll attach it :)

Wrong one. I need sleep.

JMarc

Index: src/cursor.C
===
--- src/cursor.C	(revision 13257)
+++ src/cursor.C	(working copy)
@@ -127,16 +127,26 @@
 		BOOST_ASSERT(!cursor.empty());
 		InsetBase  inset = cursor[0].inset();
 
-		DocIterator it = doc_iterator_begin(inset);
-		DocIterator const et = doc_iterator_end(inset);
+		CoordCache::InnerParPosCache const  cache = theCoords.getParPos().find(cursor.bottom().text())-second;
+		// Get an iterator on the first paragraph in the cache
+		DocIterator it(inset);
+		it.push_back(CursorSlice(inset));
+		it.pit() = cache.begin()-first;
+		// Get an iterator after the last paragraph in the cache
+		DocIterator et(inset);
+		et.push_back(CursorSlice(inset));
+		et.pit() = boost::prior(cache.end())-first;
+		if (et.pit() = et.lastpit())
+			et = doc_iterator_end(inset);
+		else 
+			++et.pit();
 
 		double best_dist = std::numeric_limitsdouble::max();;
 		DocIterator best_cursor = et;
 
 		for ( ; it != et; it.forwardPos(true)) {
 			// avoid invalid nesting when selecting
-			if (bv_funcs::status(cursor.bv(), it) == bv_funcs::CUR_INSIDE
-			 (!cursor.selection() || positionable(it, cursor.anchor_))) {
+			if (!cursor.selection() || positionable(it, cursor.anchor_)) {
 Point p = bv_funcs::getPos(it, false);
 int xo = p.x_;
 int yo = p.y_;
@@ -147,7 +157,7 @@
 	// '=' in order to take the last possible position
 	// this is important for clicking behind \sum in e.g. '\sum_i a'
 	if (d = best_dist) {
-		lyxerr  *  endl;
+		//	lyxerr  *  endl;
 		best_dist   = d;
 		best_cursor = it;
 	}
Index: src/ChangeLog
===
--- src/ChangeLog	(revision 13257)
+++ src/ChangeLog	(working copy)
@@ -1,3 +1,8 @@
+2006-02-20  Jean-Marc Lasgouttes  [EMAIL PROTECTED]
+
+	* cursor.C (bruteFind): only iterate over the paragraphs that are
+	in the CoordCache (bug 2217)
+
 2006-02-06  Georg Baum  [EMAIL PROTECTED]
 
 	* text2.C (deleteEmptyParagraphMechanism): 64bit compile fix

Re: [PATCH] bug 2217: getting out of mathed is slow

[Martin Vermeer]

On Thu, Mar 23, 2006 at 04:52:10PM +0100, Jean-Marc Lasgouttes wrote:
  Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
 
 Jean-Marc OK, since you insist, I'll attach it :)
 
 Wrong one. I need sleep.
 
 JMarc

This is the one that I tested, right?

- Martin
 


pgplNNJEXXofL.pgp
Description: PGP signature

Re: Problem compiling Lyx 1.4. svn

[Helge Hafting]

Charles de Miramon wrote:


Before make, type
export CC=gcc-3.3
export CXX=g++-3.3
 


Nice! For 1.5, this also works with
export CC=gcc-4.1
export CXX=g++-4.1

gcc/g++ version 4.1 is available debian users in the experimental 
distribution.



Helge Hafting

Is the qt4 frontend ready for (experimental) use?

[Helge Hafting]

I finally got my compiler sorted out, I can compile lyx again. :-)

At least I got the qt frontend going with g++ 4.1

I then tried to install qt4 tools  libraries to compile that
frontend, but it failed. 


Is qt4 simply not ready for testing yet, or broken in svn right now,
or should I look for errors in my setup?

Helge Hafting

Re: Is the qt4 frontend ready for (experimental) use?

[Georg Baum]

Helge Hafting wrote:

 Is qt4 simply not ready for testing yet, or broken in svn right now,
 or should I look for errors in my setup?

It compiles fine here with gcc 3.3. Please send the error messages, maybe
some error is tolerated by older gccs but not by gcc 4.1


Georg

amazon problem

[lyx]

I have unsubbed the amazon.com address.  Please let me know immediately if
the problem occurs again, and I will then block amazon.com from the LyX
lists.  At this point I am just not sure if some people could have an email
account at amazon.com.

The problem was--besides that amazon.com somehow got subscribed---that
amazon does not bounce to the address it supposed to (the enevelope sender
address) but to the address in the From: header.  If amazon.com bounced
properly, our list manager software, ezmlm, would have unsubbed it because
of bounced messages.


Mate

Re: Is the qt4 frontend ready for (experimental) use?

[Abdelrazak Younes]

Helge Hafting a écrit :

I finally got my compiler sorted out, I can compile lyx again. :-)

At least I got the qt frontend going with g++ 4.1

I then tried to install qt4 tools  libraries to compile that
frontend, but it failed.
Is qt4 simply not ready for testing yet, or broken in svn right now,
or should I look for errors in my setup?


Unless I have introduced something bad lately, it should compile and 
work OK (except for the Citation dialog). At least Georg, Juegen and 
Edwin were able to run it.
Is it a configuration error or a compilation error? If the later please 
post the gcc output.


Thanks,
Abdel.

Re: [patch] remove wheel mouse ui from qt2

[Abdelrazak Younes]

Abdelrazak Younes a écrit :

Done, patch attached (not tested).
I will apply that once I get some spare time to compile and test (if you 
don't beat me at this :-)).


Committed.

Abdel.

Re: A Cygwin related patch

[Enrico Forestieri]

Georg Baum [EMAIL PROTECTED] writes:

 What I meant was: Do we need for one setting of cygwin_path_fix_needed both
 windos/posix styles, or does cygwin_path_fix_needed simply switch
 external_path() between the windows and posix version?

As it is now, cygwin_path_fix_needed simply switch external_path()
between the windows and posix version. However, if regarded as an OS,
cygwin is really posix, so in some cases one must always use
internal_path(). This is a singular case with respect to the other
supported OSes. It may seem complicated, but apart the need for some
polish, it does work.

-- 
Enrico

Re: qtwin compilation

[Michael Gerz]

Angus Leeming wrote:


Could you glance over
http://wiki.lyx.org/Windows/LyX14x Is that enough
info? Feel free to add anything else.
 


Hi Angus,

some comments/questions:

- First bullet: LyX files will be associated with the LyX application 
that has been installed most recently (I guess it works like that; I 
haven't tested it!!!)
- Second bullet: What happens if you overwrite a LyX 1.4 by another LyX 
1.4? Windows user are used to installers that look for older software 
versions and replace them. What does your installer do? What happens if 
I forget to deinstall the old software?

- Third bullet: Aspell 0.6 = 0.60.4

Michael

Re: [PATCH] bug 2217: getting out of mathed is slow

[Jean-Marc Lasgouttes]

 This is the one that I tested, right?

Yes.

JMarc 

Re: A Cygwin related patch

[Enrico Forestieri]

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
 
  Georg == Georg Baum [EMAIL PROTECTED] writes:
 
 Georg Now I don't like either anymore. The problem of both fixes is
 Georg that they use a trailing '/' as flag whether external_path() is
 Georg needed or not. This will strike back sooner or later.
 
 Sure, this is not good. Is the problem that latex_path() needs
 different syntax depending on whether the file name is used inside a
 .tex file or as command argument?
 
 What is the problem exactly?

The problem is that I have not a full grasp of the overall code and don't
want introduce changes without fully knowing the consequences. I repeat,
my idea is of only fixing what is broken, making changes that I fully
understand. As a problem arised with [EMAIL PROTECTED], I tried to fix only
that case.

As regards the trailing '/', I think this is not a problem, as there is
only one place in the code where latex_path() is called for generating
the argument of [EMAIL PROTECTED] It is in src/buffer.C, so a patch in which
I am confident is along these lines:

--- src/buffer.C(revision 13450)
+++ src/buffer.C(working copy)
@@ -875,7 +876,9 @@ void Buffer::makeLaTeXFile(ostream  os,
texrow().newline();
}
if (!original_path.empty()) {
-   string const inputpath = latex_path(original_path);
+   // A trailing slash is used as a flag for latex_path
+   // which will return an unslashed path.
+   string const inputpath = latex_path(original_path + /)
;
os  \\makeatletter\n
 [EMAIL PROTECTED]
 inputpath  /}}\n


and then in latex_path(), either:

--- src/support/filetools.C (revision 13450)
+++ src/support/filetools.C (working copy)
@@ -87,6 +87,11 @@ string const latex_path(string const  o
latex_path_dots dots)
 {
string path = subst(original_path, \\, /);
+   if (suffixIs(path, '/')) {
+   path = rtrim(path, /);
+   if (os::cygwin_path_fix())
+   path = os::external_path(path);
+   }
path = subst(path, ~, \\string~);
if (path.find(' ') != string::npos) {
// We can't use '' because  is sometimes active (e.g. if


alongthe lines of the first patch, or:


--- src/support/filetools.C (revision 13450)
+++ src/support/filetools.C (working copy)
@@ -86,7 +86,15 @@ string const latex_path(string const  o
latex_path_extension extension,
latex_path_dots dots)
 {
-   string path = subst(original_path, \\, /);
+   string path;
+
+   if (suffixIs(original_path, '/')) {
+   path = rtrim(path, /);
+   // The call to os::external_path is needed for Cygwin.
+   path = subst(os::external_path(original_path), \\, /);
+   } else
+   path = subst(original_path, \\, /);
+
path = subst(path, ~, \\string~);
if (path.find(' ') != string::npos) {
// We can't use '' because  is sometimes active (e.g. if


along the lines of the second patch. Both approaches work and are robust
because the trailing '/' is anyway added. Please, tell me what to do.
I do not feel confortable in unconditionally call external_path (I don't
want to fix what is not broken).

-- 
Enrico

Re: amazon problem

[Lars Gullik Bjønnes]

[EMAIL PROTECTED] writes:

| I have unsubbed the amazon.com address.  Please let me know immediately if
| the problem occurs again, and I will then block amazon.com from the LyX
| lists.

Thanks.

-- 
Lgb

Re: A Cygwin related patch

[Georg Baum]

Enrico Forestieri wrote:

 The problem is that I have not a full grasp of the overall code and don't
 want introduce changes without fully knowing the consequences. I repeat,
 my idea is of only fixing what is broken, making changes that I fully
 understand. As a problem arised with [EMAIL PROTECTED], I tried to fix only
 that case.

I do fully agree. My point however is that using a trailing '/' as flag will
sooner or later strike back. If it is really necessary to tell latex_path()
whether it should call external_path() or not, add an additional parameter
that tells exactly that.

 --- src/support/filetools.C (revision 13450)
 +++ src/support/filetools.C (working copy)
 @@ -86,7 +86,15 @@ string const latex_path(string const  o
 latex_path_extension extension,
 latex_path_dots dots)
  {
 -   string path = subst(original_path, \\, /);
 +   string path;
 +
 +   if (suffixIs(original_path, '/')) {
 +   path = rtrim(path, /);
 +   // The call to os::external_path is needed for Cygwin.
 +   path = subst(os::external_path(original_path), \\, /);
 +   } else
 +   path = subst(original_path, \\, /);
 +
 path = subst(path, ~, \\string~);
 if (path.find(' ') != string::npos) {
 // We can't use '' because  is sometimes active (e.g. if
 
 
 along the lines of the second patch. Both approaches work and are robust
 because the trailing '/' is anyway added. Please, tell me what to do.

This version is preferrable since it does not need the cygwin switch.

 I do not feel confortable in unconditionally call external_path (I don't
 want to fix what is not broken).

I think that you can safely call it unconditionally. I looked it up, and
latex_path() is only called on filenames that are written to .tex files. I
would be very surprised if a TeX compiler exists on windows that needs win
style paths in [EMAIL PROTECTED] but posix style paths in \includegraphics or
\input.
To be sure you could make a simple test: Call external_path()
unconditionally, and try to view a document that contains a graphics inset,
and two include insets, one with \input and one with \include. All files
should be entered with absolute names.
If my theory is right then running latex on the exported .tex file will work
with the unconditional fix and fail with the conditional one.
The absolute names are necessary to get slashes in the name, and running
latex on the exported .tex file is necessary because LyX uses always
relative paths for running latex internally.


Georg

PS: You might want to have a look at the cygwin version of external_path().
It contains unreachable code.

[PATCH} Was: Feature request: Remember the editing location when a file is closed.

[Bo Peng]

Dear list,

This time, a formal patch. Here are the rationals:

 I am not sure if I like lastfiles to be the files that store this
 info. One of the reason is that we only store a very limited number of
 files there... lastpostion info should hold more files.

Using a separate file like $HOME/.lyx/filepos means more source code
to change and maintain so I prefer the lastfile interface. In my
implementation, the first several lines are  for lastfiles, and the
rest of the lines will be loaded for file positions.

 bookmark0? where is that stored? if it in the lyx document, then
 please no.

The bookmark is not saved in .lyx file.

 What do you need the menuitem for?

I though a menuitem would be less intrusive, but a rc entry should
serve our purpose better, especially when the menuitem will be used
only once. So, on a second thought, I removed this menu item.

 Please do not use paragraph id it is not stable. Perhaps use the
 cursor stack info instead.

Use pit() instead of id() now.

 I must admit that I prefere to not use in/out parameters.
 I like tupples though :-)  (boost::tuple)

For two items, std::pair is better. I do not really like the get0() interface.

 I think we should just have a switch. LyX wide per user where (lyxrc)
 the decides where the lastposition info should be used or not.

I do not know how to do it. It should be simple for you guys. ( I have
a FIXME in the patch)

 Using paragraph id is icky. Please use offsets into the paragraphlist
 instead. You should be able to get that from the cursor.

I use pit() and paragraphs()[ pit() ].id() etc (see attached patch). I
am not quite confident about this part.

 This is a no-go. This information must be in the LastFiles object
 (class).

Done. With another entry num_positions. An rc entry for it should be
fine but I simply set it to 100.

 Using ClassName::Func in the class decl. is a syntax error. Just use
 'Func' instead.

Oops, copy/paste problem. But why did not my gcc complain?

The patch seems to be working. Please test it. Also, I really would
like the close-button to work as File-exit.

Cheers,
Bo
Index: src/BufferView_pimpl.C
===
--- src/BufferView_pimpl.C	(revision 13463)
+++ src/BufferView_pimpl.C	(working copy)
@@ -293,6 +293,20 @@
 
 	setBuffer(b);
 	bv_-showErrorList(_(Parse));
+
+	// scroll to the position when the file was last closed
+	// FIXME: this if(true) should be changed to a rcfile switch
+	// I do not know how to do it now.
+	if( true ) {
+		std::pairlyx::pit_type, lyx::pos_type pos = LyX::ref().lastfiles().loadFilePosition(s);
+		// p.get0 is pit, need to translate it to paragraph id.
+		ParagraphList prghs = b-paragraphs();
+		// be careful since the file may have been externally changed ...
+		if ( pos.first  prghs.size() ) {
+			saved_positions[0] = Position(s, prghs[pos.first].id(), pos.second);
+			restorePosition(0);
+		}
+	}
 
 	if (tolastfiles)
 		LyX::ref().lastfiles().newFile(b-fileName());
@@ -767,7 +781,15 @@
 	saved_positions[i] = Position(buffer_-fileName(),
   cursor_.paragraph().id(),
   cursor_.pos());
-	if (i  0)
+	// if i == 0, (called when this buffer is closed), 
+	// save current position to lastfile, not that paragraph
+	// index instead of id is saved.
+	if (i == 0) {
+		LyX::ref().lastfiles().saveFilePosition(buffer_-fileName(),
+cursor_.pit(), 
+cursor_.pos());
+}
+	else
 		owner_-message(bformat(_(Saved bookmark %1$d), i));
 }
 
Index: src/lastfiles.C
===
--- src/lastfiles.C	(revision 13463)
+++ src/lastfiles.C	(working copy)
@@ -19,6 +19,8 @@
 #include fstream
 #include iterator
 
+#include sstream
+
 namespace fs = boost::filesystem;
 
 using std::copy;
@@ -26,13 +28,13 @@
 using std::find;
 using std::getline;
 using std::string;
+using std::map;
 using std::ifstream;
 using std::ofstream;
-using std::ostream_iterator;
+using std::istringstream;
 
-
 LastFiles::LastFiles(string const  filename, bool st, unsigned int num)
-	: dostat(st)
+	: num_positions(100), dostat(st)
 {
 	setNumberOfFiles(num);
 	readFile(filename);
@@ -59,10 +61,31 @@
 	ifstream ifs(filename.c_str());
 	string tmp;
 
-	while (getline(ifs, tmp)  files.size()  num_files) {
+	while (getline(ifs, tmp)) {
+		// id, position filename\n
+		if (tmp[0] == ''  tmp.find('', 1) != string::npos ) {
+			istringstream itmp(tmp);
+			string fname;
+			int id;
+			lyx::pos_type pos;
+			itmp.ignore(1);  // ignore 
+			itmp  id;
+			itmp.ignore(2);  // ignore , 
+			itmp  pos;
+			itmp.ignore(2);  // ingore  
+			itmp  fname;
+			if (file_positions.size()  num_positions )
+file_positions[fname] = FilePos(id, pos);
+			tmp = fname;
+		}
+		// 'tmp' is now the last part of id, pos file or a line 
+		// without . The latter case provides a smooth transition 
+		// for people who have the old lastfile format
 		if (dostat  !fs::exists(tmp))
-continue;
-		

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

[Lars Gullik Bjønnes]

Bo Peng [EMAIL PROTECTED] writes:

| Dear list,
| 
| This time, a formal patch. Here are the rationals:
| 
|  I am not sure if I like lastfiles to be the files that store this
|  info. One of the reason is that we only store a very limited number of
|  files there... lastpostion info should hold more files.
| 
| Using a separate file like $HOME/.lyx/filepos means more source code
| to change and maintain so I prefer the lastfile interface.
| In my
| implementation, the first several lines are  for lastfiles, and the
| rest of the lines will be loaded for file positions.

I do not like this one bit.
IMO completely ortogonal feature that happens to share some of the
omplementation. IMHO you have just made a super simple LastFiles a lot
more complex.

|  bookmark0? where is that stored? if it in the lyx document, then
|  please no.
| 
| The bookmark is not saved in .lyx file.

Ok. IMHO this lastpos feature should not be mixed with bookmarks.

|  Please do not use paragraph id it is not stable. Perhaps use the
|  cursor stack info instead.
| 
| Use pit() instead of id() now.

You won't be able to please the cursor accurately then.
 
|  I must admit that I prefere to not use in/out parameters.
|  I like tupples though :-)  (boost::tuple)
| 
| For two items, std::pair is better. I do not really like the
| get0() interface.

boost::tie

| 
|  I think we should just have a switch. LyX wide per user where (lyxrc)
|  the decides where the lastposition info should be used or not.
| 
| I do not know how to do it. It should be simple for you guys. ( I have
| a FIXME in the patch)

To add it to the lyxrc is easy enough... it is getting it into the gui
frontends that is hard...
 
|  Using paragraph id is icky. Please use offsets into the paragraphlist
|  instead. You should be able to get that from the cursor.
| 
| I use pit() and paragraphs()[ pit() ].id() etc (see attached patch). I
| am not quite confident about this part.
| 
|  This is a no-go. This information must be in the LastFiles object
|  (class).
| 
| Done. With another entry num_positions. An rc entry for it should be
| fine but I simply set it to 100.
| 
|  Using ClassName::Func in the class decl. is a syntax error. Just use
|  'Func' instead.
| 
| Oops, copy/paste problem. But why did not my gcc complain?

Too old gcc. I think only gcc  4.1 warns/errors about this.

-- 
Lgb

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

[Jose' Matos]

On Thursday 23 March 2006 18:39, Lars Gullik Bjønnes wrote:
 Too old gcc. I think only gcc  4.1 warns/errors about this.

 gcc = 4.1

  :-)

 --
 Lgb

-- 
José Abílio

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

[Lars Gullik Bjønnes]

Bo Peng [EMAIL PROTECTED] writes:

| Index: src/BufferView_pimpl.C
| ===
| --- src/BufferView_pimpl.C(revision 13463)
| +++ src/BufferView_pimpl.C(working copy)
| @@ -293,6 +293,20 @@
|  
|   setBuffer(b);
|   bv_-showErrorList(_(Parse));
| +
| + // scroll to the position when the file was last closed
| + // FIXME: this if(true) should be changed to a rcfile switch
| + // I do not know how to do it now.
| + if( true ) {
| + std::pairlyx::pit_type, lyx::pos_type pos = 
LyX::ref().lastfiles().loadFilePosition(s);

Alternatively, more similar to what you had earlier:

int pit;
int pos;
boost::tie(pit, pos) = LyX::ref().lastfiles().loadFilePosition(s);

| + // p.get0 is pit, need to translate it to paragraph id.

pos.first

| + ParagraphList prghs = b-paragraphs();
| + // be careful since the file may have been externally changed 
...
| + if ( pos.first  prghs.size() ) {
| + saved_positions[0] = Position(s, prghs[pos.first].id(), 
pos.second);
| + restorePosition(0);
| + }
| + }

Can you please drop the bookmark part of the patch for now?
If we decide that we do want bookmark[0] to be the position the cursor
was in when the doc was last saved we can put this in later.
(but... I just realized that you rely on this in your
implementation... hmm)

We actually want to get rid of the whole paragraph.id thing. It is not
stable enough. I have some (vague) plans of introducing a
(universally) unique id to use on paragraphs.

Just as a test... load a document move the cursor save.
Exit lyx. Start lyx. Load a different document. Load the first doc.
Where is the cursor placed now?

| Index: src/lastfiles.C

Doesn't this almost double the size of lastfiles.C?
(I am just trying to prove that code complexity is not reduced it IMNO
increases a lot.)

Note that despite all my negativism I am super happy that you have
picked up this ball. This is a feature I have wanted for a long time,
but have never found the time to implement.

-- 
Lgb

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

[Bo Peng]

 I do not like this one bit.
 IMO completely ortogonal feature that happens to share some of the
 omplementation. IMHO you have just made a super simple LastFiles a lot
 more complex.

It is much more troublesome to have a separate implementation.
Afterall, lastfiles do mean information regarding files we have
edited.

 | Use pit() instead of id() now.

 You won't be able to please the cursor accurately then.

I do not understand why the cursor can not be placed accurately. But
it is good enough to scroll to the beginning of a paragraph so I can
actually ignore the cursor position part.

I also noticed some other problems:

1. Why closeBuffer() is not called when lyx exits through File-Exit?
I think I need to put view()-savePosition(0) somewhere else.

2. When a file is passed through commond line (lyx file.lyx), my patch
does automatically scroll to the  saved location but the file still
appears from the beginning. Why does this happen?

Cheers,
Bo

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

[Bo Peng]

 Alternatively, more similar to what you had earlier:

 int pit;
 int pos;
 boost::tie(pit, pos) = LyX::ref().lastfiles().loadFilePosition(s);

This is good to know.

 Can you please drop the bookmark part of the patch for now?
 If we decide that we do want bookmark[0] to be the position the cursor
 was in when the doc was last saved we can put this in later.
 (but... I just realized that you rely on this in your
 implementation... hmm)

No problem. I can copy part of restorePosition to here ...

 Just as a test... load a document move the cursor save.
 Exit lyx. Start lyx. Load a different document. Load the first doc.
 Where is the cursor placed now?

It will move to the position when the first file was closed. My test
goes well except that lyx file.lyx does not scroll as expected.

 Doesn't this almost double the size of lastfiles.C?
 (I am just trying to prove that code complexity is not reduced it IMNO
 increases a lot.)

I added about 50 lines. Now the code is 155 lines. A separate
fileposition.C will be this long as well, and we need to change the
lyx().lastfile() interface.

Cheers,
Bo

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

[Lars Gullik Bjønnes]

Bo Peng [EMAIL PROTECTED] writes:

|  I do not like this one bit.
|  IMO completely ortogonal feature that happens to share some of the
|  omplementation. IMHO you have just made a super simple LastFiles a lot
|  more complex.
| 
| It is much more troublesome to have a separate implementation.
| Afterall, lastfiles do mean information regarding files we have
| edited.

Only which files not any information about them.

And I am not going to stop bitching about using a separate file...

|  | Use pit() instead of id() now.
| 
|  You won't be able to please the cursor accurately then.
| 
| I do not understand why the cursor can not be placed accurately. But
| it is good enough to scroll to the beginning of a paragraph so I can
| actually ignore the cursor position part.

Don't you only look-up the outer paragraph list? What if the cursor is
nested (deeply) inside insets?

-- 
Lgb

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

[Lars Gullik Bjønnes]

Bo Peng [EMAIL PROTECTED] writes:

|  Just as a test... load a document move the cursor save.
|  Exit lyx. Start lyx. Load a different document. Load the first doc.
|  Where is the cursor placed now?
| 
| It will move to the position when the first file was closed. My test
| goes well except that lyx file.lyx does not scroll as expected.

The comment above aimed at the 'use par.id()' for lastpos situation.

pit is a lot more stable.

| 
|  Doesn't this almost double the size of lastfiles.C?
|  (I am just trying to prove that code complexity is not reduced it IMNO
|  increases a lot.)
| 
| I added about 50 lines. Now the code is 155 lines.

And of this some ~40 lines is copyrigh and headers. You have doubled
the code size of the file.

| A separate
| fileposition.C will be this long as well, and we need to change the
| lyx().lastfile() interface.

No. We need to have the last position feature in addition, not mixed
with lastfile.

-- 
Lgb

Re: [Qt4 bug] Branches dialog, small issue with alter color

[Georg Baum]

Am Mittwoch, 22. März 2006 17:18 schrieb Georg Baum:
 Yes. It would be a pity to ditch this code together with the xforms 
frontend
 if it is useful somewhere else.
 I think I am going to apply the patch this evening (will send Changelog
 then, too).

OK, here comes the patch + log. It is going in right now. The difference 
to the last one are only two comments and one mechanical change in 
bufferparams.C I had forgotten.


Georg

Log:

* src/frontends/xforms/Color.[Ch]: move to src

* src/Color.[Ch] (getRGBColor): move to src/frontends/*/lyx_gui.C

* src/BranchList.h
(Branch::color_): change type to lyx::RGBColor

* src/BranchList.[Ch]
(Branch): new constrcutor, set color_ to LColor::background
(getColor, setColor): adapt to type change of color_

* src/bufferparams.C
(BufferParams::writeFile): adapt to type change of branch color

* src/frontends/lyx_gui.h
* src/frontends/gtk/lyx_gui.C
* src/frontends/qt2/lyx_gui.C
* src/frontends/qt4/lyx_gui.C
* src/frontends/xforms/lyx_gui.C
(getRGBColor): move from src/Color.[Ch] here

* src/frontends/gtk/lyx_gui.C
* src/frontends/xforms/lyx_gui.C
(hexname): use getRGBColor

* src/frontends/gtk/GDocument.C
(update): adapt to type change of branch color
(apply): add comment about color chooser

* src/frontends/qt2/QDocumentDialog.C
(updateBranchView): adapt to type change of branch color
(toggleBranchColor): ditto

* src/frontends/qt2/lcolorcache.[Ch]
* src/frontends/qt4/lcolorcache.[Ch]
(rgb2qcolor): new utility function

* src/frontends/qt4/QBranches.C
(QBranches::update): adapt to type change of branch color
(QBranches::on_colorPB_clicked): ditto

* src/frontends/xforms/FormDocument.C
(get_current_color): adapt to type change of branch color
(FormDocument::branch_update):

* src/frontends/xforms/FormPreferences.C
(FormPreferences::Colors::LoadBrowse): adapt to RGBColor changes

* src/frontends/xforms/FormPreferences.h: remove unneeded RGBColor
forward declaration 

* src/frontends/xforms/XWorkArea.C
(XWorkArea::XWorkArea): adapt to RGBColor changes

* src/frontends/xforms/Makefile.am: remove Color.[Ch]

* src/frontends/xforms/FormColorpicker.[Ch]: adapt to RGBColor changes

* src/frontends/xforms/xformsImage.C: adapt to RGBColor changes

* src/frontends/controllers/ControlDocument.C
(ControlDocument::dispatchParams): adapt to type change of branch color

* src/Makefile.am: add Color.[Ch]
Index: src/Color.h
===
--- src/Color.h	(Revision 13453)
+++ src/Color.h	(Arbeitskopie)
@@ -18,16 +18,7 @@
 
 #include string
 
-class LColor_color;
-
 namespace lyx {
-namespace frontend {
-
-/** Given col, fills r, g, b in the range 0-255.
-The function returns true if successful.
-It returns false on failure and sets r, g, b to 0. */
-bool getRGBColor(LColor_color col,
-		 unsigned int  r, unsigned int  g, unsigned int  b);
 
 struct RGBColor;
 /// returns a string of form #rrggbb, given an RGBColor struct
@@ -78,7 +69,6 @@ bool operator!=(RGBColor const  c1, RGB
 	return !(c1 == c2);
 }
 
-} // namespace frontend
 } // namespace lyx
 
 #endif
Index: src/BranchList.C
===
--- src/BranchList.C	(Revision 13453)
+++ src/BranchList.C	(Arbeitskopie)
@@ -11,11 +11,19 @@
 #include config.h
 
 #include BranchList.h
+#include LColor.h
+#include frontends/lyx_gui.h
 #include algorithm
 
 using std::string;
 
 
+Branch::Branch()
+{
+	lyx_gui::getRGBColor(LColor::background, color_);
+}
+
+
 string const  Branch::getBranch() const
 {
 	return branch_;
@@ -43,18 +51,28 @@ bool Branch::setSelected(bool b)
 }
 
 
-string const  Branch::getColor() const
+lyx::RGBColor const  Branch::getColor() const
 {
 	return color_;
 }
 
 
-void Branch::setColor(string const  c)
+void Branch::setColor(lyx::RGBColor const  c)
 {
 	color_ = c;
 }
 
 
+void Branch::setColor(string const  c)
+{
+	if (c.size() == 7  c[0] == '#')
+		color_ = lyx::RGBColor(c);
+	else
+		// no color set or invalid color - use normal background
+		lyx_gui::getRGBColor(LColor::background, color_);
+}
+
+
 Branch * BranchList::find(std::string const  name)
 {
 	List::iterator it =
@@ -91,7 +109,6 @@ bool BranchList::add(string const  s)
 			Branch br;
 			br.setBranch(name);
 			br.setSelected(false);
-			br.setColor(none);
 			list.push_back(br);
 		}
 		if (j == string::npos)
Index: src/BranchList.h
===
--- src/BranchList.h	(Revision 13453)
+++ src/BranchList.h	(Arbeitskopie)
@@ -30,6 +30,8 @@
 #ifndef BRANCHES_H
 #define BRANCHES_H
 
+#include Color.h
+
 #include string
 #include list
 

Re: A Cygwin related patch

[Enrico Forestieri]

Georg Baum [EMAIL PROTECTED] writes:

 I think that you can safely call it unconditionally. I looked it up, and
 latex_path() is only called on filenames that are written to .tex files. I
 would be very surprised if a TeX compiler exists on windows that needs win
 style paths in \inputa at path but posix style paths in \includegraphics or
 \input.
 To be sure you could make a simple test: Call external_path()
 unconditionally, and try to view a document that contains a graphics inset,
 and two include insets, one with \input and one with \include. All files
 should be entered with absolute names.
 If my theory is right then running latex on the exported .tex file will work
 with the unconditional fix and fail with the conditional one.
 The absolute names are necessary to get slashes in the name, and running
 latex on the exported .tex file is necessary because LyX uses always
 relative paths for running latex internally.

Your theory is right and I wasn't fearless enough, not having the time
to study the code. So, the attached is apparently the right fix. While
testing this patch I run up against another bug.

1) File-New
2) Insert-File-Child Document   (say we input ~/test.tex)
3) File-Export-LaTeX

LyX pops up a dialog telling me that ~/test.tex already exists and
asking for overwriting it. I say yes, overwrite it, but newfile1.lyx
is normally created and ~/test.tex is not overwritten. This is
independent from the fact that the buffer has been given a name or not.
This also happens on Solaris and I could not find a similar bug
reported in bugzilla.
 
 PS: You might want to have a look at the cygwin version of external_path().
 It contains unreachable code.

Uhm, I don't think so. The code after else return p; gets executed when
the previous if() clause is satisfied.

Many thanks for your helpful and appreciated comments.

-- 
Enrico


Index: src/support/filetools.C
===
--- src/support/filetools.C (revision 13463)
+++ src/support/filetools.C (working copy)
@@ -86,7 +86,9 @@ string const latex_path(string const  o
latex_path_extension extension,
latex_path_dots dots)
 {
-   string path = subst(original_path, \\, /);
+   // The call to os::external_path is only needed for Cygwin.
+   string path = subst(os::external_path(original_path), \\, /);
+   path = rtrim(path, /);
path = subst(path, ~, \\string~);
if (path.find(' ') != string::npos) {
// We can't use '' because  is sometimes active (e.g. if

Re: A Cygwin related patch

[Georg Baum]

Am Donnerstag, 23. März 2006 21:26 schrieb Enrico Forestieri:

 Your theory is right and I wasn't fearless enough, not having the time
 to study the code. So, the attached is apparently the right fix. While
 testing this patch I run up against another bug.
 
 1) File-New
 2) Insert-File-Child Document   (say we input ~/test.tex)
 3) File-Export-LaTeX
 
 LyX pops up a dialog telling me that ~/test.tex already exists and
 asking for overwriting it. I say yes, overwrite it, but newfile1.lyx
 is normally created and ~/test.tex is not overwritten. This is
 independent from the fact that the buffer has been given a name or not.
 This also happens on Solaris and I could not find a similar bug
 reported in bugzilla.

I will have a look.

 Uhm, I don't think so. The code after else return p; gets executed 
when
 the previous if() clause is satisfied.

Oh yes, you are right.

 Many thanks for your helpful and appreciated comments.

I hope they are not too disappointing :-)

Unfortunately I have another one:

 Index: src/support/filetools.C
 ===
 --- src/support/filetools.C   (revision 13463)
 +++ src/support/filetools.C   (working copy)
 @@ -86,7 +86,9 @@ string const latex_path(string const  o
   latex_path_extension extension,
   latex_path_dots dots)
  {
 - string path = subst(original_path, \\, /);
 + // The call to os::external_path is only needed for Cygwin.
 + string path = subst(os::external_path(original_path), \\, /);

Here you basically revert external_path on non-cygwin windows. This is a 
bit ugly, so I moved this into a new function 
lyx::support::os::latex_path(). This is a noop except on cygwin, where it 
is identical to external_path().
Shall I put this in?


Georg
Index: src/support/os_unix.C
===
--- src/support/os_unix.C	(Revision 13467)
+++ src/support/os_unix.C	(Arbeitskopie)
@@ -63,6 +63,12 @@ string internal_path(string const  p)
 }
 
 
+string latex_path(string const  p)
+{
+	return p;
+}
+
+
 bool is_absolute_path(string const  p)
 {
 	return !p.empty()  p[0] == '/';
Index: src/support/os.h
===
--- src/support/os.h	(Revision 13467)
+++ src/support/os.h	(Arbeitskopie)
@@ -47,6 +47,14 @@ std::string external_path(std::string co
 /// Converts a host OS style path to unix style.
 std::string internal_path(std::string const  p);
 
+/**
+ * Converts a unix style path into a form suitable for inclusion in a LaTeX
+ * document.
+ * Caution: This function handles only the OS specific part of that task.
+ * Never use it directly, use lyx::support::latex_path instead.
+ */
+std::string latex_path(std::string const  p);
+
 /// Is the path absolute?
 bool is_absolute_path(std::string const  p);
 
Index: src/support/filetools.C
===
--- src/support/filetools.C	(Revision 13467)
+++ src/support/filetools.C	(Arbeitskopie)
@@ -87,6 +87,8 @@ string const latex_path(string const  o
 		latex_path_dots dots)
 {
 	string path = subst(original_path, \\, /);
+	// On cygwin, we may need windows or posix style paths.
+	path = os::latex_path(path);
 	path = subst(path, ~, \\string~);
 	if (path.find(' ') != string::npos) {
 		// We can't use '' because  is sometimes active (e.g. if
Index: src/support/os_win32.C
===
--- src/support/os_win32.C	(Revision 13467)
+++ src/support/os_win32.C	(Arbeitskopie)
@@ -216,6 +216,12 @@ string internal_path(string const  p)
 }
 
 
+string latex_path(string const  p)
+{
+	return p;
+}
+
+
 // (Claus H.) On Win32 both Unix and Win32/DOS pathnames are used.
 // Therefore an absolute path could be either a pathname starting
 // with a slash (Unix) or a pathname starting with a drive letter
Index: src/support/os_cygwin.C
===
--- src/support/os_cygwin.C	(Revision 13467)
+++ src/support/os_cygwin.C	(Arbeitskopie)
@@ -102,6 +102,15 @@ string internal_path(string const  p)
 }
 
 
+string latex_path(string const  p)
+{
+	// We may need a posix style path or a windows style path (depending
+	// on cygwin_path_fix_), but we use always forward slashes, since it
+	// gets written into a .tex file.
+	return external_path(p);
+}
+
+
 bool is_absolute_path(string const  p)
 {
 	if (p.empty())

Bug in most recent svn -stable branch

[Lodewijk Bonebakker]

When compiling lyx on Solaris 10, using an up-to-date gnu setup (updated 
autoconf, automake, etc). Compilation of the recent svn stable branch 
completes without problems.


At startup however, lyx displays the main window, reports a SIGSEGV, 
displays the 'please report a bug message' and core dumps.


The debugger reports:
#0 0xd09f1015 in _lwp_kill () from /usr/lib/libc.so.1

The following parameters were used for configure:
export LDFLAGS=-L/usr/lib
export CPPFLAGS=-I/usr/include
./configure --prefix=/opt/lyx/latest --with-x --with-frontend=xforms \
--with-packaging=posix --with-pic  --x-includes=/opt/sfw/include \
--x-libraries=/opt/sfw/lib --with-pspell=no --disable-static \
--enable-shared

RESULT=$?
if [ $RESULT -eq 0 ]; then
gmake
fi


I am now in the process of making a debug build.


Any suggestions?

Kind regards,

Lodewijk Bonebakker

[patch] fix layout2layout

[Georg Baum]

The attached patch is the outcome of a discussion with Jean-Marc at
http://bugzilla.lyx.org/show_bug.cgi?id=2355. The problem is that I did 
not realize that TocLevel was a new keyword when I wrote layout2layout.

This patch adds this keyword for sectioning styles. Comments?


Georg
Index: lib/scripts/layout2layout.py
===
--- lib/scripts/layout2layout.py	(Revision 13467)
+++ lib/scripts/layout2layout.py	(Arbeitskopie)
@@ -60,7 +60,7 @@ def convert(lines):
 re_Format = re.compile(r'^(\s*)(Format)(\s+)(\S+)', re.IGNORECASE)
 re_Preamble = re.compile(r'^(\s*)Preamble', re.IGNORECASE)
 re_EndPreamble = re.compile(r'^(\s*)EndPreamble', re.IGNORECASE)
-re_MaxCounter = re.compile(r'^\s*MaxCounter', re.IGNORECASE)
+re_MaxCounter = re.compile(r'^(\s*)(MaxCounter)(\s+)(\S+)', re.IGNORECASE)
 re_LabelType = re.compile(r'^(\s*)(LabelType)(\s+)(\S+)', re.IGNORECASE)
 re_LatexType = re.compile(r'^(\s*)(LatexType)(\s+)(\S+)', re.IGNORECASE)
 re_Style = re.compile(r'^(\s*)(Style)(\s+)(\S+)', re.IGNORECASE)
@@ -72,6 +72,7 @@ def convert(lines):
 space1 = 
 latextype_line = -1
 style = 
+maxcounter = 0
 while i  len(lines):
 
 # Skip comments and empty lines
@@ -101,7 +102,27 @@ def convert(lines):
 continue
 
 # Delete MaxCounter
-if re_MaxCounter.match(lines[i]):
+match = re_MaxCounter.match(lines[i])
+if match:
+level = match.group(4)
+if string.lower(level) == counter_chapter:
+maxcounter = 0
+elif string.lower(level) == counter_section:
+maxcounter = 1
+elif string.lower(level) == counter_subsection:
+maxcounter = 2
+elif string.lower(level) == counter_subsubsection:
+maxcounter = 3
+elif string.lower(level) == counter_paragraph:
+maxcounter = 4
+elif string.lower(level) == counter_subparagraph:
+maxcounter = 5
+elif string.lower(level) == counter_enumi:
+maxcounter = 6
+elif string.lower(level) == counter_enumii:
+maxcounter = 7
+elif string.lower(level) == counter_enumiii:
+maxcounter = 8
 del lines[i]
 continue
 
@@ -126,6 +147,8 @@ def convert(lines):
 
 # Add a line LatexType Bib_Environment if LabelType is Bibliography
 # (or change the existing LatexType)
+#
+# Add the TocLevel setting for sectioning styles
 match = re_LatexType.match(lines[i])
 if match:
 latextype_line = i
@@ -135,12 +158,32 @@ def convert(lines):
 label = 
 space1 = 
 latextype_line = -1
-if re_End.match(lines[i]) and string.lower(label) == bibliography:
-if (latextype_line  0):
-lines.insert(i, %sLatexType Bib_Environment % space1)
+if re_End.match(lines[i]):
+if string.lower(label) == bibliography:
+if (latextype_line  0):
+lines.insert(i, %sLatexType Bib_Environment % space1)
+i = i + 1
+else:
+lines[latextype_line] = re_LatexType.sub(r'\1\2\3Bib_Environment', lines[latextype_line])
+if (maxcounter == 0 and
+(string.lower(style) == chapter or string.lower(style) == part)):
+lines.insert(i, %sTocLevel 0 % space1)
+i = i + 1
+elif maxcounter = 1 and string.lower(style) == section:
+lines.insert(i, %sTocLevel 1 % space1)
+i = i + 1
+elif maxcounter = 2 and string.lower(style) == subsection:
+lines.insert(i, %sTocLevel 2 % space1)
+i = i + 1
+elif maxcounter = 3 and string.lower(style) == subsubsection:
+lines.insert(i, %sTocLevel 3 % space1)
+i = i + 1
+elif maxcounter = 4 and string.lower(style) == paragraph:
+lines.insert(i, %sTocLevel 4 % space1)
+i = i + 1
+elif maxcounter = 5 and string.lower(style) == subparagraph:
+lines.insert(i, %sTocLevel 5 % space1)
 i = i + 1
-else:
-lines[latextype_line] = re_LatexType.sub(r'\1\2\3Bib_Environment', lines[latextype_line])
 
 i = i + 1
 

Re: A Cygwin related patch

[Enrico Forestieri]

Georg Baum [EMAIL PROTECTED] writes:

  Many thanks for your helpful and appreciated comments.
 
 I hope they are not too disappointing 

Oh, not at all...

 Here you basically revert external_path on non-cygwin windows. This is a 
 bit ugly, so I moved this into a new function 
 lyx::support::os::latex_path(). This is a noop except on cygwin, where it 
 is identical to external_path().
 Shall I put this in?

It's very elegant. Please do.

-- 
Enrico

Possible charstyle bug

[Markus Mayer]

Hi,

I think I may have found a bug in the way character styles are handled.
See attached sample document and sample styles.

If a character style is used in an itemize environment, LyX
genereates LaTeX code like this:

\begin{itemize}
\item item 1
\item item 2
\item item 3 has a \texttt{\begin{itemize}
\item command
\end{itemize}
} and then some more text
...

That's not the intention. There is no reason to repeat itemize inside
the command character style. It should have been

\begin{itemize}
\item item 1
\item item 2
\item item 3 has a \texttt{command} and then some more text
...

But not only does LyX generate a nested itemize structure, it also
displays it like that (no line breaks around command, but a - in
front of it to symbolize the 2nd level of itemize).

Regards,
Markus
#% Do not delete the line below; configure depends on this
#  \DeclareLaTeXClass[article]{MM Article}
# Markus' Article textclass definition file.
# Author : Markus Mayer

Input article.layout
Input mm_charstyles.inc
# Textclass definition file for article.
# Character Styles definition

Format 2

CharStyle filename
LatexType Command
LatexName textsf
Font
  Family  Sans
EndFont
LabelFont
  Family  Roman
  Color   blue
EndFont
End

CharStyle variable
LatexType Command
LatexName textsf
Font
  Family  Sans
EndFont
LabelFont
  Family  Roman
  Color   blue
EndFont
End

CharStyle command
LatexType Command
LatexName texttt
Font
  Family  Typewriter
EndFont
LabelFont
  Family  Roman
  Color   blue
EndFont
End

CharStyle code
LatexType Command
LatexName texttt
Font
  Family  Typewriter
EndFont
LabelFont
  Family  Roman
  Color   blue
EndFont
End
#LyX 1.4.0 created this file. For more info see http://www.lyx.org/
\lyxformat 245
\begin_document
\begin_header
\textclass mm_article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\spacing single
\papersize default
\use_geometry false
\use_amsmath 1
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\end_header

\begin_body

\begin_layout Standard
Enumeration test
\end_layout

\begin_layout Itemize
item 1
\end_layout

\begin_layout Itemize
item 2
\end_layout

\begin_layout Itemize
item 3 has a 
\begin_inset CharStyle command
status inlined

\begin_layout Itemize
command
\end_layout

\end_inset

 and then some more text
\end_layout

\begin_layout Itemize
item 4 has a 
\begin_inset CharStyle filename
status inlined

\begin_layout Itemize
filename
\end_layout

\end_inset

 and then some more text
\end_layout

\begin_layout Itemize
item 5
\end_layout

\begin_layout Standard
That's it.
\end_layout

\end_body
\end_document


charstyle-bug.tex
Description: TeX document

Re: Bug in most recent svn -stable branch

[Lars Gullik Bjønnes]

Lodewijk Bonebakker [EMAIL PROTECTED] writes:

| When compiling lyx on Solaris 10, using an up-to-date gnu setup
| (updated autoconf, automake, etc). Compilation of the recent svn
| stable branch completes without problems.
| 
| At startup however, lyx displays the main window, reports a SIGSEGV,
| displays the 'please report a bug message' and core dumps.
| 
| The debugger reports:
| #0 0xd09f1015 in _lwp_kill () from /usr/lib/libc.so.1

Was this all you got?

| The following parameters were used for configure:
| export LDFLAGS=-L/usr/lib
| export CPPFLAGS=-I/usr/include
| ./configure --prefix=/opt/lyx/latest --with-x --with-frontend=xforms \
| --with-packaging=posix --with-pic  --x-includes=/opt/sfw/include \
| --x-libraries=/opt/sfw/lib --with-pspell=no --disable-static \
| --enable-shared

Please drop these two: --disable-static --enable-shared
they are not doing what you tink they do.
(probably drop --with-pic as well)

-- 
Lgb

LyX/Win 1.4.1 pre 1

[Paul A. Rubin]

Just installed 1.4.1pre1 on another machine (Win XP Pro) and noticed a 
couple of things.


1.  While the configuration script was running, I noticed the following 
output:


Checking for a LaTeX - LyX converter
+checking for /c/Program ... no

That 'no' doesn't surprise me.  I'm not sure what it's looking for, but 
it appears that C:\Program Files got thunked somewhere.  Not having any 
.tex files to convert (nor any desire to), I have no idea if this is 
affecting anything.



2.  All three screen fonts (Roman, San Serif, Typewriter) defaulted to 
something semi-hideous called 'MS Shell Dlg'.  Deliberate?  The 
Qt/WinFree people playing with us again?


/Paul

Re: Possible charstyle bug

[Markus Mayer]

Hi,

I just tried editing the .lyx file manually changing

\begin_inset CharStyle command
status inlined

\begin_layout Itemize
command
\end_layout

\end_inset
to
\begin_inset CharStyle command
status inlined

\begin_layout Standard
command
\end_layout

\end_inset
and that fixed everything. The text is now displayed properly (no more
hyphen to symbolize nested itemizing) and the LaTeX code is also
correct.

That means things go wrong when character styles are *added* to an
itemize structure.

Regards,
Markus

Re: configure failure... (latest CVS) missing file?

[Lars Gullik Bjønnes]

Kayvan A. Sylvan [EMAIL PROTECTED] writes:

| Yes. This gets me past the initial problem. Now there is a link issue (see
| my other email).

I am unable to find your other mail, can you repost?

-- 
Lgb

Re: Bug in most recent svn -stable branch

[Enrico Forestieri]

Lodewijk Bonebakker [EMAIL PROTECTED] writes:
 
 When compiling lyx on Solaris 10, using an up-to-date gnu setup (updated 
 autoconf, automake, etc). Compilation of the recent svn stable branch 
 completes without problems.
 
 At startup however, lyx displays the main window, reports a SIGSEGV, 
 displays the 'please report a bug message' and core dumps.

I have no problems compiling LyX 1.4.x on Solaris 10 (sparc).

 The debugger reports:
 #0 0xd09f1015 in _lwp_kill () from /usr/lib/libc.so.1
 
 The following parameters were used for configure:
 export LDFLAGS=-L/usr/lib
 export CPPFLAGS=-I/usr/include
 ./configure --prefix=/opt/lyx/latest --with-x --with-frontend=xforms \
 --with-packaging=posix --with-pic  --x-includes=/opt/sfw/include \
 --x-libraries=/opt/sfw/lib --with-pspell=no --disable-static \
 --enable-shared

Your --x-includes and --x-libraries look suspicious, drop them.
However, you may need --with-extra-lib=/usr/X11/lib

 RESULT=$?
 if [ $RESULT -eq 0 ]; then
  gmake
 fi
 
 I am now in the process of making a debug build.
 
 Any suggestions?

I think that your configure options are wrong.

-- 
Enrico

Potential 1.4 patches

[Michael Gerz]

Hi,

my new hobby-horse: Keeping track of patches to the trunk that may also 
be relevant for LyX 1.4.X :-)


Michael

=

Change Tracking

r13339 - Fix bug 880, or the multi-paragraph change tracking patch
r13356 - fix painting of change bar with only paragraph break changed
r13385 - Change tracking -related bug fixes (reported by Juergen)
r13408 - fix stripLeadingSpaces mechanism with change tracking enabled
r13422 - Fix changebar non-update (Juergen)

Performance

r13328 - Fix bug 2195: Slowness in rendering inside insets, especially 
on the Mac

r13415 - Changes to the within-inset row rendering caching code
r13418 - expand redrawing of current row to endpos() AGAIN
r13420 - constify; remove unneeded casts

r13467 - LGB - ParagraphList

Various

r13432 - MV - Selective expose patch
r13434 - AY - replace hard-coded /tmp with package().temp_dir()
=

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

[Bo Peng]

 No. We need to have the last position feature in addition, not mixed
 with lastfile.

OK, since you insist, here comes a much larger patch.

The patch works on my system. However, there are two problems that
make this feature almost useless. Please help me resolve them.

1. Alt-F4 and close-button do not trigger LDUNC_QUIT or bufferClose()
so position will not be saved. Note that Alt-F4 is marked as a
shortcut for File-Exit but it behaves differently than File-Exit.

2. If a filename is passed to lyx as 'lyx file.lyx', the cursor will
be moved by my patch, but then moved back by some unknown mechanism
(seems to be some GUI stuff). This is a big drawback since this is the
main way I start lyx.

Cheers,
Bo
Index: src/lyx_cb.C
===
--- src/lyx_cb.C	(revision 13470)
+++ src/lyx_cb.C	(working copy)
@@ -23,6 +23,7 @@
 #include debug.h
 #include gettext.h
 #include lastfiles.h
+#include filepositions.h
 #include LaTeXFeatures.h
 #include lyx_main.h
 #include lyxlayout.h
@@ -197,6 +198,7 @@
 			return;
 
 		LyX::cref().lastfiles().writeFile(lyxrc.lastfiles);
+		LyX::cref().filepositions().writeFile(lyxrc.filepositions);
 	}
 
 	// Set a flag that we do quitting from the program,
Index: src/BufferView_pimpl.C
===
--- src/BufferView_pimpl.C	(revision 13470)
+++ src/BufferView_pimpl.C	(working copy)
@@ -43,6 +43,7 @@
 #include lyxtext.h
 #include lyxrc.h
 #include lastfiles.h
+#include filepositions.h
 #include metricsinfo.h
 #include paragraph.h
 #include paragraph_funcs.h
@@ -293,6 +294,23 @@
 
 	setBuffer(b);
 	bv_-showErrorList(_(Parse));
+
+	// scroll to the position when the file was last closed
+	if (lyxrc.use_filepos) {
+		lyx::pit_type pit = LyX::ref().filepositions().loadFilePosition(s);
+		// move to the beginning of that paragraph
+		// be careful since the file may have been externally changed ...
+		if ( static_castsize_t(pit)  b-paragraphs().size() ) {
+			cursor_.clearSelection();
+			ParIterator it = b-par_iterator_begin();
+			ParIterator const end = b-par_iterator_end();
+			for (; it != end; ++it)
+if (it.pit() == pit)
+	break;
+			if (it != end)		
+bv_-setCursor(makeDocIterator(it, 0));
+		}
+	}
 
 	if (tolastfiles)
 		LyX::ref().lastfiles().newFile(b-fileName());
@@ -767,7 +785,12 @@
 	saved_positions[i] = Position(buffer_-fileName(),
   cursor_.paragraph().id(),
   cursor_.pos());
-	if (i  0)
+	// if i == 0, (called when this buffer is closed), 
+	// save current paragraph pit to filepositions
+	if (i == 0)
+		LyX::ref().filepositions().saveFilePosition(buffer_-fileName(),
+cursor_.pit() );
+	else
 		owner_-message(bformat(_(Saved bookmark %1$d), i));
 }
 
Index: src/lyxfunc.C
===
--- src/lyxfunc.C	(revision 13470)
+++ src/lyxfunc.C	(working copy)
@@ -996,6 +996,11 @@
 			break;
 
 		case LFUN_QUIT:
+			// with this, File-exit will save Position,
+			// however, Alt-F4 and close-button do not go 
+			// through here ...
+			if (view()-available())
+view()-savePosition(0);
 			QuitLyX(argument == force);
 			break;
 
@@ -1880,6 +1885,8 @@
 
 void LyXFunc::closeBuffer()
 {
+	// save current position to lastfile
+	view()-savePosition(0);
 	if (bufferlist.close(owner-buffer(), true)  !quitting) {
 		if (bufferlist.empty()) {
 			// need this otherwise SEGV may occur while
@@ -2008,6 +2015,7 @@
 	case LyXRC::RC_LANGUAGE_PACKAGE:
 	case LyXRC::RC_LANGUAGE_USE_BABEL:
 	case LyXRC::RC_LASTFILES:
+	case LyXRC::RC_FILEPOSITIONS:
 	case LyXRC::RC_MAKE_BACKUP:
 	case LyXRC::RC_MARK_FOREIGN_LANGUAGE:
 	case LyXRC::RC_NUMLASTFILES:
Index: src/Makefile.am
===
--- src/Makefile.am	(revision 13470)
+++ src/Makefile.am	(working copy)
@@ -191,6 +191,8 @@
 	language.h \
 	lastfiles.C \
 	lastfiles.h \
+	filepositions.C \
+	filepositions.h \
 	layout.h \
 	lengthcommon.C \
 	lengthcommon.h \
Index: src/lyxrc.C
===
--- src/lyxrc.C	(revision 13470)
+++ src/lyxrc.C	(working copy)
@@ -26,6 +26,7 @@
 #include format.h
 #include gettext.h
 #include lastfiles.h
+#include filepositions.h
 #include LColor.h
 #include lyxlex.h
 #include lyxfont.h
@@ -105,6 +106,8 @@
 	{ \\language_package, LyXRC::RC_LANGUAGE_PACKAGE },
 	{ \\language_use_babel, LyXRC::RC_LANGUAGE_USE_BABEL },
 	{ \\lastfiles, LyXRC::RC_LASTFILES },
+	{ \\use_filepos, LyXRC::RC_USEFILEPOS },
+	{ \\filepositions, LyXRC::RC_FILEPOSITIONS },
 	{ \\make_backup, LyXRC::RC_MAKE_BACKUP },
 	{ \\mark_foreign_language, LyXRC::RC_MARK_FOREIGN_LANGUAGE },
 	{ \\num_lastfiles, LyXRC::RC_NUMLASTFILES },
@@ -246,6 +249,7 @@
 	ascii_linelen = 65;
 	num_lastfiles = maxlastfiles;
 	check_lastfiles = true;
+	use_filepos = true;
 	make_backup = true;
 	backupdir_path.erase();
 	display_graphics = 

Re: Possible charstyle bug

[Martin Vermeer]

On Thu, Mar 23, 2006 at 01:31:03PM -0800, Markus Mayer wrote:
 Hi,
 
 I think I may have found a bug in the way character styles are handled.
 See attached sample document and sample styles.
 
 If a character style is used in an itemize environment, LyX
 genereates LaTeX code like this:
 
 \begin{itemize}
 \item item 1
 \item item 2
 \item item 3 has a \texttt{\begin{itemize}
 \item command
 \end{itemize}
 } and then some more text
 ...
 
 That's not the intention. There is no reason to repeat itemize inside
 the command character style. It should have been
 
 \begin{itemize}
 \item item 1
 \item item 2
 \item item 3 has a \texttt{command} and then some more text
 ...
 

Ah. So we have to add a forceDefaultParagraphs = true definition...

- Martin



pgpno73q80IKK.pgp
Description: PGP signature

Re: Potential 1.4 patches

[Juergen Spitzmueller]

Am Freitag, 24. März 2006 00:38 schrieb Michael Gerz:
 Change Tracking

 r13339 - Fix bug 880, or the multi-paragraph change tracking patch
 r13356 - fix painting of change bar with only paragraph break changed
 r13385 - Change tracking -related bug fixes (reported by Juergen)
 r13408 - fix stripLeadingSpaces mechanism with change tracking enabled
 r13422 - Fix changebar non-update (Juergen)

This is all combined in this patch for 1.4.:
http://bugzilla.lyx.org/attachment.cgi?id=1036action=view
Even if it is probably rather sheduled for 1.4.2, some testing (apart from 
what Martin I I have done) would be nice.

Jürgen

Re: [PATCH} Was: Feature request: Remember the editing location when a file is closed.

[Lars Gullik Bjønnes]

Bo Peng [EMAIL PROTECTED] writes:

|  No. We need to have the last position feature in addition, not mixed
|  with lastfile.
| 
| OK, since you insist, here comes a much larger patch.

I like this patch a lot better. Thanks for doing this.

One thing we should think about though; not caused by this patch, but
releated to it:

We have 'lastfiles' and 'lastpos' as configurable filenames, I am not
sure that they should be. IMHO we should just hardcode them. Opinions
on that?
 
| The patch works on my system. However, there are two problems that
| make this feature almost useless. Please help me resolve them.
 
| 1. Alt-F4 and close-button do not trigger LDUNC_QUIT or bufferClose()
| so position will not be saved. Note that Alt-F4 is marked as a
| shortcut for File-Exit but it behaves differently than File-Exit.

This not triggering, is it the same on all frontends?
 
| 2. If a filename is passed to lyx as 'lyx file.lyx', the cursor will
| be moved by my patch, but then moved back by some unknown mechanism
| (seems to be some GUI stuff). This is a big drawback since this is the
| main way I start lyx.

Ok, we need to investigate a bit.
Could it be that a -setCursor is also called later, so that your
setting is overwritten?

| Index: src/BufferView_pimpl.C
| ===
| --- src/BufferView_pimpl.C(revision 13470)
| +++ src/BufferView_pimpl.C(working copy)
| @@ -293,6 +294,23 @@
|  
|   setBuffer(b);
|   bv_-showErrorList(_(Parse));
| +
| + // scroll to the position when the file was last closed
| + if (lyxrc.use_filepos) {
| + lyx::pit_type pit = 
LyX::ref().filepositions().loadFilePosition(s);
| + // move to the beginning of that paragraph
| + // be careful since the file may have been externally changed 
...
| + if ( static_castsize_t(pit)  b-paragraphs().size() ) {
| + cursor_.clearSelection();
| + ParIterator it = b-par_iterator_begin();
| + ParIterator const end = b-par_iterator_end();
| + for (; it != end; ++it)
| + if (it.pit() == pit)
| + break;
| + if (it != end)  
| + bv_-setCursor(makeDocIterator(it, 0));

I am not sure that the look is needed (even for safety).
I think that a it = b-paragraphs()[pit] would be enough.
(might have to be written as something else, but eh above would be the
meaning.)

Also, is the clearSelection ever needed? This is upon file load. Can a
selection ever be set?

| @@ -767,7 +785,12 @@
|   saved_positions[i] = Position(buffer_-fileName(),
| cursor_.paragraph().id(),
| cursor_.pos());
| - if (i  0)
| + // if i == 0, (called when this buffer is closed), 
| + // save current paragraph pit to filepositions
| + if (i == 0)
| + LyX::ref().filepositions().saveFilePosition(buffer_-fileName(),
| + cursor_.pit() );
| + else
|   owner_-message(bformat(_(Saved bookmark %1$d), i));
|  }

As said I don't like this mix of features, but as it is strictly an
internal thing, let's handle that one later.

(I am dreaming of a .lyx/bookmarks file as well.)

| Index: src/filepositions.C
| ===
| --- src/filepositions.C   (revision 0)
| +++ src/filepositions.C   (revision 0)
| @@ -0,0 +1,86 @@
| +/**
| + * \file filespositions.C
| + * This file is part of LyX, the document processor.
| + * Licence details can be found in the file COPYING.
| + *
| + * \author Bo Peng
| + *
| + * Full author contact details are available in file CREDITS.
| + */
| +
| +#include config.h
| +
| +#include filepositions.h
| +#include debug.h
| +
| +#include boost/filesystem/operations.hpp
| +
| +#include fstream
| +#include sstream
| +
| +using std::getline;
| +using std::string;
| +using std::ifstream;
| +using std::ofstream;
| +using std::endl;
| +using std::istringstream;
| +
| +FilePositions::FilePositions(string const  filename)
| + : num_positions(100)
| +{
| + readFile(filename);
| +}
| +
| +void FilePositions::readFile(string const  filename)
| +{
| + // we will not complain if we can't find filename nor will
| + // we issue a warning. (Lgb)
| + ifstream ifs(filename.c_str());
| + string tmp;
| +
| + while (getline(ifs, tmp)  file_positions.size()  num_positions ) {
| + // pos, filename\n
| + FilePos pos;
| + string fname;
| + istringstream itmp(tmp);
| + itmp  pos;
| + itmp.ignore(2);  // ingore ,

Typo in comment. Also are you not ignoring , ?

| +void FilePositions::saveFilePosition(string const fname, FilePos
| pos )

space before '' please

| +{
| + 

Re: LyX 1.5 crash while scrolling

[Juergen Spitzmueller]

Georg Baum wrote:
> This smells like a boost thing. Does it happen also if you compile against
> system boost? Do you have that at all? 

No, I haven't installed that currently. Anyway, I think SuSE 10 ships the same 
version than LyX 1.5 (1.33.1).

> Or maybe with the boost directory 
> of 1.4?

How can I compile against that?
What is the procedure anyway? Does it use system boost if it finds it and 
--with-included-boost is not used?

Jürgen

Re: [patch] remove wheel mouse ui from qt2

[Georg Baum]

Juergen Spitzmueller wrote:

> The attached patch finally eliminates the gui element.
> I did not touch qt4, since Abdel is reorganizing the Prefs dialog
> currently. Abdel, while you are at it, could you please remove the wheel
> mouse spinbox?
> 
> OK to apply to branch and trunk?

I would think so. Since the system wheel setting is obeyed now it is only
logical to remove this setting in the same release (1.4.1).
It would be nice if you could lookup whether gtk uses this setting at all,
and make a comment in lyxrc.h stating which frontedns actually use
wheel_jump.


Georg

Re: LyX 1.5 crash while scrolling

[Georg Baum]

Juergen Spitzmueller wrote:

> Georg Baum wrote:
>> Or maybe with the boost directory
>> of 1.4?
> 
> How can I compile against that?

I think it would work if you temporarily exchange the boost subdirectory of
LyX with that of 1.4, but I am not sure. Of course you should rerun
autogen.sh etc. and do a full rebuild, because normal file date based
dependency tracking will not work.

> What is the procedure anyway? Does it use system boost if it finds it and
> --with-included-boost is not used?

No, you have to explicitly request --without-included-boost.


Georg

Re: [Pre-Patch] Was: Feature request: Remember the editing location when a file is closed.

[Georg Baum]

Martin Vermeer wrote:

> On Wed, 2006-03-22 at 23:19 -0600, Bo Peng wrote:
>> Dear list,
>> 
>> It does not look so difficult to implement this feature so I tried to
>> implement it by myself. Attached is my patch. Since I rarely submit a
>> patch here so I am afraid that there might be many problems (format,
>> logic, bugs). Please have a look and give me some feedbacks.
> 
> Format looks OK. The logic is a bit ad-hoc, but that comes with the
> territory.
> 
> Others may give detailed feedback on the code.
> 
>> Many files have been modified:
>> 
>> src/BufferView_pimpl.C
>> When a new buffer is loaded, it tries to get last cursor position from
>> ref().lastfiles(). When a file is going to be closed, current location
>> is saved as bookmark 0, and to ref().lastfiles(). A side effect of
>> this is that a file can be re-opened (and to the same location) from
>> bookmark 0.

I think that this is a very sensible approach. I would avoid to store this
information in the lyx file itself (privacy). Currently ezxchanging .lyx
files is safe because they don't carry aany hidden information, and I would
like it to stay like that.

>> src/lastfiles.C:
>> I do not want to change the Files structure so I use a map to store
>> position information. lastfile format is changed to "
>> filename" if position information is available, and "filename" if not.
> 
> Would it be easier to always have the  filename format? And id
> = pos = 0 if no valid info exists, so current behaviour is reproduced?

I agree.

>> 1. Will invalid paragraph id, pos crash lyx? I mean, if a file is
>> saved (with id, pos saved locally), and is modified externally (get a
>> revised copy from others), id, pos will no longer be valid and "goto
>> bookmark 0" will fail.

This should be explicitly handled after the file is read: Check for invalid
bookmarks, and delete them.

> This is a file format change and lyx2lyx must be made to handle it.

Why? I dont' see a format change.

>> 2. Save position does not seem to work when I quit lyx by closing the
>> lyx window. Only close-buffer will do. Where should I handle the close
>> event?
> 
> Don't bother. That's not the way to leave LyX.

I disagree. I once had to tutor a lab course where a program was used that
did strange things if it was closed via thw close button. It was very hard
to get the students used to that. IMO the close button should t=do exactly
the same as File->Quit. Everything else would confuse users.


Georg

Re: A Cygwin related patch

[Georg Baum]

Enrico Forestieri wrote:

> The attached patch fixes the bug reported here:
> http://thread.gmane.org/gmane.editors.lyx.general/29227
> 
> In my intention this is the first of a series of patches aimed at
> polishing the Cygwin target, which I think is lagging behind. Please, tell
> me if this ok with you. I have no problem in maintaining the Cygwin target
> but my time is limited so I cannot guarantee a continuous commitment. I
> will do it time permitting. There should be no big problems, as I think
> the Cygwin users will not be more than those I can count with only one of
> my hands ;-)

This patch looks good. I don't like the other one, because the code in
filetools.C is more complicated, and in this one it is more clear because
of cygwin_path_fix().

> Do you prefer that I file this one on bugzilla?

I think it is there already: http://bugzilla.lyx.org/show_bug.cgi?id=2409 Or
do you fix something else?


Georg

Re: [PATCH] better support for classes that do not define a ToC

[Jose' Matos]

On Wednesday 22 March 2006 20:06, Georg Baum wrote:
> I think you should put that in. Even if we are going to fix the xurrent
> problems it will LyX make more robust wrt incomoplete layout files, which
> is a Good Thing (TM).

  I agree, otherwise layouts looks like black magic for users. Really. :-)
 
> Georg

-- 
José Abílio

Re: Feature request: Remember the editing location when a file is closed.

[Jean-Marc Lasgouttes]

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

christian> On Wed, 22 Mar 2006, Bo Peng wrote:
>> Dear list,
>> 
>> I am not sure if others will like this idea. When I edit a long
>> file, it may be troublesome to locate and continue from where I was
>> working on, after the file is re-opened. I would be happy if lyx
>> can automatically goes to the page at which lyx was closed.
>> 
>> I can think of two ways to do this:
>> 
>> 1. (More intrusive). Remember the location under .lyx and jump to
>> it when a lyx file is opened. I think this is what vim is doing.

christian> For good or worse, this also means that when working with
christian> someone else on the same file (that's sent back and forth,
christian> or under version control), you'll open it up where the
christian> other person left off...

Not if the data is saved in .lyx/ directory.

>> 2. (Less intrusive). Save bookmark with the lyx file. A user can
>> save bookmark, close the file, and go to the bookmark after the
>> file is re-opened.

christian> Maybe file a bugzilla report? Or if you're brave, discss
christian> which of the options would be best on the user's list :-)

I would not be surprised to see that this bug already exists.

JMarc

Re: Feature request: Remember the editing location when a file is closed.

[Jose' Matos]

On Wednesday 22 March 2006 22:44, [EMAIL PROTECTED] wrote:
> On Wed, 22 Mar 2006, Bo Peng wrote:
> > Dear list,
> >
> > I am not sure if others will like this idea. When I edit a long file,
> > it may be troublesome to locate and continue from where I was working
> > on, after the file is re-opened. I would be happy if lyx can
> > automatically goes to the page at which lyx was closed.
> >
> > I can think of two ways to do this:
> >
> > 1. (More intrusive). Remember the location under .lyx and jump to it
> > when a lyx file is opened. I think this is what vim is doing.
>
> For good or worse, this also means that when working with someone else on
> the same file (that's sent back and forth, or under version control),
> you'll open it up where the other person left off...

  Lars suggested that those values could be saved on .lyx directory. That 
would serve both purposes. :-)

> > 2. (Less intrusive). Save bookmark with the lyx file. A user can save
> > bookmark, close the file, and go to the bookmark after the file is
> > re-opened.
>
> Maybe file a bugzilla report? Or if you're brave, discss which of the
> options would be best on the user's list :-)

  This feature is orthogonal to the one above. Should bookmarks be persistent?

> /C

-- 
José Abílio

Re: [patch] remove wheel mouse ui from qt2

[Jean-Marc Lasgouttes]

> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:

Juergen> The attached patch finally eliminates the gui element. I did
Juergen> not touch qt4, since Abdel is reorganizing the Prefs dialog
Juergen> currently. Abdel, while you are at it, could you please
Juergen> remove the wheel mouse spinbox?

Juergen> OK to apply to branch and trunk?

Definitely yes :)

JMarc

Re: Feature request: Remember the editing location when a file is closed.

[christian . ridderstrom]

On Thu, 23 Mar 2006, Jean-Marc Lasgouttes wrote:

> >> I can think of two ways to do this:
> >> 
> >> 1. (More intrusive). Remember the location under .lyx and jump to
> >> it when a lyx file is opened. I think this is what vim is doing.
> 
> christian> For good or worse, this also means that when working with
> christian> someone else on the same file (that's sent back and forth,
> christian> or under version control), you'll open it up where the
> christian> other person left off...
> 
> Not if the data is saved in .lyx/ directory.

Oops... I put my reply under the wrong solution. Just in case it's not
obvious to everybody, my comment should refer to when saving the bookmarks 
to the .lyx-file, not the .lyx-directory.

> >> 2. (Less intrusive). Save bookmark with the lyx file. A user can
> >> save bookmark, close the file, and go to the bookmark after the
> >> file is re-opened.

/C

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

Re: [patch] remove wheel mouse ui from qt2

[Juergen Spitzmueller]

Georg Baum wrote:
> I would think so. Since the system wheel setting is obeyed now it is only
> logical to remove this setting in the same release (1.4.1).
> It would be nice if you could lookup whether gtk uses this setting at all,
> and make a comment in lyxrc.h stating which frontedns actually use
> wheel_jump.

I cannot compile gtk.
I have committed the changes to qt2.

Jürgen

Re: A Cygwin related patch

[Enrico Forestieri]

Martin Vermeer <[EMAIL PROTECTED]> writes:
> 
> On Wed, Mar 22, 2006 at 09:29:35PM +, Enrico Forestieri wrote:
> > The attached patch fixes the bug reported here:
> > http://thread.gmane.org/gmane.editors.lyx.general/29227
> > 
> > In my intention this is the first of a series of patches aimed at polishing
> > the Cygwin target, which I think is lagging behind. Please, tell me if this
> > ok with you. I have no problem in maintaining the Cygwin target but my time
> > is limited so I cannot guarantee a continuous commitment. I will do it time
> > permitting. There should be no big problems, as I think the Cygwin users
> > will not be more than those I can count with only one of my hands 
> 
> You would be amazed by the true number of LyX/Windows users...

I have no doubt, but somehow I have the idea that LyX/Cygwin users are
a niche. However, I maybe wrong.

> Unfortunately I am unable / cannot be bothered to work on that, but I am
> really happy somebody does. LyX adoption benefits greatly by having the
> option of cross-platform collaborative authoring. And some people are
> stuck on Windows.
> 
> BTW some of us are hit by symptoms like compulsive hand washing after
> touching Windows. Another reason for admiring you 

I am not any different... I can bear Windows only because of cygwin. With
it, my working environment is not any different from some *nix flavor ;-)

-- 
Enrico

Re: [patch] remove wheel mouse ui from qt2

[Abdelrazak Younes]

Juergen Spitzmueller a écrit :

The attached patch finally eliminates the gui element.
I did not touch qt4, since Abdel is reorganizing the Prefs dialog currently. 


I am done for now with the Prefs reorg. Feel free to modify it (or even 
better process to phase 2 of my reorg ;-)).


I will working on the Citation/AddCitation dialog from now on. Please 
retain any modification on this before I apply my cleanup probably this 
week-end.



Abdel, while you are at it, could you please remove the wheel mouse spinbox?


Done, patch attached (not tested).
I will apply that once I get some spare time to compile and test (if you 
don't beat me at this :-)).


Abdel.



 * src/frontends/qt2/QPrefsDialog.C
 (QPrefsDialog::QPrefsDialog):
 (void QPrefsDialog::apply):
 (void QPrefsDialog::update):
 * src/frontends/qt2/ui/QPrefUI.ui:  remove wheel mouse spin box
(bug 783).

Index: QPrefsDialog.C
===
--- QPrefsDialog.C  (revision 13453)
+++ QPrefsDialog.C  (working copy)
@@ -394,7 +394,6 @@
connect(uiModule->uiFileED, SIGNAL(textChanged(const QString&)), this, 
SLOT(change_adaptor()));
connect(uiModule->bindFileED, SIGNAL(textChanged(const QString&)), 
this, SLOT(change_adaptor()));
connect(uiModule->cursorFollowsCB, SIGNAL(toggled(bool)), this, 
SLOT(change_adaptor()));
-   connect(uiModule->wheelMouseSB, SIGNAL(valueChanged(int)), this, 
SLOT(change_adaptor()));
connect(uiModule->autoSaveSB, SIGNAL(valueChanged(int)), this, 
SLOT(change_adaptor()));
connect(uiModule->autoSaveCB, SIGNAL(toggled(bool)), this, 
SLOT(change_adaptor()));
connect(uiModule->lastfilesSB, SIGNAL(valueChanged(int)), this, 
SLOT(change_adaptor()));
@@ -1121,7 +1120,6 @@
rc.ui_file = internal_path(uiModule->uiFileED->text());
rc.bind_file = internal_path(uiModule->bindFileED->text());
rc.cursor_follows_scrollbar = uiModule->cursorFollowsCB->isChecked();
-   rc.wheel_jump = uiModule->wheelMouseSB->value();
rc.autosave = uiModule->autoSaveSB->value() * 60;
rc.make_backup = uiModule->autoSaveCB->isChecked();
rc.num_lastfiles = uiModule->lastfilesSB->value();
@@ -1416,7 +1414,6 @@
uiModule->uiFileED->setText(external_path(rc.ui_file));
uiModule->bindFileED->setText(external_path(rc.bind_file));
uiModule->cursorFollowsCB->setChecked(rc.cursor_follows_scrollbar);
-   uiModule->wheelMouseSB->setValue(rc.wheel_jump);
// convert to minutes
int mins(rc.autosave / 60);
if (rc.autosave && !mins)
Index: ui/QPrefUi.ui
===
--- ui/QPrefUi.ui   (revision 13453)
+++ ui/QPrefUi.ui   (working copy)
@@ -1,300 +1,274 @@
-
-  
-  
-  
-  QPrefUi
-  
-
-  
-0
-0
-416
-441
-  
-
-
-  
-1
-1
-0
-0
-  
-
-
-  
-
-
-  
-11
-  
-  
+
+ 
+ 
+ 
+ QPrefUI
+ 
+  
+   
+0
+0
+416
+441
+   
+  
+  
+   
+1
+1
+0
+0
+   
+  
+  
+   
+  
+  
+   
+11
+   
+   
+6
+   
+   
+
+ 
+  0
+ 
+ 
+  6
+ 
+ 
+  
+   
+Browse...
+   
+  
+ 
+ 
+  
+   
+User interface file:
+   
+   
+uiFileED
+   
+  
+ 
+ 
+  
+   
+Bind file:
+   
+   
+bindFileED
+   
+  
+ 
+ 
+  
+ 
+ 
+  
+   
+Browse...
+   
+  
+ 
+ 
+  
+ 
+
+   
+   
+
+ 
+  0
+ 
+ 
+  6
+ 
+ 
+  
+   
+0
+   
+   
 6
-  
-  
-
+   
+   
+
+ 
+  Documents
+ 
+ 
   
-0
+   11
   
   
-6
+   6
   
-  
-
-  
-Browse...
-  
-
+  
+   
+
+ Backup documents 
+
+   
   
-  
-
-  
-User interface file:
+  
+   
+
+ 0
+
+
+ 6
+
+
+ 
+  
+   Qt::Horizontal
   
-  
-uiFileED
+  
+   QSizePolicy::Fixed
   
-
-  
-  
-
+  
+   
+21
+20
+   
+  
+ 
+
+
+ 
   
-Bind file:
+every

Re: A Cygwin related patch

[Enrico Forestieri]

Georg Baum <[EMAIL PROTECTED]> writes:
> 
> Enrico Forestieri wrote:
> 
> > The attached patch fixes the bug reported here:
> > http://thread.gmane.org/gmane.editors.lyx.general/29227
> > 
> > In my intention this is the first of a series of patches aimed at
> > polishing the Cygwin target, which I think is lagging behind. Please, tell
> > me if this ok with you. I have no problem in maintaining the Cygwin target
> > but my time is limited so I cannot guarantee a continuous commitment. I
> > will do it time permitting. There should be no big problems, as I think
> > the Cygwin users will not be more than those I can count with only one of
> > my hands 
> 
> This patch looks good. I don't like the other one, because the code in
> filetools.C is more complicated, and in this one it is more clear because
> of cygwin_path_fix().

Really? I had thought the second one was more cleaner. Actually I had to
figure out that when latex_path() is called for generating the argument
of [EMAIL PROTECTED] it is assumed that a trailing / is present, and the second
patch makes this clear not only for cygwin. On the other hand,
external_path() is almost a no-op for the other OSes, so I don't it is
such an overhead. So, what shall I use?

> > Do you prefer that I file this one on bugzilla?
> 
> I think it is there already: http://bugzilla.lyx.org/show_bug.cgi?id=2409 Or
> do you fix something else?

Funny, it was not there when I started working on the bug ;-)

-- 
Enrico

Re: A Cygwin related patch

[Jean-Marc Lasgouttes]

> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:

Enrico> Really? I had thought the second one was more cleaner.
Enrico> Actually I had to figure out that when latex_path() is called
Enrico> for generating the argument of [EMAIL PROTECTED] it is assumed that
Enrico> a trailing / is present, and the second patch makes this clear
Enrico> not only for cygwin. 

Why shall we assume that? I do not really understand this explicit
check for a trailing slash. I think it should be elsewhere.

JMarc

Re: configure failure... (latest CVS) missing file?

[Jean-Marc Lasgouttes]

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


Lars> This is the correct fix.


I applied it.

JMarc

Re: A Cygwin related patch

[Georg Baum]

Enrico Forestieri wrote:

> Really? I had thought the second one was more cleaner. Actually I had to
> figure out that when latex_path() is called for generating the argument
> of [EMAIL PROTECTED] it is assumed that a trailing / is present, and the 
> second
> patch makes this clear not only for cygwin.

[EMAIL PROTECTED] must always be an absolute path (otherwise it would not work
TeX-wise), but why should that matter in LyX?

> On the other hand, 
> external_path() is almost a no-op for the other OSes, so I don't it is
> such an overhead. So, what shall I use?

The overhead does not matter at all here. We have had a lot of path problems
on the different windows flavors. Angus worked hard to resolve these, and
implemented the external/internal path distiction.
If we want to avoid more problems we must keep this distinction and be
always explicit whether a path is external or intrnal.
In the long run we should not juggle with paths as strings, but always use a
path class with external() and internal() methods. This will make the
distinction more clear.

I am not really sure how things work on cygwin. Can we always assume that
all external paths are either windows or posix style? Or do we need posix
paths in some cases and windows paths in others?

> Funny, it was not there when I started working on the bug ;-)

It should have been there a long time ago, but finally somebody did not only
complain on lyx-users and added it.


Georg

Re: [another PATCH] Re: [PATCH] bug 2313: Save should be disabled for unchanged documents

[Helge Hafting]

John McCabe-Dansted wrote:


John> If LyX locked files which were open in a still running LyX
John> process, that would have saved me some confusion.

Yes, but I am sure this can cause a lot of confusion too...
   



I am not sure why this would cause confusion. You could have a dialog
box warning that "Another LyX window has this file open" and offer
some of the following alternatives:

* Do not open.
 


fine


* Open read only.
 


fine


* Open anyway.
 


fine, assume the user sorts it out after being warned


* Attempt to kill other LyX window.
 


How?  Killing the process is no good, that process may have
several unsaved documents open.  And it might belong
to another user anyway.

Helge Hafting

Re: [patch] remove wheel mouse ui from qt2

[Georg Baum]

Juergen Spitzmueller wrote:

> I cannot compile gtk.

You don't need to compile it in order to find out whether wheel_jump is used
or not :-)
Anyway, I looked now myself and will commit the attached patch.


GeorgIndex: src/lyxrc.h
===
--- src/lyxrc.h	(Revision 13460)
+++ src/lyxrc.h	(Arbeitskopie)
@@ -238,6 +238,7 @@ public:
 	/// Zoom factor for screen fonts
 	unsigned int zoom;
 	/// parameter for button_4 and button_5 (scrollwheel)
+	/// Only used by the xforms frontend
 	unsigned int wheel_jump;
 	/// Screen font sizes in points for each font size
 	std::string font_sizes[10];

Re: bug 2313: Save should be disabled for unchanged documents

[John McCabe-Dansted]

>* Open anyway.
>fine, assume the user sorts it out after being warned

Letting the user "Open anyway" after being warned still seems a lot
better than not warning the user at all. I thought that not letting
the user open the file rw may not be popular in certain quarters...
this was the only reason I could think of that  "locking" could be
accused of "adding confusion".

>* Attempt to kill other LyX window.
>How?  Killing the process is no good, that process may have
>several unsaved documents open.  And it might belong
>to another user anyway.

I was thinking of firefox which has a habit of leaving stale processes
around, locking the ~/.firefox directory.  Probably not really useful
for LyX.

On 3/23/06, Helge Hafting <[EMAIL PROTECTED]> wrote:
> John McCabe-Dansted wrote:
>
> >>John> If LyX locked files which were open in a still running LyX
> >>John> process, that would have saved me some confusion.
> >>
> >>Yes, but I am sure this can cause a lot of confusion too...
> >>
> >>
> >
> >I am not sure why this would cause confusion. You could have a dialog
> >box warning that "Another LyX window has this file open" and offer
> >some of the following alternatives:
> >
> >* Do not open.
> >
> >
> fine
>
> >* Open read only.
> >
> >
> fine
>
> >* Open anyway.
> >
> >
> fine, assume the user sorts it out after being warned
>
> >* Attempt to kill other LyX window.
> >
> >
> How?  Killing the process is no good, that process may have
> several unsaved documents open.  And it might belong
> to another user anyway.
>
> Helge Hafting
>


--
John C. McCabe-Dansted
Master's Student

Re: A Cygwin related patch

[Enrico Forestieri]

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> 
> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
> 
> Enrico> Really? I had thought the second one was more cleaner.
> Enrico> Actually I had to figure out that when latex_path() is called
> Enrico> for generating the argument of \input  path it is assumed that
> Enrico> a trailing / is present, and the second patch makes this clear
> Enrico> not only for cygwin. 
> 
> Why shall we assume that? I do not really understand this explicit
> check for a trailing slash. I think it should be elsewhere.

I saw that the [EMAIL PROTECTED] argument always has a double / appended.
In my eyes this was not wrong because I remember that in kpathsea a
double / signals to also search for subdirectories.

Your post rang an alarm bell for me and I checked the [EMAIL PROTECTED] syntax
and indeed it is not the same as for kpathsea. A single / should be
appended to the path, but it seems that two do not hurt.

Now, as a / was later added to the path, in my mind a / should have
already been in the path. And indeed this is the case: whenever
latex_path() is called to generate the argument of [EMAIL PROTECTED] the
path which is passed always has a / appended.

As I think that one should not fix what is not broken, in my patch I
used that to distinguish when latex_path should generate the argument
of [EMAIL PROTECTED] such that to act on this case only. Not only, as in
cygwin external_path() can remove the trailing slash, I also paid
attention to readd it...

So I now know that the trailing slash is not there on purpose. However,
it is a good flag for signaling latex_path() that a path for [EMAIL PROTECTED]
is to be generated.

Now I think I have two choices:

1) Find in the sources where latex_path() is called for [EMAIL PROTECTED], in
   order to enforce the trailing slash as a flag for this case, and then
   modify the patch such as to later remove it in latex_path().

2) Check if the path passed to latex_path() is a directory. If it is,
   assume that this is the [EMAIL PROTECTED] case and act accordingly.

What do you think is the better choice?

-- 
Enrico