Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

[Koji Yokota]

 I'm not quite sure about the data structure used here, but arguments fmt
 and arg1 in bformat() seem to contain no data fields:

Oh, I should assume fmt and arg1 contain pointers. Sorry.

 (gdb) p fmt
 $44 = (const docstring *) 0xbfbfe588
 (gdb) p arg1
 $46 = (docstring *) 0xbfbfe580
 (gdb) x/s 0xbfbfe588
 0xbfbfe588: [EMAIL PROTECTED],%\bD
 (gdb) x/s 0xbfbfe580
 0xbfbfe580:	 
[EMAIL PROTECTED],%\bD


Koji

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

[Koji Yokota]

Also,


template class Ch, class Tr, class Alloc
basic_formatCh, Tr, Alloc:: basic_format(const string_type s)
: style_(0), cur_arg_(0), num_args_(0), dumped_(false),
  exceptions_(io::all_error_bits)
{
parse(s);  }


it contains:

 (gdb) p s
 $47 = (
 const 
std::basic_stringwchar_t,std::char_traitswchar_t,std::allocatorwchar_t 
 *) 0xbfbfe588


 (gdb) x/s 0xbfbfe588
 0xbfbfe588: [EMAIL PROTECTED],%\bD

and in


bool parse_ok = io::detail::parse_printf_directive(
it, buf.end(), items_[cur_item], fac, i1, exceptions());



we have the following argument data:

 (gdb) p items_[cur_item]
 $48 = (
const 
boost::io::detail::format_itemwchar_t,std::char_traitswchar_t,std::allocatorwchar_t 
 *) 0x8af4a80


 (gdb) x/s 0x8af4a80
 0x8af4a80:  \b\b


Koji

Re: UTF8-UCS4 failure on FreeBSD 6.2-RELEASE

[Koji Yokota]

So, this may have to be modified too.


  (gdb) p *start
  $38 = (const wchar_t ) @0x8b1e9c0: 49


 (gdb) x/5s 0x8b1e9c0
 0x8b1e9c0:  1
 0x8b1e9c2:  
 0x8b1e9c3:  
 0x8b1e9c4:  $
 0x8b1e9c6:  
 0x8b1e9c7:  
 0x8b1e9c8:  s
 0x8b1e9ca:  
 0x8b1e9cb:  
 0x8b1e9cc:  \r0
 0x8b1e9cf:  
 0x8b1e9d0:  \2220
 0x8b1e9d3:  
 0x8b1e9d4:  \\O
 0x8b1e9d7:  
 0x8b1e9d8:  \020b
 0x8b1e9db:  
 0x8b1e9dc:  W0
 0x8b1e9df:  
 0x8b1e9e0:  f0
 0x8b1e9e3:  
 0x8b1e9e4:  D0
 0x8b1e9e7:  
 0x8b1e9e8:  ~0
 0x8b1e9eb:  

where string size is

 (gdb) p fstring_size
 $54 = 25


Koji

Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...

[Jürgen Spitzmüller]

Bo Peng wrote:
 That is *too much* work!

Hm, you only have to copy the Listings-ERT conversion you already have done 
to the 273-272 chain and add a check for @params.

In the future, you will have to add a simple check that adds/removes @ for 
newly supported params (no ERT conversion necessary then).

I admit it's a bit awkward, but that's the price. We should have noticed this 
file format problem earlier.

 I will propose, instead,

 1. revert my @ idea
 2. add a checkbox like 'bypass validation', 'use what I have inputted'.
 3. if this checkbox is clicked, the parameter is allowed.

This dosn't solve the problem IMHO. If you add that checkbox, you'll have to 
handel te file format nevertheless.

 In this way, there will be no lyx2lyx problem.

 Agreed?

Jürgen

[patch] bug 3835: inset-toggle doesn't work for branch insets

[Jürgen Spitzmüller]

The attached patch fixes it for Bennett and me. Martin cannot remeber why he 
put the removed test there in the first place, but I didn't find any 
drawbacks.

OK?

Jürgen
Index: src/insets/InsetBranch.cpp
===
--- src/insets/InsetBranch.cpp	(Revision 18720)
+++ src/insets/InsetBranch.cpp	(Arbeitskopie)
@@ -152,7 +152,7 @@
 
 
 	case LFUN_INSET_TOGGLE:
-		if (cmd.argument() == assign || cmd.argument().empty()) {
+		if (cmd.argument() == assign) {
 			// The branch inset uses assign.
 			if (isBranchSelected(cur.buffer())) {
 if (status() != Open)

Re: [PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters

[Jürgen Spitzmüller]

Bo Peng wrote:
 In this patch, I add a check box 'bypass validation' that will allow
 any listings parameters to be passed to lyx/latex if this checkboz is
 checked. No file format is changed so no lyx2lyx is needed.

This is not true. You need to change the file format, because if people open 
such a file with an older version that doesn't have this checkbox, LyX will 
crash.

Same as with the @-solution.

Jürgen

Re: Bug #3812: Comments on patch

[Jürgen Spitzmüller]

Michael Gerz wrote:
 Maybe I was talking nonsense. I just looked at the patch (without the
 surrounding code). It looked like you check for the first character and
 then match(...) tries to match the complete string.

On a second thought, you might be right. The attached patch does what you 
propose and works for me.

OK to apply?

Jürgen
Index: src/lyxfind.cpp
===
--- src/lyxfind.cpp	(Revision 18720)
+++ src/lyxfind.cpp	(Arbeitskopie)
@@ -62,7 +62,8 @@
 	{}
 
 	// returns true if the specified string is at the specified position
-	bool operator()(Paragraph const  par, pos_type pos) const
+	// del specifies whether deleted strings in ct mode will be considered
+	bool operator()(Paragraph const  par, pos_type pos, bool del = true) const
 	{
 		docstring::size_type const size = str.length();
 		pos_type i = 0;
@@ -74,6 +75,8 @@
 break;
 			if (!cs  uppercase(str[i]) != uppercase(par.getChar(pos + i)))
 break;
+			if (!del  par.isDeleted(pos + i))
+break;
 		}
 
 		if (size != docstring::size_type(i))
@@ -101,20 +104,24 @@
 };
 
 
-bool findForward(DocIterator  cur, MatchString const  match)
+bool findForward(DocIterator  cur, MatchString const  match,
+		 bool find_del = true)
 {
 	for (; cur; cur.forwardChar())
-		if (cur.inTexted()  match(cur.paragraph(), cur.pos()))
+		if (cur.inTexted() 
+		match(cur.paragraph(), cur.pos(), find_del))
 			return true;
 	return false;
 }
 
 
-bool findBackwards(DocIterator  cur, MatchString const  match)
+bool findBackwards(DocIterator  cur, MatchString const  match,
+		 bool find_del = true)
 {
 	while (cur) {
 		cur.backwardChar();
-		if (cur.inTexted()  match(cur.paragraph(), cur.pos()))
+		if (cur.inTexted() 
+		match(cur.paragraph(), cur.pos(), find_del))
 			return true;
 	}
 	return false;
@@ -141,7 +148,8 @@
 }
 
 
-bool find(BufferView * bv, docstring const  searchstr, bool cs, bool mw, bool fw)
+bool find(BufferView * bv, docstring const  searchstr, bool cs, bool mw, bool fw,
+	  bool find_del = true)
 {
 	if (!searchAllowed(bv, searchstr))
 		return false;
@@ -150,7 +158,8 @@
 
 	MatchString const match(searchstr, cs, mw);
 
-	bool found = fw ? findForward(cur, match) : findBackwards(cur, match);
+	bool found = fw ? findForward(cur, match, find_del) :
+			  findBackwards(cur, match, find_del);
 
 	if (found)
 		bv-putSelectionAt(cur, searchstr.length(), !fw);
@@ -177,7 +186,7 @@
 	int const ssize = searchstr.size();
 
 	DocIterator cur = doc_iterator_begin(buf.inset());
-	while (findForward(cur, match)) {
+	while (findForward(cur, match, false)) {
 		pos_type pos = cur.pos();
 		Font const font
 			= cur.paragraph().getFontSettings(buf.params(), pos);
@@ -227,7 +236,7 @@
 	Cursor  cur = bv-cursor();
 	cap::replaceSelectionWithString(cur, replacestr, fw);
 	bv-buffer()-markDirty();
-	find(bv, searchstr, cs, mw, fw);
+	find(bv, searchstr, cs, mw, fw, false);
 	bv-update();
 
 	return 1;
Index: src/BufferView.cpp
===
--- src/BufferView.cpp	(Revision 18720)
+++ src/BufferView.cpp	(Arbeitskopie)
@@ -665,6 +665,8 @@
 {
 	FuncStatus flag;
 
+	Cursor  cur = cursor_;
+
 	switch (cmd.action) {
 
 	case LFUN_UNDO:
@@ -678,7 +680,7 @@
 	case LFUN_FILE_INSERT_PLAINTEXT:
 	case LFUN_BOOKMARK_SAVE:
 		// FIXME: Actually, these LFUNS should be moved to Text
-		flag.enabled(cursor_.inTexted());
+		flag.enabled(cur.inTexted());
 		break;
 	case LFUN_FONT_STATE:
 	case LFUN_LABEL_INSERT:
@@ -691,7 +693,6 @@
 	case LFUN_NOTE_NEXT:
 	case LFUN_REFERENCE_NEXT:
 	case LFUN_WORD_FIND:
-	case LFUN_WORD_REPLACE:
 	case LFUN_MARK_OFF:
 	case LFUN_MARK_ON:
 	case LFUN_MARK_TOGGLE:
@@ -703,9 +704,13 @@
 		flag.enabled(true);
 		break;
 
+	case LFUN_WORD_REPLACE:
+		flag.enabled(!cur.paragraph().isDeleted(cur.pos()));
+		break;
+
 	case LFUN_LABEL_GOTO: {
 		flag.enabled(!cmd.argument().empty()
-		|| getInsetByCodeInsetRef(cursor_, Inset::REF_CODE));
+		|| getInsetByCodeInsetRef(cur, Inset::REF_CODE));
 		break;
 	}
 
@@ -1617,7 +1622,9 @@
 		FileDialog fileDlg(_(Select LyX document to insert),
 			LFUN_FILE_INSERT,
 			make_pair(_(Documents|#o#O), from_utf8(lyxrc.document_path)),
-			make_pair(_(Examples|#E#e), from_utf8(addPath(package().system_support().absFilename(), examples;
+			make_pair(_(Examples|#E#e),
+from_utf8(addPath(package().system_support().absFilename(),
+examples;
 
 		FileDialog::Result result =
 			fileDlg.open(from_utf8(initpath),

1.5 RC1 crashes on show Outline

[Ramon Ramos]

Hi, 

1.5 RC1 crashes with the msg:
Assertion triggered in const lyx::docstring lyx::from_ascii(const char*)
by failing check static_castunsigned char(*c) 
 0x80 in file docstring.cpp:32
Abortado

always when I want to show the outline (TOC). Now I am using 1.5 beta3
again

Regards,

Ramón

Re: 1.5 RC1 crashes on show Outline

[Stefan Schimanski]

Am 10.06.2007 um 10:38 schrieb Ramon Ramos:


Hi,

1.5 RC1 crashes with the msg:
Assertion triggered in const lyx::docstring lyx::from_ascii(const  
char*)

by failing check static_castunsigned char(*c) 
 0x80 in file docstring.cpp:32
Abortado

always when I want to show the outline (TOC). Now I am using 1.5 beta3
again


Wasn't there some post-beta-1 commit which remove the from_ascii call?

Stefan


PGP.sig
Description: Signierter Teil der Nachricht

Re: 1.5 RC1 crashes on show Outline

[Jürgen Spitzmüller]

Ramon Ramos wrote:
 1.5 RC1 crashes with the msg:
 Assertion triggered in const lyx::docstring lyx::from_ascii(const char*)
 by failing check static_castunsigned char(*c) 
  0x80 in file docstring.cpp:32
 Abortado

This bug 3793:
http://bugzilla.lyx.org/show_bug.cgi?id=3793

It's fixed in the meantime.

Jürgen

Re: invoices

[Jürgen Spitzmüller]

Ralph Boland wrote:
 I am looking for a simple package to do a couple of invoices only.
 One option is to use invoice.sty
 I don't know latex but I do know lyx.
 So, one option is to create an invoice.layout file.
 But I don't know how to create a layout file.

 Is there documentation on how to do this?

Help-Customization, chap. 5
and
http://wiki.lyx.org/Layouts/CreatingLayouts

 Assuming I do this how do I then submit my layout file to Lyx
 so it can be used by others?

First, you can upload it to the wiki:
http://wiki.lyx.org/Layouts/Layouts/

If it proves to be interesting enough, we might consider to include it to the 
distribution.

 I am using Lyx 1.4.2.  I don't suppose a invoice.layout file exists in a
 newer
 version of Lyx or in some repository somewhere?

Not that I know.

 Thanks

 Ralph Boland


Jürgen

Re: Bug #3812: Comments on patch

[Jürgen Spitzmüller]

Jürgen Spitzmüller wrote:
 On a second thought, you might be right. The attached patch does what you
 propose and works for me.

 OK to apply?

This patch also fixes bug 3160:
http://bugzilla.lyx.org/show_bug.cgi?id=3160

Jürgen

Re: [patch] bug 3835: inset-toggle doesn't work for branch insets

[Martin Vermeer]

On Sun, Jun 10, 2007 at 09:31:19AM +0200, Jürgen Spitzmüller wrote:
 The attached patch fixes it for Bennett and me. Martin cannot remeber why he 
 put the removed test there in the first place, but I didn't find any 
 drawbacks.
 
 OK?
 
 Jürgen

Did you try save/reload to see if only branch insets for
the selected branch(es) are open? (vague recollection)

- Martin


 Index: src/insets/InsetBranch.cpp
 ===
 --- src/insets/InsetBranch.cpp(Revision 18720)
 +++ src/insets/InsetBranch.cpp(Arbeitskopie)
 @@ -152,7 +152,7 @@
  
  
   case LFUN_INSET_TOGGLE:
 - if (cmd.argument() == assign || cmd.argument().empty()) {
 + if (cmd.argument() == assign) {
   // The branch inset uses assign.
   if (isBranchSelected(cur.buffer())) {
   if (status() != Open)
 

Re: [patch] bug 3835: inset-toggle doesn't work for branch insets

[Jürgen Spitzmüller]

Martin Vermeer wrote:
 Did you try save/reload to see if only branch insets for
 the selected branch(es) are open? (vague recollection)

Yes. This still works.

Jürgen

Re: [PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters

[Bo Peng]

This is not true. You need to change the file format, because if people open
such a file with an older version that doesn't have this checkbox, LyX will
crash.


Let us just forget about RC1, which is meant to be experimental.

1.5.0 == 1.4.x

Current lyx2lyx translate listings to ERT. No problem.

1.5.0 ==  1.5.x

No file format problem.


1.5.x == 1.5.0


Parameters are *not* validated so the file can be compiled as long as
a user is using a capable listings package. If some parameter is
acceptable by 1.5.2, but not 1.5.0, a user will be in trouble only
when he use GUI to edit the inset. In this case, he can use this
bypass button.

Because RC1 does not acceptable unrecognized parameters, RC1
1. ignore all global parameters (try/catch in bufferparam.cpp) if a
global parameter is not recognized.
2. may crash or compile for normal insets (need to check code).
3. GUI will not work for unrecognized parameter.

The only solution would be using ERT from 1.5.x = RC1.

Cheers,
Bo

Re: [patch] Huge fonts do not set the row height, #3787

[Alfredo Braunstein]

Jürgen Spitzmüller wrote:

 Stefan Schimanski wrote:
 Bug: http://bugzilla.lyx.org/show_bug.cgi?id=3787
 Problem: Changing the font does not change the fontmetrics variable.
 Patch:
 
 Looks good and works for me.

The patch seems trivially correct. The only thing that bothers me is that
the scope of the fontmetrics var is that 'if' block, while the font
variable it refers to has whole function scope... so this is prone to error
if fontmetrics is used later (which for now it isn't). As Jürgen already
approved, just add a comment about that and put it in.

A/

Re: [PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters

[Jürgen Spitzmüller]

Bo Peng wrote:
 Parameters are *not* validated so the file can be compiled as long as
 a user is using a capable listings package. 

That's a progress indeed.

 If some parameter is 
 acceptable by 1.5.2, but not 1.5.0, a user will be in trouble only
 when he use GUI to edit the inset. In this case, he can use this
 bypass button.

What happens if he doesn't? An error message?

 Because RC1 does not acceptable unrecognized parameters, RC1
 1. ignore all global parameters (try/catch in bufferparam.cpp) if a
 global parameter is not recognized.
 2. may crash or compile for normal insets (need to check code).

it will for sure.

 3. GUI will not work for unrecognized parameter.

Therefore ...

 The only solution would be using ERT from 1.5.x = RC1.

Why are you so reluctant about this? Most of the code is there, so it's really 
not to much work, and our reversion chain is significantly less corrupted 
than it is anyway.

Jürgen

Re: Bug #3812: Comments on patch

[Alfredo Braunstein]

Jürgen Spitzmüller wrote:

 Jürgen Spitzmüller wrote:
 On a second thought, you might be right. The attached patch does what you
 propose and works for me.

 OK to apply?
 
 This patch also fixes bug 3160:
 http://bugzilla.lyx.org/show_bug.cgi?id=3160

This patch looks fine. 

Regards,

A/

Re: Bug #3812: Comments on patch

[Jürgen Spitzmüller]

Alfredo Braunstein wrote:
 This patch looks fine.

committed now.

Jürgen

Re: Road to rc2

[Stefan Schimanski]

- What are the patches submitted that you think deserve attention?
I would like to give special attention to critical bugs and so on...


I have posted several patches which are waiting to go in or a comment  
why not:


* [patch] sometimes only paragraph of cursor is visible, #3231
* [patch] Up/down cursor in math-macro jumps out of the macro, #3830
* [patch] fixing segfault because of empty coord cache, #3715
* [patch] lyx crashes/mutilates document using math-delimiter ( ) in  
hebrew text, #2446


The last two fix critical bugs. See the threads for more info.

Stefan


PGP.sig
Description: Signierter Teil der Nachricht

Re: [patch] Huge fonts do not set the row height, #3787

[Alfredo Braunstein]

Alfredo Braunstein wrote:

if (maxsize  font.size()) {
+   // use standard paragraph font with the maximal size
font.setSize(maxsize);
-   maxasc  = max(maxasc,  fontmetrics.maxAscent());
-   maxdesc = max(maxdesc, fontmetrics.maxDescent());
+   FontMetrics const  maxfontmetrics = theFontMetrics(font);
+   maxasc  = max(maxasc,  maxfontmetrics.maxAscent());
+   }


I would add a comment saying that the fontmetrics variable is outdated once
you change 'font'. Otherwise there's the risk we hit this bug again and
again...

A/

Re: [patch] Huge fonts do not set the row height, #3787

[Stefan Schimanski]

Am 10.06.2007 um 17:12 schrieb Alfredo Braunstein:


Alfredo Braunstein wrote:

if (maxsize  font.size()) {
+   // use standard paragraph font with the maximal size
font.setSize(maxsize);
-   maxasc  = max(maxasc,  fontmetrics.maxAscent());
-   maxdesc = max(maxdesc, fontmetrics.maxDescent());
+   FontMetrics const  maxfontmetrics = theFontMetrics 
(font);

+   maxasc  = max(maxasc,  maxfontmetrics.maxAscent());
+   }


I would add a comment saying that the fontmetrics variable is  
outdated once
you change 'font'. Otherwise there's the risk we hit this bug again  
and

again...


I make a copy now. So it should be clear. I think it's obvious that  
the fontmetric does not adapt if the font is changed. The update was  
just forgotten.


Stefan


PGP.sig
Description: Signierter Teil der Nachricht

Re: [patch] Huge fonts do not set the row height, #3787

[Alfredo Braunstein]

Stefan Schimanski wrote:

 I would add a comment saying that the fontmetrics variable is
 outdated once
 you change 'font'. Otherwise there's the risk we hit this bug again
 and
 again...
 
 I make a copy now. So it should be clear. I think it's obvious that

even better.

 the fontmetric does not adapt if the font is changed. The update was
 just forgotten.

Ok.

A/

Re: [PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters

[Bo Peng]

 If some parameter is
 acceptable by 1.5.2, but not 1.5.0, a user will be in trouble only
 when he use GUI to edit the inset. In this case, he can use this
 bypass button.

What happens if he doesn't? An error message?


Then the parameter will be used without problem because they are not
validated by 1.5.0.


 Because RC1 does not acceptable unrecognized parameters, RC1
 1. ignore all global parameters (try/catch in bufferparam.cpp) if a
 global parameter is not recognized.
 2. may crash or compile for normal insets (need to check code).

it will for sure.

 3. GUI will not work for unrecognized parameter.

Therefore ...

 The only solution would be using ERT from 1.5.x = RC1.

Why are you so reluctant about this? Most of the code is there, so it's really
not to much work, and our reversion chain is significantly less corrupted
than it is anyway.


I think we only need to support official releases, but if you insist,
I will do something with lyx2lyx.

Have you tested the patch (without lyx2lyx)? Any opinion?

Cheers,
Bo

Re: [patch] bug 3835: inset-toggle doesn't work for branch insets

[Martin Vermeer]

On Sun, Jun 10, 2007 at 12:05:47PM +0200, Jürgen Spitzmüller wrote:
 Martin Vermeer wrote:
  Did you try save/reload to see if only branch insets for
  the selected branch(es) are open? (vague recollection)
 
 Yes. This still works.

Great. Then I suspect I did unthinking cut'n paste from somewhere.

- Martin
 

Re: SV: [PATCH] Change default mathbg and add mathhoverbg.

[Jean-Marc Lasgouttes]

 Edwin == Leuven, E [EMAIL PROTECTED] writes:

Edwin Jean-Marc Lasgouttes wrote:
 It is completely different: dEPM disallows things that have _no_
 meaning to LaTeX (like double space). And empty math inset is
 acceptable, even if it is most of the times not wanted.

Edwin sure, perhaps latex permits this but when would you want to
Edwin create an empty math inset?

There are always people who have good reasons to do weird things.
Which should not artificially forbid constructs.

 None of these solve the problem for an inset containing a hard
 space, but those who ask for trouble deserve it.

Edwin maybe we should disallow a space after a backslash in math?

Edwin or are there situations where this makes sense?

\  is pretty useful in maths. It should definitely stay.

JMarc

Re: [patch] bug 3835: inset-toggle doesn't work for branch insets

[Jean-Marc Lasgouttes]

 Jürgen == Jürgen Spitzmüller [EMAIL PROTECTED] writes:

Jürgen The attached patch fixes it for Bennett and me. Martin cannot
Jürgen remeber why he put the removed test there in the first place,
Jürgen but I didn't find any drawbacks.

Looks good.

JMarc

Re: [PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters

[Bo Peng]

I think we only need to support official releases, but if you insist,
I will do something with lyx2lyx.


Attached please find an updated patch with lyx2lyx support for RC1.

OK to apply?

Cheers,
Bo
Index: src/insets/InsetListingsParams.h
===
--- src/insets/InsetListingsParams.h	(revision 18733)
+++ src/insets/InsetListingsParams.h	(working copy)
@@ -74,6 +74,9 @@
 
 	///
 	void clear() { params_.clear(); }
+	
+	/// validate parameter, return an error message
+	docstring validate() const;
 
 private:
 	/// inline or normal listings
@@ -87,22 +90,6 @@
 };
 
 
-class invalidParam : public std::exception {
-public:
-	invalidParam(docstring const  details)
-	: details_(to_utf8(details))
-	{}
-
-	virtual const char * what() const throw() {
-		return details_.c_str();
-	}
-
-	virtual ~invalidParam() throw() {}
-private:
-	std::string const details_;
-};
-
-
 } // namespace lyx
 
 #endif
Index: src/insets/InsetListingsParams.cpp
===
--- src/insets/InsetListingsParams.cpp	(revision 18733)
+++ src/insets/InsetListingsParams.cpp	(working copy)
@@ -271,15 +271,13 @@
 public:
 	ParValidator();
 
-	/// \return the associated \c ListingsParam.
-	/// \warning an \c invalidParamexception will be thrown
-	///  if the key is not found.
-	ListingsParam const  param(string const  key) const;
+	/// validate a parameter for a given name.
+	/// return an error message if \c par is an invalid parameter.
+	docstring validate(string const  name, string const  par) const;
 
-	/// validate a parameter for a given key.
-	/// \warning an \c invalidParam exception will be thrown if
-	/// \c par is an invalid parameter.
-	ListingsParam const  validate(string const  key, string const  par) const;
+	/// return the onoff status of a parameter \c key, if \c key is not found
+	/// return false
+	bool onoff(string const  key) const;
 
 private:
 	/// key is the name of the parameter
@@ -584,21 +582,11 @@
 }
 
 
-ListingsParam const  ParValidator::validate(string const  key,
+docstring ParValidator::validate(string const  name,
 		string const  par) const
 {
-	ListingsParam const  lparam = param(key);
-	docstring s = lparam.validate(par);
-	if (!s.empty())
-		throw invalidParam(bformat(_(Parameter %1$s: ), from_utf8(key)) + s);
-	return lparam;
-}
-
-
-ListingsParam const  ParValidator::param(string const  name) const
-{
 	if (name.empty())
-		throw invalidParam(_(Invalid (empty) listing parameter name.));
+		return _(Invalid (empty) listing parameter name.);
 
 	if (name[0] == '?') {
 		string suffix = trim(string(name, 1));
@@ -613,39 +601,59 @@
 			}
 		}
 		if (suffix.empty())
-			throw invalidParam(bformat(
-	_(Available listing parameters are %1$s), from_ascii(param_names)));
+			return bformat(
+	_(Available listing parameters are %1$s), from_ascii(param_names));
 		else
-			throw invalidParam(bformat(
+			return bformat(
 	_(Available listings parameters containing string \%1$s\ are %2$s), 
-		from_utf8(suffix), from_utf8(param_names)));
+		from_utf8(suffix), from_utf8(param_names));
 	}
  
 	// locate name in parameter table
 	ListingsParams::const_iterator it = all_params_.find(name);
-	if (it != all_params_.end())
-		return it-second;
-
-	// otherwise, produce a meaningful error message.
-	string matching_names;
-	ListingsParams::const_iterator end = all_params_.end();
-	for (it = all_params_.begin(); it != end; ++it) {
-		if (prefixIs(it-first, name)) {
-			if (!matching_names.empty())
-matching_names += , ;
-			matching_names += it-first;
+	if (it != all_params_.end()) {
+		docstring msg = it-second.validate(par);
+		if (msg.empty())
+			return msg;
+		else
+			return bformat(_(Parameter %1$s: ), from_utf8(name)) + msg;
+	} else {
+		// otherwise, produce a meaningful error message.
+		string matching_names;
+		ListingsParams::const_iterator end = all_params_.end();
+		for (it = all_params_.begin(); it != end; ++it) {
+			if (prefixIs(it-first, name)) {
+if (!matching_names.empty())
+	matching_names += , ;
+matching_names += it-first;
+			}
 		}
+		if (matching_names.empty())
+			return bformat(_(Unknown listing parameter name: %1$s),
+from_utf8(name));
+		else
+			return bformat(_(Parameters starting with '%1$s': %2$s),
+from_utf8(name), from_utf8(matching_names));
 	}
-	if (matching_names.empty())
-		throw invalidParam(bformat(_(Unknown listing parameter name: %1$s),
-		from_utf8(name)));
+	return docstring();
+}
+
+
+bool ParValidator::onoff(string const  name) const
+{
+	// locate name in parameter table
+	ListingsParams::const_iterator it = all_params_.find(name);
+	if (it != all_params_.end())
+		return it-second.onoff_;
 	else
-		throw invalidParam(bformat(_(Parameters starting with '%1$s': %2$s),
-		from_utf8(name), from_utf8(matching_names)));
+		return false;
 }
 
 } // namespace anon.
 
+// define a global 

Re: SV: [PATCH] Change default mathbg and add mathhoverbg.

[Edwin Leuven]

Jean-Marc Lasgouttes wrote:

Edwin sure, perhaps latex permits this but when would you want to
Edwin create an empty math inset?

There are always people who have good reasons to do weird things.
Which should not artificially forbid constructs.


we wouldn't, there is ert

...

signing off on this thread now.

Re: [PATCH] get rid of Inset::background_color_

[Andre Poenitz]

On Fri, Jun 08, 2007 at 11:16:49AM +0200, Jean-Marc Lasgouttes wrote:
 
 This rather straightforward patch gets rid of Inset::background_color_,
 which adds 4 bytes to Inset for no good reason.
 
 If there is _really_ a need for setBackgroundColor, we could consider
 moving it to InsetText instead.
 
 I note that a footnote/table inside a yellow note will not inherit the
 background. This is something that used to work in 1.3, but got killed
 in 1.4.
 
 Andre', Jose', would that be OK?

Sure, fine with me.

Andre'

Re: [PATCH] Change default mathbg and add mathhoverbg.

[Andre Poenitz]

On Fri, Jun 08, 2007 at 04:51:33PM +0200, Leuven, E. wrote:
 Bo Peng wrote:
  what is the point of $ $ and $\ $ ?
  
  A method to force extra spaces, and more likely, entered by accident
  (and then it is impossible to remove them).
 
 so the inset should be dissolved when these are entered...?

I don't tink it is worth adding special code for such a corner case
(especially when the resolution is disputable).

I never ever had the problem of having an emptyh math inset hanging
around, and even if I had it'd probably been there for good reason
(like I entered it)

Andre'

Re: [PATCH] Change default mathbg and add mathhoverbg.

[Andre Poenitz]

On Fri, Jun 08, 2007 at 03:53:58PM +0100, José Matos wrote:
 On Friday 08 June 2007 15:51:33 Leuven, E. wrote:
  so the inset should be dissolved when these are entered...?
 
 It seems more intuitive, no?

And an ő on a line of its own doesn't make much sense either.
Not even in Hungary. So I propose to remove such lines as
soon as we see one.

Ok for 1.5.0, Jose'?

Andre'

Re: [patch] fixing segfault because of empty coord cache

[Andre Poenitz]

On Fri, Jun 08, 2007 at 05:03:55PM +0200, Stefan Schimanski wrote:
 Critical bugs don't get less critical by ignorance.
 
 If anybody wants to know more:
 
 1) CommandInset (used e.g. for references in mathed) has two cells to  
 hold information about where it points to. But it only draws a  
 button, not the cells themselves. So accessing the cells' coordinates  
 in the cache during drawSelection segfaults.
 2) This all happens only because, after creating the InsetMathRef  
 (derived from CommandInset) with \ref, the cursor is inside of it.  
 Hence, InsetMathNest will try to draw the selection inside the  
 InsetMathRef below the cells.
 3) So, why is the cursor inside it? Because it is derived from  
 InsetMathNest and has = 1 cells. The LFUN_SELF_INSERT handler of the  
 hull (in fact in InsetMathNest::doDispatch) takes this as a reason to  
 put the cursor inside. I guess that's not correct, because the cursor- 
 left behavior normally checks the isActive() method before entering  
 an inset. But here isActive() is not called.

Good analysis.
 
 So I propose the following patch (which fixes #3715). The first hunk  
 is trivial. But I am not sure about the consequences of the second. I  
 think it's the correct way to insert an inset, but maybe there are  
 other inset which depend on the old (wrong) behavior. Comments?

I can't tell you. It is conceptionally sound, however, so close to 1.5.0
it might be more prudent to use something like 

  ...  !atom-isMathRefInset()

and put a fat FIXME there to ask fopr investigation in quieter times.

The second part most definitely has a potential smell of brown
paperbags...

Andre'

Re: [PATCH] Change default mathbg and add mathhoverbg.

[Andre Poenitz]

On Fri, Jun 08, 2007 at 10:23:21AM -0500, Bo Peng wrote:
   The objection to this was because it implied to another data member to 
   the
 inset. Is there a solution that does not imply this?
 
 Only mathhull has this mouse_hover_ variable so it is less a problem
 than the inset background case. (at least mathchar does not have it).

Right, as a general rule putting _some_ stuff into math hull is fine.

[That's not an endorsement of mouse_hover_, but a general commemt.
mouse_hover_ could e.g. be a buffer view member pointing to the 'hovered
over' inset. It certainly is a 'view' thing, whereas data in
the insets are (at least theoretically *cough*) 'model' thingies.]

Andre'

Re: [PATCH] Change default mathbg and add mathhoverbg.

[Andre Poenitz]

On Fri, Jun 08, 2007 at 10:38:05AM -0500, Bo Peng wrote:
  even if it's possible it doesn't mean it is advisable or even desirable
 
 I toss M$ Word because, among other overly clever features, it changes
 i to I all the time. I would object, in general, any *automatic*
 changes to what I entered without my agreement.

I am completely on your side in this case.

Andre'

Re: SV: [PATCH] Change default mathbg and add mathhoverbg.

[Andre Poenitz]

On Fri, Jun 08, 2007 at 06:25:16PM +0200, Leuven, E. wrote:
  I toss M$ Word because, among other overly clever features, it changes
  i to I all the time.
  
 (before we used the big nasty wolf to scare people, now it is the big nasty 
 M$)
  
  I would object, in general, any *automatic*
  changes to what I entered without my agreement.
  
 can u say D, can u say E, can u say P, can u say M
  
 can u say DEPM?!

And DEPM is the feature that caused a lot of grieve so far (for
developers, not users in this case)

Andre'

Re: LyX document-build process

[John Pye]

Hi Andre,

Thanks for these comments. More follows:

Andre Poenitz wrote:
 On Tue, Jun 05, 2007 at 09:52:49PM +1000, John Pye wrote:
   
 Sorry for a bit of a delay on this one. I thought I would follow up with
 some comments though.

 Firstly,

 Jean-Marc Lasgouttes wrote:

[...]

   
 The concept I had here was that one might be writing some software with
 a tarball that contains both C code and supporting LyX documentation.
 The documentation ultimately gets embedded into the application file in
 the form of let's say a windows .CHM help file. Imagine that a developer
 want to make some changes to a small part of the program and perhaps
 some small change in the documentation. If the LyX build process were
 somehow integrated with scons, then developer could just call 'scons'
 and rebuild the necessary bits of the program code plus the missing bits
 of the documentation. The dependency checker would have everything it
 needed without launching the full-blown LyX application to build the
 documentation. In this case, LyX would just do the job of perhaps
 transforming .lyx to .tex; scons would do the job of compiling the .tex
 file together with .png images together into a set of .html files and
 then convert the .html files to .chm files...
 

 People have successfully used plain Makefile for this purpose.
   

Although I am sure it can be made work (inefficiently), it just doesn't
seem like the architecture is right for this. More comment further below.

   
 At present, because lyx uses its own build system, the efficiencies of
 the above approach are not possible.
 

 ?

 Which 'own' build system?
   

LyX *does* contain a build system. The following features:

* LyX can work out what image files need to be converted (dependency
  tracking)
* LyX knows how to convert image files (build rules)
* The LyX GUI detects when an image file is changed and triggers an
  updated file conversion (source file modification tracking)
* LyX instantiates tex in order to create a PDF file (multiple steps
  to achieve required output file)
* LyX knows the order that things need to be built in (graph algorithms)
* LyX keeps a cache of converted image files and doesn't re-convert
  them all every time (output caching)
* Build rules and file types can be specified by the user
  (user-defined build rules)
* LyX contains certain hard-wired default rules (default build rules)

It may not be full-blown thing but I don't see any clear distinction
between where LyX functionality stops and where a 'full blown' build
system starts.

   
 I think that perhaps it does need a build system. My thesis takes a good
 five minutes to build, and there is absolutely no indication of how far
 through it is, or what it's doing at any given point in time.
 

 You know that it takes five minutes, and if it takes an average of two
 minutes to fill your coffee mug you'll know when 40% are done...
   

More coffee will only heighten my paranoia! Seriously, LyX is a GUI
application but it makes no effort at being GUI-friendly during the
document build process. It wouldn't be that hard to add a 'progress'
dialog box for this stuff? Run a separate thread for the build tools and
update the screen as they go? Helps to know when images are too large or
too detailed, or if something is hung, etc?

[...]

   
 When I change things in 'sub-files' in my thesis (ie chapters) LyX
 doesn't always correctly detect that something's changed, and it ends up
 producing the same PDF file as before I made my changes. It seems that
 there could be a missing link in the dependency tracking.
 

 Makefile.
   

I think that this is a bug in LyX. LyX *must* be able to do this type of
dependency tracking 100% correctly if it is going to attempt it at all.
It is no good that it outputs the wrong document in this case.

[...]

   
 So you mentioned that the build process is trivial but I think that the
 above examples show that it's perhaps not so trivial, and perhaps if a
 full-scale build system were used it might allow the LyX development
 effort to reduce the amount of 'support code' that needs to be
 maintained, so that you can focus on some of the more core LyX
 functionality?
 

 The point is that LyX is not a build system, cannot be, and does not
 want to be. If you need one (and you have shown good reasons for that)
 just use one. If you prefer Scons over make, so be it, but in both cases
 this is a solution _wrapping_ LyX, not a solution integrated in LyX.
   

My basic problem here is that LyX is not really wrap-able, because of
the way that it fires off an indeterminate number of sub-processes to
convert images and other source material. It works quite differently
from the usual tools that are called from a build script such as CPP,
GCC, flex, bison, SWIG, etc.

As I argued above, LyX contains *its own* build system: it defines tools
and file transformations, dependency tracking and 

Crashing when pressing enter...

[Alexander Streit]

Hi Guys,

I'm using the 1.5RC1 release (released May 31). On the Mac (PowerPC
architecture) the table of contents pane simply doesn't show, so I'm
using my windows machine instead. But that is not why I am writing. I
am writing because I get a consistent crash when I try to press enter
to insert a new line in a paragraph. I've kept the file. I don't want
the file to be public (since it is a journal submission), but I'm
happy to send it whoever would be fixing/confirming the crash. it is
93kb.

Unfortunately the more details dialog doesn't give me much info at
all: simply closing lyx socket and completed. There was one time
when it said more, with the following line embedded among other
harmless looking messages:
NoRepeatedApplyReadOnlyPolicy: No transition for input SMI_OKAY from
state INVALID

I don't know if it is related, because it does not seem to reappear.
The paragraph in question has a cross reference to a figure at the end
of it, otherwise it is a normal paragraph with nothing fancy at all
(no math or emphasize or anything).

Keep up the good work!

-alex

Re: Window-independent dialogs

[Angus Leeming]

Stefan Schimanski wrote:

Hi!

Is there a reason that the non-modal dialogs (like to edit tables, 
change text styles etc.) depend on the LyX window? You can open another 
one for every window which is open. It's somehow strange and confusing 
to have a text style dialog, but it doesn't work because it belongs to 
another window.


That's just the way they were designed. getDialogs belongs to the 
LyXView. When a dialog is created, it contains a pointer to this 
LyXView so that it can dispatch requests back to it. See 
src/frontends/controllers/Kernel.cpp:


33 void Kernel::dispatch(FuncRequest const  fr) const
34 {
35 lyxview_.dispatch(fr);
36 }

Angus

Re: [PATCH] Bug 3711, add insets without valid ParConstIterator to TOC.

[Angus Leeming]

Abdelrazak Younes wrote:

Bo Peng wrote:

Per the use of exception, I think exception should be used more often
in lyx.


LyX's code base is not exception safe. The code hasn't been written 
with exception safety in mind, largely because we weren't proficient 
in the use of exceptions. (I certainly include myself in that statement.)


For example, counters are not updated immediately after, say,

an caption is added to InsetInclude. It would be good to have
something like

try
   work on inset going on
except updateCounter (+1, or -1)
except updateScreen (partial or all)
except kill me please

Just some random thought.


IMHO exceptions should only be used in _exceptional_ situation because 
they bypass the normal function to function communication. I think the 
way you want to use them is going to slow down the code significantly. 
This is reason why I don't like for example the way exceptions are 
misused in the listings code.


Yes, unwinding the stack is very expensive.

Angus

Suggested improvements for LyX macros

[Mark Kortink]

Hi
 
Below are some suggestions for improving macros in LyX. As a user it has
taken many hours of going through the poor user documentation and various
LaTeX manuals and editors trying to figure out how to get them working and
then why they don't work, very frustrating! Hopefully these suggestions can
be incorporated into some release because I have given up on macros even
though I eventually got them working and they would be extremely useful if
they worked in such a way to make life easier, even working in a simple way
would be better..
 
1. In the user guide:
- do not use the name macro or macrowarg as the example macro names,
guaranteed to confuse.
- show all the steps in sequence and what it looks like on screen, don't
give examples of output without showing the input. Step 1, enter the
math-macro mname n in the minibuffer then step 2, type the LaTeX defs into
the blue boxes which defines the macros so it can be used then step 3, use
it over and over by going into math mode and typing \mname and entering the
argument values after the m: placeholders. You get the idea. 
- I found after much pain that you can't put #n, you have to escape it like
\#n, this is not documented and should not be the case anyhow, #n is the
standard. 
 
2. Fix the way they work and look on screen 
- When values have been supplied for the argument display the result
WYSIWYM. When the user clicks on the macro to edit its values revert back to
edit mode with the arguments lists 1:, 2:, etc as now.
 
3. The big one, allow \newcommand and \DeclareMathOperator to be defined in
the preamble, even if you have to follow some LyX conventions, they need to
be able to be imported from a file.
 
Regards
 
Mark Kortink
e: [EMAIL PROTECTED]
p: 0419-250-403
 

Re: LyX document-build process

[Angus Leeming]

John Pye wrote:

As I argued above, LyX contains *its own* build system: it defines tools
and file transformations, dependency tracking and caching. Because it
contains all of these things internally it makes using it within an
external build system much more difficult that it should be.

I think that good architecture going forward might be for LyX to divest
all of the build tracking stuff to an external program that specialises
in dependency tracking, caching, and parallel building, and to try to
re-use what others have already done in this area.

Thoughts?


LyX needs passionate people to drive forward its development. As 
you're clearly passionate about this, then you should consider 
contributing code to realize your vision.


Angus

Re: Suggested improvements for LyX macros

[Stefan Schimanski]

Please take a look at my new macro implementation:

http://www.youtube.com/watch?v=68Gys4rp3u4

Make it fullscreen while watching to see what's going on. Some points  
you give should be solved by that.


Stefan

Am 11.06.2007 um 06:36 schrieb Mark Kortink:


Hi

Below are some suggestions for improving macros in LyX. As a user  
it has
taken many hours of going through the poor user documentation and  
various
LaTeX manuals and editors trying to figure out how to get them  
working and
then why they don't work, very frustrating! Hopefully these  
suggestions can
be incorporated into some release because I have given up on macros  
even
though I eventually got them working and they would be extremely  
useful if
they worked in such a way to make life easier, even working in a  
simple way

would be better..

1. In the user guide:
- do not use the name macro or macrowarg as the example macro  
names,

guaranteed to confuse.
- show all the steps in sequence and what it looks like on screen,  
don't

give examples of output without showing the input. Step 1, enter the
math-macro mname n in the minibuffer then step 2, type the LaTeX  
defs into
the blue boxes which defines the macros so it can be used then step  
3, use
it over and over by going into math mode and typing \mname and  
entering the

argument values after the m: placeholders. You get the idea.
- I found after much pain that you can't put #n, you have to escape  
it like
\#n, this is not documented and should not be the case anyhow, #n  
is the

standard.

2. Fix the way they work and look on screen
- When values have been supplied for the argument display the result
WYSIWYM. When the user clicks on the macro to edit its values  
revert back to

edit mode with the arguments lists 1:, 2:, etc as now.

3. The big one, allow \newcommand and \DeclareMathOperator to be  
defined in
the preamble, even if you have to follow some LyX conventions, they  
need to

be able to be imported from a file.

Regards

Mark Kortink
e: [EMAIL PROTECTED]
p: 0419-250-403





PGP.sig
Description: Signierter Teil der Nachricht

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

[Koji Yokota]

> I'm not quite sure about the data structure used here, but arguments fmt
> and arg1 in bformat() seem to contain no data fields:

Oh, I should assume  and  contain pointers. Sorry.

> (gdb) p 
> $44 = (const docstring *) 0xbfbfe588
> (gdb) p 
> $46 = (docstring *) 0xbfbfe580
> (gdb) x/s 0xbfbfe588
> 0xbfbfe588: "[EMAIL PROTECTED],%\bD"
> (gdb) x/s 0xbfbfe580
> 0xbfbfe580:	 
"[EMAIL PROTECTED],%\bD"


Koji

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

[Koji Yokota]

Also,


template< class Ch, class Tr, class Alloc>
basic_format:: basic_format(const string_type& s)
: style_(0), cur_arg_(0), num_args_(0), dumped_(false),
  exceptions_(io::all_error_bits)
{
parse(s);  }


it contains:

> (gdb) p 
> $47 = (
> const 
std::basic_string *) 0xbfbfe588

>
> (gdb) x/s 0xbfbfe588
> 0xbfbfe588: "[EMAIL PROTECTED],%\bD"

and in


bool parse_ok = io::detail::parse_printf_directive(
it, buf.end(), _[cur_item], fac, i1, exceptions());



we have the following argument data:

> (gdb) p _[cur_item]
> $48 = (
const 
boost::io::detail::format_item *) 0x8af4a80

>
> (gdb) x/s 0x8af4a80
> 0x8af4a80:  "\b\b"


Koji

Re: UTF8->UCS4 failure on FreeBSD 6.2-RELEASE

[Koji Yokota]

So, this may have to be modified too.


 > (gdb) p *start
 > $38 = (const wchar_t &) @0x8b1e9c0: 49


> (gdb) x/5s 0x8b1e9c0
> 0x8b1e9c0:  "1"
> 0x8b1e9c2:  ""
> 0x8b1e9c3:  ""
> 0x8b1e9c4:  "$"
> 0x8b1e9c6:  ""
> 0x8b1e9c7:  ""
> 0x8b1e9c8:  "s"
> 0x8b1e9ca:  ""
> 0x8b1e9cb:  ""
> 0x8b1e9cc:  "\r0"
> 0x8b1e9cf:  ""
> 0x8b1e9d0:  "\2220"
> 0x8b1e9d3:  ""
> 0x8b1e9d4:  "\\O"
> 0x8b1e9d7:  ""
> 0x8b1e9d8:  "\020b"
> 0x8b1e9db:  ""
> 0x8b1e9dc:  "W0"
> 0x8b1e9df:  ""
> 0x8b1e9e0:  "f0"
> 0x8b1e9e3:  ""
> 0x8b1e9e4:  "D0"
> 0x8b1e9e7:  ""
> 0x8b1e9e8:  "~0"
> 0x8b1e9eb:  ""

where string size is

> (gdb) p fstring_size
> $54 = 25


Koji

Re: r18728 - in /lyx-devel/trunk/src/insets: InsetListings.cp...

[Jürgen Spitzmüller]

Bo Peng wrote:
> That is *too much* work!

Hm, you only have to copy the Listings->ERT conversion you already have done 
to the 273->272 chain and add a check for @params.

In the future, you will have to add a simple check that adds/removes @ for 
newly supported params (no ERT conversion necessary then).

I admit it's a bit awkward, but that's the price. We should have noticed this 
file format problem earlier.

> I will propose, instead,
>
> 1. revert my @ idea
> 2. add a checkbox like 'bypass validation', 'use what I have inputted'.
> 3. if this checkbox is clicked, the parameter is allowed.

This dosn't solve the problem IMHO. If you add that checkbox, you'll have to 
handel te file format nevertheless.

> In this way, there will be no lyx2lyx problem.
>
> Agreed?

Jürgen

[patch] bug 3835: inset-toggle doesn't work for branch insets

[Jürgen Spitzmüller]

The attached patch fixes it for Bennett and me. Martin cannot remeber why he 
put the removed test there in the first place, but I didn't find any 
drawbacks.

OK?

Jürgen
Index: src/insets/InsetBranch.cpp
===
--- src/insets/InsetBranch.cpp	(Revision 18720)
+++ src/insets/InsetBranch.cpp	(Arbeitskopie)
@@ -152,7 +152,7 @@
 
 
 	case LFUN_INSET_TOGGLE:
-		if (cmd.argument() == "assign" || cmd.argument().empty()) {
+		if (cmd.argument() == "assign") {
 			// The branch inset uses "assign".
 			if (isBranchSelected(cur.buffer())) {
 if (status() != Open)

Re: [PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters

[Jürgen Spitzmüller]

Bo Peng wrote:
> In this patch, I add a check box 'bypass validation' that will allow
> any listings parameters to be passed to lyx/latex if this checkboz is
> checked. No file format is changed so no lyx2lyx is needed.

This is not true. You need to change the file format, because if people open 
such a file with an older version that doesn't have this checkbox, LyX will 
crash.

Same as with the @-solution.

Jürgen

Re: Bug #3812: Comments on patch

[Jürgen Spitzmüller]

Michael Gerz wrote:
> Maybe I was talking nonsense. I just looked at the patch (without the
> surrounding code). It looked like you check for the first character and
> then match(...) tries to match the complete string.

On a second thought, you might be right. The attached patch does what you 
propose and works for me.

OK to apply?

Jürgen
Index: src/lyxfind.cpp
===
--- src/lyxfind.cpp	(Revision 18720)
+++ src/lyxfind.cpp	(Arbeitskopie)
@@ -62,7 +62,8 @@
 	{}
 
 	// returns true if the specified string is at the specified position
-	bool operator()(Paragraph const & par, pos_type pos) const
+	// del specifies whether deleted strings in ct mode will be considered
+	bool operator()(Paragraph const & par, pos_type pos, bool del = true) const
 	{
 		docstring::size_type const size = str.length();
 		pos_type i = 0;
@@ -74,6 +75,8 @@
 break;
 			if (!cs && uppercase(str[i]) != uppercase(par.getChar(pos + i)))
 break;
+			if (!del && par.isDeleted(pos + i))
+break;
 		}
 
 		if (size != docstring::size_type(i))
@@ -101,20 +104,24 @@
 };
 
 
-bool findForward(DocIterator & cur, MatchString const & match)
+bool findForward(DocIterator & cur, MatchString const & match,
+		 bool find_del = true)
 {
 	for (; cur; cur.forwardChar())
-		if (cur.inTexted() && match(cur.paragraph(), cur.pos()))
+		if (cur.inTexted() &&
+		match(cur.paragraph(), cur.pos(), find_del))
 			return true;
 	return false;
 }
 
 
-bool findBackwards(DocIterator & cur, MatchString const & match)
+bool findBackwards(DocIterator & cur, MatchString const & match,
+		 bool find_del = true)
 {
 	while (cur) {
 		cur.backwardChar();
-		if (cur.inTexted() && match(cur.paragraph(), cur.pos()))
+		if (cur.inTexted() &&
+		match(cur.paragraph(), cur.pos(), find_del))
 			return true;
 	}
 	return false;
@@ -141,7 +148,8 @@
 }
 
 
-bool find(BufferView * bv, docstring const & searchstr, bool cs, bool mw, bool fw)
+bool find(BufferView * bv, docstring const & searchstr, bool cs, bool mw, bool fw,
+	  bool find_del = true)
 {
 	if (!searchAllowed(bv, searchstr))
 		return false;
@@ -150,7 +158,8 @@
 
 	MatchString const match(searchstr, cs, mw);
 
-	bool found = fw ? findForward(cur, match) : findBackwards(cur, match);
+	bool found = fw ? findForward(cur, match, find_del) :
+			  findBackwards(cur, match, find_del);
 
 	if (found)
 		bv->putSelectionAt(cur, searchstr.length(), !fw);
@@ -177,7 +186,7 @@
 	int const ssize = searchstr.size();
 
 	DocIterator cur = doc_iterator_begin(buf.inset());
-	while (findForward(cur, match)) {
+	while (findForward(cur, match, false)) {
 		pos_type pos = cur.pos();
 		Font const font
 			= cur.paragraph().getFontSettings(buf.params(), pos);
@@ -227,7 +236,7 @@
 	Cursor & cur = bv->cursor();
 	cap::replaceSelectionWithString(cur, replacestr, fw);
 	bv->buffer()->markDirty();
-	find(bv, searchstr, cs, mw, fw);
+	find(bv, searchstr, cs, mw, fw, false);
 	bv->update();
 
 	return 1;
Index: src/BufferView.cpp
===
--- src/BufferView.cpp	(Revision 18720)
+++ src/BufferView.cpp	(Arbeitskopie)
@@ -665,6 +665,8 @@
 {
 	FuncStatus flag;
 
+	Cursor & cur = cursor_;
+
 	switch (cmd.action) {
 
 	case LFUN_UNDO:
@@ -678,7 +680,7 @@
 	case LFUN_FILE_INSERT_PLAINTEXT:
 	case LFUN_BOOKMARK_SAVE:
 		// FIXME: Actually, these LFUNS should be moved to Text
-		flag.enabled(cursor_.inTexted());
+		flag.enabled(cur.inTexted());
 		break;
 	case LFUN_FONT_STATE:
 	case LFUN_LABEL_INSERT:
@@ -691,7 +693,6 @@
 	case LFUN_NOTE_NEXT:
 	case LFUN_REFERENCE_NEXT:
 	case LFUN_WORD_FIND:
-	case LFUN_WORD_REPLACE:
 	case LFUN_MARK_OFF:
 	case LFUN_MARK_ON:
 	case LFUN_MARK_TOGGLE:
@@ -703,9 +704,13 @@
 		flag.enabled(true);
 		break;
 
+	case LFUN_WORD_REPLACE:
+		flag.enabled(!cur.paragraph().isDeleted(cur.pos()));
+		break;
+
 	case LFUN_LABEL_GOTO: {
 		flag.enabled(!cmd.argument().empty()
-		|| getInsetByCode(cursor_, Inset::REF_CODE));
+		|| getInsetByCode(cur, Inset::REF_CODE));
 		break;
 	}
 
@@ -1617,7 +1622,9 @@
 		FileDialog fileDlg(_("Select LyX document to insert"),
 			LFUN_FILE_INSERT,
 			make_pair(_("Documents|#o#O"), from_utf8(lyxrc.document_path)),
-			make_pair(_("Examples|#E#e"), from_utf8(addPath(package().system_support().absFilename(), "examples";
+			make_pair(_("Examples|#E#e"),
+from_utf8(addPath(package().system_support().absFilename(),
+"examples";
 
 		FileDialog::Result result =
 			fileDlg.open(from_utf8(initpath),

1.5 RC1 crashes on show Outline

[Ramon Ramos]

Hi, 

1.5 RC1 crashes with the msg:
Assertion triggered in const lyx::docstring lyx::from_ascii(const char*)
by failing check "static_cast(*c) <
 0x80" in file docstring.cpp:32
Abortado

always when I want to show the outline (TOC). Now I am using 1.5 beta3
again

Regards,

Ramón

Re: 1.5 RC1 crashes on show Outline

[Stefan Schimanski]

Am 10.06.2007 um 10:38 schrieb Ramon Ramos:


Hi,

1.5 RC1 crashes with the msg:
Assertion triggered in const lyx::docstring lyx::from_ascii(const  
char*)

by failing check "static_cast(*c) <
 0x80" in file docstring.cpp:32
Abortado

always when I want to show the outline (TOC). Now I am using 1.5 beta3
again


Wasn't there some post-beta-1 commit which remove the from_ascii call?

Stefan


PGP.sig
Description: Signierter Teil der Nachricht

Re: 1.5 RC1 crashes on show Outline

[Jürgen Spitzmüller]

Ramon Ramos wrote:
> 1.5 RC1 crashes with the msg:
> Assertion triggered in const lyx::docstring lyx::from_ascii(const char*)
> by failing check "static_cast(*c) <
>  0x80" in file docstring.cpp:32
> Abortado

This bug 3793:
http://bugzilla.lyx.org/show_bug.cgi?id=3793

It's fixed in the meantime.

Jürgen

Re: invoices

[Jürgen Spitzmüller]

Ralph Boland wrote:
> I am looking for a simple package to do a couple of invoices only.
> One option is to use invoice.sty
> I don't know latex but I do know lyx.
> So, one option is to create an invoice.layout file.
> But I don't know how to create a layout file.
>
> Is there documentation on how to do this?

Help->Customization, chap. 5
and
http://wiki.lyx.org/Layouts/CreatingLayouts

> Assuming I do this how do I then submit my layout file to Lyx
> so it can be used by others?

First, you can upload it to the wiki:
http://wiki.lyx.org/Layouts/Layouts/

If it proves to be interesting enough, we might consider to include it to the 
distribution.

> I am using Lyx 1.4.2.  I don't suppose a invoice.layout file exists in a
> newer
> version of Lyx or in some repository somewhere?

Not that I know.

> Thanks
>
> Ralph Boland


Jürgen

Re: Bug #3812: Comments on patch

[Jürgen Spitzmüller]

Jürgen Spitzmüller wrote:
> On a second thought, you might be right. The attached patch does what you
> propose and works for me.
>
> OK to apply?

This patch also fixes bug 3160:
http://bugzilla.lyx.org/show_bug.cgi?id=3160

Jürgen

Re: [patch] bug 3835: inset-toggle doesn't work for branch insets

[Martin Vermeer]

On Sun, Jun 10, 2007 at 09:31:19AM +0200, Jürgen Spitzmüller wrote:
> The attached patch fixes it for Bennett and me. Martin cannot remeber why he 
> put the removed test there in the first place, but I didn't find any 
> drawbacks.
> 
> OK?
> 
> Jürgen

Did you try save/reload to see if only branch insets for
the selected branch(es) are open? (vague recollection)

- Martin


> Index: src/insets/InsetBranch.cpp
> ===
> --- src/insets/InsetBranch.cpp(Revision 18720)
> +++ src/insets/InsetBranch.cpp(Arbeitskopie)
> @@ -152,7 +152,7 @@
>  
>  
>   case LFUN_INSET_TOGGLE:
> - if (cmd.argument() == "assign" || cmd.argument().empty()) {
> + if (cmd.argument() == "assign") {
>   // The branch inset uses "assign".
>   if (isBranchSelected(cur.buffer())) {
>   if (status() != Open)
> 

Re: [patch] bug 3835: inset-toggle doesn't work for branch insets

[Jürgen Spitzmüller]

Martin Vermeer wrote:
> Did you try save/reload to see if only branch insets for
> the selected branch(es) are open? (vague recollection)

Yes. This still works.

Jürgen

Re: [PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters

[Bo Peng]

This is not true. You need to change the file format, because if people open
such a file with an older version that doesn't have this checkbox, LyX will
crash.


Let us just forget about RC1, which is meant to be experimental.

1.5.0 ==> 1.4.x

Current lyx2lyx translate listings to ERT. No problem.

1.5.0 ==> > 1.5.x

No file format problem.


1.5.x ==> 1.5.0


Parameters are *not* validated so the file can be compiled as long as
a user is using a capable listings package. If some parameter is
acceptable by 1.5.2, but not 1.5.0, a user will be in trouble only
when he use GUI to edit the inset. In this case, he can use this
bypass button.

Because RC1 does not acceptable unrecognized parameters, RC1
1. ignore all global parameters (try/catch in bufferparam.cpp) if a
global parameter is not recognized.
2. may crash or compile for normal insets (need to check code).
3. GUI will not work for unrecognized parameter.

The only solution would be using ERT from 1.5.x => RC1.

Cheers,
Bo

Re: [patch] Huge fonts do not set the row height, #3787

[Alfredo Braunstein]

Jürgen Spitzmüller wrote:

> Stefan Schimanski wrote:
>> Bug: http://bugzilla.lyx.org/show_bug.cgi?id=3787
>> Problem: Changing the font does not change the fontmetrics variable.
>> Patch:
> 
> Looks good and works for me.

The patch seems trivially correct. The only thing that bothers me is that
the scope of the fontmetrics var is that 'if' block, while the font
variable it refers to has whole function scope... so this is prone to error
if fontmetrics is used later (which for now it isn't). As Jürgen already
approved, just add a comment about that and put it in.

A/

Re: [PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters

[Jürgen Spitzmüller]

Bo Peng wrote:
> Parameters are *not* validated so the file can be compiled as long as
> a user is using a capable listings package. 

That's a progress indeed.

> If some parameter is 
> acceptable by 1.5.2, but not 1.5.0, a user will be in trouble only
> when he use GUI to edit the inset. In this case, he can use this
> bypass button.

What happens if he doesn't? An error message?

> Because RC1 does not acceptable unrecognized parameters, RC1
> 1. ignore all global parameters (try/catch in bufferparam.cpp) if a
> global parameter is not recognized.
> 2. may crash or compile for normal insets (need to check code).

it will for sure.

> 3. GUI will not work for unrecognized parameter.

Therefore ...

> The only solution would be using ERT from 1.5.x => RC1.

Why are you so reluctant about this? Most of the code is there, so it's really 
not to much work, and our reversion chain is significantly less corrupted 
than it is anyway.

Jürgen

Re: Bug #3812: Comments on patch

[Alfredo Braunstein]

Jürgen Spitzmüller wrote:

> Jürgen Spitzmüller wrote:
>> On a second thought, you might be right. The attached patch does what you
>> propose and works for me.
>>
>> OK to apply?
> 
> This patch also fixes bug 3160:
> http://bugzilla.lyx.org/show_bug.cgi?id=3160

This patch looks fine. 

Regards,

A/

Re: Bug #3812: Comments on patch

[Jürgen Spitzmüller]

Alfredo Braunstein wrote:
> This patch looks fine.

committed now.

Jürgen

Re: Road to rc2

[Stefan Schimanski]

- What are the patches submitted that you think deserve attention?
I would like to give special attention to critical bugs and so on...


I have posted several patches which are waiting to go in or a comment  
why not:


* [patch] sometimes only paragraph of cursor is visible, #3231
* [patch] Up/down cursor in math-macro jumps out of the macro, #3830
* [patch] fixing segfault because of empty coord cache, #3715
* [patch] lyx crashes/mutilates document using math-delimiter ( ) in  
hebrew text, #2446


The last two fix critical bugs. See the threads for more info.

Stefan


PGP.sig
Description: Signierter Teil der Nachricht

Re: [patch] Huge fonts do not set the row height, #3787

[Alfredo Braunstein]

Alfredo Braunstein wrote:

if (maxsize > font.size()) {
+   // use standard paragraph font with the maximal size
font.setSize(maxsize);
-   maxasc  = max(maxasc,  fontmetrics.maxAscent());
-   maxdesc = max(maxdesc, fontmetrics.maxDescent());
+   FontMetrics const & maxfontmetrics = theFontMetrics(font);
+   maxasc  = max(maxasc,  maxfontmetrics.maxAscent());
+   }


I would add a comment saying that the fontmetrics variable is outdated once
you change 'font'. Otherwise there's the risk we hit this bug again and
again...

A/

Re: [patch] Huge fonts do not set the row height, #3787

[Stefan Schimanski]

Am 10.06.2007 um 17:12 schrieb Alfredo Braunstein:


Alfredo Braunstein wrote:

if (maxsize > font.size()) {
+   // use standard paragraph font with the maximal size
font.setSize(maxsize);
-   maxasc  = max(maxasc,  fontmetrics.maxAscent());
-   maxdesc = max(maxdesc, fontmetrics.maxDescent());
+   FontMetrics const & maxfontmetrics = theFontMetrics 
(font);

+   maxasc  = max(maxasc,  maxfontmetrics.maxAscent());
+   }


I would add a comment saying that the fontmetrics variable is  
outdated once
you change 'font'. Otherwise there's the risk we hit this bug again  
and

again...


I make a copy now. So it should be clear. I think it's obvious that  
the fontmetric does not adapt if the font is changed. The update was  
just forgotten.


Stefan


PGP.sig
Description: Signierter Teil der Nachricht

Re: [patch] Huge fonts do not set the row height, #3787

[Alfredo Braunstein]

Stefan Schimanski wrote:

>> I would add a comment saying that the fontmetrics variable is
>> outdated once
>> you change 'font'. Otherwise there's the risk we hit this bug again
>> and
>> again...
> 
> I make a copy now. So it should be clear. I think it's obvious that

even better.

> the fontmetric does not adapt if the font is changed. The update was
> just forgotten.

Ok.

A/

Re: [PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters

[Bo Peng]

> If some parameter is
> acceptable by 1.5.2, but not 1.5.0, a user will be in trouble only
> when he use GUI to edit the inset. In this case, he can use this
> bypass button.

What happens if he doesn't? An error message?


Then the parameter will be used without problem because they are not
validated by 1.5.0.


> Because RC1 does not acceptable unrecognized parameters, RC1
> 1. ignore all global parameters (try/catch in bufferparam.cpp) if a
> global parameter is not recognized.
> 2. may crash or compile for normal insets (need to check code).

it will for sure.

> 3. GUI will not work for unrecognized parameter.

Therefore ...

> The only solution would be using ERT from 1.5.x => RC1.

Why are you so reluctant about this? Most of the code is there, so it's really
not to much work, and our reversion chain is significantly less corrupted
than it is anyway.


I think we only need to support official releases, but if you insist,
I will do something with lyx2lyx.

Have you tested the patch (without lyx2lyx)? Any opinion?

Cheers,
Bo

Re: [patch] bug 3835: inset-toggle doesn't work for branch insets

[Martin Vermeer]

On Sun, Jun 10, 2007 at 12:05:47PM +0200, Jürgen Spitzmüller wrote:
> Martin Vermeer wrote:
> > Did you try save/reload to see if only branch insets for
> > the selected branch(es) are open? (vague recollection)
> 
> Yes. This still works.

Great. Then I suspect I did unthinking cut'n paste from somewhere.

- Martin
 

Re: SV: [PATCH] Change default mathbg and add mathhoverbg.

[Jean-Marc Lasgouttes]

> "Edwin" == Leuven, E <[EMAIL PROTECTED]> writes:

Edwin> Jean-Marc Lasgouttes wrote:
>> It is completely different: dEPM disallows things that have _no_
>> meaning to LaTeX (like double space). And empty math inset is
>> acceptable, even if it is most of the times not wanted.

Edwin> sure, perhaps latex permits this but when would you want to
Edwin> create an empty math inset?

There are always people who have good reasons to do weird things.
Which should not artificially forbid constructs.

>> None of these solve the problem for an inset containing a hard
>> space, but those who ask for trouble deserve it.

Edwin> maybe we should disallow a space after a backslash in math?

Edwin> or are there situations where this makes sense?

"\ " is pretty useful in maths. It should definitely stay.

JMarc

Re: [patch] bug 3835: inset-toggle doesn't work for branch insets

[Jean-Marc Lasgouttes]

> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:

Jürgen> The attached patch fixes it for Bennett and me. Martin cannot
Jürgen> remeber why he put the removed test there in the first place,
Jürgen> but I didn't find any drawbacks.

Looks good.

JMarc

Re: [PATCH] Add bypass validation checkboxes to dialogs that enter listings parameters

[Bo Peng]

I think we only need to support official releases, but if you insist,
I will do something with lyx2lyx.


Attached please find an updated patch with lyx2lyx support for RC1.

OK to apply?

Cheers,
Bo
Index: src/insets/InsetListingsParams.h
===
--- src/insets/InsetListingsParams.h	(revision 18733)
+++ src/insets/InsetListingsParams.h	(working copy)
@@ -74,6 +74,9 @@
 
 	///
 	void clear() { params_.clear(); }
+	
+	/// validate parameter, return an error message
+	docstring validate() const;
 
 private:
 	/// inline or normal listings
@@ -87,22 +90,6 @@
 };
 
 
-class invalidParam : public std::exception {
-public:
-	invalidParam(docstring const & details)
-	: details_(to_utf8(details))
-	{}
-
-	virtual const char * what() const throw() {
-		return details_.c_str();
-	}
-
-	virtual ~invalidParam() throw() {}
-private:
-	std::string const details_;
-};
-
-
 } // namespace lyx
 
 #endif
Index: src/insets/InsetListingsParams.cpp
===
--- src/insets/InsetListingsParams.cpp	(revision 18733)
+++ src/insets/InsetListingsParams.cpp	(working copy)
@@ -271,15 +271,13 @@
 public:
 	ParValidator();
 
-	/// \return the associated \c ListingsParam.
-	/// \warning an \c invalidParamexception will be thrown
-	///  if the key is not found.
-	ListingsParam const & param(string const & key) const;
+	/// validate a parameter for a given name.
+	/// return an error message if \c par is an invalid parameter.
+	docstring validate(string const & name, string const & par) const;
 
-	/// validate a parameter for a given key.
-	/// \warning an \c invalidParam exception will be thrown if
-	/// \c par is an invalid parameter.
-	ListingsParam const & validate(string const & key, string const & par) const;
+	/// return the onoff status of a parameter \c key, if \c key is not found
+	/// return false
+	bool onoff(string const & key) const;
 
 private:
 	/// key is the name of the parameter
@@ -584,21 +582,11 @@
 }
 
 
-ListingsParam const & ParValidator::validate(string const & key,
+docstring ParValidator::validate(string const & name,
 		string const & par) const
 {
-	ListingsParam const & lparam = param(key);
-	docstring s = lparam.validate(par);
-	if (!s.empty())
-		throw invalidParam(bformat(_("Parameter %1$s: "), from_utf8(key)) + s);
-	return lparam;
-}
-
-
-ListingsParam const & ParValidator::param(string const & name) const
-{
 	if (name.empty())
-		throw invalidParam(_("Invalid (empty) listing parameter name."));
+		return _("Invalid (empty) listing parameter name.");
 
 	if (name[0] == '?') {
 		string suffix = trim(string(name, 1));
@@ -613,39 +601,59 @@
 			}
 		}
 		if (suffix.empty())
-			throw invalidParam(bformat(
-	_("Available listing parameters are %1$s"), from_ascii(param_names)));
+			return bformat(
+	_("Available listing parameters are %1$s"), from_ascii(param_names));
 		else
-			throw invalidParam(bformat(
+			return bformat(
 	_("Available listings parameters containing string \"%1$s\" are %2$s"), 
-		from_utf8(suffix), from_utf8(param_names)));
+		from_utf8(suffix), from_utf8(param_names));
 	}
  
 	// locate name in parameter table
 	ListingsParams::const_iterator it = all_params_.find(name);
-	if (it != all_params_.end())
-		return it->second;
-
-	// otherwise, produce a meaningful error message.
-	string matching_names;
-	ListingsParams::const_iterator end = all_params_.end();
-	for (it = all_params_.begin(); it != end; ++it) {
-		if (prefixIs(it->first, name)) {
-			if (!matching_names.empty())
-matching_names += ", ";
-			matching_names += it->first;
+	if (it != all_params_.end()) {
+		docstring msg = it->second.validate(par);
+		if (msg.empty())
+			return msg;
+		else
+			return bformat(_("Parameter %1$s: "), from_utf8(name)) + msg;
+	} else {
+		// otherwise, produce a meaningful error message.
+		string matching_names;
+		ListingsParams::const_iterator end = all_params_.end();
+		for (it = all_params_.begin(); it != end; ++it) {
+			if (prefixIs(it->first, name)) {
+if (!matching_names.empty())
+	matching_names += ", ";
+matching_names += it->first;
+			}
 		}
+		if (matching_names.empty())
+			return bformat(_("Unknown listing parameter name: %1$s"),
+from_utf8(name));
+		else
+			return bformat(_("Parameters starting with '%1$s': %2$s"),
+from_utf8(name), from_utf8(matching_names));
 	}
-	if (matching_names.empty())
-		throw invalidParam(bformat(_("Unknown listing parameter name: %1$s"),
-		from_utf8(name)));
+	return docstring();
+}
+
+
+bool ParValidator::onoff(string const & name) const
+{
+	// locate name in parameter table
+	ListingsParams::const_iterator it = all_params_.find(name);
+	if (it != all_params_.end())
+		return it->second.onoff_;
 	else
-		throw invalidParam(bformat(_("Parameters starting with '%1$s': %2$s"),
-		from_utf8(name), from_utf8(matching_names)));
+		return false;
 }
 

Re: SV: [PATCH] Change default mathbg and add mathhoverbg.

[Edwin Leuven]

Jean-Marc Lasgouttes wrote:

Edwin> sure, perhaps latex permits this but when would you want to
Edwin> create an empty math inset?

There are always people who have good reasons to do weird things.
Which should not artificially forbid constructs.


we wouldn't, there is ert

...

signing off on this thread now.

Re: [PATCH] get rid of Inset::background_color_

[Andre Poenitz]

On Fri, Jun 08, 2007 at 11:16:49AM +0200, Jean-Marc Lasgouttes wrote:
> 
> This rather straightforward patch gets rid of Inset::background_color_,
> which adds 4 bytes to Inset for no good reason.
> 
> If there is _really_ a need for setBackgroundColor, we could consider
> moving it to InsetText instead.
> 
> I note that a footnote/table inside a yellow note will not inherit the
> background. This is something that used to work in 1.3, but got killed
> in 1.4.
> 
> Andre', Jose', would that be OK?

Sure, fine with me.

Andre'

Re: [PATCH] Change default mathbg and add mathhoverbg.

[Andre Poenitz]

On Fri, Jun 08, 2007 at 04:51:33PM +0200, Leuven, E. wrote:
> Bo Peng wrote:
> >> what is the point of $ $ and $\ $ ?
> > 
> > A method to force extra spaces, and more likely, entered by accident
> > (and then it is impossible to remove them).
> 
> so the inset should be dissolved when these are entered...?

I don't tink it is worth adding special code for such a corner case
(especially when the resolution is disputable).

I never ever had the problem of having an emptyh math inset hanging
around, and even if I had it'd probably been there for good reason
(like "I entered it")

Andre'

Re: [PATCH] Change default mathbg and add mathhoverbg.

[Andre Poenitz]

On Fri, Jun 08, 2007 at 03:53:58PM +0100, José Matos wrote:
> On Friday 08 June 2007 15:51:33 Leuven, E. wrote:
> > so the inset should be dissolved when these are entered...?
> 
> It seems more intuitive, no?

And an ő on a line of its own doesn't make much sense either.
Not even in Hungary. So I propose to remove such lines as
soon as we see one.

Ok for 1.5.0, Jose'?

Andre'

Re: [patch] fixing segfault because of empty coord cache

[Andre Poenitz]

On Fri, Jun 08, 2007 at 05:03:55PM +0200, Stefan Schimanski wrote:
> Critical bugs don't get less critical by ignorance.
> 
> If anybody wants to know more:
> 
> 1) CommandInset (used e.g. for references in mathed) has two cells to  
> hold information about where it points to. But it only draws a  
> button, not the cells themselves. So accessing the cells' coordinates  
> in the cache during drawSelection segfaults.
> 2) This all happens only because, after creating the InsetMathRef  
> (derived from CommandInset) with \ref, the cursor is inside of it.  
> Hence, InsetMathNest will try to draw the selection inside the  
> InsetMathRef below the cells.
> 3) So, why is the cursor inside it? Because it is derived from  
> InsetMathNest and has >= 1 cells. The LFUN_SELF_INSERT handler of the  
> hull (in fact in InsetMathNest::doDispatch) takes this as a reason to  
> put the cursor inside. I guess that's not correct, because the cursor- 
> left behavior normally checks the isActive() method before entering  
> an inset. But here isActive() is not called.

Good analysis.
 
> So I propose the following patch (which fixes #3715). The first hunk  
> is trivial. But I am not sure about the consequences of the second. I  
> think it's the correct way to insert an inset, but maybe there are  
> other inset which depend on the old (wrong) behavior. Comments?

I can't tell you. It is conceptionally sound, however, so close to 1.5.0
it might be more prudent to use something like 

  ... && !atom->isMathRefInset()

and put a fat FIXME there to ask fopr investigation in quieter times.

The second part most definitely has a potential smell of brown
paperbags...

Andre'

Re: [PATCH] Change default mathbg and add mathhoverbg.

[Andre Poenitz]

On Fri, Jun 08, 2007 at 10:23:21AM -0500, Bo Peng wrote:
> >  The objection to this was because it implied to another data member to 
> >  the
> >inset. Is there a solution that does not imply this?
> 
> Only mathhull has this mouse_hover_ variable so it is less a problem
> than the inset background case. (at least mathchar does not have it).

Right, as a general rule putting _some_ stuff into math hull is fine.

[That's not an endorsement of mouse_hover_, but a general commemt.
mouse_hover_ could e.g. be a buffer view member pointing to the 'hovered
over' inset. It certainly is a 'view' thing, whereas data in
the insets are (at least theoretically *cough*) 'model' thingies.]

Andre'

Re: [PATCH] Change default mathbg and add mathhoverbg.

[Andre Poenitz]

On Fri, Jun 08, 2007 at 10:38:05AM -0500, Bo Peng wrote:
> > even if it's possible it doesn't mean it is advisable or even desirable
> 
> I toss M$ Word because, among other overly clever features, it changes
> i to I all the time. I would object, in general, any *automatic*
> changes to what I entered without my agreement.

I am completely on your side in this case.

Andre'

Re: SV: [PATCH] Change default mathbg and add mathhoverbg.

[Andre Poenitz]

On Fri, Jun 08, 2007 at 06:25:16PM +0200, Leuven, E. wrote:
> > I toss M$ Word because, among other overly clever features, it changes
> > i to I all the time.
>  
> (before we used the big nasty wolf to scare people, now it is the big nasty 
> M$)
>  
> > I would object, in general, any *automatic*
> > changes to what I entered without my agreement.
>  
> can u say D, can u say E, can u say P, can u say M
>  
> can u say DEPM?!

And DEPM is the feature that caused a lot of grieve so far (for
developers, not users in this case)

Andre'

Re: LyX document-build process

[John Pye]

Hi Andre,

Thanks for these comments. More follows:

Andre Poenitz wrote:
> On Tue, Jun 05, 2007 at 09:52:49PM +1000, John Pye wrote:
>   
>> Sorry for a bit of a delay on this one. I thought I would follow up with
>> some comments though.
>>
>> Firstly,
>>
>> Jean-Marc Lasgouttes wrote:

[...]

>   
>> The concept I had here was that one might be writing some software with
>> a tarball that contains both C code and supporting LyX documentation.
>> The documentation ultimately gets embedded into the application file in
>> the form of let's say a windows .CHM help file. Imagine that a developer
>> want to make some changes to a small part of the program and perhaps
>> some small change in the documentation. If the LyX build process were
>> somehow integrated with scons, then developer could just call 'scons'
>> and rebuild the necessary bits of the program code plus the missing bits
>> of the documentation. The dependency checker would have everything it
>> needed without launching the full-blown LyX application to build the
>> documentation. In this case, LyX would just do the job of perhaps
>> transforming .lyx to .tex; scons would do the job of compiling the .tex
>> file together with .png images together into a set of .html files and
>> then convert the .html files to .chm files...
>> 
>
> People have successfully used plain Makefile for this purpose.
>   

Although I am sure it can be made work (inefficiently), it just doesn't
seem like the architecture is right for this. More comment further below.

>   
>> At present, because lyx uses its own build system, the efficiencies of
>> the above approach are not possible.
>> 
>
> ?
>
> Which 'own' build system?
>   

LyX *does* contain a build system. The following features:

* LyX can work out what image files need to be converted (dependency
  tracking)
* LyX knows how to convert image files (build rules)
* The LyX GUI detects when an image file is changed and triggers an
  updated file conversion (source file modification tracking)
* LyX instantiates tex in order to create a PDF file (multiple steps
  to achieve required output file)
* LyX knows the order that things need to be built in (graph algorithms)
* LyX keeps a cache of converted image files and doesn't re-convert
  them all every time (output caching)
* Build rules and file types can be specified by the user
  (user-defined build rules)
* LyX contains certain hard-wired default rules (default build rules)

It may not be full-blown thing but I don't see any clear distinction
between where LyX functionality stops and where a 'full blown' build
system starts.

>   
>> I think that perhaps it does need a build system. My thesis takes a good
>> five minutes to build, and there is absolutely no indication of how far
>> through it is, or what it's doing at any given point in time.
>> 
>
> You know that it takes five minutes, and if it takes an average of two
> minutes to fill your coffee mug you'll know when 40% are done...
>   

More coffee will only heighten my paranoia! Seriously, LyX is a GUI
application but it makes no effort at being GUI-friendly during the
document build process. It wouldn't be that hard to add a 'progress'
dialog box for this stuff? Run a separate thread for the build tools and
update the screen as they go? Helps to know when images are too large or
too detailed, or if something is hung, etc?

[...]

>   
>> When I change things in 'sub-files' in my thesis (ie chapters) LyX
>> doesn't always correctly detect that something's changed, and it ends up
>> producing the same PDF file as before I made my changes. It seems that
>> there could be a missing link in the dependency tracking.
>> 
>
> Makefile.
>   

I think that this is a bug in LyX. LyX *must* be able to do this type of
dependency tracking 100% correctly if it is going to attempt it at all.
It is no good that it outputs the wrong document in this case.

[...]

>   
>> So you mentioned that the build process is trivial but I think that the
>> above examples show that it's perhaps not so trivial, and perhaps if a
>> full-scale build system were used it might allow the LyX development
>> effort to reduce the amount of 'support code' that needs to be
>> maintained, so that you can focus on some of the more core LyX
>> functionality?
>> 
>
> The point is that LyX is not a build system, cannot be, and does not
> want to be. If you need one (and you have shown good reasons for that)
> just use one. If you prefer Scons over make, so be it, but in both cases
> this is a solution _wrapping_ LyX, not a solution integrated in LyX.
>   

My basic problem here is that LyX is not really wrap-able, because of
the way that it fires off an indeterminate number of sub-processes to
convert images and other source material. It works quite differently
from the usual tools that are called from a build script such as CPP,
GCC, flex, bison, SWIG, etc.

As I argued above, LyX 

Crashing when pressing enter...

[Alexander Streit]

Hi Guys,

I'm using the 1.5RC1 release (released May 31). On the Mac (PowerPC
architecture) the table of contents pane simply doesn't show, so I'm
using my windows machine instead. But that is not why I am writing. I
am writing because I get a consistent crash when I try to press enter
to insert a new line in a paragraph. I've kept the file. I don't want
the file to be public (since it is a journal submission), but I'm
happy to send it whoever would be fixing/confirming the crash. it is
93kb.

Unfortunately the "more details" dialog doesn't give me much info at
all: simply "closing lyx socket" and "completed". There was one time
when it said more, with the following line embedded among other
harmless looking messages:
"NoRepeatedApplyReadOnlyPolicy: No transition for input SMI_OKAY from
state INVALID"

I don't know if it is related, because it does not seem to reappear.
The paragraph in question has a cross reference to a figure at the end
of it, otherwise it is a normal paragraph with nothing fancy at all
(no math or emphasize or anything).

Keep up the good work!

-alex

Re: Window-independent dialogs

[Angus Leeming]

Stefan Schimanski wrote:

Hi!

Is there a reason that the non-modal dialogs (like to edit tables, 
change text styles etc.) depend on the LyX window? You can open another 
one for every window which is open. It's somehow strange and confusing 
to have a text style dialog, but it "doesn't work" because it belongs to 
another window.


That's just the way they were designed. getDialogs belongs to the 
LyXView. When a dialog is created, it contains a pointer to this 
LyXView so that it can dispatch requests back to it. See 
src/frontends/controllers/Kernel.cpp:


33 void Kernel::dispatch(FuncRequest const & fr) const
34 {
35 lyxview_.dispatch(fr);
36 }

Angus

Re: [PATCH] Bug 3711, add insets without valid ParConstIterator to TOC.

[Angus Leeming]

Abdelrazak Younes wrote:

Bo Peng wrote:

Per the use of exception, I think exception should be used more often
in lyx.


LyX's code base is not exception safe. The code hasn't been written 
with exception safety in mind, largely because we weren't proficient 
in the use of exceptions. (I certainly include myself in that statement.)


For example, counters are not updated immediately after, say,

an caption is added to InsetInclude. It would be good to have
something like

try
   work on inset going on
except updateCounter (+1, or -1)
except updateScreen (partial or all)
except kill me please

Just some random thought.


IMHO exceptions should only be used in _exceptional_ situation because 
they bypass the normal function to function communication. I think the 
way you want to use them is going to slow down the code significantly. 
This is reason why I don't like for example the way exceptions are 
misused in the listings code.


Yes, unwinding the stack is very expensive.

Angus

Suggested improvements for LyX macros

[Mark Kortink]

Hi
 
Below are some suggestions for improving macros in LyX. As a user it has
taken many hours of going through the poor user documentation and various
LaTeX manuals and editors trying to figure out how to get them working and
then why they don't work, very frustrating! Hopefully these suggestions can
be incorporated into some release because I have given up on macros even
though I eventually got them working and they would be extremely useful if
they worked in such a way to make life easier, even working in a simple way
would be better..
 
1. In the user guide:
- do not use the name "macro" or "macrowarg" as the example macro names,
guaranteed to confuse.
- show all the steps in sequence and what it looks like on screen, don't
give examples of output without showing the input. Step 1, enter the
"math-macro mname n" in the minibuffer then step 2, type the LaTeX defs into
the blue boxes which defines the macros so it can be used then step 3, use
it over and over by going into math mode and typing \mname and entering the
argument values after the m: placeholders. You get the idea. 
- I found after much pain that you can't put #n, you have to escape it like
\#n, this is not documented and should not be the case anyhow, #n is the
standard. 
 
2. Fix the way they work and look on screen 
- When values have been supplied for the argument display the result
WYSIWYM. When the user clicks on the macro to edit its values revert back to
edit mode with the arguments lists 1:, 2:, etc as now.
 
3. The big one, allow \newcommand and \DeclareMathOperator to be defined in
the preamble, even if you have to follow some LyX conventions, they need to
be able to be imported from a file.
 
Regards
 
Mark Kortink
e: [EMAIL PROTECTED]
p: 0419-250-403
 

Re: LyX document-build process

[Angus Leeming]

John Pye wrote:

As I argued above, LyX contains *its own* build system: it defines tools
and file transformations, dependency tracking and caching. Because it
contains all of these things internally it makes using it within an
external build system much more difficult that it should be.

I think that good architecture going forward might be for LyX to divest
all of the build tracking stuff to an external program that specialises
in dependency tracking, caching, and parallel building, and to try to
re-use what others have already done in this area.

Thoughts?


LyX needs passionate people to drive forward its development. As 
you're clearly passionate about this, then you should consider 
contributing code to realize your vision.


Angus

Re: Suggested improvements for LyX macros

[Stefan Schimanski]

Please take a look at my new macro implementation:

http://www.youtube.com/watch?v=68Gys4rp3u4

Make it fullscreen while watching to see what's going on. Some points  
you give should be solved by that.


Stefan

Am 11.06.2007 um 06:36 schrieb Mark Kortink:


Hi

Below are some suggestions for improving macros in LyX. As a user  
it has
taken many hours of going through the poor user documentation and  
various
LaTeX manuals and editors trying to figure out how to get them  
working and
then why they don't work, very frustrating! Hopefully these  
suggestions can
be incorporated into some release because I have given up on macros  
even
though I eventually got them working and they would be extremely  
useful if
they worked in such a way to make life easier, even working in a  
simple way

would be better..

1. In the user guide:
- do not use the name "macro" or "macrowarg" as the example macro  
names,

guaranteed to confuse.
- show all the steps in sequence and what it looks like on screen,  
don't

give examples of output without showing the input. Step 1, enter the
"math-macro mname n" in the minibuffer then step 2, type the LaTeX  
defs into
the blue boxes which defines the macros so it can be used then step  
3, use
it over and over by going into math mode and typing \mname and  
entering the

argument values after the m: placeholders. You get the idea.
- I found after much pain that you can't put #n, you have to escape  
it like
\#n, this is not documented and should not be the case anyhow, #n  
is the

standard.

2. Fix the way they work and look on screen
- When values have been supplied for the argument display the result
WYSIWYM. When the user clicks on the macro to edit its values  
revert back to

edit mode with the arguments lists 1:, 2:, etc as now.

3. The big one, allow \newcommand and \DeclareMathOperator to be  
defined in
the preamble, even if you have to follow some LyX conventions, they  
need to

be able to be imported from a file.

Regards

Mark Kortink
e: [EMAIL PROTECTED]
p: 0419-250-403





PGP.sig
Description: Signierter Teil der Nachricht