Re: cursor (selection) question

2013-02-22 Thread Jean-Marc Lasgouttes 

Le 20/02/2013 06:23, Scott Kostyshak a écrit :

I think I am close to correctly fixing #8543, where search finds the
same word twice when switching directions.

See the patch here:
http://www.lyx.org/trac/attachment/ticket/8543/0001-This-patch-flips-the-cursor-but-sel-is-lost.patch


What about the following straightforward approach to the problem?

JMarc



From 2bfdbfd7d9dd0e915540bb53f5f06b53071fc53f Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes lasgout...@lyx.org
Date: Fri, 22 Feb 2013 11:06:25 +0100
Subject: [PATCH] Fix confusing behavior in search when changing directions (bug 8543)

---
 src/lyxfind.cpp |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/src/lyxfind.cpp b/src/lyxfind.cpp
index 73700cb..d6df0ef 100644
--- a/src/lyxfind.cpp
+++ b/src/lyxfind.cpp
@@ -154,7 +154,9 @@ bool findOne(BufferView * bv, docstring const  searchstr,
 	if (!searchAllowed(searchstr))
 		return false;
 
-	DocIterator cur = bv-cursor();
+	DocIterator cur = forward 
+		? bv-cursor().selectionEnd() 
+		: bv-cursor().selectionBegin();
 
 	MatchString const match(searchstr, case_sens, whole);
 
-- 
1.7.0.4

Re: cursor (selection) question

2013-02-22 Thread Scott Kostyshak 
On Thu, Feb 21, 2013 at 11:09 AM, Richard Heck rgh...@lyx.org wrote:
 On 02/20/2013 12:23 AM, Scott Kostyshak wrote:

 I think I am close to correctly fixing #8543, where search finds the
 same word twice when switching directions.

 See the patch here:

 http://www.lyx.org/trac/attachment/ticket/8543/0001-This-patch-flips-the-cursor-but-sel-is-lost.patch

 The only problem I have is that LFUN_SELECTION_FLIP loses the
 selection (this is a problem because it looks bad and if you change
 directions twice in a row we are back to the original problem):

 Why is the selection lost? Where is it being redrawn?
 How can I use cur.selectionBegin(), cur.selectionEnd(),
 cur.selBegin(), and cur.selEnd() to do one of the following?
 (1) keep the selection
 or
 (2) lose it but redraw it how it was after I move the cursor


 I think the issue is that the anchor is now where the cursor is. We need to
 reset that, since we're now selecting in the opposite direction. The
 attached works for me. It needs minor cleaning (don't simply break where the
 errors are).

Yes, you are right. That does the trick. I had a feeling the anchor
was important but didn't (and still don't) understand its purpose.
Thanks for this correction.


 A few other comments.

 diff --git a/src/Text3.cpp b/src/Text3.cpp
 index 2893e08..5f35071 100644
 --- a/src/Text3.cpp
 +++ b/src/Text3.cpp
 @@ -551,6 +551,30 @@ void Text::dispatch(Cursor  cur, FuncRequest  cmd)
  break;
  }

 +case LFUN_SELECTION_FLIP: {
 +CursorSlice from;
 +CursorSlice to;
 +if (cur.pos() == cur.selectionBegin().pos()) {
 +from = cur.selBegin();
 +to = cur.selEnd();
 +}
 +else if (cur.pos() == cur.selectionEnd().pos()) {
 +to = cur.selBegin();
 +from = cur.selEnd();
 +}
 +// else assert?


 At least print an error and return. What follows will be invalid in that
 case.

 +if (cur.top() != from)
 +setCursor(cur, from.pit(), from.pos());

 I'm not sure I follow the logic, but it looks as if, in this case, you set
 the cursor here, and then set it again immediately thereafter. So I took
 this out.

 +if (to == from)
 +return;


 We have an empty selection if this is true. We should not have that, but we
 can just test on cur.selection() to start.

 Richard


I appreciate your comments, Richard. I was close to finishing the
patch when JMarc had to come along and ruin the fun :)

I learned a lot from experimenting and from your comments.

Thanks,

Scott

Re: cursor (selection) question

2013-02-22 Thread Scott Kostyshak 
On Fri, Feb 22, 2013 at 5:08 AM, Jean-Marc Lasgouttes
lasgout...@lyx.org wrote:
 Le 20/02/2013 06:23, Scott Kostyshak a écrit :

 I think I am close to correctly fixing #8543, where search finds the
 same word twice when switching directions.

 See the patch here:

 http://www.lyx.org/trac/attachment/ticket/8543/0001-This-patch-flips-the-cursor-but-sel-is-lost.patch


 What about the following straightforward approach to the problem?

Your patch is 100x better than what I was proposing. It is much
cleaner and it also fixes the problem at its source which means that
the LFUNs exhibit the same behavior as GuiSearch (this was not the
case for my patch). It is also better because the cursor doesn't
visually move, from the user perspective. I could imagine someone
being confused as to why the cursor is moving around when they toggle
the box search backwards. Not to mention, 4 lines versus 40 lines.

Thanks for looking into this,

Scott

Re: Re: [LyX master] Merge branch 'master' of git.lyx.org:lyx

2013-02-22 Thread Kornel Benko 
Am Donnerstag, 21. Februar 2013 um 17:15:16, schrieb Jürgen Spitzmüller 
sp...@lyx.org
 Kornel Benko wrote:
   As said, I don't think this is correct. Instead, the current platex
   support  should be fixed.
  
  Sorry. Also for my next commit I done.
 
 So can you please revert these commits?
 
 Jürgen

Done.

Kornel

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

Re: #7839: equation editor: cropped PDF and EPS

2013-02-22 Thread Guenter Milde 
On 2013-02-21, Liviu Andronic wrote:
 On Thu, Feb 21, 2013 at 10:14 AM, Guenter Milde mi...@users.sf.net wrote:
 Please also consider view/export cropped SVG (if unicode-math is used):

 * with the traditional TeX math fonts, the conversion of mathematical
   content is buggy, because of the non-standard font metrics.

 * with Xe/LuaTeX, unicode-math, and OpenType Math fonts (LatinModern
   math, Asana Math, or XITS), the conversion is OK.

Unfortunately I found out that also with unicode-math, prolems with the SVG
conversin exist

 SVG is supported by HTML. This allows the inclusion of scalable vector
 images of equations in HTML pages - far better than bitmap PNGs!

 That would be nice, indeed. Could you come up with a patch and post it
 on the ticket?

I posted an example.

 (I cannot test this as I'm running TeXLive 2009 and
 thus no unicode-math.)

How about upgrading? Debian/testing has TeXLive 2012 (and AFAIK Ubuntu as
well). So even in a Debian/stable it should be easy to upgrade to a mixed
stable/testing setup.

Günter

Re: cursor (selection) question

2013-02-22 Thread Jean-Marc Lasgouttes 

Le 22/02/2013 11:40, Scott Kostyshak a écrit :

Your patch is 100x better than what I was proposing. It is much
cleaner and it also fixes the problem at its source which means that
the LFUNs exhibit the same behavior as GuiSearch (this was not the
case for my patch). It is also better because the cursor doesn't
visually move, from the user perspective. I could imagine someone
being confused as to why the cursor is moving around when they toggle
the box search backwards. Not to mention, 4 lines versus 40 lines.


Do you want to test it? Shall I apply?

JMarc

Re: cursor (selection) question

2013-02-22 Thread Jean-Marc Lasgouttes 

Le 22/02/2013 15:39, Jean-Marc Lasgouttes a écrit :

Le 22/02/2013 11:40, Scott Kostyshak a écrit :

Your patch is 100x better than what I was proposing. It is much
cleaner and it also fixes the problem at its source which means that
the LFUNs exhibit the same behavior as GuiSearch (this was not the
case for my patch). It is also better because the cursor doesn't
visually move, from the user perspective. I could imagine someone
being confused as to why the cursor is moving around when they toggle
the box search backwards. Not to mention, 4 lines versus 40 lines.


Do you want to test it? Shall I apply?


I applied it.

JMarc

Re: cursor (selection) question

2013-02-22 Thread Richard Heck 

On 02/22/2013 05:40 AM, Scott Kostyshak wrote:
I appreciate your comments, Richard. I was close to finishing the 
patch when JMarc had to come along and ruin the fun :) I learned a lot 
from experimenting and from your comments.


And I learned a bit about anchors myself. But JMarc knows this code.

rh

Re: cursor (selection) question

2013-02-22 Thread Richard Heck 

On 02/22/2013 10:04 AM, Jean-Marc Lasgouttes wrote:

Le 22/02/2013 15:39, Jean-Marc Lasgouttes a écrit :

Le 22/02/2013 11:40, Scott Kostyshak a écrit :

Your patch is 100x better than what I was proposing. It is much
cleaner and it also fixes the problem at its source which means that
the LFUNs exhibit the same behavior as GuiSearch (this was not the
case for my patch). It is also better because the cursor doesn't
visually move, from the user perspective. I could imagine someone
being confused as to why the cursor is moving around when they toggle
the box search backwards. Not to mention, 4 lines versus 40 lines.


Do you want to test it? Shall I apply?


I applied it.


Pretty safe, too, so good for branch.

rh

Re: [LyX master] Some fixes to parsing in tex2lyx

2013-02-22 Thread Richard Heck 

On 02/22/2013 10:04 AM, Jean-Marc Lasgouttes wrote:

diff --git a/src/tex2lyx/Parser.cpp b/src/tex2lyx/Parser.cpp
index 11ecfe1..d87ff29 100644
--- a/src/tex2lyx/Parser.cpp
+++ b/src/tex2lyx/Parser.cpp
@@ -131,11 +131,11 @@ bool iparserdocstream::setEncoding(std::string const  e)

  void iparserdocstream::putback(char_type c)
  {
-   s_ += c;
+   s_ = c + s_;
  }


I'm just curious: Is there an actual difference between these?

rh

Re: [LyX master] Some fixes to parsing in tex2lyx

2013-02-22 Thread Jean-Marc Lasgouttes 

Le 22/02/2013 16:29, Richard Heck a écrit :

On 02/22/2013 10:04 AM, Jean-Marc Lasgouttes wrote:

diff --git a/src/tex2lyx/Parser.cpp b/src/tex2lyx/Parser.cpp
index 11ecfe1..d87ff29 100644
--- a/src/tex2lyx/Parser.cpp
+++ b/src/tex2lyx/Parser.cpp
@@ -131,11 +131,11 @@ bool iparserdocstream::setEncoding(std::string
const  e)

  void iparserdocstream::putback(char_type c)
  {
-s_ += c;
+s_ = c + s_;
  }


I'm just curious: Is there an actual difference between these?


In on case you append, in the other one you prepend.

JMarc

Re: [LyX master] Some fixes to parsing in tex2lyx

2013-02-22 Thread Richard Heck 

On 02/22/2013 10:37 AM, Jean-Marc Lasgouttes wrote:

Le 22/02/2013 16:29, Richard Heck a écrit :

On 02/22/2013 10:04 AM, Jean-Marc Lasgouttes wrote:

diff --git a/src/tex2lyx/Parser.cpp b/src/tex2lyx/Parser.cpp
index 11ecfe1..d87ff29 100644
--- a/src/tex2lyx/Parser.cpp
+++ b/src/tex2lyx/Parser.cpp
@@ -131,11 +131,11 @@ bool iparserdocstream::setEncoding(std::string
const  e)

  void iparserdocstream::putback(char_type c)
  {
-s_ += c;
+s_ = c + s_;
  }


I'm just curious: Is there an actual difference between these?


In on case you append, in the other one you prepend.


Oh, right, sorry. Blindness must have set in.

rh

Re: [LyX master] Some fixes to parsing in tex2lyx

2013-02-22 Thread José Matos 
On 02/22/2013 05:09 PM, Richard Heck wrote:
 Oh, right, sorry. Blindness must have set in.

 rh

Usually you expect that sum is a commutative operation, and fwiw in this
case so did I. :-)

-- 
José Matos

Re: cursor (selection) question

2013-02-22 Thread Scott Kostyshak 
On Fri, Feb 22, 2013 at 9:39 AM, Jean-Marc Lasgouttes
lasgout...@lyx.org wrote:
 Le 22/02/2013 11:40, Scott Kostyshak a écrit :

 Your patch is 100x better than what I was proposing. It is much
 cleaner and it also fixes the problem at its source which means that
 the LFUNs exhibit the same behavior as GuiSearch (this was not the
 case for my patch). It is also better because the cursor doesn't
 visually move, from the user perspective. I could imagine someone
 being confused as to why the cursor is moving around when they toggle
 the box search backwards. Not to mention, 4 lines versus 40 lines.


 Do you want to test it? Shall I apply?

I tested it in every situation I could think of and it worked well.

Thanks,

Scott

Re: [LyX 2.0.x] Fix broken installation (typo, already fixed in 1e44661fa04896036d9).

2013-02-22 Thread Scott Kostyshak 
On Fri, Feb 22, 2013 at 5:41 PM, Pavel Sanda sa...@lyx.org wrote:
 commit 215042720c04e430807b044ef89ff87c3e393ba9
 Author: Pavel Sanda sa...@lyx.org
 Date:   Fri Feb 22 14:33:56 2013 -0800

 Fix broken installation (typo, already fixed in 1e44661fa04896036d9).

 https://bugs.gentoo.org/show_bug.cgi?id=458692

 diff --git a/lib/Makefile.am b/lib/Makefile.am
 index 423fa61..f00fa73 100644
 --- a/lib/Makefile.am
 +++ b/lib/Makefile.am
 @@ -1635,6 +1635,6 @@ dist_ui_DATA = \

  install-data-hook:
 $(CHMOD) 755 $(DESTDIR)$(pkgdatadir)/configure.py
 -   for i in $(scriptdir)/*.py ; do \
 +   for i in $(scriptsdir)/*.py ; do \
 $(CHMOD) 755 $(DESTDIR)$(pkgdatadir)/$$i; \
 done

In bash, if set -u is put at the top of a script, unbound variables
cause an error. Is there something like this that could be put in
Makefile.am? Or can an option be specified when calling Makefile.am?
If so, is there any reason not to do this?

I have the same question for CMake. I remember that there was a
similar variable typo at some point.

Scott

Re: [LyX 2.0.x] Fix broken installation (typo, already fixed in 1e44661fa04896036d9).

2013-02-22 Thread Pavel Sanda 
Scott Kostyshak wrote:
 On Fri, Feb 22, 2013 at 5:41 PM, Pavel Sanda sa...@lyx.org wrote:
  commit 215042720c04e430807b044ef89ff87c3e393ba9
  Author: Pavel Sanda sa...@lyx.org
  Date:   Fri Feb 22 14:33:56 2013 -0800
 
  Fix broken installation (typo, already fixed in 1e44661fa04896036d9).
 
  https://bugs.gentoo.org/show_bug.cgi?id=458692
 
  diff --git a/lib/Makefile.am b/lib/Makefile.am
  index 423fa61..f00fa73 100644
  --- a/lib/Makefile.am
  +++ b/lib/Makefile.am
  @@ -1635,6 +1635,6 @@ dist_ui_DATA = \
 
   install-data-hook:
  $(CHMOD) 755 $(DESTDIR)$(pkgdatadir)/configure.py
  -   for i in $(scriptdir)/*.py ; do \
  +   for i in $(scriptsdir)/*.py ; do \
  $(CHMOD) 755 $(DESTDIR)$(pkgdatadir)/$$i; \
  done
 
 In bash, if set -u is put at the top of a script, unbound variables
 cause an error. Is there something like this that could be put in
 Makefile.am? Or can an option be specified when calling Makefile.am?
 If so, is there any reason not to do this?
 
 I have the same question for CMake. I remember that there was a
 similar variable typo at some point.


a-ou, it actually doesn't work in working environment when you fix the typo; no 
time
to inspect more, so i'll revert.

make[4]: Entering directory 
`/var/tmp/portage/app-office/lyx-2.0.98/work/var/tmp/portage/app-office/lyx-2
.0.98/work/lyx-2.0.98/lib'
chmod 755 
/var/tmp/portage/app-office/lyx-2.0.98/image//usr/share/lyx/configure.py
for i in /usr/share/lyx/scripts/*.py ; do \
chmod 755 /var/tmp/portage/app-office/lyx-2.0.98/image//usr/share/lyx/$i; \
done
chmod: cannot access 
'/var/tmp/portage/app-office/lyx-2.0.98/image//usr/share/lyx//usr/share/lyx/scripts/
clean_dvi.py': No such file or directory

(no worry worry about 98, just temporary build)

Richard, sorry to mess-up with the branch.

Pavel

Re: cursor (selection) question

2013-02-22 Thread Jean-Marc Lasgouttes 

Le 20/02/2013 06:23, Scott Kostyshak a écrit :

I think I am close to correctly fixing #8543, where search finds the
same word twice when switching directions.

See the patch here:
http://www.lyx.org/trac/attachment/ticket/8543/0001-This-patch-flips-the-cursor-but-sel-is-lost.patch


What about the following straightforward approach to the problem?

JMarc



>From 2bfdbfd7d9dd0e915540bb53f5f06b53071fc53f Mon Sep 17 00:00:00 2001
From: Jean-Marc Lasgouttes 
Date: Fri, 22 Feb 2013 11:06:25 +0100
Subject: [PATCH] Fix confusing behavior in search when changing directions (bug 8543)

---
 src/lyxfind.cpp |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/src/lyxfind.cpp b/src/lyxfind.cpp
index 73700cb..d6df0ef 100644
--- a/src/lyxfind.cpp
+++ b/src/lyxfind.cpp
@@ -154,7 +154,9 @@ bool findOne(BufferView * bv, docstring const & searchstr,
 	if (!searchAllowed(searchstr))
 		return false;
 
-	DocIterator cur = bv->cursor();
+	DocIterator cur = forward 
+		? bv->cursor().selectionEnd() 
+		: bv->cursor().selectionBegin();
 
 	MatchString const match(searchstr, case_sens, whole);
 
-- 
1.7.0.4

Re: cursor (selection) question

2013-02-22 Thread Scott Kostyshak 
On Thu, Feb 21, 2013 at 11:09 AM, Richard Heck  wrote:
> On 02/20/2013 12:23 AM, Scott Kostyshak wrote:
>>
>> I think I am close to correctly fixing #8543, where search finds the
>> same word twice when switching directions.
>>
>> See the patch here:
>>
>> http://www.lyx.org/trac/attachment/ticket/8543/0001-This-patch-flips-the-cursor-but-sel-is-lost.patch
>>
>> The only problem I have is that LFUN_SELECTION_FLIP loses the
>> selection (this is a problem because it looks bad and if you change
>> directions twice in a row we are back to the original problem):
>>
>> Why is the selection lost? Where is it being redrawn?
>> How can I use cur.selectionBegin(), cur.selectionEnd(),
>> cur.selBegin(), and cur.selEnd() to do one of the following?
>> (1) keep the selection
>> or
>> (2) lose it but redraw it how it was after I move the cursor
>
>
> I think the issue is that the anchor is now where the cursor is. We need to
> reset that, since we're now selecting in the opposite direction. The
> attached works for me. It needs minor cleaning (don't simply break where the
> errors are).

Yes, you are right. That does the trick. I had a feeling the anchor
was important but didn't (and still don't) understand its purpose.
Thanks for this correction.

>
> A few other comments.
>
>> diff --git a/src/Text3.cpp b/src/Text3.cpp
>> index 2893e08..5f35071 100644
>> --- a/src/Text3.cpp
>> +++ b/src/Text3.cpp
>> @@ -551,6 +551,30 @@ void Text::dispatch(Cursor & cur, FuncRequest & cmd)
>>  break;
>>  }
>>
>> +case LFUN_SELECTION_FLIP: {
>> +CursorSlice from;
>> +CursorSlice to;
>> +if (cur.pos() == cur.selectionBegin().pos()) {
>> +from = cur.selBegin();
>> +to = cur.selEnd();
>> +}
>> +else if (cur.pos() == cur.selectionEnd().pos()) {
>> +to = cur.selBegin();
>> +from = cur.selEnd();
>> +}
>> +// else assert?
>>
>
> At least print an error and return. What follows will be invalid in that
> case.
>
>> +if (cur.top() != from)
>> +setCursor(cur, from.pit(), from.pos());
>>
> I'm not sure I follow the logic, but it looks as if, in this case, you set
> the cursor here, and then set it again immediately thereafter. So I took
> this out.
>
>> +if (to == from)
>> +return;
>>
>
> We have an empty selection if this is true. We should not have that, but we
> can just test on cur.selection() to start.
>
> Richard
>

I appreciate your comments, Richard. I was close to finishing the
patch when JMarc had to come along and ruin the fun :)

I learned a lot from experimenting and from your comments.

Thanks,

Scott

Re: cursor (selection) question

2013-02-22 Thread Scott Kostyshak 
On Fri, Feb 22, 2013 at 5:08 AM, Jean-Marc Lasgouttes
 wrote:
> Le 20/02/2013 06:23, Scott Kostyshak a écrit :
>
>> I think I am close to correctly fixing #8543, where search finds the
>> same word twice when switching directions.
>>
>> See the patch here:
>>
>> http://www.lyx.org/trac/attachment/ticket/8543/0001-This-patch-flips-the-cursor-but-sel-is-lost.patch
>
>
> What about the following straightforward approach to the problem?

Your patch is 100x better than what I was proposing. It is much
cleaner and it also fixes the problem at its source which means that
the LFUNs exhibit the same behavior as GuiSearch (this was not the
case for my patch). It is also better because the cursor doesn't
visually move, from the user perspective. I could imagine someone
being confused as to why the cursor is moving around when they toggle
the box "search backwards". Not to mention, 4 lines versus 40 lines.

Thanks for looking into this,

Scott

Re: Re: [LyX master] Merge branch 'master' of git.lyx.org:lyx

2013-02-22 Thread Kornel Benko 
Am Donnerstag, 21. Februar 2013 um 17:15:16, schrieb Jürgen Spitzmüller 

> Kornel Benko wrote:
> > > As said, I don't think this is correct. Instead, the current platex
> > > support  should be fixed.
> > 
> > Sorry. Also for my next commit I done.
> 
> So can you please revert these commits?
> 
> Jürgen

Done.

Kornel

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

Re: #7839: equation editor: cropped PDF and EPS

2013-02-22 Thread Guenter Milde 
On 2013-02-21, Liviu Andronic wrote:
> On Thu, Feb 21, 2013 at 10:14 AM, Guenter Milde  wrote:
>> Please also consider "view/export cropped SVG" (if unicode-math is used):

>> * with the traditional TeX math fonts, the conversion of mathematical
>>   content is buggy, because of the non-standard font metrics.

>> * with Xe/LuaTeX, "unicode-math", and OpenType Math fonts (LatinModern
>>   math, Asana Math, or XITS), the conversion is OK.

Unfortunately I found out that also with unicode-math, prolems with the SVG
conversin exist

>> SVG is supported by HTML. This allows the inclusion of scalable vector
>> images of equations in HTML pages - far better than bitmap PNGs!

> That would be nice, indeed. Could you come up with a patch and post it
> on the ticket?

I posted an example.

> (I cannot test this as I'm running TeXLive 2009 and
> thus no "unicode-math".)

How about upgrading? Debian/testing has TeXLive 2012 (and AFAIK Ubuntu as
well). So even in a Debian/stable it should be easy to upgrade to a mixed
stable/testing setup.

Günter

Re: cursor (selection) question

2013-02-22 Thread Jean-Marc Lasgouttes 

Le 22/02/2013 11:40, Scott Kostyshak a écrit :

Your patch is 100x better than what I was proposing. It is much
cleaner and it also fixes the problem at its source which means that
the LFUNs exhibit the same behavior as GuiSearch (this was not the
case for my patch). It is also better because the cursor doesn't
visually move, from the user perspective. I could imagine someone
being confused as to why the cursor is moving around when they toggle
the box "search backwards". Not to mention, 4 lines versus 40 lines.


Do you want to test it? Shall I apply?

JMarc

Re: cursor (selection) question

2013-02-22 Thread Jean-Marc Lasgouttes 

Le 22/02/2013 15:39, Jean-Marc Lasgouttes a écrit :

Le 22/02/2013 11:40, Scott Kostyshak a écrit :

Your patch is 100x better than what I was proposing. It is much
cleaner and it also fixes the problem at its source which means that
the LFUNs exhibit the same behavior as GuiSearch (this was not the
case for my patch). It is also better because the cursor doesn't
visually move, from the user perspective. I could imagine someone
being confused as to why the cursor is moving around when they toggle
the box "search backwards". Not to mention, 4 lines versus 40 lines.


Do you want to test it? Shall I apply?


I applied it.

JMarc

Re: cursor (selection) question

2013-02-22 Thread Richard Heck 

On 02/22/2013 05:40 AM, Scott Kostyshak wrote:
I appreciate your comments, Richard. I was close to finishing the 
patch when JMarc had to come along and ruin the fun :) I learned a lot 
from experimenting and from your comments.


And I learned a bit about anchors myself. But JMarc knows this code.

rh

Re: cursor (selection) question

2013-02-22 Thread Richard Heck 

On 02/22/2013 10:04 AM, Jean-Marc Lasgouttes wrote:

Le 22/02/2013 15:39, Jean-Marc Lasgouttes a écrit :

Le 22/02/2013 11:40, Scott Kostyshak a écrit :

Your patch is 100x better than what I was proposing. It is much
cleaner and it also fixes the problem at its source which means that
the LFUNs exhibit the same behavior as GuiSearch (this was not the
case for my patch). It is also better because the cursor doesn't
visually move, from the user perspective. I could imagine someone
being confused as to why the cursor is moving around when they toggle
the box "search backwards". Not to mention, 4 lines versus 40 lines.


Do you want to test it? Shall I apply?


I applied it.


Pretty safe, too, so good for branch.

rh

Re: [LyX master] Some fixes to parsing in tex2lyx

2013-02-22 Thread Richard Heck 

On 02/22/2013 10:04 AM, Jean-Marc Lasgouttes wrote:

diff --git a/src/tex2lyx/Parser.cpp b/src/tex2lyx/Parser.cpp
index 11ecfe1..d87ff29 100644
--- a/src/tex2lyx/Parser.cpp
+++ b/src/tex2lyx/Parser.cpp
@@ -131,11 +131,11 @@ bool iparserdocstream::setEncoding(std::string const&  e)

  void iparserdocstream::putback(char_type c)
  {
-   s_ += c;
+   s_ = c + s_;
  }


I'm just curious: Is there an actual difference between these?

rh

Re: [LyX master] Some fixes to parsing in tex2lyx

2013-02-22 Thread Jean-Marc Lasgouttes 

Le 22/02/2013 16:29, Richard Heck a écrit :

On 02/22/2013 10:04 AM, Jean-Marc Lasgouttes wrote:

diff --git a/src/tex2lyx/Parser.cpp b/src/tex2lyx/Parser.cpp
index 11ecfe1..d87ff29 100644
--- a/src/tex2lyx/Parser.cpp
+++ b/src/tex2lyx/Parser.cpp
@@ -131,11 +131,11 @@ bool iparserdocstream::setEncoding(std::string
const&  e)

  void iparserdocstream::putback(char_type c)
  {
-s_ += c;
+s_ = c + s_;
  }


I'm just curious: Is there an actual difference between these?


In on case you append, in the other one you prepend.

JMarc

Re: [LyX master] Some fixes to parsing in tex2lyx

2013-02-22 Thread Richard Heck 

On 02/22/2013 10:37 AM, Jean-Marc Lasgouttes wrote:

Le 22/02/2013 16:29, Richard Heck a écrit :

On 02/22/2013 10:04 AM, Jean-Marc Lasgouttes wrote:

diff --git a/src/tex2lyx/Parser.cpp b/src/tex2lyx/Parser.cpp
index 11ecfe1..d87ff29 100644
--- a/src/tex2lyx/Parser.cpp
+++ b/src/tex2lyx/Parser.cpp
@@ -131,11 +131,11 @@ bool iparserdocstream::setEncoding(std::string
const&  e)

  void iparserdocstream::putback(char_type c)
  {
-s_ += c;
+s_ = c + s_;
  }


I'm just curious: Is there an actual difference between these?


In on case you append, in the other one you prepend.


Oh, right, sorry. Blindness must have set in.

rh

Re: [LyX master] Some fixes to parsing in tex2lyx

2013-02-22 Thread José Matos 
On 02/22/2013 05:09 PM, Richard Heck wrote:
> Oh, right, sorry. Blindness must have set in.
>
> rh

Usually you expect that sum is a commutative operation, and fwiw in this
case so did I. :-)

-- 
José Matos

Re: cursor (selection) question

2013-02-22 Thread Scott Kostyshak 
On Fri, Feb 22, 2013 at 9:39 AM, Jean-Marc Lasgouttes
 wrote:
> Le 22/02/2013 11:40, Scott Kostyshak a écrit :
>
>> Your patch is 100x better than what I was proposing. It is much
>> cleaner and it also fixes the problem at its source which means that
>> the LFUNs exhibit the same behavior as GuiSearch (this was not the
>> case for my patch). It is also better because the cursor doesn't
>> visually move, from the user perspective. I could imagine someone
>> being confused as to why the cursor is moving around when they toggle
>> the box "search backwards". Not to mention, 4 lines versus 40 lines.
>
>
> Do you want to test it? Shall I apply?

I tested it in every situation I could think of and it worked well.

Thanks,

Scott

Re: [LyX 2.0.x] Fix broken installation (typo, already fixed in 1e44661fa04896036d9).

2013-02-22 Thread Scott Kostyshak 
On Fri, Feb 22, 2013 at 5:41 PM, Pavel Sanda  wrote:
> commit 215042720c04e430807b044ef89ff87c3e393ba9
> Author: Pavel Sanda 
> Date:   Fri Feb 22 14:33:56 2013 -0800
>
> Fix broken installation (typo, already fixed in 1e44661fa04896036d9).
>
> https://bugs.gentoo.org/show_bug.cgi?id=458692
>
> diff --git a/lib/Makefile.am b/lib/Makefile.am
> index 423fa61..f00fa73 100644
> --- a/lib/Makefile.am
> +++ b/lib/Makefile.am
> @@ -1635,6 +1635,6 @@ dist_ui_DATA = \
>
>  install-data-hook:
> $(CHMOD) 755 $(DESTDIR)$(pkgdatadir)/configure.py
> -   for i in $(scriptdir)/*.py ; do \
> +   for i in $(scriptsdir)/*.py ; do \
> $(CHMOD) 755 $(DESTDIR)$(pkgdatadir)/$$i; \
> done

In bash, if "set -u" is put at the top of a script, unbound variables
cause an error. Is there something like this that could be put in
Makefile.am? Or can an option be specified when calling Makefile.am?
If so, is there any reason not to do this?

I have the same question for CMake. I remember that there was a
similar variable typo at some point.

Scott

Re: [LyX 2.0.x] Fix broken installation (typo, already fixed in 1e44661fa04896036d9).

2013-02-22 Thread Pavel Sanda 
Scott Kostyshak wrote:
> On Fri, Feb 22, 2013 at 5:41 PM, Pavel Sanda  wrote:
> > commit 215042720c04e430807b044ef89ff87c3e393ba9
> > Author: Pavel Sanda 
> > Date:   Fri Feb 22 14:33:56 2013 -0800
> >
> > Fix broken installation (typo, already fixed in 1e44661fa04896036d9).
> >
> > https://bugs.gentoo.org/show_bug.cgi?id=458692
> >
> > diff --git a/lib/Makefile.am b/lib/Makefile.am
> > index 423fa61..f00fa73 100644
> > --- a/lib/Makefile.am
> > +++ b/lib/Makefile.am
> > @@ -1635,6 +1635,6 @@ dist_ui_DATA = \
> >
> >  install-data-hook:
> > $(CHMOD) 755 $(DESTDIR)$(pkgdatadir)/configure.py
> > -   for i in $(scriptdir)/*.py ; do \
> > +   for i in $(scriptsdir)/*.py ; do \
> > $(CHMOD) 755 $(DESTDIR)$(pkgdatadir)/$$i; \
> > done
> 
> In bash, if "set -u" is put at the top of a script, unbound variables
> cause an error. Is there something like this that could be put in
> Makefile.am? Or can an option be specified when calling Makefile.am?
> If so, is there any reason not to do this?
> 
> I have the same question for CMake. I remember that there was a
> similar variable typo at some point.


a-ou, it actually doesn't work in working environment when you fix the typo; no 
time
to inspect more, so i'll revert.

make[4]: Entering directory 
`/var/tmp/portage/app-office/lyx-2.0.98/work/var/tmp/portage/app-office/lyx-2
.0.98/work/lyx-2.0.98/lib'
chmod 755 
/var/tmp/portage/app-office/lyx-2.0.98/image//usr/share/lyx/configure.py
for i in /usr/share/lyx/scripts/*.py ; do \
chmod 755 /var/tmp/portage/app-office/lyx-2.0.98/image//usr/share/lyx/$i; \
done
chmod: cannot access 
'/var/tmp/portage/app-office/lyx-2.0.98/image//usr/share/lyx//usr/share/lyx/scripts/
clean_dvi.py': No such file or directory

(no worry worry about "98", just temporary build)

Richard, sorry to mess-up with the branch.

Pavel