Re: Bugs status

[Juergen Spitzmueller]

Martin Vermeer wrote:
 I believe bug 822 is fixed.
 Is 1561 still major? Was partly fixed by Andre.

 Are these (and 2155) the only major bugs left for 1.4.0?

and 1656.

Cf. the list of open, non-fixedintrunk bugs targeted to 1.4.0:
http://tinyurl.com/7qacq

I think bug 2019 deserves your special attendance. Also, you have a pending 
patch in bug 2015 ;-)

Happy New Year to all,
Jürgen

Re: Various change tracking issues

[Martin Vermeer]

On Mon, Jan 02, 2006 at 01:10:00AM +0100, Jean-Marc Lasgouttes wrote:
 | What is this a response to?
 
 Your 'let's always repaint the row with the cursor in it' patch I
 belive.
 
 Right. My palm is not very good at
 quoting messages, sorry.
 
 JMarc
 
 -- 
   Lgb

For some reason mutt threads it wrong. Perhaps your Palm isn't good at
adding threading info either :-/

- Martin
 


pgpc39NZI6YdV.pgp
Description: PGP signature

Re: Bugs status

[Martin Vermeer]

On Mon, Jan 02, 2006 at 09:21:09AM +0100, Juergen Spitzmueller wrote:
 Martin Vermeer wrote:
  I believe bug 822 is fixed.
  Is 1561 still major? Was partly fixed by Andre.
 
  Are these (and 2155) the only major bugs left for 1.4.0?
 
 and 1656.

I remember that this can be fixed, but in a way that terminates LyX
without an emergency save -- unacceptable. Jean-Marc knows this one.

 Cf. the list of open, non-fixedintrunk bugs targeted to 1.4.0:
 http://tinyurl.com/7qacq
 
 I think bug 2019 deserves your special attendance. 

Hmmm... perhaps the remark in insetcharstyle.C:draw:

// I don't understand why the above .reduce and .realize aren't
//needed, or even wanted, here. It just works. -- MV 10.04.2005

isn't quite true... could you have a look? I'm short on time right now.

 Also, you have a pending 
 patch in bug 2015 ;-)

Yes... but it is pending a policy decision (by Lars?) on whether we use
the vector nature of lyxtext, search in a loop, use std::find and/or 
factor out the thing into its own routine.

 Happy New Year to all,
 Jürgen

A Happy 2006 to you all!

- Martin



pgpGhKKLCDVvs.pgp
Description: PGP signature

Re: Bugs status

[Juergen Spitzmueller]

Martin Vermeer wrote:
  I think bug 2019 deserves your special attendance.

 Hmmm... perhaps the remark in insetcharstyle.C:draw:

 // I don't understand why the above .reduce and .realize aren't
 //needed, or even wanted, here. It just works. -- MV 10.04.2005

 isn't quite true... could you have a look? I'm short on time right now.

I have already tried to implement those, but that didn't change anything. I 
have also tried other things to no avail, so I finally gave up.
I fear I just understand the whole fonts framework to less to fix this bug. 
E.g. I just do not understand why, apparently, the color that is used to draw 
the charstyle text on screen is also used in output, as is the case in the 
bug in question. Aren't on-screen font colors and output font colors clearly 
separated?

Jürgen

Re: Bugs status

[Martin Vermeer]

On Mon, Jan 02, 2006 at 10:42:58AM +0100, Juergen Spitzmueller wrote:
 Martin Vermeer wrote:
   I think bug 2019 deserves your special attendance.
 
  Hmmm... perhaps the remark in insetcharstyle.C:draw:
 
  // I don't understand why the above .reduce and .realize aren't
  //needed, or even wanted, here. It just works. -- MV 10.04.2005
 
  isn't quite true... could you have a look? I'm short on time right now.
 
 I have already tried to implement those, but that didn't change anything. I 
 have also tried other things to no avail, so I finally gave up.
 I fear I just understand the whole fonts framework to less to fix this bug. 
 E.g. I just do not understand why, apparently, the color that is used to draw 
 the charstyle text on screen is also used in output, as is the case in the 
 bug in question. Aren't on-screen font colors and output font colors clearly 
 separated?

In my understanding the colour on-screen is the one that was
defined in the layout file. What appears in the LaTeX output is defined
in the inset's ::latex method. No, I don't think the on-screen colour
should appear in the output. If it does, something is wrong.

- Martin



pgpkcfiCt2K0r.pgp
Description: PGP signature

Re: lyx 1.4.0 for windows: compilation progress report and impression

[Helge Hafting]

On Fri, Dec 23, 2005 at 04:42:17PM +0100, Jean-Marc Lasgouttes wrote:
  Abdel == Abdel  [EMAIL PROTECTED] writes:
 
 Abdel Jean-Marc Lasgouttes a écrit :
  Abdel == Abdel [EMAIL PROTECTED]
  writes:
 Abdel Oups, I have just discovered the math and table bars right
 Abdel clicking on the top toolbar. All I can say is WAHOU !!! :-)
 Abdel Sorry for that.
  Actually, it is possible to edit ui/default.ui to have these
  toolbars appear automatically when needed.
 
 Abdel Very good! This should be the default IMHO.
 
 Not everybody appreciates to have toolbars popping up at seemingly
 random times. What we need is an user interface to set these values.

That'd be nice.  In the meantime, what exactly do I do to my
default.ui in order to enable this labor-saving behaviour?

I copied a default.ui from /usr/share/lyx/ui to .lyx/ui
but found no trivial way of enabling automatic toolbars.

Helge Hafting

Re: Bugs status

[Martin Vermeer]

On Mon, Jan 02, 2006 at 10:42:58AM +0100, Juergen Spitzmueller wrote:
 Martin Vermeer wrote:
   I think bug 2019 deserves your special attendance.
 
  Hmmm... perhaps the remark in insetcharstyle.C:draw:
 
  // I don't understand why the above .reduce and .realize aren't
  //needed, or even wanted, here. It just works. -- MV 10.04.2005
 
  isn't quite true... could you have a look? I'm short on time right now.
 
 I have already tried to implement those, but that didn't change anything. I 
 have also tried other things to no avail, so I finally gave up.
 I fear I just understand the whole fonts framework to less to fix this bug. 
 E.g. I just do not understand why, apparently, the color that is used to draw 
 the charstyle text on screen is also used in output, as is the case in the 
 bug in question. Aren't on-screen font colors and output font colors clearly 
 separated?

As further info, it appears that I have copied the getDrawFont/tmpfont
etc. mechanism from insetert. There, however, the ::latex method ouputs
directly by brute force, while in charinset, it goes over insettext, and
thus lyxtext. Perhaps this is too powerful.

That having been said, obviously *some* font attributes should appear
both on-screen and in output. My understanding was that, for LaTeX use,
charstyles were for things like Emph and Noun. They should not use
any coloured representation on-screen, but rather realistic fonts. For
XML, I just don't know.

- Martin



pgphyQqFTB0B4.pgp
Description: PGP signature

Re: Documentation out of date for 1.4.

[Jose' Matos]

On Monday 02 January 2006 02:32, Lars Gullik Bjønnes wrote:

 Does it actually say 'voil' or is my mailreader/terminal a bit off?

I see voilà... So probably some encoding mess from your mailreader. :-)

  :-)
-- 
José Abílio

Re: lyx 1.4.0 for windows: compilation progress report and impression

[Abdel]

Helge Hafting a écrit :

On Fri, Dec 23, 2005 at 04:42:17PM +0100, Jean-Marc Lasgouttes wrote:

Abdel == Abdel  [EMAIL PROTECTED] writes:

Abdel Jean-Marc Lasgouttes a écrit :

Abdel == Abdel [EMAIL PROTECTED]
writes:

Abdel Oups, I have just discovered the math and table bars right
Abdel clicking on the top toolbar. All I can say is WAHOU !!! :-)
Abdel Sorry for that.

Actually, it is possible to edit ui/default.ui to have these
toolbars appear automatically when needed.

Abdel Very good! This should be the default IMHO.

Not everybody appreciates to have toolbars popping up at seemingly
random times. What we need is an user interface to set these values.


That'd be nice.  In the meantime, what exactly do I do to my
default.ui in order to enable this labor-saving behaviour?


Under windows, the location would be:
lyx-1.4.0\Resources\LyX\ui\default.ui

Modify the toolbar section like this:

Toolbars
standard on,top
extra on,top
table table,bottom
math math,bottom
minibuffer off,bottom
End



I copied a default.ui from /usr/share/lyx/ui to .lyx/ui
but found no trivial way of enabling automatic toolbars.


Attached my default.ui



Helge Hafting



# -*- text -*-

# file default.ui
# This file is part of LyX, the document processor.
# Licence details can be found in the file COPYING.

# author John Levon

# Full author contact details are available in file CREDITS.

# This is the default LyX user interface definition file.
# The syntax should be straightforward enough.

# The interface is designed (partially) following the KDE Human Interface
# Guidelines (http://usability.kde.org/hig/)

Include stdmenus.ui

Include stdtoolbars.ui

# Which toolbars to use.
#
# The second parameter are the flags :
#
# on: the toolbar is visible
# off: the toolbar is not visible
# math: the toolbar is visible only when in math
# table: the toolbar is visible only when in a table
# top: the toolbar should be at the top of the window
# bottom: the toolbar should be at the bottom of the window
# left: the toolbar should be at the left of the window
# right: the toolbar should be at the right of the window
#
Toolbars
standard on,top
extra on,top
table table,bottom
math math,bottom
minibuffer off,bottom
End

Re: [patch] bug 2155: Crash when undoing DEPM deletion of the first par (pit = 0)

[Juergen Spitzmueller]

Juergen Spitzmueller wrote:
 Jean-Marc Lasgouttes wrote:
  I'm very glad that you found the
  cause, but the fix doesn't look
  right.

 Too bad. Then I am at my witness end.

I have tried to enhance my witness a bit this year. Here's how I understand 
this case:

After DEPM, doRecordUndo is finally called, where undo.end is calculated as
undo.end = cell.lastpit() - last_pit;
cell.lastpit() is the lastpit of the buffer _including_ the paragraph that 
will be deleted. last_pit is the paragraph where the cursor sits.
If this is the first paragraph (pit = 0), then undo.end = cell.lastpit(), 
which is 1 bigger than lastpit() of the buffer _after_ DEPM.

Now if undo is activated after DEPM, textUndoOrRedo calls doRecordUndo again, 
with a last_pit that is calculated from cell_dit.lastpit() - undo.end. In our 
case, this is -1, since, as elaborated, undo.end is 1 bigger than current 
lastpit.

Until now, we thought that such a value is invalid, but as I understand it 
now, this is correct, since last_pit is again only used to calculate 
undo.end: 
undo.end = cell.lastpit() - last_pit;
which is
undo.end = cell.lastpit() - (-1), e.g. undo.end = cell.lastpit() + 1
IMHO this is correct, since the deleted paragraph is being added again at this 
stage, so undo.end has to increase by one. However, I'm not definitely sure.

Let's have a look at the crash. This is due to the first action of 
doRecordUndo:
if (first_pit  last_pit)
std::swap(first_pit, last_pit);
this is of course triggeres if last_pit = -1, but it shouldn't in this case. I 
don't know if it crashes because swap cannot handle negative values or 
because of some later action, anyway, it just shouldn't try to swap the two 
values here.

So my proposal to fix the bug now is

- if (first_pit  last_pit)
+ if (last_pit = 0  first_pit  last_pit)
std::swap(first_pit, last_pit);

(see attached patch).

As expected, this fixes the crash and also works as expected for undo after 
DEPM.

Does this sound reasonable?

Jürgen
Index: undo.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/undo.C,v
retrieving revision 1.69
diff -u -r1.69 undo.C
--- undo.C	24 Nov 2005 16:22:39 -	1.69
+++ undo.C	2 Jan 2006 11:43:19 -
@@ -64,7 +64,9 @@
 	bool isFullBuffer,
 	limited_stackUndo  stack)
 {
-	if (first_pit  last_pit)
+	// last_pit can legally be -1 when a DEPM action in the first paragraph
+	// has to be restored! Then undo.end below is cell.lastpit + 1
+	if (last_pit = 0  first_pit  last_pit)
 		std::swap(first_pit, last_pit);
 	// create the position information of the Undo entry
 	Undo undo;
@@ -150,10 +152,9 @@
 	Buffer * buf = bv.buffer();
 	DocIterator cell_dit = undo.cell.asDocIterator(buf-inset());
 
-	doRecordUndo(Undo::ATOMIC, cell_dit,
-		   undo.from, cell_dit.lastpit() - undo.end, bv.cursor(),
-			 undo.bparams, undo.isFullBuffer,
-		   otherstack);
+	doRecordUndo(Undo::ATOMIC, cell_dit, undo.from,
+		cell_dit.lastpit() - undo.end, bv.cursor(),
+		undo.bparams, undo.isFullBuffer, otherstack);
 
 	// This does the actual undo/redo.
 	//lyxerr  undo, performing:   undo  std::endl;

Re: Bugs status

[Jose' Matos]

On Monday 02 January 2006 10:15, Martin Vermeer wrote:
 That having been said, obviously *some* font attributes should appear
 both on-screen and in output. My understanding was that, for LaTeX use,
 charstyles were for things like Emph and Noun. They should not use
 any coloured representation on-screen, but rather realistic fonts. For
 XML, I just don't know.

  XML does not have the concept of colours. :-)
  You are implying a policy here, so it should be the same not matter what 
backend is being used... unless I missed the point completely, it happened 
before. ;-)

 - Martin

-- 
José Abílio

Re: Bugs status

[Martin Vermeer]

On Mon, Jan 02, 2006 at 10:42:58AM +0100, Juergen Spitzmueller wrote:
 Martin Vermeer wrote:
   I think bug 2019 deserves your special attendance.
 
  Hmmm... perhaps the remark in insetcharstyle.C:draw:
 
  // I don't understand why the above .reduce and .realize aren't
  //needed, or even wanted, here. It just works. -- MV 10.04.2005
 
  isn't quite true... could you have a look? I'm short on time right now.
 
 I have already tried to implement those, but that didn't change anything. I 
 have also tried other things to no avail, so I finally gave up.
 I fear I just understand the whole fonts framework to less to fix this bug. 
 E.g. I just do not understand why, apparently, the color that is used to draw 
 the charstyle text on screen is also used in output, as is the case in the 
 bug in question. Aren't on-screen font colors and output font colors clearly 
 separated?
 
 Jürgen

Actually I don't dare to touch this stuff. The whole font architecture
needs an overhaul/simplification. E.g., there are two different
getFonts, one in lyxtext (for display) and one in paragraph (for
latexing).

There should be a clear concept of underlying font, to which a font is
reduced (or not) before drawing/latexing, be it the current layout
default font, the outer font in nested lists, or the outer font
outside the current inset. As of now, the concept exists but is
sort-of implemented all over the place.

Would it be an idea to open a bug targeting 1.5 for this?

- Martin



pgpIivWBEP7hm.pgp
Description: PGP signature

Re: Bugs status

[Juergen Spitzmueller]

Martin Vermeer wrote:
 Actually I don't dare to touch this stuff. The whole font architecture
 needs an overhaul/simplification. E.g., there are two different
 getFonts, one in lyxtext (for display) and one in paragraph (for
 latexing).

If it is too complicated or risky to fix this stuff now, we could of course 
postpone the fix and tell people to not use font colors for representation of 
charstyles (or let LyX just ignore such font color definitions). 
I think the restriction is bearable.

Jürgen

Re: [announce] sixth release of LyXWinInstaller

[Angus Leeming]

Stephen Harris wrote:
 Bo
 
 The Miktex installation doc recommends installing Miktex into paths
 and/or directories without spaces. LyX has a history of problems
 with paths having spaces some passed on from Miktex.
 
 http://wiki.lyx.org/pmwiki.php/Windows/LyX136pre
 13 July 2005
 Axel Rasche reported that spaces in the file path caused BibTeX to fail.
 The adopted solution copies the BibTeX data base to the temp directory,
 mangling its name in the process into something that's both recognizable
 to the user and useable by BibTeX. Note that this fix hasn't yet made it
 into the official sources.

??? Yes it has. It's in the cvs repositories and will be part of future LyX
1.3.7/1.4.0 releases.

-- 
Angus

Re: Documentation out of date for 1.4.

[Angus Leeming]

Bennett Helm wrote:
 1. One for the Mac users: where is the preferences file to be found?
 Currently I have:

 It's at ~/Library/Application Support/LyX/preferences.

Thanks, Bennett

-- 
Angus

Re: [PATCH] Tiny text changes

[Georg Baum]

A Happy New Year to verybody!

Lars Gullik Bjønnes wrote:

 Michael Gerz [EMAIL PROTECTED]
 writes:
 | How about the first change regarding amsart-seq?
 
 If it is only a label change then it should not be changed now. If it
 OTOH fixes a real problem, then we should fix it now.

It fixes a typo in the LaTeX preamble and should go in IMHO. The Exercise
layout references a non-existing counter without it.


Georg

Re: Bugs status

[Martin Vermeer]

On Mon, Jan 02, 2006 at 01:01:46PM +0100, Juergen Spitzmueller wrote:
 Martin Vermeer wrote:
  Actually I don't dare to touch this stuff. The whole font architecture
  needs an overhaul/simplification. E.g., there are two different
  getFonts, one in lyxtext (for display) and one in paragraph (for
  latexing).
 
 If it is too complicated or risky to fix this stuff now, we could of course 
 postpone the fix and tell people to not use font colors for representation of 
 charstyles (or let LyX just ignore such font color definitions). 
 I think the restriction is bearable.

For now, yes.

- Martin


pgppHpoCYvp0Q.pgp
Description: PGP signature

ChkTeX errors dialog almost unusable

[Angus Leeming]

When the dialog is open, clicking in the main document resets the position
of both dialog and document to the beginning. I find that I have to use
the dialog to naviagate to an error, close the dialog, fix the problem,
rerun chktex and hope that I can return to the same point relatively
quickly by navigating through all those errors I've looked at already
and decided were OK.

-- 
Angus

Re: ChkTeX errors dialog almost unusable

[Juergen Spitzmueller]

Angus Leeming wrote:
 When the dialog is open, clicking in the main document resets the position
 of both dialog and document to the beginning. I find that I have to use
 the dialog to naviagate to an error, close the dialog, fix the problem,
 rerun chktex and hope that I can return to the same point relatively
 quickly by navigating through all those errors I've looked at already
 and decided were OK.

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

Regards,
Jürgen

Toolbar setup

[Helge Hafting]

On Mon, Jan 02, 2006 at 11:41:55AM +0100, Abdel wrote:
 Helge Hafting a écrit :
 On Fri, Dec 23, 2005 at 04:42:17PM +0100, Jean-Marc Lasgouttes wrote:
 Abdel == Abdel  [EMAIL PROTECTED] 
 writes:
 Abdel Jean-Marc Lasgouttes a écrit :
 Abdel == Abdel [EMAIL PROTECTED]
 writes:
 Abdel Oups, I have just discovered the math and table bars right
 Abdel clicking on the top toolbar. All I can say is WAHOU !!! :-)
 Abdel Sorry for that.
 Actually, it is possible to edit ui/default.ui to have these
 toolbars appear automatically when needed.
 Abdel Very good! This should be the default IMHO.
 
 Not everybody appreciates to have toolbars popping up at seemingly
 random times. What we need is an user interface to set these values.
 
 That'd be nice.  In the meantime, what exactly do I do to my
 default.ui in order to enable this labor-saving behaviour?
 
 Under windows, the location would be:
 lyx-1.4.0\Resources\LyX\ui\default.ui
 
 Modify the toolbar section like this:
 
 Toolbars
   standard on,top
   extra on,top
   table table,bottom
   math math,bottom
   minibuffer off,bottom
 End
 
Thanks a lot!  

Now, I understand that this won't be the default, but how about sticking
a commented-out version of this example in the distributed default.ui?
That should be safe even for 1.4.0, it is only documentation
this way.  And it sure makes life easier for anyone wanting to 
customize this. Then the nice GUI setup can be made for 1.4.1 or whatever.

Helge Hafting

Re: [announce] sixth release of LyXWinInstaller

[Bo Peng]

 _TeX_ cannot handle spaces. I suppose that you do not really
 know the difference of TeX, LaTeX, pdfTeX, pdfLaTeX, bibTeX, MiKTeX

I do not. My understanding is that miktex is another implementation of
latex standard ( if there is such a standard). If miktex aims at
windows platform, I assume that it will do something for the path with
spaces problem.

Bo

Re: [announce] sixth release of LyXWinInstaller

[Bo Peng]

 The mistake is making C:\Program files the default for LyX and
 friends.

I totally agree. I think it is a good idea to install Lyx to c:\lyx by default.

This will save us from some troubles, but not all. Most windows users
save their files under ...\My Documents or ... and
Settings\Desktop and will still suffer from this problem. It is quite
tricky to move these folders to something like D:\Documents.

Cheers,
Bo

Re: [announce] sixth release of LyXWinInstaller

[Angus Leeming]

Bo Peng wrote:

 _TeX_ cannot handle spaces. I suppose that you do not really
 know the difference of TeX, LaTeX, pdfTeX, pdfLaTeX, bibTeX, MiKTeX
 
 I do not. My understanding is that miktex is another implementation of
 latex standard ( if there is such a standard). If miktex aims at
 windows platform, I assume that it will do something for the path with
 spaces problem.

Free software isn't built on assumptions, it's built on contributions. If
you're sufficiently irritated by this to want to do something about it,
then I'm sure that the MikTeX people will be more than happy to help you
help them.

Or, perhaps, this thread might help:
http://thread.gmane.org/gmane.editors.lyx.devel/43772

background
Jean-Marc contacted the real TeX gurus on the tex-k mailing list to ask for
some advice. You can find the full thread in the tex-k archives here:
http://www.tug.org/pipermail/tex-k/2005-April/index.html#1287
/background

-- 
Angus

Re: Bugs status

[Martin Vermeer]

On Mon, Jan 02, 2006 at 03:30:21PM +0200, Martin Vermeer wrote:
 On Mon, Jan 02, 2006 at 01:01:46PM +0100, Juergen Spitzmueller wrote:
  Martin Vermeer wrote:
   Actually I don't dare to touch this stuff. The whole font architecture
   needs an overhaul/simplification. E.g., there are two different
   getFonts, one in lyxtext (for display) and one in paragraph (for
   latexing).
  
  If it is too complicated or risky to fix this stuff now, we could of course 
  postpone the fix and tell people to not use font colors for representation 
  of 
  charstyles (or let LyX just ignore such font color definitions). 
  I think the restriction is bearable.
 
 For now, yes.
 
 - Martin

Actually I would put it differently: you are not supposed to mix
character styles and font attributes :-)

My idea with charstyles has always been, longer term, to become a
logical replacement for visual font attributes. In XML they represent
elements; in LaTeX my idea was, that they would replace the existing
Noun and Emph thingies -- and whatever more the layout writers would
find useful... or with a GUI front-end, even the ordinary users. 

[Note that if the bug reporter would have defined and used an Emph
charstyle instead of the Emph font attribute, things would have worked
for him... perhaps a recommended workaround]

This did not happen for 1.4, as charstyle was viewed as not quite ready
yet (although apparently it is for _some_ users!), but that is still the
programme for me. When done, you wouldn't ever use raw font attributes
anymore.

- Martin


pgp5dI5bRmRwH.pgp
Description: PGP signature

Re: Bugs status

[Juergen Spitzmueller]

Martin Vermeer wrote:
 Actually I would put it differently: you are not supposed to mix
 character styles and font attributes :-)

 My idea with charstyles has always been, longer term, to become a
 logical replacement for visual font attributes. In XML they represent
 elements; in LaTeX my idea was, that they would replace the existing
 Noun and Emph thingies -- and whatever more the layout writers would
 find useful... or with a GUI front-end, even the ordinary users.

[...]

 This did not happen for 1.4, as charstyle was viewed as not quite ready
 yet (although apparently it is for _some_ users!), but that is still the
 programme for me. When done, you wouldn't ever use raw font attributes
 anymore.

This sounds very reasonable to me.
Perhaps you could add this explanation to the bug report. IIRC there is also 
another bug involved which will be fixed by your #2015-patch.

I propose to move bug 2019 out of the 1.4.0-radar after 2015 is fixed and 
target it to 1.5. If the gui for charstyles is in place, we can still see 
what we'll do with this.

Now convince HIM to put the #2015-fix in ;-)

Jürgen

Re: Bugs status

[Martin Vermeer]

On Mon, Jan 02, 2006 at 05:39:52PM +0100, Juergen Spitzmueller wrote:
 Martin Vermeer wrote:

...
 
 This sounds very reasonable to me.
 Perhaps you could add this explanation to the bug report. IIRC there is also 
 another bug involved which will be fixed by your #2015-patch.
 
 I propose to move bug 2019 out of the 1.4.0-radar after 2015 is fixed and 
 target it to 1.5. If the gui for charstyles is in place, we can still see 
 what we'll do with this.

Perhaps this should be called an enhancement request and get its own bug
number.
 
 Now convince HIM to put the #2015-fix in ;-)

Which of them? ;-)

- Martin
 


pgpqQCMNjnKk0.pgp
Description: PGP signature

Re: [announce] sixth release of LyXWinInstaller

[Georg Baum]

Angus Leeming wrote:

 background
 Jean-Marc contacted the real TeX gurus on the tex-k mailing list to ask
 for some advice. You can find the full thread in the tex-k archives here:
 http://www.tug.org/pipermail/tex-k/2005-April/index.html#1287
 /background

A bit more background:
http://sarovar.org/tracker/index.php?func=detailaid=377group_id=106atid=493
This spaces in filenames stuff is _very_ difficult (if not impossible) to
fix, for reasons see the mentioned references.


Georg

Re: Bugs status

[Juergen Spitzmueller]

Martin Vermeer wrote:
 Perhaps this should be called an enhancement request and get its own bug
 number.

perhaps.

  Now convince HIM to put the #2015-fix in ;-)

 Which of them? ;-)

Lars or Gullik. Jean and Marc have already expressed their principal 
accordance on bugzilla IIRC.

Jür  gen

Re: Bugs status

[Herbert Voss]

Juergen Spitzmueller wrote:

Martin Vermeer wrote:


Perhaps this should be called an enhancement request and get its own bug
number.



perhaps.



Now convince HIM to put the #2015-fix in ;-)


Which of them? ;-)



Lars or Gullik. Jean and Marc have already expressed their principal 
accordance on bugzilla IIRC.


Jür  gen


uuh, this causes an error!

\tabular{lr}
Jür  gen
\endtabular

and don't forget \usepackage[latin9]{inputenc} ... :-)

Herbert

Re: Bugs status

[Jose' Matos]

On Monday 02 January 2006 17:41, Herbert Voss wrote:
 uuh, this causes an error!

 \tabular{lr}
 Jür  gen
 \endtabular

  You are really a magician, splitting Jürgen in half. ;-)

 and don't forget \usepackage[latin9]{inputenc} ... :-)

  We are very modest, in this case 1 is enough. ;-)

 Herbert

-- 
José Abílio

Re: [announce] sixth release of LyXWinInstaller

[Michael Gerz]

Bo Peng wrote:


The mistake is making C:\Program files the default for LyX and
friends.
   


I totally agree. I think it is a good idea to install Lyx to c:\lyx by default.
 

No, the directory must be configurable. On my (German) machine, the 
appropriate directory is C:\Programme. There is nothing worse than 
programs that ignore basic Windows guidelines.



This will save us from some troubles, but not all. Most windows users
save their files under ...\My Documents or ... and
Settings\Desktop and will still suffer from this problem. It is quite
tricky to move these folders to something like D:\Documents.
 

Indeed. We cannot assume that all Windows users have administrator 
privileges (in fact they shouldn't). Being unable to use \My Documents 
is like forbidding a *nix user to use $HOME (guess what he will tell you 
:-)).


In other words: We have to support spaces in paths to the maximum extent.

Michael

Re: [announce] sixth release of LyXWinInstaller

[Angus Leeming]

Michael Gerz wrote:

 Bo Peng wrote:
 
The mistake is making C:\Program files the default for LyX and
friends.


I totally agree. I think it is a good idea to install Lyx to c:\lyx by
default.
  

 No, the directory must be configurable. On my (German) machine, the
 appropriate directory is C:\Programme. There is nothing worse than
 programs that ignore basic Windows guidelines.
 
This will save us from some troubles, but not all. Most windows users
save their files under ...\My Documents or ... and
Settings\Desktop and will still suffer from this problem. It is quite
tricky to move these folders to something like D:\Documents.
  

 Indeed. We cannot assume that all Windows users have administrator
 privileges (in fact they shouldn't). Being unable to use \My Documents
 is like forbidding a *nix user to use $HOME (guess what he will tell you
 :-)).
 
 In other words: We have to support spaces in paths to the maximum extent.

Right. And since I install at C:\Program Files\LyX and the bloody thing
works for me, I'm going to put on my grumpy old man hat and say it's a
user error to try and use a .bst file in a path with spaces.

Signing off this thread now...

-- 
Angus

Re: Bugs status

[Martin Vermeer]

On Mon, Jan 02, 2006 at 06:17:31PM +0200, Martin Vermeer wrote:

...
 
 Actually I would put it differently: you are not supposed to mix
 character styles and font attributes :-)
 
 My idea with charstyles has always been, longer term, to become a
 logical replacement for visual font attributes. In XML they represent
 elements; in LaTeX my idea was, that they would replace the existing
 Noun and Emph thingies -- and whatever more the layout writers would
 find useful... or with a GUI front-end, even the ordinary users. 
 
 [Note that if the bug reporter would have defined and used an Emph
 charstyle instead of the Emph font attribute, things would have worked
 for him... perhaps a recommended workaround]
 
 This did not happen for 1.4, as charstyle was viewed as not quite ready
 yet (although apparently it is for _some_ users!), but that is still the
 programme for me. When done, you wouldn't ever use raw font attributes
 anymore.

Bugzilla has a fix which simply disables font attribute editing inside a
charstyle inset; see above theory. Problem solved :-)

What it means in practice is, that if someone insists on using, say Emph
inside a charstyle inset, he should define another charstyle that does
Emph, and insert that. That works. Alternatively, split the inset in two
and put the emphasized text inbetween.

See attached, tested and works. OK to commit?

- Martin

Index: insetcharstyle.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcharstyle.C,v
retrieving revision 1.39
diff -u -p -r1.39 insetcharstyle.C
--- insetcharstyle.C25 Nov 2005 14:40:32 -  1.39
+++ insetcharstyle.C2 Jan 2006 18:59:02 -
@@ -249,6 +249,19 @@ bool InsetCharStyle::getStatus(LCursor 
case LFUN_BREAKPARAGRAPH:
case LFUN_BREAKPARAGRAPHKEEPLAYOUT:
case LFUN_BREAKPARAGRAPH_SKIP:
+   // font attributes also not allowed
+   case LFUN_DEFAULT:
+   case LFUN_CODE:
+   case LFUN_ROMAN:
+   case LFUN_SANS:
+   case LFUN_BOLD:
+   case LFUN_ITAL:
+   case LFUN_EMPH:
+   case LFUN_NOUN:
+   case LFUN_UNDERLINE:
+   case LFUN_FONT_SIZE:
+   case LFUN_FREEFONT_APPLY:
+   case LFUN_FREEFONT_UPDATE:
status.enabled(false);
return true;
 


pgpFyqSEH5WrX.pgp
Description: PGP signature

Screen update improvements

[Michael Gerz]

Martin,

your row signature patch is excellent as it reduces screen flickering 
significantly (you could the flicking on Windows with qtwin).


However, I don't understand why we have to redraw the whole screen in 
case of selections. Doesn't your nice always draw current row patch 
capture selections?


I tried the following modification and couldn't find anything going 
wrong. Could you please enlighten me?


Thanks, Michael


Index: rowpainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v
retrieving revision 1.162
diff -u -r1.162 rowpainter.C
--- rowpainter.C1 Jan 2006 23:06:23 -   1.162
+++ rowpainter.C2 Jan 2006 19:47:28 -
@@ -826,7 +826,7 @@
   for (pit_type pit = vi.p1; pit = vi.p2; ++pit) {
   Paragraph const  par = text-getPar(pit);
   yy += par.ascent();
-   paintPar(pi, *bv.text(), pit, 0, yy, select || 
!vi.singlepar);
+   paintPar(pi, *bv.text(), pit, 0, yy, /*select ||*/ 
!vi.singlepar);

   yy += par.descent();
   }

Re: Screen update improvements

[Martin Vermeer]

On Mon, Jan 02, 2006 at 08:26:13PM +0100, Michael Gerz wrote:
 Martin,
 
 your row signature patch is excellent as it reduces screen flickering 
 significantly (you could the flicking on Windows with qtwin).
 
 However, I don't understand why we have to redraw the whole screen in 
 case of selections. Doesn't your nice always draw current row patch 
 capture selections?
 
 I tried the following modification and couldn't find anything going 
 wrong. Could you please enlighten me?
 
 Thanks, Michael

Yes, it works... apparently because !vi.singlerow implies select, in a
way that I haven't been able to figure out. So you don't actually save
anything.

Still might be wise to delete select from the two places where it occurs
together with || vi.singlerow.

- Martin



pgpILSNxnMmCt.pgp
Description: PGP signature

Re: [announce] sixth release of LyXWinInstaller

[Stephen Harris]

- Original Message - 
From: Michael Gerz [EMAIL PROTECTED]

To: Bo Peng [EMAIL PROTECTED]
Cc: Stephen Harris [EMAIL PROTECTED]; lyx-users@lists.lyx.org; 
lyx-devel@lists.lyx.org

Sent: Monday, January 02, 2006 10:04 AM
Subject: Re: [announce] sixth release of LyXWinInstaller



Bo Peng wrote:


The mistake is making C:\Program files the default for LyX and
friends.

I totally agree. I think it is a good idea to install Lyx to c:\lyx by 
default.


No, the directory must be configurable. On my (German) machine, the 
appropriate directory is C:\Programme. There is nothing worse than 
programs that ignore basic Windows guidelines.




Who said anything about the directory not being configurable.
The Default installation directory now reads: C:\program files\lyx
That can be manually changed to C:\Lyx
I think that the Default should be C:\LyX and the user can run
the risk of problems of paths with spaces if he chooses by
manually installing elsewhere or C:\program files\lyx

German doesn't have a problem with spaces by default
because Programme doesn't have any spaces in it.
Therefore C:\programme\lyx or C:\programme\miktex
will not have a space in it.

Why doesn't English have the default of C:\Programs?
Is it because C:\program files adheres to basic Windows guidelines?
No, certainly not.
Just because Word pioneered filenames with spaces doesn't
mean that practice should be emulated by other editors, nor
does Words ability to do this elevate the filename with spaces
capability to a basic windows guideline.

Basic windows guidelines should be adopted according to
their ability to make windows and other programs work well
together. It is certainly not something Microsoft bought on
top of Mt. Sinai to redeem its clutch of customers.

I've investigated this issue. I have not been able to find any
reason for the adoption of path with spaces to make the
Windows OS work better or work better with other programs.

I think then that the default install of a path with spaces is not
part of basic windows guidelines. It is not a guideline but
maybe a standard. Microsoft introduces many proprietary
standards to gain market share. I see no reason why LyX, as
a member of the Free Source community, should endorse
MS standards in order to make LyX run poorly in conjunction
with its helper programs.

To be a basic windows guideline for LyX, it must help LyX
run better on Windows. Using paths with spaces damages
LyX's (with helper apps) ability to run well on Windows.
Thus it is no basic windows guideline which has any bearing
on how LyX should be installed.



This will save us from some troubles, but not all. Most windows users
save their files under ...\My Documents or ... and
Settings\Desktop and will still suffer from this problem. It is quite
tricky to move these folders to something like D:\Documents.

Indeed. We cannot assume that all Windows users have administrator 
privileges (in fact they shouldn't). Being unable to use \My Documents 
is like forbidding a *nix user to use $HOME (guess what he will tell you 
:-)).


In other words: We have to support spaces in paths to the maximum extent.

Michael



I haven't tested this. But, I don't think there is a problem with
My Documents because there is no problem when the work
directory is beneath Application Data. When the path which
contains *.bst files has no spaces, there is no problem. That
nospace path doesn't get changed because you store the lyx file
in C:\this is \a path\ wtih a lot \of spaces or in
C:\documents and settings\username\my documents

Re: Screen update improvements

[Abdel]

Michael Gerz a écrit :

Martin,

your row signature patch is excellent as it reduces screen flickering 
significantly (you could the flicking on Windows with qtwin).


FYI, without this patch (I have not update my cvs yet), my Qt4 port has 
zero flickering :-)
I think this patch is solving here a problem which is in the Qt3 
frontend. During my port, I have erased all the calls to the 
QWidget::repaint function and I just have one update to the screen. 
In other word, I let Qt decide when to draw.
I think the screen redraw that you see is due to an excessive call to 
repaint() that are not necessary. IMHO this patch tries to reduce the 
number of painting on the intermediate pixmap and this is good because, 
as a side effect it reduces also the number of screen repaint.
But I am not an expert so maybe this is just because Qt4 is supposed to 
be totally double-buffered.


Abdel.



However, I don't understand why we have to redraw the whole screen in 
case of selections. Doesn't your nice always draw current row patch 
capture selections?


I tried the following modification and couldn't find anything going 
wrong. Could you please enlighten me?


Thanks, Michael


Index: rowpainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v
retrieving revision 1.162
diff -u -r1.162 rowpainter.C
--- rowpainter.C1 Jan 2006 23:06:23 -   1.162
+++ rowpainter.C2 Jan 2006 19:47:28 -
@@ -826,7 +826,7 @@
   for (pit_type pit = vi.p1; pit = vi.p2; ++pit) {
   Paragraph const  par = text-getPar(pit);
   yy += par.ascent();
-   paintPar(pi, *bv.text(), pit, 0, yy, select || 
!vi.singlepar);
+   paintPar(pi, *bv.text(), pit, 0, yy, /*select ||*/ 
!vi.singlepar);

   yy += par.descent();
   }

Re: [announce] sixth release of LyXWinInstaller

[Stephen Harris]

- Original Message - 
From: Angus Leeming [EMAIL PROTECTED]

To: lyx-users@lists.lyx.org
Cc: lyx-devel@lists.lyx.org
Sent: Monday, January 02, 2006 10:21 AM
Subject: Re: [announce] sixth release of LyXWinInstaller



Michael Gerz wrote:


Bo Peng wrote:


The mistake is making C:\Program files the default for LyX and
friends.



I totally agree. I think it is a good idea to install Lyx to c:\lyx by
default.



No, the directory must be configurable. On my (German) machine, the
appropriate directory is C:\Programme. There is nothing worse than
programs that ignore basic Windows guidelines.


This will save us from some troubles, but not all. Most windows users
save their files under ...\My Documents or ... and
Settings\Desktop and will still suffer from this problem. It is quite
tricky to move these folders to something like D:\Documents.



Indeed. We cannot assume that all Windows users have administrator
privileges (in fact they shouldn't). Being unable to use \My Documents
is like forbidding a *nix user to use $HOME (guess what he will tell you
:-)).

In other words: We have to support spaces in paths to the maximum extent.


Right. And since I install at C:\Program Files\LyX and the bloody thing
works for me, I'm going to put on my grumpy old man hat and say it's a
user error to try and use a .bst file in a path with spaces.

Signing off this thread now...

--
Angus



And to think, just last night it was a party hat. I thought your post
was missing the usual reminder that whosoever developer declareth
the value of patch, yea verily, let him proceed to make it so,
to paraphrase:

Free software isn't built on assumptions, it's built on contributions. If
you're sufficiently inspired by your convictions to want to do something 
about it, then I'm sure that the MikTeX people will be more than happy

to help you help them.

Re: Screen update improvements

[Angus Leeming]

Abdel wrote:
 your row signature patch is excellent as it reduces screen flickering
 significantly (you could the flicking on Windows with qtwin).
 
 FYI, without this patch (I have not update my cvs yet), my Qt4 port has
 zero flickering :-)

Right. Because Qt4 double buffers everything.

 I think this patch is solving here a problem which is in the Qt3
 frontend. During my port, I have erased all the calls to the
 QWidget::repaint function and I just have one update to the screen.
 In other word, I let Qt decide when to draw.

Also right (and good). But if we regenerate a pixmap a hundred times and Qt
displays it only once, then there's some redundancy there, no?

-- 
Angus

Re: [announce] sixth release of LyXWinInstaller

[Angus Leeming]

Stephen Harris wrote:
 Right. And since I install at C:\Program Files\LyX and the bloody thing
 works for me, I'm going to put on my grumpy old man hat and say it's a
 user error to try and use a .bst file in a path with spaces.

 And to think, just last night it was a party hat.

The mood swings of old age and new parenthood, huh?

-- 
Angus

Re: Screen update improvements

[Abdel]

Angus Leeming a écrit :

Abdel wrote:

your row signature patch is excellent as it reduces screen flickering
significantly (you could the flicking on Windows with qtwin).

FYI, without this patch (I have not update my cvs yet), my Qt4 port has
zero flickering :-)


Right. Because Qt4 double buffers everything.


I think this patch is solving here a problem which is in the Qt3
frontend. During my port, I have erased all the calls to the
QWidget::repaint function and I just have one update to the screen.
In other word, I let Qt decide when to draw.


Also right (and good). But if we regenerate a pixmap a hundred times and Qt
displays it only once, then there's some redundancy there, no?


Totally, both painting should be minimum. I just wanted to point out 
that (IMHO) the flickering is not due to the pixmap repaint but more to 
the screen repaint. But as I said, I am not an expert and I am sure that 
this patch is necessary.


Abdel.

Re: [announce] sixth release of LyXWinInstaller

[Bo Peng]

Dear all,

It is confirmed that if the .bst file is in a path without space, the
bibliography will be generated correctly, even if lyx is installed
under c:\program files\lyx. So,

1. It is safe to install lyx to c:\program files,
2. It is not safe to put .bst files in a path with spaces. .lyx files
and all figure files are OK, as well as .bib files.

Bo

Can't compile lyx-1.4cvs with gcc 4.1

[Helge Hafting]

This is not something I really expected to work, with gcc 4.1 being
a work in progress.  Still, if someone is interested,
here is what happened:

In file included from ../../boost/boost/config.hpp:35,
 from ../../boost/boost/bind.hpp:23,
 from ../../src/support/translator.h:16,
 from ../../src/graphics/GraphicsTypes.h:18,
 from ../../src/graphics/GraphicsLoader.h:27,
 from render_graphic.h:17,
 from render_graphic.C:13:
../../boost/boost/config/compiler/gcc.hpp:92:7: warning: #warning Unknown 
compiler version - please run the configure tests and report the results
../../boost/boost/bind.hpp: In function 'void boost::visit_each(V, const 
boost::_bi::valueT, int) [with V = 
boost::signals::detail::bound_objects_visitor, T = const InsetBase*]':
../../boost/boost/bind.hpp:296:   instantiated from 'void 
boost::_bi::list2A1, A2::accept(V) const [with V = 
boost::signals::detail::bound_objects_visitor, A1 = 
boost::reference_wrapperconst LyX, A2 = boost::_bi::valueconst InsetBase*]'
../../boost/boost/bind/bind_template.hpp:150:   instantiated from 'void 
boost::_bi::bind_tR, F, L::accept(V) const [with V = 
boost::signals::detail::bound_objects_visitor, R = const Buffer* const, F = 
boost::_mfi::cmf1const Buffer* const, LyX, const InsetBase*, L = 
boost::_bi::list2boost::reference_wrapperconst LyX, boost::_bi::valueconst 
InsetBase* ]'
../../boost/boost/bind.hpp:1110:   instantiated from 'void 
boost::visit_each(V, const boost::_bi::bind_tR, F, L, int) [with V = 
boost::signals::detail::bound_objects_visitor, R = const Buffer* const, F = 
boost::_mfi::cmf1const Buffer* const, LyX, const InsetBase*, L = 
boost::_bi::list2boost::reference_wrapperconst LyX, boost::_bi::valueconst 
InsetBase* ]'
../../boost/boost/visit_each.hpp:25:   instantiated from 'void 
boost::visit_each(Visitor, const T) [with Visitor = 
boost::signals::detail::bound_objects_visitor, T = boost::_bi::bind_tconst 
Buffer* const, boost::_mfi::cmf1const Buffer* const, LyX, const InsetBase*, 
boost::_bi::list2boost::reference_wrapperconst LyX, boost::_bi::valueconst 
InsetBase*  ]'
../../boost/boost/signals/slot.hpp:121:   instantiated from 
'boost::slotSlotFunction::slot(const F) [with F = boost::_bi::bind_tconst 
Buffer* const, boost::_mfi::cmf1const Buffer* const, LyX, const InsetBase*, 
boost::_bi::list2boost::reference_wrapperconst LyX, boost::_bi::valueconst 
InsetBase*  , SlotFunction = boost::functionvoid ()(), 
std::allocatorvoid ]'
render_graphic.C:44:   instantiated from here
../../boost/boost/bind.hpp:1105: error: no matching function for call to 
'visit_each(boost::signals::detail::bound_objects_visitor, const InsetBase* 
const, int)'
make[4]: *** [render_graphic.lo] Error 1
make[4]: Leaving directory `/usr/src/lyx-devel/src/insets'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/usr/src/lyx-devel/src/insets'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/lyx-devel/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/lyx-devel/src'
make: *** [all-recursive] Error 1

Helge Hafting

Re: [announce] sixth release of LyXWinInstaller

[Stephen Harris]

- Original Message - 
From: Bo Peng [EMAIL PROTECTED]

To: lyx-users@lists.lyx.org
Cc: lyx-devel@lists.lyx.org
Sent: Monday, January 02, 2006 4:41 PM
Subject: Re: [announce] sixth release of LyXWinInstaller


Dear all,

It is confirmed that if the .bst file is in a path without space, the
bibliography will be generated correctly, even if lyx is installed
under c:\program files\lyx. So,

1. It is safe to install lyx to c:\program files,
2. It is not safe to put .bst files in a path with spaces. .lyx files
and all figure files are OK, as well as .bib files.

Bo

To repeat back what you said in a different way for clarification:

It is better to install Miktex in C:\Miktex and/or C:\texmf
which usually contains the .bst files. 


A problem is likely to arise if you install Miktex to
C:\program files\miktex and/or c:\program files\texmf

Storing the output .lyx file and retrieving it later does not
require avoiding using a work directory without spaces.
IOW, you can use 
C:\documents and settings\username\My Documents

which has a space, or one can also use a nospace directory,
C:\MyDocs or C:\LyX\resources\lyx\work\Mydocs

So that working around the .bst problem of path and spaces by 
using a nospace directory path such as C:\texmf\bibtex\bst does
not impact negatively on the Windows traditional use of storing 
files in C:\Documents and Settings\username\My Documents or
C:\~...\...\Application data\LyX\Work for later retrieval. No change 
needs to be made for My Documents to accomodate using a nospace 
bst (texmf) directory path. Do I understand you correctly?


speculative remark
Apparently, the code that works for bibtex and paths with spaces
can't be easily substituted to handle bst (some kind of find/replace).

From what I read, TeX ends a filename when a space occurs. It

used to be that you could quote, \path\with a space\ and the space
wouldn't cause a problem. But there seems to be a problem with
quotemarks, two, getting removed. I tried \path\with a space\
but \ is also used as an escape character which is why it maybe
doesn't work as well as a path delimiter as /.
/speculative remark

Regards,
Stephen

LyXWinInstaller and WinXPx64

[Uwe Stöhr]

Stephen Harris wrote:


German doesn't have a problem with spaces by default
because Programme doesn't have any spaces in it.
Therefore C:\programme\lyx or C:\programme\miktex
will not have a space in it.


Beginning with WindowsXPx64 Microsoft only delivers native OS versions 
for english and japanese. All other OS language versions are'n native. 
That means also if you use german menus of Windows, the default is 
always C:\program files.


Just for information.
Btw. LyXWinInstaller and all of the installed programs work fine under 
WindowsXPx64.


A happy new year and regards
Uwe

Re: Bugs status

[Juergen Spitzmueller]

Martin Vermeer wrote:
> I believe bug 822 is fixed.
> Is 1561 still major? Was partly fixed by Andre.
>
> Are these (and 2155) the only major bugs left for 1.4.0?

and 1656.

Cf. the list of open, non-fixedintrunk bugs targeted to 1.4.0:
http://tinyurl.com/7qacq

I think bug 2019 deserves your special attendance. Also, you have a pending 
patch in bug 2015 ;-)

Happy New Year to all,
Jürgen

Re: Various change tracking issues

[Martin Vermeer]

On Mon, Jan 02, 2006 at 01:10:00AM +0100, Jean-Marc Lasgouttes wrote:
> | What is this a response to?
> 
> >Your 'let's always repaint the row >with the cursor in it' patch I
> >belive.
> 
> Right. My palm is not very good at
> quoting messages, sorry.
> 
> JMarc
> 
> -- 
>   Lgb

For some reason mutt threads it wrong. Perhaps your Palm isn't good at
adding threading info either :-/

- Martin
 


pgpc39NZI6YdV.pgp
Description: PGP signature

Re: Bugs status

[Martin Vermeer]

On Mon, Jan 02, 2006 at 09:21:09AM +0100, Juergen Spitzmueller wrote:
> Martin Vermeer wrote:
> > I believe bug 822 is fixed.
> > Is 1561 still major? Was partly fixed by Andre.
> >
> > Are these (and 2155) the only major bugs left for 1.4.0?
> 
> and 1656.

I remember that this can be fixed, but in a way that terminates LyX
without an emergency save -- unacceptable. Jean-Marc knows this one.

> Cf. the list of open, non-fixedintrunk bugs targeted to 1.4.0:
> http://tinyurl.com/7qacq
> 
> I think bug 2019 deserves your special attendance. 

Hmmm... perhaps the remark in insetcharstyle.C:draw:

// I don't understand why the above .reduce and .realize aren't
//needed, or even wanted, here. It just works. -- MV 10.04.2005

isn't quite true... could you have a look? I'm short on time right now.

> Also, you have a pending 
> patch in bug 2015 ;-)

Yes... but it is pending a policy decision (by Lars?) on whether we use
the  nature of lyxtext, search in a loop, use std::find and/or 
factor out the thing into its own routine.

> Happy New Year to all,
> Jürgen

A Happy 2006 to you all!

- Martin



pgpGhKKLCDVvs.pgp
Description: PGP signature

Re: Bugs status

[Juergen Spitzmueller]

Martin Vermeer wrote:
> > I think bug 2019 deserves your special attendance.
>
> Hmmm... perhaps the remark in insetcharstyle.C:draw:
>
> // I don't understand why the above .reduce and .realize aren't
> //needed, or even wanted, here. It just works. -- MV 10.04.2005
>
> isn't quite true... could you have a look? I'm short on time right now.

I have already tried to implement those, but that didn't change anything. I 
have also tried other things to no avail, so I finally gave up.
I fear I just understand the whole fonts framework to less to fix this bug. 
E.g. I just do not understand why, apparently, the color that is used to draw 
the charstyle text on screen is also used in output, as is the case in the 
bug in question. Aren't on-screen font colors and output font colors clearly 
separated?

Jürgen

Re: Bugs status

[Martin Vermeer]

On Mon, Jan 02, 2006 at 10:42:58AM +0100, Juergen Spitzmueller wrote:
> Martin Vermeer wrote:
> > > I think bug 2019 deserves your special attendance.
> >
> > Hmmm... perhaps the remark in insetcharstyle.C:draw:
> >
> > // I don't understand why the above .reduce and .realize aren't
> > //needed, or even wanted, here. It just works. -- MV 10.04.2005
> >
> > isn't quite true... could you have a look? I'm short on time right now.
> 
> I have already tried to implement those, but that didn't change anything. I 
> have also tried other things to no avail, so I finally gave up.
> I fear I just understand the whole fonts framework to less to fix this bug. 
> E.g. I just do not understand why, apparently, the color that is used to draw 
> the charstyle text on screen is also used in output, as is the case in the 
> bug in question. Aren't on-screen font colors and output font colors clearly 
> separated?

In my understanding the colour on-screen is the one that was
defined in the layout file. What appears in the LaTeX output is defined
in the inset's ::latex method. No, I don't think the on-screen colour
should appear in the output. If it does, something is wrong.

- Martin



pgpkcfiCt2K0r.pgp
Description: PGP signature

Re: lyx 1.4.0 for windows: compilation progress report and impression

[Helge Hafting]

On Fri, Dec 23, 2005 at 04:42:17PM +0100, Jean-Marc Lasgouttes wrote:
> > "Abdel" == Abdel  <[EMAIL PROTECTED]> writes:
> 
> Abdel> Jean-Marc Lasgouttes a écrit :
> >>> "Abdel" == Abdel <[EMAIL PROTECTED]>
> >>> writes:
> Abdel> Oups, I have just discovered the math and table bars right
> Abdel> clicking on the top toolbar. All I can say is WAHOU !!! :-)
> Abdel> Sorry for that.
> >> Actually, it is possible to edit ui/default.ui to have these
> >> toolbars appear automatically when needed.
> 
> Abdel> Very good! This should be the default IMHO.
> 
> Not everybody appreciates to have toolbars popping up at seemingly
> random times. What we need is an user interface to set these values.

That'd be nice.  In the meantime, what exactly do I do to my
"default.ui" in order to enable this labor-saving behaviour?

I copied a default.ui from /usr/share/lyx/ui to .lyx/ui
but found no trivial way of enabling automatic toolbars.

Helge Hafting

Re: Bugs status

[Martin Vermeer]

On Mon, Jan 02, 2006 at 10:42:58AM +0100, Juergen Spitzmueller wrote:
> Martin Vermeer wrote:
> > > I think bug 2019 deserves your special attendance.
> >
> > Hmmm... perhaps the remark in insetcharstyle.C:draw:
> >
> > // I don't understand why the above .reduce and .realize aren't
> > //needed, or even wanted, here. It just works. -- MV 10.04.2005
> >
> > isn't quite true... could you have a look? I'm short on time right now.
> 
> I have already tried to implement those, but that didn't change anything. I 
> have also tried other things to no avail, so I finally gave up.
> I fear I just understand the whole fonts framework to less to fix this bug. 
> E.g. I just do not understand why, apparently, the color that is used to draw 
> the charstyle text on screen is also used in output, as is the case in the 
> bug in question. Aren't on-screen font colors and output font colors clearly 
> separated?

As further info, it appears that I have copied the getDrawFont/tmpfont
etc. mechanism from insetert. There, however, the ::latex method ouputs
directly by brute force, while in charinset, it goes over insettext, and
thus lyxtext. Perhaps this is too powerful.

That having been said, obviously *some* font attributes should appear
both on-screen and in output. My understanding was that, for LaTeX use,
charstyles were for things like Emph and Noun. They should not use
any coloured representation on-screen, but rather "realistic" fonts. For
XML, I just don't know.

- Martin



pgphyQqFTB0B4.pgp
Description: PGP signature

Re: Documentation out of date for 1.4.

[Jose' Matos]

On Monday 02 January 2006 02:32, Lars Gullik Bjønnes wrote:
>
> Does it actually say 'voil' or is my mailreader/terminal a bit off?

I see "voilà"... So probably some encoding mess from your mailreader. :-)

  :-)
-- 
José Abílio

Re: lyx 1.4.0 for windows: compilation progress report and impression

[Abdel]

Helge Hafting a écrit :

On Fri, Dec 23, 2005 at 04:42:17PM +0100, Jean-Marc Lasgouttes wrote:

"Abdel" == Abdel  <[EMAIL PROTECTED]> writes:

Abdel> Jean-Marc Lasgouttes a écrit :

"Abdel" == Abdel <[EMAIL PROTECTED]>
writes:

Abdel> Oups, I have just discovered the math and table bars right
Abdel> clicking on the top toolbar. All I can say is WAHOU !!! :-)
Abdel> Sorry for that.

Actually, it is possible to edit ui/default.ui to have these
toolbars appear automatically when needed.

Abdel> Very good! This should be the default IMHO.

Not everybody appreciates to have toolbars popping up at seemingly
random times. What we need is an user interface to set these values.


That'd be nice.  In the meantime, what exactly do I do to my
"default.ui" in order to enable this labor-saving behaviour?


Under windows, the location would be:
\Resources\LyX\ui\default.ui

Modify the toolbar section like this:

Toolbars
"standard" "on,top"
"extra" "on,top"
"table" "table,bottom"
"math" "math,bottom"
"minibuffer" "off,bottom"
End



I copied a default.ui from /usr/share/lyx/ui to .lyx/ui
but found no trivial way of enabling automatic toolbars.


Attached my default.ui



Helge Hafting



# -*- text -*-

# file default.ui
# This file is part of LyX, the document processor.
# Licence details can be found in the file COPYING.

# author John Levon

# Full author contact details are available in file CREDITS.

# This is the default LyX user interface definition file.
# The syntax should be straightforward enough.

# The interface is designed (partially) following the KDE Human Interface
# Guidelines (http://usability.kde.org/hig/)

Include "stdmenus.ui"

Include "stdtoolbars.ui"

# Which toolbars to use.
#
# The second parameter are the flags :
#
# on: the toolbar is visible
# off: the toolbar is not visible
# math: the toolbar is visible only when in math
# table: the toolbar is visible only when in a table
# top: the toolbar should be at the top of the window
# bottom: the toolbar should be at the bottom of the window
# left: the toolbar should be at the left of the window
# right: the toolbar should be at the right of the window
#
Toolbars
"standard" "on,top"
"extra" "on,top"
"table" "table,bottom"
"math" "math,bottom"
"minibuffer" "off,bottom"
End

Re: [patch] bug 2155: Crash when undoing DEPM deletion of the first par (pit = 0)

[Juergen Spitzmueller]

Juergen Spitzmueller wrote:
> Jean-Marc Lasgouttes wrote:
> > I'm very glad that you found the
> > cause, but the fix doesn't look
> > right.
>
> Too bad. Then I am at my witness end.

I have tried to enhance my witness a bit this year. Here's how I understand 
this case:

After DEPM, doRecordUndo is finally called, where undo.end is calculated as
undo.end = cell.lastpit() - last_pit;
cell.lastpit() is the lastpit of the buffer _including_ the paragraph that 
will be deleted. last_pit is the paragraph where the cursor sits.
If this is the first paragraph (pit = 0), then undo.end = cell.lastpit(), 
which is 1 bigger than lastpit() of the buffer _after_ DEPM.

Now if undo is activated after DEPM, textUndoOrRedo calls doRecordUndo again, 
with a last_pit that is calculated from cell_dit.lastpit() - undo.end. In our 
case, this is -1, since, as elaborated, undo.end is 1 bigger than current 
lastpit.

Until now, we thought that such a value is invalid, but as I understand it 
now, this is correct, since last_pit is again only used to calculate 
undo.end: 
undo.end = cell.lastpit() - last_pit;
which is
undo.end = cell.lastpit() - (-1), e.g. undo.end = cell.lastpit() + 1
IMHO this is correct, since the deleted paragraph is being added again at this 
stage, so undo.end has to increase by one. However, I'm not definitely sure.

Let's have a look at the crash. This is due to the first action of 
doRecordUndo:
if (first_pit > last_pit)
std::swap(first_pit, last_pit);
this is of course triggeres if last_pit = -1, but it shouldn't in this case. I 
don't know if it crashes because swap cannot handle negative values or 
because of some later action, anyway, it just shouldn't try to swap the two 
values here.

So my proposal to fix the bug now is

- if (first_pit > last_pit)
+ if (last_pit >= 0 && first_pit > last_pit)
std::swap(first_pit, last_pit);

(see attached patch).

As expected, this fixes the crash and also works as expected for undo after 
DEPM.

Does this sound reasonable?

Jürgen
Index: undo.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/undo.C,v
retrieving revision 1.69
diff -u -r1.69 undo.C
--- undo.C	24 Nov 2005 16:22:39 -	1.69
+++ undo.C	2 Jan 2006 11:43:19 -
@@ -64,7 +64,9 @@
 	bool isFullBuffer,
 	limited_stack & stack)
 {
-	if (first_pit > last_pit)
+	// last_pit can legally be -1 when a DEPM action in the first paragraph
+	// has to be restored! Then undo.end below is cell.lastpit + 1
+	if (last_pit >= 0 && first_pit > last_pit)
 		std::swap(first_pit, last_pit);
 	// create the position information of the Undo entry
 	Undo undo;
@@ -150,10 +152,9 @@
 	Buffer * buf = bv.buffer();
 	DocIterator cell_dit = undo.cell.asDocIterator(>inset());
 
-	doRecordUndo(Undo::ATOMIC, cell_dit,
-		   undo.from, cell_dit.lastpit() - undo.end, bv.cursor(),
-			 undo.bparams, undo.isFullBuffer,
-		   otherstack);
+	doRecordUndo(Undo::ATOMIC, cell_dit, undo.from,
+		cell_dit.lastpit() - undo.end, bv.cursor(),
+		undo.bparams, undo.isFullBuffer, otherstack);
 
 	// This does the actual undo/redo.
 	//lyxerr << "undo, performing: " << undo << std::endl;

Re: Bugs status

[Jose' Matos]

On Monday 02 January 2006 10:15, Martin Vermeer wrote:
> That having been said, obviously *some* font attributes should appear
> both on-screen and in output. My understanding was that, for LaTeX use,
> charstyles were for things like Emph and Noun. They should not use
> any coloured representation on-screen, but rather "realistic" fonts. For
> XML, I just don't know.

  XML does not have the concept of colours. :-)
  You are implying a policy here, so it should be the same not matter what 
backend is being used... unless I missed the point completely, it happened 
before. ;-)

> - Martin

-- 
José Abílio

Re: Bugs status

[Martin Vermeer]

On Mon, Jan 02, 2006 at 10:42:58AM +0100, Juergen Spitzmueller wrote:
> Martin Vermeer wrote:
> > > I think bug 2019 deserves your special attendance.
> >
> > Hmmm... perhaps the remark in insetcharstyle.C:draw:
> >
> > // I don't understand why the above .reduce and .realize aren't
> > //needed, or even wanted, here. It just works. -- MV 10.04.2005
> >
> > isn't quite true... could you have a look? I'm short on time right now.
> 
> I have already tried to implement those, but that didn't change anything. I 
> have also tried other things to no avail, so I finally gave up.
> I fear I just understand the whole fonts framework to less to fix this bug. 
> E.g. I just do not understand why, apparently, the color that is used to draw 
> the charstyle text on screen is also used in output, as is the case in the 
> bug in question. Aren't on-screen font colors and output font colors clearly 
> separated?
> 
> Jürgen

Actually I don't dare to touch this stuff. The whole font architecture
needs an overhaul/simplification. E.g., there are two different
getFonts, one in lyxtext (for display) and one in paragraph (for
latexing).

There should be a clear concept of "underlying font", to which a font is
reduced (or not) before drawing/latexing, be it the current layout
default font, the "outer font" in nested lists, or the "outer font"
outside the current inset. As of now, the concept exists but is
sort-of implemented all over the place.

Would it be an idea to open a bug targeting 1.5 for this?

- Martin



pgpIivWBEP7hm.pgp
Description: PGP signature

Re: Bugs status

[Juergen Spitzmueller]

Martin Vermeer wrote:
> Actually I don't dare to touch this stuff. The whole font architecture
> needs an overhaul/simplification. E.g., there are two different
> getFonts, one in lyxtext (for display) and one in paragraph (for
> latexing).

If it is too complicated or risky to fix this stuff now, we could of course 
postpone the fix and tell people to not use font colors for representation of 
charstyles (or let LyX just ignore such font color definitions). 
I think the restriction is bearable.

Jürgen

Re: [announce] sixth release of LyXWinInstaller

[Angus Leeming]

Stephen Harris wrote:
> Bo
> 
> The Miktex installation doc recommends installing Miktex into paths
> and/or directories without spaces. LyX has a history of problems
> with paths having spaces some passed on from Miktex.
> 
> http://wiki.lyx.org/pmwiki.php/Windows/LyX136pre
> 13 July 2005
> Axel Rasche reported that spaces in the file path caused BibTeX to fail.
> The adopted solution copies the BibTeX data base to the temp directory,
> mangling its name in the process into something that's both recognizable
> to the user and useable by BibTeX. Note that this fix hasn't yet made it
> into the official sources.

??? Yes it has. It's in the cvs repositories and will be part of future LyX
1.3.7/1.4.0 releases.

-- 
Angus

Re: Documentation out of date for 1.4.

[Angus Leeming]

Bennett Helm wrote:
>> 1. One for the Mac users: where is the "preferences" file to be found?
>> Currently I have:

> It's at ~/Library/Application Support/LyX/preferences.

Thanks, Bennett

-- 
Angus

Re: [PATCH] Tiny text changes

[Georg Baum]

A Happy New Year to verybody!

Lars Gullik Bjønnes wrote:

> Michael Gerz <[EMAIL PROTECTED]>
> writes:
> | How about the first change regarding amsart-seq?
> 
> If it is only a label change then it should not be changed now. If it
> OTOH fixes a real problem, then we should fix it now.

It fixes a typo in the LaTeX preamble and should go in IMHO. The "Exercise"
layout references a non-existing counter without it.


Georg

Re: Bugs status

[Martin Vermeer]

On Mon, Jan 02, 2006 at 01:01:46PM +0100, Juergen Spitzmueller wrote:
> Martin Vermeer wrote:
> > Actually I don't dare to touch this stuff. The whole font architecture
> > needs an overhaul/simplification. E.g., there are two different
> > getFonts, one in lyxtext (for display) and one in paragraph (for
> > latexing).
> 
> If it is too complicated or risky to fix this stuff now, we could of course 
> postpone the fix and tell people to not use font colors for representation of 
> charstyles (or let LyX just ignore such font color definitions). 
> I think the restriction is bearable.

For now, yes.

- Martin


pgppHpoCYvp0Q.pgp
Description: PGP signature

ChkTeX errors dialog almost unusable

[Angus Leeming]

When the dialog is open, clicking in the main document resets the position
of both dialog and document to the beginning. I find that I have to use
the dialog to naviagate to an error, close the dialog, fix the problem,
rerun chktex and hope that I can return to the same point relatively
quickly by navigating through all those "errors" I've looked at already
and decided were OK.

-- 
Angus

Re: ChkTeX errors dialog almost unusable

[Juergen Spitzmueller]

Angus Leeming wrote:
> When the dialog is open, clicking in the main document resets the position
> of both dialog and document to the beginning. I find that I have to use
> the dialog to naviagate to an error, close the dialog, fix the problem,
> rerun chktex and hope that I can return to the same point relatively
> quickly by navigating through all those "errors" I've looked at already
> and decided were OK.

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

Regards,
Jürgen

Toolbar setup

[Helge Hafting]

On Mon, Jan 02, 2006 at 11:41:55AM +0100, Abdel wrote:
> Helge Hafting a écrit :
> >On Fri, Dec 23, 2005 at 04:42:17PM +0100, Jean-Marc Lasgouttes wrote:
> >>>"Abdel" == Abdel  <[EMAIL PROTECTED]> 
> >>>writes:
> >>Abdel> Jean-Marc Lasgouttes a écrit :
> >"Abdel" == Abdel <[EMAIL PROTECTED]>
> >writes:
> >>Abdel> Oups, I have just discovered the math and table bars right
> >>Abdel> clicking on the top toolbar. All I can say is WAHOU !!! :-)
> >>Abdel> Sorry for that.
> Actually, it is possible to edit ui/default.ui to have these
> toolbars appear automatically when needed.
> >>Abdel> Very good! This should be the default IMHO.
> >>
> >>Not everybody appreciates to have toolbars popping up at seemingly
> >>random times. What we need is an user interface to set these values.
> >
> >That'd be nice.  In the meantime, what exactly do I do to my
> >"default.ui" in order to enable this labor-saving behaviour?
> 
> Under windows, the location would be:
> \Resources\LyX\ui\default.ui
> 
> Modify the toolbar section like this:
> 
> Toolbars
>   "standard" "on,top"
>   "extra" "on,top"
>   "table" "table,bottom"
>   "math" "math,bottom"
>   "minibuffer" "off,bottom"
> End
> 
Thanks a lot!  

Now, I understand that this won't be the default, but how about sticking
a commented-out version of this example in the distributed default.ui?
That should be safe even for 1.4.0, it is only documentation
this way.  And it sure makes life easier for anyone wanting to 
customize this. Then the nice GUI setup can be made for 1.4.1 or whatever.

Helge Hafting

Re: [announce] sixth release of LyXWinInstaller

[Bo Peng]

> _TeX_ cannot handle spaces. I suppose that you do not really
> know the difference of TeX, LaTeX, pdfTeX, pdfLaTeX, bibTeX, MiKTeX

I do not. My understanding is that miktex is another implementation of
latex standard ( if there is such a standard). If miktex aims at
windows platform, I assume that it will do something for the path with
spaces problem.

Bo

Re: [announce] sixth release of LyXWinInstaller

[Bo Peng]

> The mistake is making C:\Program files the default for LyX and
> friends.

I totally agree. I think it is a good idea to install Lyx to c:\lyx by default.

This will save us from some troubles, but not all. Most windows users
save their files under "...\My Documents" or "... and
Settings\Desktop" and will still suffer from this problem. It is quite
tricky to move these folders to something like D:\Documents.

Cheers,
Bo

Re: [announce] sixth release of LyXWinInstaller

[Angus Leeming]

Bo Peng wrote:

>> _TeX_ cannot handle spaces. I suppose that you do not really
>> know the difference of TeX, LaTeX, pdfTeX, pdfLaTeX, bibTeX, MiKTeX
> 
> I do not. My understanding is that miktex is another implementation of
> latex standard ( if there is such a standard). If miktex aims at
> windows platform, I assume that it will do something for the path with
> spaces problem.

Free software isn't built on assumptions, it's built on contributions. If
you're sufficiently irritated by this to want to do something about it,
then I'm sure that the MikTeX people will be more than happy to help you
help them.

Or, perhaps, this thread might help:
http://thread.gmane.org/gmane.editors.lyx.devel/43772


Jean-Marc contacted the real TeX gurus on the tex-k mailing list to ask for
some advice. You can find the full thread in the tex-k archives here:
http://www.tug.org/pipermail/tex-k/2005-April/index.html#1287


-- 
Angus

Re: Bugs status

[Martin Vermeer]

On Mon, Jan 02, 2006 at 03:30:21PM +0200, Martin Vermeer wrote:
> On Mon, Jan 02, 2006 at 01:01:46PM +0100, Juergen Spitzmueller wrote:
> > Martin Vermeer wrote:
> > > Actually I don't dare to touch this stuff. The whole font architecture
> > > needs an overhaul/simplification. E.g., there are two different
> > > getFonts, one in lyxtext (for display) and one in paragraph (for
> > > latexing).
> > 
> > If it is too complicated or risky to fix this stuff now, we could of course 
> > postpone the fix and tell people to not use font colors for representation 
> > of 
> > charstyles (or let LyX just ignore such font color definitions). 
> > I think the restriction is bearable.
> 
> For now, yes.
> 
> - Martin

Actually I would put it differently: you are not supposed to mix
character styles and font attributes :-)

My idea with charstyles has always been, longer term, to become a
logical replacement for visual font attributes. In XML they represent
"elements"; in LaTeX my idea was, that they would replace the existing
Noun and Emph thingies -- and whatever more the layout writers would
find useful... or with a GUI front-end, even the ordinary users. 

[Note that if the bug reporter would have defined and used an Emph
charstyle instead of the Emph font attribute, things would have worked
for him... perhaps a recommended workaround]

This did not happen for 1.4, as charstyle was viewed as not quite ready
yet (although apparently it is for _some_ users!), but that is still the
programme for me. When done, you wouldn't ever use raw font attributes
anymore.

- Martin


pgp5dI5bRmRwH.pgp
Description: PGP signature

Re: Bugs status

[Juergen Spitzmueller]

Martin Vermeer wrote:
> Actually I would put it differently: you are not supposed to mix
> character styles and font attributes :-)
>
> My idea with charstyles has always been, longer term, to become a
> logical replacement for visual font attributes. In XML they represent
> "elements"; in LaTeX my idea was, that they would replace the existing
> Noun and Emph thingies -- and whatever more the layout writers would
> find useful... or with a GUI front-end, even the ordinary users.

[...]

> This did not happen for 1.4, as charstyle was viewed as not quite ready
> yet (although apparently it is for _some_ users!), but that is still the
> programme for me. When done, you wouldn't ever use raw font attributes
> anymore.

This sounds very reasonable to me.
Perhaps you could add this explanation to the bug report. IIRC there is also 
another bug involved which will be fixed by your #2015-patch.

I propose to move bug 2019 out of the 1.4.0-radar after 2015 is fixed and 
target it to 1.5. If the gui for charstyles is in place, we can still see 
what we'll do with this.

Now convince HIM to put the #2015-fix in ;-)

Jürgen

Re: Bugs status

[Martin Vermeer]

On Mon, Jan 02, 2006 at 05:39:52PM +0100, Juergen Spitzmueller wrote:
> Martin Vermeer wrote:

...
 
> This sounds very reasonable to me.
> Perhaps you could add this explanation to the bug report. IIRC there is also 
> another bug involved which will be fixed by your #2015-patch.
> 
> I propose to move bug 2019 out of the 1.4.0-radar after 2015 is fixed and 
> target it to 1.5. If the gui for charstyles is in place, we can still see 
> what we'll do with this.

Perhaps this should be called an enhancement request and get its own bug
number.
 
> Now convince HIM to put the #2015-fix in ;-)

Which of them? ;-)

- Martin
 


pgpqQCMNjnKk0.pgp
Description: PGP signature

Re: [announce] sixth release of LyXWinInstaller

[Georg Baum]

Angus Leeming wrote:

> 
> Jean-Marc contacted the real TeX gurus on the tex-k mailing list to ask
> for some advice. You can find the full thread in the tex-k archives here:
> http://www.tug.org/pipermail/tex-k/2005-April/index.html#1287
> 

A bit more background:
http://sarovar.org/tracker/index.php?func=detail=377_id=106=493
This "spaces in filenames" stuff is _very_ difficult (if not impossible) to
fix, for reasons see the mentioned references.


Georg

Re: Bugs status

[Juergen Spitzmueller]

Martin Vermeer wrote:
> Perhaps this should be called an enhancement request and get its own bug
> number.

perhaps.

> > Now convince HIM to put the #2015-fix in ;-)
>
> Which of them? ;-)

Lars or Gullik. Jean and Marc have already expressed their principal 
accordance on bugzilla IIRC.

Jür & gen

Re: Bugs status

[Herbert Voss]

Juergen Spitzmueller wrote:

Martin Vermeer wrote:


Perhaps this should be called an enhancement request and get its own bug
number.



perhaps.



Now convince HIM to put the #2015-fix in ;-)


Which of them? ;-)



Lars or Gullik. Jean and Marc have already expressed their principal 
accordance on bugzilla IIRC.


Jür & gen


uuh, this causes an error!

\tabular{lr}
Jür & gen
\endtabular

and don't forget \usepackage[latin9]{inputenc} ... :-)

Herbert

Re: Bugs status

[Jose' Matos]

On Monday 02 January 2006 17:41, Herbert Voss wrote:
> uuh, this causes an error!
>
> \tabular{lr}
> Jür & gen
> \endtabular

  You are really a magician, splitting Jürgen in half. ;-)

> and don't forget \usepackage[latin9]{inputenc} ... :-)

  We are very modest, in this case 1 is enough. ;-)

> Herbert

-- 
José Abílio

Re: [announce] sixth release of LyXWinInstaller

[Michael Gerz]

Bo Peng wrote:


The mistake is making C:\Program files the default for LyX and
friends.
   


I totally agree. I think it is a good idea to install Lyx to c:\lyx by default.
 

No, the directory must be configurable. On my (German) machine, the 
appropriate directory is "C:\Programme". There is nothing worse than 
programs that ignore basic Windows guidelines.



This will save us from some troubles, but not all. Most windows users
save their files under "...\My Documents" or "... and
Settings\Desktop" and will still suffer from this problem. It is quite
tricky to move these folders to something like D:\Documents.
 

Indeed. We cannot assume that all Windows users have administrator 
privileges (in fact they shouldn't). Being unable to use "\My Documents" 
is like forbidding a *nix user to use $HOME (guess what he will tell you 
:-)).


In other words: We have to support spaces in paths to the maximum extent.

Michael

Re: [announce] sixth release of LyXWinInstaller

[Angus Leeming]

Michael Gerz wrote:

> Bo Peng wrote:
> 
>>>The mistake is making C:\Program files the default for LyX and
>>>friends.
>>>
>>>
>>I totally agree. I think it is a good idea to install Lyx to c:\lyx by
>>default.
>>  
>>
> No, the directory must be configurable. On my (German) machine, the
> appropriate directory is "C:\Programme". There is nothing worse than
> programs that ignore basic Windows guidelines.
> 
>>This will save us from some troubles, but not all. Most windows users
>>save their files under "...\My Documents" or "... and
>>Settings\Desktop" and will still suffer from this problem. It is quite
>>tricky to move these folders to something like D:\Documents.
>>  
>>
> Indeed. We cannot assume that all Windows users have administrator
> privileges (in fact they shouldn't). Being unable to use "\My Documents"
> is like forbidding a *nix user to use $HOME (guess what he will tell you
> :-)).
> 
> In other words: We have to support spaces in paths to the maximum extent.

Right. And since I install at C:\Program Files\LyX and the bloody thing
works for me, I'm going to put on my grumpy old man hat and say it's a
"user error" to try and use a .bst file in a path with spaces.

Signing off this thread now...

-- 
Angus

Re: Bugs status

[Martin Vermeer]

On Mon, Jan 02, 2006 at 06:17:31PM +0200, Martin Vermeer wrote:

...
 
> Actually I would put it differently: you are not supposed to mix
> character styles and font attributes :-)
> 
> My idea with charstyles has always been, longer term, to become a
> logical replacement for visual font attributes. In XML they represent
> "elements"; in LaTeX my idea was, that they would replace the existing
> Noun and Emph thingies -- and whatever more the layout writers would
> find useful... or with a GUI front-end, even the ordinary users. 
> 
> [Note that if the bug reporter would have defined and used an Emph
> charstyle instead of the Emph font attribute, things would have worked
> for him... perhaps a recommended workaround]
> 
> This did not happen for 1.4, as charstyle was viewed as not quite ready
> yet (although apparently it is for _some_ users!), but that is still the
> programme for me. When done, you wouldn't ever use raw font attributes
> anymore.

Bugzilla has a fix which simply disables font attribute editing inside a
charstyle inset; see above theory. Problem solved :-)

What it means in practice is, that if someone insists on using, say Emph
inside a charstyle inset, he should define another charstyle that does
Emph, and insert that. That works. Alternatively, split the inset in two
and put the emphasized text inbetween.

See attached, tested and works. OK to commit?

- Martin

Index: insetcharstyle.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcharstyle.C,v
retrieving revision 1.39
diff -u -p -r1.39 insetcharstyle.C
--- insetcharstyle.C25 Nov 2005 14:40:32 -  1.39
+++ insetcharstyle.C2 Jan 2006 18:59:02 -
@@ -249,6 +249,19 @@ bool InsetCharStyle::getStatus(LCursor &
case LFUN_BREAKPARAGRAPH:
case LFUN_BREAKPARAGRAPHKEEPLAYOUT:
case LFUN_BREAKPARAGRAPH_SKIP:
+   // font attributes also not allowed
+   case LFUN_DEFAULT:
+   case LFUN_CODE:
+   case LFUN_ROMAN:
+   case LFUN_SANS:
+   case LFUN_BOLD:
+   case LFUN_ITAL:
+   case LFUN_EMPH:
+   case LFUN_NOUN:
+   case LFUN_UNDERLINE:
+   case LFUN_FONT_SIZE:
+   case LFUN_FREEFONT_APPLY:
+   case LFUN_FREEFONT_UPDATE:
status.enabled(false);
return true;
 


pgpFyqSEH5WrX.pgp
Description: PGP signature

Screen update improvements

[Michael Gerz]

Martin,

your row signature patch is excellent as it reduces screen flickering 
significantly (you could the flicking on Windows with qtwin).


However, I don't understand why we have to redraw the whole screen in 
case of selections. Doesn't your nice "always draw current row" patch 
capture selections?


I tried the following modification and couldn't find anything going 
wrong. Could you please enlighten me?


Thanks, Michael


Index: rowpainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v
retrieving revision 1.162
diff -u -r1.162 rowpainter.C
--- rowpainter.C1 Jan 2006 23:06:23 -   1.162
+++ rowpainter.C2 Jan 2006 19:47:28 -
@@ -826,7 +826,7 @@
   for (pit_type pit = vi.p1; pit <= vi.p2; ++pit) {
   Paragraph const & par = text->getPar(pit);
   yy += par.ascent();
-   paintPar(pi, *bv.text(), pit, 0, yy, select || 
!vi.singlepar);
+   paintPar(pi, *bv.text(), pit, 0, yy, /*select ||*/ 
!vi.singlepar);

   yy += par.descent();
   }

Re: Screen update improvements

[Martin Vermeer]

On Mon, Jan 02, 2006 at 08:26:13PM +0100, Michael Gerz wrote:
> Martin,
> 
> your row signature patch is excellent as it reduces screen flickering 
> significantly (you could the flicking on Windows with qtwin).
> 
> However, I don't understand why we have to redraw the whole screen in 
> case of selections. Doesn't your nice "always draw current row" patch 
> capture selections?
> 
> I tried the following modification and couldn't find anything going 
> wrong. Could you please enlighten me?
> 
> Thanks, Michael

Yes, it works... apparently because !vi.singlerow implies select, in a
way that I haven't been able to figure out. So you don't actually save
anything.

Still might be wise to delete select from the two places where it occurs
together with || vi.singlerow.

- Martin



pgpILSNxnMmCt.pgp
Description: PGP signature

Re: [announce] sixth release of LyXWinInstaller

[Stephen Harris]

- Original Message - 
From: "Michael Gerz" <[EMAIL PROTECTED]>

To: "Bo Peng" <[EMAIL PROTECTED]>
Cc: "Stephen Harris" <[EMAIL PROTECTED]>; ; 


Sent: Monday, January 02, 2006 10:04 AM
Subject: Re: [announce] sixth release of LyXWinInstaller



Bo Peng wrote:


The mistake is making C:\Program files the default for LyX and
friends.

I totally agree. I think it is a good idea to install Lyx to c:\lyx by 
default.


No, the directory must be configurable. On my (German) machine, the 
appropriate directory is "C:\Programme". There is nothing worse than 
programs that ignore basic Windows guidelines.




Who said anything about the directory not being configurable.
The Default installation directory now reads: C:\program files\lyx
That can be manually changed to C:\Lyx
I think that the Default should be C:\LyX and the user can run
the risk of problems of paths with spaces if he chooses by
manually installing elsewhere or C:\program files\lyx

German doesn't have a problem with spaces by default
because Programme doesn't have any spaces in it.
Therefore C:\programme\lyx or C:\programme\miktex
will not have a space in it.

Why doesn't English have the default of C:\Programs?
Is it because C:\program files adheres to basic Windows guidelines?
No, certainly not.
Just because Word pioneered filenames with spaces doesn't
mean that practice should be emulated by other editors, nor
does Words ability to do this elevate the filename with spaces
capability to a "basic windows guideline".

Basic windows guidelines should be adopted according to
their ability to make windows and other programs work well
together. It is certainly not something Microsoft bought on
top of Mt. Sinai to redeem its clutch of customers.

I've investigated this issue. I have not been able to find any
reason for the adoption of path with spaces to make the
Windows OS work better or work better with other programs.

I think then that the default install of a path with spaces is not
part of basic windows guidelines. It is not a guideline but
maybe a standard. Microsoft introduces many proprietary
standards to gain market share. I see no reason why LyX, as
a member of the Free Source community, should endorse
MS standards in order to make LyX run poorly in conjunction
with its helper programs.

To be a basic windows guideline for LyX, it must help LyX
run better on Windows. Using paths with spaces damages
LyX's (with helper apps) ability to run well on Windows.
Thus it is no basic windows guideline which has any bearing
on how LyX should be installed.



This will save us from some troubles, but not all. Most windows users
save their files under "...\My Documents" or "... and
Settings\Desktop" and will still suffer from this problem. It is quite
tricky to move these folders to something like D:\Documents.

Indeed. We cannot assume that all Windows users have administrator 
privileges (in fact they shouldn't). Being unable to use "\My Documents" 
is like forbidding a *nix user to use $HOME (guess what he will tell you 
:-)).


In other words: We have to support spaces in paths to the maximum extent.

Michael



I haven't tested this. But, I don't think there is a problem with
My Documents because there is no problem when the work
directory is beneath Application Data. When the path which
contains *.bst files has no spaces, there is no problem. That
nospace path doesn't get changed because you store the lyx file
in C:\this is \a path\ wtih a lot \of spaces or in
C:\documents and settings\username\my documents

Re: Screen update improvements

[Abdel]

Michael Gerz a écrit :

Martin,

your row signature patch is excellent as it reduces screen flickering 
significantly (you could the flicking on Windows with qtwin).


FYI, without this patch (I have not update my cvs yet), my Qt4 port has 
zero flickering :-)
I think this patch is solving here a problem which is in the Qt3 
frontend. During my port, I have erased all the calls to the 
"QWidget::repaint" function and I just have one "update" to the screen. 
In other word, I let Qt decide when to draw.
I think the screen redraw that you see is due to an excessive call to 
repaint() that are not necessary. IMHO this patch tries to reduce the 
number of painting on the intermediate pixmap and this is good because, 
as a side effect it reduces also the number of screen repaint.
But I am not an expert so maybe this is just because Qt4 is supposed to 
be totally double-buffered.


Abdel.



However, I don't understand why we have to redraw the whole screen in 
case of selections. Doesn't your nice "always draw current row" patch 
capture selections?


I tried the following modification and couldn't find anything going 
wrong. Could you please enlighten me?


Thanks, Michael


Index: rowpainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/rowpainter.C,v
retrieving revision 1.162
diff -u -r1.162 rowpainter.C
--- rowpainter.C1 Jan 2006 23:06:23 -   1.162
+++ rowpainter.C2 Jan 2006 19:47:28 -
@@ -826,7 +826,7 @@
   for (pit_type pit = vi.p1; pit <= vi.p2; ++pit) {
   Paragraph const & par = text->getPar(pit);
   yy += par.ascent();
-   paintPar(pi, *bv.text(), pit, 0, yy, select || 
!vi.singlepar);
+   paintPar(pi, *bv.text(), pit, 0, yy, /*select ||*/ 
!vi.singlepar);

   yy += par.descent();
   }

Re: [announce] sixth release of LyXWinInstaller

[Stephen Harris]

- Original Message - 
From: "Angus Leeming" <[EMAIL PROTECTED]>

To: 
Cc: 
Sent: Monday, January 02, 2006 10:21 AM
Subject: Re: [announce] sixth release of LyXWinInstaller



Michael Gerz wrote:


Bo Peng wrote:


The mistake is making C:\Program files the default for LyX and
friends.



I totally agree. I think it is a good idea to install Lyx to c:\lyx by
default.



No, the directory must be configurable. On my (German) machine, the
appropriate directory is "C:\Programme". There is nothing worse than
programs that ignore basic Windows guidelines.


This will save us from some troubles, but not all. Most windows users
save their files under "...\My Documents" or "... and
Settings\Desktop" and will still suffer from this problem. It is quite
tricky to move these folders to something like D:\Documents.



Indeed. We cannot assume that all Windows users have administrator
privileges (in fact they shouldn't). Being unable to use "\My Documents"
is like forbidding a *nix user to use $HOME (guess what he will tell you
:-)).

In other words: We have to support spaces in paths to the maximum extent.


Right. And since I install at C:\Program Files\LyX and the bloody thing
works for me, I'm going to put on my grumpy old man hat and say it's a
"user error" to try and use a .bst file in a path with spaces.

Signing off this thread now...

--
Angus



And to think, just last night it was a party hat. I thought your post
was missing the usual reminder that whosoever developer declareth
the value of patch, yea verily, let him proceed to make it so,
to paraphrase:

Free software isn't built on assumptions, it's built on contributions. If
you're sufficiently inspired by your convictions to want to do something 
about it, then I'm sure that the MikTeX people will be more than happy

to help you help them.

Re: Screen update improvements

[Angus Leeming]

Abdel wrote:
>> your row signature patch is excellent as it reduces screen flickering
>> significantly (you could the flicking on Windows with qtwin).
> 
> FYI, without this patch (I have not update my cvs yet), my Qt4 port has
> zero flickering :-)

Right. Because Qt4 double buffers everything.

> I think this patch is solving here a problem which is in the Qt3
> frontend. During my port, I have erased all the calls to the
> "QWidget::repaint" function and I just have one "update" to the screen.
> In other word, I let Qt decide when to draw.

Also right (and good). But if we regenerate a pixmap a hundred times and Qt
displays it only once, then there's some redundancy there, no?

-- 
Angus

Re: [announce] sixth release of LyXWinInstaller

[Angus Leeming]

Stephen Harris wrote:
>> Right. And since I install at C:\Program Files\LyX and the bloody thing
>> works for me, I'm going to put on my grumpy old man hat and say it's a
>> "user error" to try and use a .bst file in a path with spaces.

> And to think, just last night it was a party hat.

The mood swings of old age and new parenthood, huh?

-- 
Angus

Re: Screen update improvements

[Abdel]

Angus Leeming a écrit :

Abdel wrote:

your row signature patch is excellent as it reduces screen flickering
significantly (you could the flicking on Windows with qtwin).

FYI, without this patch (I have not update my cvs yet), my Qt4 port has
zero flickering :-)


Right. Because Qt4 double buffers everything.


I think this patch is solving here a problem which is in the Qt3
frontend. During my port, I have erased all the calls to the
"QWidget::repaint" function and I just have one "update" to the screen.
In other word, I let Qt decide when to draw.


Also right (and good). But if we regenerate a pixmap a hundred times and Qt
displays it only once, then there's some redundancy there, no?


Totally, both painting should be minimum. I just wanted to point out 
that (IMHO) the flickering is not due to the pixmap repaint but more to 
the screen repaint. But as I said, I am not an expert and I am sure that 
this patch is necessary.


Abdel.

Re: [announce] sixth release of LyXWinInstaller

[Bo Peng]

Dear all,

It is confirmed that if the .bst file is in a path without space, the
bibliography will be generated correctly, even if lyx is installed
under c:\program files\lyx. So,

1. It is safe to install lyx to c:\program files,
2. It is not safe to put .bst files in a path with spaces. .lyx files
and all figure files are OK, as well as .bib files.

Bo

Can't compile lyx-1.4cvs with gcc 4.1

[Helge Hafting]

This is not something I really expected to work, with gcc 4.1 being
a work in progress.  Still, if someone is interested,
here is what happened:

In file included from ../../boost/boost/config.hpp:35,
 from ../../boost/boost/bind.hpp:23,
 from ../../src/support/translator.h:16,
 from ../../src/graphics/GraphicsTypes.h:18,
 from ../../src/graphics/GraphicsLoader.h:27,
 from render_graphic.h:17,
 from render_graphic.C:13:
../../boost/boost/config/compiler/gcc.hpp:92:7: warning: #warning "Unknown 
compiler version - please run the configure tests and report the results"
../../boost/boost/bind.hpp: In function 'void boost::visit_each(V&, const 
boost::_bi::value&, int) [with V = 
boost::signals::detail::bound_objects_visitor, T = const InsetBase*]':
../../boost/boost/bind.hpp:296:   instantiated from 'void 
boost::_bi::list2::accept(V&) const [with V = 
boost::signals::detail::bound_objects_visitor, A1 = 
boost::reference_wrapper, A2 = boost::_bi::value]'
../../boost/boost/bind/bind_template.hpp:150:   instantiated from 'void 
boost::_bi::bind_t::accept(V&) const [with V = 
boost::signals::detail::bound_objects_visitor, R = const Buffer* const, F = 
boost::_mfi::cmf1, L = 
boost::_bi::list2]'
../../boost/boost/bind.hpp:1110:   instantiated from 'void 
boost::visit_each(V&, const boost::_bi::bind_t&, int) [with V = 
boost::signals::detail::bound_objects_visitor, R = const Buffer* const, F = 
boost::_mfi::cmf1, L = 
boost::_bi::list2]'
../../boost/boost/visit_each.hpp:25:   instantiated from 'void 
boost::visit_each(Visitor&, const T&) [with Visitor = 
boost::signals::detail::bound_objects_visitor, T = boost::_bi::bind_t, 
boost::_bi::list2 >]'
../../boost/boost/signals/slot.hpp:121:   instantiated from 
'boost::slot::slot(const F&) [with F = boost::_bi::bind_t, 
boost::_bi::list2 >, SlotFunction = boost::function >]'
render_graphic.C:44:   instantiated from here
../../boost/boost/bind.hpp:1105: error: no matching function for call to 
'visit_each(boost::signals::detail::bound_objects_visitor&, const InsetBase* 
const&, int)'
make[4]: *** [render_graphic.lo] Error 1
make[4]: Leaving directory `/usr/src/lyx-devel/src/insets'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/usr/src/lyx-devel/src/insets'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/lyx-devel/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/lyx-devel/src'
make: *** [all-recursive] Error 1

Helge Hafting

Re: [announce] sixth release of LyXWinInstaller

[Stephen Harris]

- Original Message - 
From: "Bo Peng" <[EMAIL PROTECTED]>

To: 
Cc: 
Sent: Monday, January 02, 2006 4:41 PM
Subject: Re: [announce] sixth release of LyXWinInstaller


Dear all,

It is confirmed that if the .bst file is in a path without space, the
bibliography will be generated correctly, even if lyx is installed
under c:\program files\lyx. So,

1. It is safe to install lyx to c:\program files,
2. It is not safe to put .bst files in a path with spaces. .lyx files
and all figure files are OK, as well as .bib files.

Bo

To repeat back what you said in a different way for clarification:

It is better to install Miktex in C:\Miktex and/or C:\texmf
which usually contains the .bst files. 


A problem is likely to arise if you install Miktex to
C:\program files\miktex and/or c:\program files\texmf

Storing the output .lyx file and retrieving it later does not
require avoiding using a work directory without spaces.
IOW, you can use 
C:\documents and settings\username\My Documents

which has a space, or one can also use a nospace directory,
C:\MyDocs or C:\LyX\resources\lyx\work\Mydocs

So that working around the .bst problem of path and spaces by 
using a nospace directory path such as C:\texmf\bibtex\bst does
not impact negatively on the Windows traditional use of storing 
files in C:\Documents and Settings\username\My Documents or
C:\~...\...\Application data\LyX\Work for later retrieval. No change 
needs to be made for My Documents to accomodate using a nospace 
bst (texmf) directory path. Do I understand you correctly?



Apparently, the code that works for bibtex and paths with spaces
can't be easily substituted to handle bst (some kind of find/replace).

From what I read, TeX ends a filename when a space occurs. It

used to be that you could quote, "\path\with a space\" and the space
wouldn't cause a problem. But there seems to be a problem with
quotemarks, two, getting removed. I tried "\path\"with a space"\"
but \ is also used as an escape character which is why it maybe
doesn't work as well as a path delimiter as /.


Regards,
Stephen

LyXWinInstaller and WinXPx64

[Uwe Stöhr]

Stephen Harris wrote:


German doesn't have a problem with spaces by default
because Programme doesn't have any spaces in it.
Therefore C:\programme\lyx or C:\programme\miktex
will not have a space in it.


Beginning with WindowsXPx64 Microsoft only delivers native OS versions 
for english and japanese. All other OS language versions are'n native. 
That means also if you use german menus of Windows, the default is 
always "C:\program files".


Just for information.
Btw. LyXWinInstaller and all of the installed programs work fine under 
WindowsXPx64.


A happy new year and regards
Uwe