Re: Should I add this to lstrings.[Ch]?

[Andre Poenitz]

On Wed, Sep 24, 2003 at 06:40:37PM +, Angus Leeming wrote:
   string output = subst(lowercase(input), $$rotatebegin,
   \\rotatebox[30]{);
 
 because I want to match the placeholder $$rotatebegin only and don't care 
 about it being upper or lower case.

We should switch to _not_ ignoring case in general. This is an
unnecessary kind of 'freedom' and only makes maintanance harder.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: Should I add this to lstrings.[Ch]?

[Andre Poenitz]

On Wed, Sep 24, 2003 at 07:20:52PM +, Angus Leeming wrote:
  My take is that you should do the whole thing with just a subst (no
  lowercase things at all.)
 
 Then this differs from other places where we use key words. The whole of 
 lyxlex for example is insensitive to the case of its keywords.

What's the advantage of that (other than historical reasons)?

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: Should I add this to lstrings.[Ch]?

[Jean-Marc Lasgouttes]

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

Lars Yes. And I really want to change that. IMHO our language
Lars should be case sensitive. I am not sure if Jean-Marc still
Lars agrees with this, but he did once upon a time.

I still agree with that. Let's keep things simple.

JMarc

lyx 1.3.2: xpm files

[Hartmut Haase]

Why can some xpm files like 
/usr/share/lyx/images/depth-increment.xpm or 
/usr/share/lyx/images/math/sqrt.xpm be seen in LyX AND xdvi/gv/acroread
and other like 
/usr/share/lyx/images/font-noun.xpm or
/usr/share/lyx/images/math/blacktriangle.xpm
ONLY in LyX?
-- 
Regards, Hartmut 

Hungerhilfe: http://www.thehungersite.com

ATTAC - für eine solidarische weltwirtschaft
gegen neoliberale globalisierung: http://www.attac.de

Mitmachen bei der GATS-Kampagne: http://www.attac.de/gats

Das heutige Motto:
Try to value useful qualities in one who loves you. 

Re: lyx 1.3.2: xpm files

[Angus Leeming]

Hartmut Haase wrote:

 Why can some xpm files like
 /usr/share/lyx/images/depth-increment.xpm or
 /usr/share/lyx/images/math/sqrt.xpm be seen in LyX AND xdvi/gv/acroread
 and other like
 /usr/share/lyx/images/font-noun.xpm or
 /usr/share/lyx/images/math/blacktriangle.xpm
 ONLY in LyX?

Because there are different flavours of XPM and different apps support 
different subsets of them.

The problems all stem from the definition of the colour table. You say that 
everything can read images/depth-increment.xpm? Let's have a look:
* XPM */
static char * depth_increment_xpm[] = {
20 20 5 1,
   c None,
.  c #00,
+  c #FF,
@  c #00,
#  c #BC,

Conclusion 1: everything understands None.
Conclusion 2: everything understands hexadecimal colour specs of the form 
'#rrggbb'.

You say that other apps have a problem with images/font-noun.xpm:
/* XPM */
static char const * noun_xpm[] = {
20 20 2 1,
   c None,
.  c #,

Conclusion 3: some apps don't understand '#'.

You say that other apps have a problem with images/math/blacktriangle.xpm:
/* XPM */
static char *a[] = {
/* columns rows colors chars-per-pixel */
17 17 3 1,
  c black,
. c black,
X c None,

Conclusion 4: some apps don't use the (standard X11) database file rgb.txt 
to translate string representations such as 'black' to the equivalent 
'#rrggbb' (here #ff').

Regards,

-- 
Angus

Re: boostifying DebugStream

[Angus Leeming]

Lars Gullik Bjønnes wrote:
Grrr. We just had a mini powercut that hosed the message I was writing.
Try 2.

Dunno, why, but all your attachements are unnamed, so it's hard to refer to 
them. Also, they all come with mome-type application/octet-stream. Why not 
some text format? Anyway...

File containing basic_debugstream: vety nice. I even understand it. One 
point: the comment does not match reality.
/// Constructor, sets the debug level to t.
explicit basic_debugstream(std::basic_streambufcharT, traits * buf)
: std::basic_ostreamcharT, traits(buf), dt(debug::NONE)
{}

File containing lyx_debug_trait: presumably the header should have
 * \file DebugStream.h

Maybe you could use support/translator.h to simplify switching between the 
string and enum representations of the debug level?

File containing basic_teebuf: nice idea. Why do you call the two streams 
'master' and 'slave'? There is no slvery going on here. Why restrict 
yourself to two streambufs? Why not have a std::listbase_type *?

-- 
Angus

Re: boostifying DebugStream

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| Lars Gullik Bjønnes wrote:
| Grrr. We just had a mini powercut that hosed the message I was writing.
| Try 2.

| Dunno, why, but all your attachements are unnamed, so it's hard to refer to 
| them. Also, they all come with mome-type application/octet-stream. Why not 
| some text format? Anyway...

Should be named by the attached file?
(octed-stream: probably the 'ø' in my name)

| File containing basic_debugstream: vety nice. I even understand it. One 
| point: the comment does not match reality.
| /// Constructor, sets the debug level to t.
| explicit basic_debugstream(std::basic_streambufcharT, traits * buf)
| : std::basic_ostreamcharT, traits(buf), dt(debug::NONE)
| {}

Yes, the comment is outdated, and does not reflect reality.

| File containing lyx_debug_trait: presumably the header should have
|  * \file DebugStream.h

| Maybe you could use support/translator.h to simplify switching between the 
| string and enum representations of the debug level?

Will that be easier? That would also mean that I would have to set up
the translation table manually (and dynamically) instead of statically
as we do now.


| File containing basic_teebuf: nice idea. Why do you call the two streams 
| 'master' and 'slave'? There is no slvery going on here. Why restrict 
| yourself to two streambufs? Why not have a std::listbase_type *?

The teebuf has been there forever :-)
Just unused.

Why master/slave? Well only master is listened to when it comes to
error conditions and return values. The slave just tags along.

I don't want the teebuf to _ever_ handle more than two streambufs, so
no need for a list. If you want more than two, you should chain
teebuf's or create your own multibuf.

-- 
Lgb

Re: boostifying DebugStream

[Angus Leeming]

Lars Gullik Bjønnes wrote:
 The teebuf has been there forever :-)
 Just unused.
 
 Why master/slave? Well only master is listened to when it comes to
 error conditions and return values. The slave just tags along.
 
 I don't want the teebuf to _ever_ handle more than two streambufs, so
 no need for a list. If you want more than two, you should chain
 teebuf's or create your own multibuf.

I don't. Nonetheless, I think you should forget your intended usage for a 
moment and look at the class with fresh eyes. There is nothing in it that 
indicates that master_ has greater priveleges than slave_.

Why not rename them as 
base_type * buf[2];
At least that indicates to others that they are simply two otherwise 
identical buffers.

Passing/storing raw pointers isn't very nice...

Incidentally, are the typedefs needed? As they come from the base class, 
don't you get them for free?

-- 
Angus

Re: boostifying DebugStream

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| Lars Gullik Bjønnes wrote:
 The teebuf has been there forever :-)
 Just unused.
 
 Why master/slave? Well only master is listened to when it comes to
 error conditions and return values. The slave just tags along.
 
 I don't want the teebuf to _ever_ handle more than two streambufs, so
 no need for a list. If you want more than two, you should chain
 teebuf's or create your own multibuf.

| I don't. Nonetheless, I think you should forget your intended usage for a 
| moment and look at the class with fresh eyes. There is nothing in it that 
| indicates that master_ has greater priveleges than slave_.

| Why not rename them as 
| base_type * buf[2];
| At least that indicates to others that they are simply two otherwise 
| identical buffers.

but they are not of equal importance.
(even if I'd like them to be...)
Perhaps master and slave is the wrong names, but they should be
differently named. (primary,secondary?) 
And probably handle all failure conditions teebuf is way to
simplistic.

| Passing/storing raw pointers isn't very nice...

I have no other solution.

| Incidentally, are the typedefs needed? As they come from the base class, 
| don't you get them for free?

No. Then I need to sprinkle typename all over. The typdefs helps
avoid that.

-- 
Lgb

Re: boostifying DebugStream

[Angus Leeming]

Lars Gullik Bjønnes wrote:

 but they are not of equal importance.
 (even if I'd like them to be...)
 Perhaps master and slave is the wrong names, but they should be
 differently named. (primary,secondary?)

primary, secondary is better.

But I still don't get it.

std::ofstream ofs2(/tmp/dump2.dbg);
teebuf tb(ofs2.rdbuf(), std::cerr.rdbuf());
lyxdebugstream dbg(tb);
dbg  Let's roll  endl;

This sends output to the file and to stderr. There is no concept of 
importance here at all.

 And probably handle all failure conditions teebuf is way to
 simplistic.

I can't grep this. Could you explain further?

-- 
Angus

Re: boostifying DebugStream

[Lars Gullik Bjønnes]

Angus Leeming [EMAIL PROTECTED] writes:

| Lars Gullik Bjønnes wrote:

 but they are not of equal importance.
 (even if I'd like them to be...)
 Perhaps master and slave is the wrong names, but they should be
 differently named. (primary,secondary?)

| primary, secondary is better.

| But I still don't get it.

| std::ofstream ofs2(/tmp/dump2.dbg);
| teebuf tb(ofs2.rdbuf(), std::cerr.rdbuf());
| lyxdebugstream dbg(tb);
| dbg  Let's roll  endl;

| This sends output to the file and to stderr. There is no concept of 
| importance here at all.

if you look at the implementation there is. In this case it is hte
ofs2's return values that are used for error handling (and discovery).

 And probably handle all failure conditions teebuf is way to
 simplistic.

| I can't grep this. Could you explain further?

Teebuf is probably to simplistic to handle all failure conditions a
proper streambuf should handle.

-- 
Lgb

Re: boostifying DebugStream

[Angus Leeming]

Lars Gullik Bjønnes wrote:
 | This sends output to the file and to stderr. There is no concept of
 | importance here at all.
 
 if you look at the implementation there is. In this case it is hte
 ofs2's return values that are used for error handling (and discovery).

Got it! Thank you. I'd missed those all-important return values. A comment 
about this wouldn't go amiss. Perhaps:

/** \c basic_teebuf is a streambuf that sends the output to 
two different streambufs. There is no restriction on their type.
The return values from the 'master' streambuf are passed as
\c basic_teebuf's return values.
*/

primary and secondary is still better...


 And probably handle all failure conditions teebuf is way to
 simplistic.

 | I can't grep this. Could you explain further?
 
 Teebuf is probably to simplistic to handle all failure conditions a
 proper streambuf should handle.

Thank you.

-- 
Angus

LyX one dot three dot three

[Jean-Marc Lasgouttes]

I have tagged LyX 1.3.3 and uploaded the various bits to ftp.lyx.org.
I will make the actual announcement tomorrow (unless something ugly
surfaces).

JMarc

support::regexMatch

[Angus Leeming]

This started off as a simple question about this code in 
support/lstrings.[Ch]:

/** Compares a string and a (simple) regular expression
 *  The only element allowed is * for any string of characters
 */
bool regexMatch(string const  a, string const  pattern);

bool regexMatch(string const  a, string const  pattern)
{
// We massage the pattern a bit so that the usual
// shell pattern we all are used to will work.
// One nice thing about using a real regex is that
// things like *.*[^~] will work also.
// build the regex string.
string regex(pattern);
regex = subst(regex, ., \\.);
regex = subst(regex, *, .*);
boost::regex reg(regex);
return boost::regex_match(a, reg);
}

It looks to me like the comment in lstrings.h is no longer true.
However, before I change it, could someone explain the 'massaging' to me?

It seems to me that this is a perfectly fine regex
string const my_regex file  *myfile\\.C;
which gets changed by regexMatch to
file  .*myfile.C

Why does it do that? Surely that does not conform to the principle of least 
surprise.
---

So, I went looking for the places regexMatch is used. It is used in two 
places only, so my question has changed to

Shall I just remove the function and use boost::regex in its place?

---
xforms/FormFileDialog.C which uses it to search for stuff like
*.(gif|png|jpg|bmp|pbm|ppm|tga|tif|xpm|xbm)
In this case, regexMatch is doing exactly what FormFileDialog.C wants, but 
I think that performing the massaging should actually be 
FormFileDialog.C's job.

---
The only place it is used is filetools.C (ReplaceEnvironmentPath) and here 
the shit really hits the fan.

// Search ${...} as Variable-Name inside the string
// and replace it with the denoted environmentvariable
string copy1(result0); // contains String after $
string const RegExp(*}*); // Exist EndChar inside a String?
if (!regexMatch(copy1, RegExp)) {

Apart from the fact that this regex as designed ALWAYS matches, regexMatch 
changes it to .*}.* which actually makes it work as I suspect the author 
of ReplaceEnvironmentPath intended ;-)

Nonetheless, if you're searching for '}', why not search for '}'? Why use a 
regex at all?

IMO, what should actually be searched for _is_ a regex, but it is this:
string const RegExp = ${[^}]*};
Doing so would allow you to actually extract the string you were actually 
interested in.

In fact, the whole function is a pile of crap and could be replaced by

#includeiostream
#includestring
#include boost/regex.hpp

using std::string;

string const my_getenv(string const  data)
{
if (data == HOME)
return /home/angus;
if (data == AWAY)
return foreign;
return string();
}


string const ReplaceEnvironmentPath(string const  path)
{
boost::regex const re((.*)[$]\\{([^}]*)\\}(.*));
boost::smatch what;

string result = path;
while (1) {
regex_match(result, what, re, boost::match_partial);
if (!what[0].matched)
break;
result = what.str(1) + my_getenv(what.str(2)) + what.str(3);
}
return result;
}



int main()
{
string const input = /foo/bar/${HOME}/emma/${HOME}/${AWAY};
string const output = ReplaceEnvironmentPath(input);

std::cout  Input:   input  std::endl;
std::cout  Output:   output  std::endl;

return 0;
}

-- 
Angus

Re: support::regexMatch

[Jean-Marc Lasgouttes]

 Angus == Angus Leeming [EMAIL PROTECTED] writes:

Angus The only place it is used is filetools.C
Angus (ReplaceEnvironmentPath) and here the shit really hits the fan.

This function is completely broken, and actually kills LyX when you
try to use it (we are lucky that nobody uses it, but it would be
useful to have it more visible). So please replace it with whatever
makes sense.

JMarc

Re: lyx 1.3.2: xpm files

[Jean-Marc Lasgouttes]

 Angus == Angus Leeming [EMAIL PROTECTED] writes:

Angus Hartmut Haase wrote:
 Why can some xpm files like
 /usr/share/lyx/images/depth-increment.xpm or
 /usr/share/lyx/images/math/sqrt.xpm be seen in LyX AND
 xdvi/gv/acroread and other like /usr/share/lyx/images/font-noun.xpm
 or /usr/share/lyx/images/math/blacktriangle.xpm ONLY in LyX?

Angus Because there are different flavours of XPM and different apps
Angus support different subsets of them.

Angus The problems all stem from the definition of the colour table.
Angus You say that everything can read images/depth-increment.xpm?

[...]

In this case, 'everything' is probably convert and this occurs
because Hartmut uses the xpm icons in his german translation of the
docs.

It would be nice to change our xpms so that this works consistently. I
am not sure though what is the best tool to do that...

JMarc

Re: support::regexMatch

[Angus Leeming]

Jean-Marc Lasgouttes wrote:

 Angus == Angus Leeming [EMAIL PROTECTED] writes:
 
 Angus The only place it is used is filetools.C
 Angus (ReplaceEnvironmentPath) and here the shit really hits the fan.
 
 This function is completely broken, and actually kills LyX when you
 try to use it (we are lucky that nobody uses it, but it would be
 useful to have it more visible). So please replace it with whatever
 makes sense.

The comment defines this as a valid variable:
variable :=  '$' '{' [A-Za-z_]{[A-Za-z_0-9]*} '}'

I think that the internal curly brackets are just there to 'help' make it 
readable, right? (Can't have '{' in an environment variable.)

That being the case, this works, but isn't strict enough, allowing 'nested' 
stuff like this hypothetical example:

$ x=M
$ echo ${HO${x}E}
/home/angus

The real shell won't allow this.

IS THIS A PROBLEM, or should I just commit it?
Angus

string const ReplaceEnvironmentPath(string const  path)
{
boost::regex const re((.*)[$]\\{([A-Za-z_][A-Za-z_0-9]*)\\}(.*));
boost::smatch what;

string result = path;
while (1) {
regex_match(result, what, re, boost::match_partial);
if (!what[0].matched)
break;
result = what.str(1) + my_getenv(what.str(2)) + what.str(3);
}
return result;
}

Re: lyx 1.3.2: xpm files

[Angus Leeming]

Jean-Marc Lasgouttes wrote:
 It would be nice to change our xpms so that this works consistently. I
 am not sure though what is the best tool to do that...

A shell script... (probably)
sed -n 's/^\( *[]*c *#\)\([0-9]\{4\}\)\([0-9]\{4\}\)\([0-9]\{4\}\) * *, *$/\1 \2 
\3 \4/p' images/font-noun.xpm

   c #   

So, I can extract the three colours, but how do I left shift em?

Ahhh. I could take each \([0-9]\{4\}\) block and split it into two:
\([0-9]\{2\}\)\([0-9]\{2\}\)
outputting only the first match.

Will that do?

-- 

Re: lyx 1.3.2: xpm files

[Andre Poenitz]

On Thu, Sep 25, 2003 at 04:52:14PM +, Angus Leeming wrote:
 Ahhh. I could take each \([0-9]\{4\}\) block and split it into two:
   \([0-9]\{2\}\)\([0-9]\{2\}\)

\([0-9][0-9]\)

is simpler to understand for the casual reader and not longer.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: lyx 1.3.2: xpm files

[Angus Leeming]

On Thursday 25 September 2003 3:56 pm, Andre Poenitz wrote:
 On Thu, Sep 25, 2003 at 04:52:14PM +, Angus Leeming wrote:
  Ahhh. I could take each \([0-9]\{4\}\) block and split it into two:
  \([0-9]\{2\}\)\([0-9]\{2\}\)

   \([0-9][0-9]\)

 is simpler to understand for the casual reader and not longer.

Ok. But is the idea valid? 1234 - 12 
A

Re: lyx 1.3.2: xpm files

[Andre Poenitz]

On Thu, Sep 25, 2003 at 05:05:07PM +, Angus Leeming wrote:
 On Thursday 25 September 2003 3:56 pm, Andre Poenitz wrote:
  On Thu, Sep 25, 2003 at 04:52:14PM +, Angus Leeming wrote:
   Ahhh. I could take each \([0-9]\{4\}\) block and split it into two:
 \([0-9]\{2\}\)\([0-9]\{2\}\)
 
  \([0-9][0-9]\)
 
  is simpler to understand for the casual reader and not longer.
 
 Ok. But is the idea valid? 1234 - 12 

Why not?

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: support::regexMatch

[Stephan Witt]

Angus Leeming wrote:
Jean-Marc Lasgouttes wrote:


Angus == Angus Leeming [EMAIL PROTECTED] writes:

[snip]

That being the case, this works, but isn't strict enough, allowing 'nested' 
stuff like this hypothetical example:

$ x=M
$ echo ${HO${x}E}
/home/angus
The real shell won't allow this.
Just for curiosity: make will do it!

% cat Makefile
x=M
home=${HO${x}E}
all:
echo ${home}
% make
echo /home/witt
/home/witt
Regards,

Stephan

Re: lyx 1.3.2: xpm files

[Angus Leeming]

Andre Poenitz wrote:
 Ok. But is the idea valid? 1234 - 12
 Why not?

Done that.

Next question: given an rbg.txt database
240 240 240 grey94
242 242 242 gray95

how do I create the appropriate #rrggbb entry from the shell?

-- 
Angus

Re: lyx 1.3.2: xpm files

[Angus Leeming]

Angus Leeming wrote:
 Next question: given an rbg.txt database
 240 240 240 grey94
 242 242 242 gray95
 
 how do I create the appropriate #rrggbb entry from the shell?

Doh!
$ printf '%x\n' 240
f0
$
-- 
Angus

Re: lyx 1.3.2: xpm files

[Angus Leeming]

Jean-Marc Lasgouttes wrote:
 It would be nice to change our xpms so that this works consistently. I
 am not sure though what is the best tool to do that...

A bit slow (about an hour ;-) but looks successful. 472 files changed in 
the 1.4 tree.

-- 
Angus

xpm_cleanup.sh
Description: application/shellscript

Rewrite of ReplaceEnvironmentPath

[Angus Leeming]

I've rewritten ReplaceEnvironmentPath in a sane manner and got rid of 
lstrings.[Ch] regexMatch because nothing was using it.

I've tested this by inserting a LyX file into the buffer (calling 
BufferView_pimpl.C's MenuInsertLyXFile which in turn calls 
support::FileSearch which in turn calls ReplaceEnvironmentPath).

Attempting to add '${HOME}/docs/some_file.lyx' when running lyx from 
somewhere other than ${HOME} works fine.

I have committed this. Please report any failures.

-- 
Angus? build
? external_bits.diff
? insetexternal.diff
? patches
? regex.diff
? stats
? stats_16Sep
? xpm.diff
? xpm_cleanup.sh
? lib/reLyX-safe
? src/lfun.sed
? src/lfuns2.h
? src/frontends/controllers/TODO
? src/frontends/xforms/1.4-XFormsView.C
? src/frontends/xforms/1.4-XWorkArea.C
? src/frontends/xforms/1.4-XWorkArea.h
? src/frontends/xforms/1.4-bmtable.c
? src/frontends/xforms/1.4-bmtable.h
? src/frontends/xforms/analyse
? src/insets/ChangeLog-safe
? src/insets/ExternalTransforms.C
? src/insets/ExternalTransforms.h
? src/support/lyxlib-orig.C
? src/support/lyxlib.C
Index: lib/external_templates
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/external_templates,v
retrieving revision 1.19
diff -u -p -r1.19 external_templates
--- lib/external_templates	25 Sep 2003 10:49:12 -	1.19
+++ lib/external_templates	25 Sep 2003 22:59:04 -
@@ -52,8 +52,17 @@ Template RasterImage
 	FileFilter *.(gif|png|jpg|bmp|pbm|ppm|tga|tif|xpm|xbm)
 	EditCommand gimp $$FName
 	AutomaticProduction true
+	Transform Rotate
+	Transform Resize
+	Transform Clip
+	Transform Extra
 	Format LaTeX
-		Product \\includegraphics{$$Basename}
+		TransformString Rotate RotationLatexOption
+		TransformString Resize ResizeLatexOption
+		TransformString Clip ClipLatexOption
+		TransformString Extra ExtraLatexOption
+		Option Arg [$$Extra,$$Rotate,$$Resize,$$Clip]
+		Product \\includegraphics$$Arg{$$Basename}
 		UpdateFormat eps
 		UpdateResult $$Basename.eps
 		Requirement graphicx
@@ -90,8 +99,12 @@ Template XFig
 	FileFilter *.fig
 	EditCommand xfig $$FName
 	AutomaticProduction true
+	Transform Rotate
+	Transform Resize
 	Format LaTeX
-		Product \\inputOrWarn{$$Basename.pstex_t}
+		TransformCommand Rotate RotationLatexCommand
+		TransformCommand Resize ResizeLatexCommand
+		Product $$RotateBegin$$ResizeBegin\\input{$$Basename.pstex_t}$$ResizeEnd$$RotateEnd
 		UpdateFormat pstex
 		UpdateResult $$Basename.pstex_t
 		Requirement graphicx
Index: src/frontends/xforms/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/ChangeLog,v
retrieving revision 1.831
diff -u -p -r1.831 ChangeLog
--- src/frontends/xforms/ChangeLog	25 Sep 2003 10:49:12 -	1.831
+++ src/frontends/xforms/ChangeLog	25 Sep 2003 22:59:14 -
@@ -1,5 +1,10 @@
 2003-09-25  Angus Leeming  [EMAIL PROTECTED]
 
+	* FormFiledialog.C (regexMatch): moved here from lstrings.[Ch] because
+	this is the only place using this 'massaged' regex.
+
+2003-09-25  Angus Leeming  [EMAIL PROTECTED]
+
 	* FormExternal.C (update, apply): InsetExternal::Params::
 	templatename now has accessor functions.
 
Index: src/frontends/xforms/FormFiledialog.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormFiledialog.C,v
retrieving revision 1.47
diff -u -p -r1.47 FormFiledialog.C
--- src/frontends/xforms/FormFiledialog.C	9 Sep 2003 22:13:40 -	1.47
+++ src/frontends/xforms/FormFiledialog.C	25 Sep 2003 22:59:15 -
@@ -28,6 +28,7 @@
 #include lyx_forms.h
 
 #include boost/bind.hpp
+#include boost/regex.hpp
 
 #include algorithm
 #include map
@@ -62,8 +63,8 @@ using lyx::support::GetEnvPath;
 using lyx::support::LyXReadLink;
 using lyx::support::MakeAbsPath;
 using lyx::support::OnlyFilename;
-using lyx::support::regexMatch;
 using lyx::support::split;
+using lyx::support::subst;
 using lyx::support::suffixIs;
 using lyx::support::trim;
 
@@ -195,6 +196,25 @@ FD_filedialog * FileDialog::Private::fil
 FileDialog::Private * FileDialog::Private::current_dlg_ = 0;
 int FileDialog::Private::minw_ = 0;
 int FileDialog::Private::minh_ = 0;
+
+
+namespace {
+
+bool regexMatch(string const  a, string const  pattern)
+{
+	// We massage the pattern a bit so that the usual
+	// shell pattern we all are used to will work.
+	// One nice thing about using a real regex is that
+	// things like *.*[^~] will work also.
+	// build the regex string.
+	string regex = subst(pattern, ., \\.);
+	regex = subst(regex, *, .*);
+
+	boost::regex reg(regex);
+	return boost::regex_match(a, reg);
+}
+
+} // namespace anon
 
 
 // Reread: updates dialog list to match class directory
Index: src/insets/ExternalTemplate.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ExternalTemplate.C,v
retrieving revision 1.29
diff -u -p -r1.29 

Re: Rewrite of ReplaceEnvironmentPath

[Angus Leeming]

Angus Leeming wrote:
 I have committed this. Please report any failures.

(Don't worry, I didn't commit lib/external_templates which somehow made its 
way into the diff.)

-- 
Angus

Re: LyX one dot three dot three

[John Levon]

On Thu, Sep 25, 2003 at 04:48:29PM +0200, Jean-Marc Lasgouttes wrote:

 I have tagged LyX 1.3.3 and uploaded the various bits to ftp.lyx.org.

RH8.0 RPMs in incoming/

They depend on latex-xft-fonts, naturally.

regards
john
-- 
Khendon's Law:
If the same point is made twice by the same person, the thread is over.

table desing flaws in lyx / possible improvements (was: longtable caption again)

[j.heidemeier]

H. Voss schrieb:
 j.heidemeier schrieb:
 
 At the moment longtables really suck :-(. 

yesss ... :-)
 
Write the whole longtable in pure LaTeX code into a single
file (not as LyX file, only text).
Then you can use in an esay way a caption. In Lyx do a
Insert-file
Well, that is only a short term solution. Meanwhile I think, the real problem 
is, that the current table handling in lyx is so difficult because it does 
not follow the LyX principle:
 * Make standard tasks as easy as possible and  discourage bad habits from 
Office programs.
So I'd like to give a brief sketch of my ideas and I hope it could start an 
improvement process for tables in lyx.
1. The idea in Lyx is to take a strictly document centric view and delegate 
the typesetting to LaTeX - which normally can handle it much better. To this 
extent the author is forced to consequently use different paragraph formats 
and to abandon the visual markup habits of Office-users. 

2. So the abstraction view of LyX authors is structure related. It contains 
chapters, paragraphs, images ...   tables - and neither the typewriter 
view of Office users nor the abstract boxes of TeX's typesetting. The latter 
translation has to be made by LyX under the hood, whereas in LaTeX this 
translation lies in the LaTeX code, which requires a much higher knowlege of 
possible users compared to lyx - at least for standard cases. 

3. LaTeX has the ability to use standard layout formats also in tables: it is 
the \newcolumtype mechanism in array.sty and allows to override the standard 
column definition with another format with mulitcolumn. If a few table 
formats (e.g. decimal aligned col., multirow cells and normal texts) were 
predefined and could be assigned via the user interface, this would be 
similar to the way the rest of LyX works. Currently LyX allows this approach 
with the special (sic!) attribute but does not enforce it. The current 
table formatting is more at the typesetting level of Office-Programms.

3. The main exposure of the Floats is misleading from the authors perspective. 
Floats are TeX's typesetting perspective. For the author tabular and 
longtable are similar - not floating figures or floating tables. The ability 
to float in the final layout should be handled as a feature of the respective 
document entity - the correct LaTeX syntax has to be assured by the LyX2LaTeX 
backend.

5- The typography of tables is nicely described in
  ftp://ftp.dante.de/tex-archive/info/german/tabsatz/tabsatz.ps
So a good lyx table should be able to handle straightforward at least the 
simple cases in that document. 
 
4. Now I'll try a rough lyx-table description from an authors perspective:
A lyx-table consists of:
a) 0 or 1 caption
b) a list of table entry which might be identical to a)
c) a continuation caption for longtables which might be identical to a)
d) 0 or 1 topruler
e) one or several headerrows, which may be repeated in longtables
f) 0 or 1 midruler
g) the actual table contens
h) 0 or 1 bottomruler.
Vertical lignes should be possible but deprecated.
The whole table shuld be wrapped in a container tag, giving the type of the 
table, i.e. standard, longtable or floating table . The lack of such a 
container tag is the source of the caption/longtable problem.

Well, enough for now.
Yous  
-- 
Dr. Joachim Heidemeier  Tel. +49-30-8903-2780 
Fachgebiet II 3.2   [EMAIL PROTECTED] 
Umweltbundesamt, Bismarckplatz 1 D-14191 Berlin

Re: Should I add this to lstrings.[Ch]?

[Andre Poenitz]

On Wed, Sep 24, 2003 at 06:40:37PM +, Angus Leeming wrote:
> >  string output = subst(lowercase(input), "$$rotatebegin",
> >  "\\rotatebox[30]{");
> 
> because I want to match the placeholder "$$rotatebegin" only and don't care 
> about it being upper or lower case.

We should switch to _not_ ignoring case in general. This is an
unnecessary kind of 'freedom' and only makes maintanance harder.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: Should I add this to lstrings.[Ch]?

[Andre Poenitz]

On Wed, Sep 24, 2003 at 07:20:52PM +, Angus Leeming wrote:
> > My take is that you should do the whole thing with just a subst (no
> > lowercase things at all.)
> 
> Then this differs from other places where we use key words. The whole of 
> lyxlex for example is insensitive to the case of its keywords.

What's the advantage of that (other than historical reasons)?

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: Should I add this to lstrings.[Ch]?

[Jean-Marc Lasgouttes]

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

Lars> Yes. And I really want to change that. IMHO our "language"
Lars> should be case sensitive. I am not sure if Jean-Marc still
Lars> agrees with this, but he did once upon a time.

I still agree with that. Let's keep things simple.

JMarc

lyx 1.3.2: xpm files

[Hartmut Haase]

Why can some xpm files like 
/usr/share/lyx/images/depth-increment.xpm or 
/usr/share/lyx/images/math/sqrt.xpm be seen in LyX AND xdvi/gv/acroread
and other like 
/usr/share/lyx/images/font-noun.xpm or
/usr/share/lyx/images/math/blacktriangle.xpm
ONLY in LyX?
-- 
Regards, Hartmut 

Hungerhilfe: http://www.thehungersite.com

ATTAC - für eine solidarische weltwirtschaft
gegen neoliberale globalisierung: http://www.attac.de

Mitmachen bei der GATS-Kampagne: http://www.attac.de/gats

Das heutige Motto:
Try to value useful qualities in one who loves you. 

Re: lyx 1.3.2: xpm files

[Angus Leeming]

Hartmut Haase wrote:

> Why can some xpm files like
> /usr/share/lyx/images/depth-increment.xpm or
> /usr/share/lyx/images/math/sqrt.xpm be seen in LyX AND xdvi/gv/acroread
> and other like
> /usr/share/lyx/images/font-noun.xpm or
> /usr/share/lyx/images/math/blacktriangle.xpm
> ONLY in LyX?

Because there are different flavours of XPM and different apps support 
different subsets of them.

The problems all stem from the definition of the colour table. You say that 
everything can read images/depth-increment.xpm? Let's have a look:
* XPM */
static char * depth_increment_xpm[] = {
"20 20 5 1",
"   c None",
".  c #00",
"+  c #FF",
"@  c #00",
"#  c #BC",

Conclusion 1: everything understands "None".
Conclusion 2: everything understands hexadecimal colour specs of the form 
'#rrggbb'.

You say that other apps have a problem with images/font-noun.xpm:
/* XPM */
static char const * noun_xpm[] = {
"20 20 2 1",
"   c None",
".  c #",

Conclusion 3: some apps don't understand '#'.

You say that other apps have a problem with images/math/blacktriangle.xpm:
/* XPM */
static char *a[] = {
/* columns rows colors chars-per-pixel */
"17 17 3 1",
"  c black",
". c black",
"X c None",

Conclusion 4: some apps don't use the (standard X11) database file rgb.txt 
to translate string representations such as 'black' to the equivalent 
'#rrggbb' (here #ff').

Regards,

-- 
Angus

Re: boostifying DebugStream

[Angus Leeming]

Lars Gullik Bjønnes wrote:
Grrr. We just had a mini powercut that hosed the message I was writing.
Try 2.

Dunno, why, but all your attachements are unnamed, so it's hard to refer to 
them. Also, they all come with mome-type application/octet-stream. Why not 
some text format? Anyway...

File containing basic_debugstream: vety nice. I even understand it. One 
point: the comment does not match reality.
/// Constructor, sets the debug level to t.
explicit basic_debugstream(std::basic_streambuf * buf)
: std::basic_ostream(buf), dt(debug::NONE)
{}

File containing lyx_debug_trait: presumably the header should have
 * \file DebugStream.h

Maybe you could use support/translator.h to simplify switching between the 
string and enum representations of the debug level?

File containing basic_teebuf: nice idea. Why do you call the two streams 
'master' and 'slave'? There is no slvery going on here. Why restrict 
yourself to two streambufs? Why not have a std::list?

-- 
Angus

Re: boostifying DebugStream

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Lars Gullik Bjønnes wrote:
| Grrr. We just had a mini powercut that hosed the message I was writing.
| Try 2.
>
| Dunno, why, but all your attachements are unnamed, so it's hard to refer to 
| them. Also, they all come with mome-type application/octet-stream. Why not 
| some text format? Anyway...

Should be named by the attached file?
(octed-stream: probably the 'ø' in my name)

| File containing basic_debugstream: vety nice. I even understand it. One 
| point: the comment does not match reality.
| /// Constructor, sets the debug level to t.
| explicit basic_debugstream(std::basic_streambuf * buf)
| : std::basic_ostream(buf), dt(debug::NONE)
| {}

Yes, the comment is outdated, and does not reflect reality.

| File containing lyx_debug_trait: presumably the header should have
|  * \file DebugStream.h
>
| Maybe you could use support/translator.h to simplify switching between the 
| string and enum representations of the debug level?

Will that be easier? That would also mean that I would have to set up
the translation table manually (and dynamically) instead of statically
as we do now.


| File containing basic_teebuf: nice idea. Why do you call the two streams 
| 'master' and 'slave'? There is no slvery going on here. Why restrict 
| yourself to two streambufs? Why not have a std::list?

The teebuf has been there forever :-)
Just unused.

Why master/slave? Well only master is listened to when it comes to
error conditions and return values. The slave just tags along.

I don't want the teebuf to _ever_ handle more than two streambufs, so
no need for a list. If you want more than two, you should chain
teebuf's or create your own multibuf.

-- 
Lgb

Re: boostifying DebugStream

[Angus Leeming]

Lars Gullik Bjønnes wrote:
> The teebuf has been there forever :-)
> Just unused.
> 
> Why master/slave? Well only master is listened to when it comes to
> error conditions and return values. The slave just tags along.
> 
> I don't want the teebuf to _ever_ handle more than two streambufs, so
> no need for a list. If you want more than two, you should chain
> teebuf's or create your own multibuf.

I don't. Nonetheless, I think you should forget your intended usage for a 
moment and look at the class with fresh eyes. There is nothing in it that 
indicates that master_ has greater priveleges than slave_.

Why not rename them as 
base_type * buf[2];
At least that indicates to others that they are simply two otherwise 
identical buffers.

Passing/storing raw pointers isn't very nice...

Incidentally, are the typedefs needed? As they come from the base class, 
don't you get them for free?

-- 
Angus

Re: boostifying DebugStream

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Lars Gullik Bjønnes wrote:
>> The teebuf has been there forever :-)
>> Just unused.
>> 
>> Why master/slave? Well only master is listened to when it comes to
>> error conditions and return values. The slave just tags along.
>> 
>> I don't want the teebuf to _ever_ handle more than two streambufs, so
>> no need for a list. If you want more than two, you should chain
>> teebuf's or create your own multibuf.
>
| I don't. Nonetheless, I think you should forget your intended usage for a 
| moment and look at the class with fresh eyes. There is nothing in it that 
| indicates that master_ has greater priveleges than slave_.
>
| Why not rename them as 
| base_type * buf[2];
| At least that indicates to others that they are simply two otherwise 
| identical buffers.

but they are not of equal importance.
(even if I'd like them to be...)
Perhaps master and slave is the wrong names, but they should be
differently named. (primary,secondary?) 
And probably handle all failure conditions teebuf is way to
simplistic.

| Passing/storing raw pointers isn't very nice...

I have no other solution.

| Incidentally, are the typedefs needed? As they come from the base class, 
| don't you get them for free?

No. Then I need to sprinkle "typename" all over. The typdefs helps
avoid that.

-- 
Lgb

Re: boostifying DebugStream

[Angus Leeming]

Lars Gullik Bjønnes wrote:

> but they are not of equal importance.
> (even if I'd like them to be...)
> Perhaps master and slave is the wrong names, but they should be
> differently named. (primary,secondary?)

primary, secondary is better.

But I still don't get it.

std::ofstream ofs2("/tmp/dump2.dbg");
teebuf tb(ofs2.rdbuf(), std::cerr.rdbuf());
lyxdebugstream dbg(tb);
dbg << "Let's roll" << endl;

This sends output to the file and to stderr. There is no concept of 
importance here at all.

> And probably handle all failure conditions teebuf is way to
> simplistic.

I can't grep this. Could you explain further?

-- 
Angus

Re: boostifying DebugStream

[Lars Gullik Bjønnes]

Angus Leeming <[EMAIL PROTECTED]> writes:

| Lars Gullik Bjønnes wrote:
>
>> but they are not of equal importance.
>> (even if I'd like them to be...)
>> Perhaps master and slave is the wrong names, but they should be
>> differently named. (primary,secondary?)
>
| primary, secondary is better.
>
| But I still don't get it.
>
| std::ofstream ofs2("/tmp/dump2.dbg");
| teebuf tb(ofs2.rdbuf(), std::cerr.rdbuf());
| lyxdebugstream dbg(tb);
| dbg << "Let's roll" << endl;
>
| This sends output to the file and to stderr. There is no concept of 
| importance here at all.

if you look at the implementation there is. In this case it is hte
ofs2's return values that are used for error handling (and discovery).

>> And probably handle all failure conditions teebuf is way to
>> simplistic.
>
| I can't grep this. Could you explain further?

Teebuf is probably to simplistic to handle all failure conditions a
proper streambuf should handle.

-- 
Lgb

Re: boostifying DebugStream

[Angus Leeming]

Lars Gullik Bjønnes wrote:
> | This sends output to the file and to stderr. There is no concept of
> | importance here at all.
> 
> if you look at the implementation there is. In this case it is hte
> ofs2's return values that are used for error handling (and discovery).

Got it! Thank you. I'd missed those all-important return values. A comment 
about this wouldn't go amiss. Perhaps:

/** \c basic_teebuf is a streambuf that sends the output to 
two different streambufs. There is no restriction on their type.
The return values from the 'master' streambuf are passed as
\c basic_teebuf's return values.
*/

primary and secondary is still better...


>>> And probably handle all failure conditions teebuf is way to
>>> simplistic.
>>
> | I can't grep this. Could you explain further?
> 
> Teebuf is probably to simplistic to handle all failure conditions a
> proper streambuf should handle.

Thank you.

-- 
Angus

LyX one dot three dot three

[Jean-Marc Lasgouttes]

I have tagged LyX 1.3.3 and uploaded the various bits to ftp.lyx.org.
I will make the actual announcement tomorrow (unless something ugly
surfaces).

JMarc

support::regexMatch

[Angus Leeming]

This started off as a simple question about this code in 
support/lstrings.[Ch]:

/** Compares a string and a (simple) regular expression
 *  The only element allowed is "*" for any string of characters
 */
bool regexMatch(string const & a, string const & pattern);

bool regexMatch(string const & a, string const & pattern)
{
// We massage the pattern a bit so that the usual
// shell pattern we all are used to will work.
// One nice thing about using a real regex is that
// things like "*.*[^~]" will work also.
// build the regex string.
string regex(pattern);
regex = subst(regex, ".", "\\.");
regex = subst(regex, "*", ".*");
boost::regex reg(regex);
return boost::regex_match(a, reg);
}

It looks to me like the comment in lstrings.h is no longer true.
However, before I change it, could someone explain the 'massaging' to me?

It seems to me that this is a perfectly fine regex
string const my_regex "file  *myfile\\.C";
which gets changed by regexMatch to
"file  .*myfile.C"

Why does it do that? Surely that does not conform to the principle of least 
surprise.
---

So, I went looking for the places regexMatch is used. It is used in two 
places only, so my question has changed to

Shall I just remove the function and use boost::regex in its place?

---
xforms/FormFileDialog.C which uses it to search for stuff like
"*.(gif|png|jpg|bmp|pbm|ppm|tga|tif|xpm|xbm)"
In this case, regexMatch is doing exactly what FormFileDialog.C wants, but 
I think that performing the massaging should actually be 
FormFileDialog.C's job.

---
The only place it is used is filetools.C (ReplaceEnvironmentPath) and here 
the shit really hits the fan.

// Search ${...} as Variable-Name inside the string
// and replace it with the denoted environmentvariable
string copy1(result0); // contains String after $
string const RegExp("*}*"); // Exist EndChar inside a String?
if (!regexMatch(copy1, RegExp)) {

Apart from the fact that this regex as designed ALWAYS matches, regexMatch 
changes it to ".*}.*" which actually makes it work as I suspect the author 
of ReplaceEnvironmentPath intended ;-)

Nonetheless, if you're searching for '}', why not search for '}'? Why use a 
regex at all?

IMO, what should actually be searched for _is_ a regex, but it is this:
string const RegExp = "${[^}]*}";
Doing so would allow you to actually extract the string you were actually 
interested in.

In fact, the whole function is a pile of crap and could be replaced by

#include
#include
#include 

using std::string;

string const my_getenv(string const & data)
{
if (data == "HOME")
return "/home/angus";
if (data == "AWAY")
return "foreign";
return string();
}


string const ReplaceEnvironmentPath(string const & path)
{
boost::regex const re("(.*)[$]\\{([^}]*)\\}(.*)");
boost::smatch what;

string result = path;
while (1) {
regex_match(result, what, re, boost::match_partial);
if (!what[0].matched)
break;
result = what.str(1) + my_getenv(what.str(2)) + what.str(3);
}
return result;
}



int main()
{
string const input = "/foo/bar/${HOME}/emma/${HOME}/${AWAY}";
string const output = ReplaceEnvironmentPath(input);

std::cout << "Input: " << input << std::endl;
std::cout << "Output: " << output << std::endl;

return 0;
}

-- 
Angus

Re: support::regexMatch

[Jean-Marc Lasgouttes]

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> The only place it is used is filetools.C
Angus> (ReplaceEnvironmentPath) and here the shit really hits the fan.

This function is completely broken, and actually kills LyX when you
try to use it (we are lucky that nobody uses it, but it would be
useful to have it more visible). So please replace it with whatever
makes sense.

JMarc

Re: lyx 1.3.2: xpm files

[Jean-Marc Lasgouttes]

> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

Angus> Hartmut Haase wrote:
>> Why can some xpm files like
>> /usr/share/lyx/images/depth-increment.xpm or
>> /usr/share/lyx/images/math/sqrt.xpm be seen in LyX AND
>> xdvi/gv/acroread and other like /usr/share/lyx/images/font-noun.xpm
>> or /usr/share/lyx/images/math/blacktriangle.xpm ONLY in LyX?

Angus> Because there are different flavours of XPM and different apps
Angus> support different subsets of them.

Angus> The problems all stem from the definition of the colour table.
Angus> You say that everything can read images/depth-increment.xpm?

[...]

In this case, 'everything' is probably "convert" and this occurs
because Hartmut uses the xpm icons in his german translation of the
docs.

It would be nice to change our xpms so that this works consistently. I
am not sure though what is the best tool to do that...

JMarc

Re: support::regexMatch

[Angus Leeming]

Jean-Marc Lasgouttes wrote:

>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
> 
> Angus> The only place it is used is filetools.C
> Angus> (ReplaceEnvironmentPath) and here the shit really hits the fan.
> 
> This function is completely broken, and actually kills LyX when you
> try to use it (we are lucky that nobody uses it, but it would be
> useful to have it more visible). So please replace it with whatever
> makes sense.

The comment defines this as a valid variable:
variable :=  '$' '{' [A-Za-z_]{[A-Za-z_0-9]*} '}'

I think that the internal curly brackets are just there to 'help' make it 
readable, right? (Can't have '{' in an environment variable.)

That being the case, this works, but isn't strict enough, allowing 'nested' 
stuff like this hypothetical example:

$ x=M
$ echo ${HO${x}E}
/home/angus

The real shell won't allow this.

IS THIS A PROBLEM, or should I just commit it?
Angus

string const ReplaceEnvironmentPath(string const & path)
{
boost::regex const re("(.*)[$]\\{([A-Za-z_][A-Za-z_0-9]*)\\}(.*)");
boost::smatch what;

string result = path;
while (1) {
regex_match(result, what, re, boost::match_partial);
if (!what[0].matched)
break;
result = what.str(1) + my_getenv(what.str(2)) + what.str(3);
}
return result;
}

Re: lyx 1.3.2: xpm files

[Angus Leeming]

Jean-Marc Lasgouttes wrote:
> It would be nice to change our xpms so that this works consistently. I
> am not sure though what is the best tool to do that...

A shell script... (probably)
sed -n 's/^\( *"[]*c *#\)\([0-9]\{4\}\)\([0-9]\{4\}\)\([0-9]\{4\}\) *" *, *$/\1 \2 
\3 \4/p' images/font-noun.xpm

"   c #   

So, I can extract the three colours, but how do I left shift em?

Ahhh. I could take each \([0-9]\{4\}\) block and split it into two:
\([0-9]\{2\}\)\([0-9]\{2\}\)
outputting only the first match.

Will that do?

-- 

Re: lyx 1.3.2: xpm files

[Andre Poenitz]

On Thu, Sep 25, 2003 at 04:52:14PM +, Angus Leeming wrote:
> Ahhh. I could take each \([0-9]\{4\}\) block and split it into two:
>   \([0-9]\{2\}\)\([0-9]\{2\}\)

\([0-9][0-9]\)

is simpler to understand for the casual reader and not longer.

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: lyx 1.3.2: xpm files

[Angus Leeming]

On Thursday 25 September 2003 3:56 pm, Andre Poenitz wrote:
> On Thu, Sep 25, 2003 at 04:52:14PM +, Angus Leeming wrote:
> > Ahhh. I could take each \([0-9]\{4\}\) block and split it into two:
> > \([0-9]\{2\}\)\([0-9]\{2\}\)
>
>   \([0-9][0-9]\)
>
> is simpler to understand for the casual reader and not longer.

Ok. But is the idea valid? "1234" -> "12" 
A

Re: lyx 1.3.2: xpm files

[Andre Poenitz]

On Thu, Sep 25, 2003 at 05:05:07PM +, Angus Leeming wrote:
> On Thursday 25 September 2003 3:56 pm, Andre Poenitz wrote:
> > On Thu, Sep 25, 2003 at 04:52:14PM +, Angus Leeming wrote:
> > > Ahhh. I could take each \([0-9]\{4\}\) block and split it into two:
> > >   \([0-9]\{2\}\)\([0-9]\{2\}\)
> >
> > \([0-9][0-9]\)
> >
> > is simpler to understand for the casual reader and not longer.
> 
> Ok. But is the idea valid? "1234" -> "12" 

Why not?

Andre'

-- 
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)

Re: support::regexMatch

[Stephan Witt]

Angus Leeming wrote:
Jean-Marc Lasgouttes wrote:


"Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:

[snip]

That being the case, this works, but isn't strict enough, allowing 'nested' 
stuff like this hypothetical example:

$ x=M
$ echo ${HO${x}E}
/home/angus
The real shell won't allow this.
Just for curiosity: make will do it!

% cat Makefile
x=M
home=${HO${x}E}
all:
echo ${home}
% make
echo /home/witt
/home/witt
Regards,

Stephan

Re: lyx 1.3.2: xpm files

[Angus Leeming]

Andre Poenitz wrote:
>> Ok. But is the idea valid? "1234" -> "12"
> Why not?

Done that.

Next question: given an rbg.txt database
240 240 240 grey94
242 242 242 gray95

how do I create the appropriate #rrggbb entry from the shell?

-- 
Angus

Re: lyx 1.3.2: xpm files

[Angus Leeming]

Angus Leeming wrote:
> Next question: given an rbg.txt database
> 240 240 240 grey94
> 242 242 242 gray95
> 
> how do I create the appropriate #rrggbb entry from the shell?

Doh!
$ printf '%x\n' 240
f0
$
-- 
Angus

Re: lyx 1.3.2: xpm files

[Angus Leeming]

Jean-Marc Lasgouttes wrote:
> It would be nice to change our xpms so that this works consistently. I
> am not sure though what is the best tool to do that...

A bit slow (about an hour ;-) but looks successful. 472 files changed in 
the 1.4 tree.

-- 
Angus

xpm_cleanup.sh
Description: application/shellscript

Rewrite of ReplaceEnvironmentPath

[Angus Leeming]

I've rewritten ReplaceEnvironmentPath in a sane manner and got rid of 
lstrings.[Ch] regexMatch because nothing was using it.

I've tested this by inserting a LyX file into the buffer (calling 
BufferView_pimpl.C's MenuInsertLyXFile which in turn calls 
support::FileSearch which in turn calls ReplaceEnvironmentPath).

Attempting to add '${HOME}/docs/some_file.lyx' when running lyx from 
somewhere other than ${HOME} works fine.

I have committed this. Please report any failures.

-- 
Angus? build
? external_bits.diff
? insetexternal.diff
? patches
? regex.diff
? stats
? stats_16Sep
? xpm.diff
? xpm_cleanup.sh
? lib/reLyX-safe
? src/lfun.sed
? src/lfuns2.h
? src/frontends/controllers/TODO
? src/frontends/xforms/1.4-XFormsView.C
? src/frontends/xforms/1.4-XWorkArea.C
? src/frontends/xforms/1.4-XWorkArea.h
? src/frontends/xforms/1.4-bmtable.c
? src/frontends/xforms/1.4-bmtable.h
? src/frontends/xforms/analyse
? src/insets/ChangeLog-safe
? src/insets/ExternalTransforms.C
? src/insets/ExternalTransforms.h
? src/support/lyxlib-orig.C
? src/support/lyxlib.C
Index: lib/external_templates
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/external_templates,v
retrieving revision 1.19
diff -u -p -r1.19 external_templates
--- lib/external_templates	25 Sep 2003 10:49:12 -	1.19
+++ lib/external_templates	25 Sep 2003 22:59:04 -
@@ -52,8 +52,17 @@ Template RasterImage
 	FileFilter "*.(gif|png|jpg|bmp|pbm|ppm|tga|tif|xpm|xbm)"
 	EditCommand "gimp $$FName"
 	AutomaticProduction true
+	Transform Rotate
+	Transform Resize
+	Transform Clip
+	Transform Extra
 	Format LaTeX
-		Product "\\includegraphics{$$Basename}"
+		TransformString Rotate RotationLatexOption
+		TransformString Resize ResizeLatexOption
+		TransformString Clip ClipLatexOption
+		TransformString Extra ExtraLatexOption
+		Option Arg "[$$Extra,$$Rotate,$$Resize,$$Clip]"
+		Product "\\includegraphics$$Arg{$$Basename}"
 		UpdateFormat eps
 		UpdateResult "$$Basename.eps"
 		Requirement "graphicx"
@@ -90,8 +99,12 @@ Template XFig
 	FileFilter "*.fig"
 	EditCommand "xfig $$FName"
 	AutomaticProduction true
+	Transform Rotate
+	Transform Resize
 	Format LaTeX
-		Product "\\inputOrWarn{$$Basename.pstex_t}"
+		TransformCommand Rotate RotationLatexCommand
+		TransformCommand Resize ResizeLatexCommand
+		Product "$$RotateBegin$$ResizeBegin\\input{$$Basename.pstex_t}$$ResizeEnd$$RotateEnd"
 		UpdateFormat pstex
 		UpdateResult "$$Basename.pstex_t"
 		Requirement "graphicx"
Index: src/frontends/xforms/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/ChangeLog,v
retrieving revision 1.831
diff -u -p -r1.831 ChangeLog
--- src/frontends/xforms/ChangeLog	25 Sep 2003 10:49:12 -	1.831
+++ src/frontends/xforms/ChangeLog	25 Sep 2003 22:59:14 -
@@ -1,5 +1,10 @@
 2003-09-25  Angus Leeming  <[EMAIL PROTECTED]>
 
+	* FormFiledialog.C (regexMatch): moved here from lstrings.[Ch] because
+	this is the only place using this 'massaged' regex.
+
+2003-09-25  Angus Leeming  <[EMAIL PROTECTED]>
+
 	* FormExternal.C (update, apply): InsetExternal::Params::
 	templatename now has accessor functions.
 
Index: src/frontends/xforms/FormFiledialog.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormFiledialog.C,v
retrieving revision 1.47
diff -u -p -r1.47 FormFiledialog.C
--- src/frontends/xforms/FormFiledialog.C	9 Sep 2003 22:13:40 -	1.47
+++ src/frontends/xforms/FormFiledialog.C	25 Sep 2003 22:59:15 -
@@ -28,6 +28,7 @@
 #include "lyx_forms.h"
 
 #include 
+#include 
 
 #include 
 #include 
@@ -62,8 +63,8 @@ using lyx::support::GetEnvPath;
 using lyx::support::LyXReadLink;
 using lyx::support::MakeAbsPath;
 using lyx::support::OnlyFilename;
-using lyx::support::regexMatch;
 using lyx::support::split;
+using lyx::support::subst;
 using lyx::support::suffixIs;
 using lyx::support::trim;
 
@@ -195,6 +196,25 @@ FD_filedialog * FileDialog::Private::fil
 FileDialog::Private * FileDialog::Private::current_dlg_ = 0;
 int FileDialog::Private::minw_ = 0;
 int FileDialog::Private::minh_ = 0;
+
+
+namespace {
+
+bool regexMatch(string const & a, string const & pattern)
+{
+	// We massage the pattern a bit so that the usual
+	// shell pattern we all are used to will work.
+	// One nice thing about using a real regex is that
+	// things like "*.*[^~]" will work also.
+	// build the regex string.
+	string regex = subst(pattern, ".", "\\.");
+	regex = subst(regex, "*", ".*");
+
+	boost::regex reg(regex);
+	return boost::regex_match(a, reg);
+}
+
+} // namespace anon
 
 
 // Reread: updates dialog list to match class directory
Index: src/insets/ExternalTemplate.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ExternalTemplate.C,v
retrieving revision 1.29
diff -u -p -r1.29 

Re: Rewrite of ReplaceEnvironmentPath

[Angus Leeming]

Angus Leeming wrote:
> I have committed this. Please report any failures.

(Don't worry, I didn't commit lib/external_templates which somehow made its 
way into the diff.)

-- 
Angus

Re: LyX one dot three dot three

[John Levon]

On Thu, Sep 25, 2003 at 04:48:29PM +0200, Jean-Marc Lasgouttes wrote:

> I have tagged LyX 1.3.3 and uploaded the various bits to ftp.lyx.org.

RH8.0 RPMs in incoming/

They depend on latex-xft-fonts, naturally.

regards
john
-- 
Khendon's Law:
If the same point is made twice by the same person, the thread is over.

table desing flaws in lyx / possible improvements (was: longtable caption again)

[j.heidemeier]

H. Voss schrieb:
> j.heidemeier schrieb:
 
>> At the moment longtables really suck :-(. 

>yesss ... :-)
 
>Write the whole longtable in pure LaTeX code into a single
>file (not as LyX file, only text).
>Then you can use in an esay way a caption. In Lyx do a
>Insert->file
Well, that is only a short term solution. Meanwhile I think, the real problem 
is, that the current table handling in lyx is so difficult because it does 
not follow the LyX principle:
 * Make standard tasks as easy as possible and  discourage bad habits from 
Office programs.
So I'd like to give a brief sketch of my ideas and I hope it could start an 
improvement process for tables in lyx.
1. The idea in Lyx is to take a strictly document centric view and delegate 
the typesetting to LaTeX - which normally can handle it much better. To this 
extent the author is forced to consequently use different paragraph formats 
and to abandon the visual markup habits of Office-users. 

2. So the abstraction view of LyX authors is structure related. It contains 
chapters, paragraphs, images ...   tables - and neither the typewriter 
view of Office users nor the abstract boxes of TeX's typesetting. The latter 
translation has to be made by LyX "under the hood", whereas in LaTeX this 
translation lies in the LaTeX code, which requires a much higher knowlege of 
possible users compared to lyx - at least for standard cases. 

3. LaTeX has the ability to use standard layout formats also in tables: it is 
the \newcolumtype mechanism in array.sty and allows to override the standard 
column definition with another format with mulitcolumn. If a few table 
formats (e.g. decimal aligned col., multirow cells and normal texts) were 
predefined and could be assigned via the user interface, this would be 
similar to the way the rest of LyX works. Currently LyX allows this approach 
with the "special" (sic!) attribute but does not enforce it. The current 
table formatting is more at the "typesetting level" of Office-Programms.

3. The main exposure of the Floats is misleading from the authors perspective. 
Floats are TeX's typesetting perspective. For the author tabular and 
longtable are similar - not floating figures or floating tables. The ability 
to float in the final layout should be handled as a feature of the respective 
document entity - the correct LaTeX syntax has to be assured by the LyX2LaTeX 
backend.

5- The typography of tables is nicely described in
  ftp://ftp.dante.de/tex-archive/info/german/tabsatz/tabsatz.ps
So a good lyx table should be able to handle straightforward at least the 
simple cases in that document. 
 
4. Now I'll try a rough lyx-table description from an authors perspective:
A lyx-table consists of:
a) 0 or 1 caption
b) a list of table entry which might be identical to a)
c) a continuation caption for longtables which might be identical to a)
d) 0 or 1 topruler
e) one or several headerrows, which may be repeated in longtables
f) 0 or 1 midruler
g) the actual table contens
h) 0 or 1 bottomruler.
Vertical lignes should be possible but deprecated.
The whole table shuld be wrapped in a container tag, giving the type of the 
table, i.e. standard, longtable or floating table . The lack of such a 
container tag is the source of the caption/longtable problem.

Well, enough for now.
Yous  
-- 
Dr. Joachim Heidemeier  Tel. +49-30-8903-2780 
Fachgebiet II 3.2   [EMAIL PROTECTED] 
Umweltbundesamt, Bismarckplatz 1 D-14191 Berlin