On 7/29/23 07:46, Pavel Sanda wrote:
On Fri, Jul 28, 2023 at 07:45:28PM -0400, Richard Kimberly Heck wrote:
Maybe some note in documentation for other users to know about this?
Where? It's one of those things that should just work but doesn't because
unicodesymbols uses \textsection instead of
On Fri, Jul 28, 2023 at 07:45:28PM -0400, Richard Kimberly Heck wrote:
> >Maybe some note in documentation for other users to know about this?
>
> Where? It's one of those things that should just work but doesn't because
> unicodesymbols uses \textsection instead of \S.
Then forget about it, most
On 7/28/23 19:43, Pavel Sanda wrote:
On Fri, Jul 28, 2023 at 04:54:07PM +0200, Richard Kimberly Heck wrote:
commit 5cb80b867f4a59c3253487652ba74a29ad5b3f0f
Author: Richard Kimberly Heck
Date: Thu Jul 27 01:18:55 2023 -0400
Hack to display section symbol
---
lib/unicodesymbols |1
On Fri, Jul 28, 2023 at 04:54:07PM +0200, Richard Kimberly Heck wrote:
> commit 5cb80b867f4a59c3253487652ba74a29ad5b3f0f
> Author: Richard Kimberly Heck
> Date: Thu Jul 27 01:18:55 2023 -0400
>
> Hack to display section symbol
> ---
> lib/unicodesymbols |1 -
On 2015-08-14, Enrico Forestieri wrote:
> Please, go on with whatever solution is deemed to be better.
Done.
http://www.lyx.org/trac/changeset/0bbc80fa83847668b58c5f6c17331a0c02058e68/lyxgit
Thanks,
Günter
On Thu, Aug 13, 2015 at 09:55:35AM -0400, Richard Heck wrote:
> On 08/13/2015 07:41 AM, Guenter Milde wrote:
> >Dear LyX developers,
> >
> >the changeset http://www.lyx.org/trac/changeset/33178/lyxsvn
> >solves a problem described in bug report http://www.lyx.org/trac/ticket/6469
> >
> >Use case:
s).
but there are.
Comment 17 goes on:
I don't think so. The workaround is only used when you choose "Times
Roman" in the GUI, but you are still free to manually load any font
package you like.
My problem with this is, that while with the current hack LyX works out of
the
On 08/13/2015 07:41 AM, Guenter Milde wrote:
Dear LyX developers,
the changeset http://www.lyx.org/trac/changeset/33178/lyxsvn
solves a problem described in bug report http://www.lyx.org/trac/ticket/6469
Use case:
* The font in this document is set to Times Roman.
* There is a Greek Unicode ch
Dear LyX developers,
the changeset http://www.lyx.org/trac/changeset/33178/lyxsvn
solves a problem described in bug report http://www.lyx.org/trac/ticket/6469
Use case:
* The font in this document is set to Times Roman.
* There is a Greek Unicode character in the document.
Problem:
thefont s
On Tue, Feb 17, 2015 at 3:22 PM, Georg Baum
wrote:
> Scott Kostyshak wrote:
>
>> To reproduce the above ctest in an actual LyX session, open
>> EmbeddedObjects with write permission, go to Document Settings >
>> Fonts, check "Use non-TeX fonts" and choose FreeSans for Roman, Sans,
>> and Typewrite
Scott Kostyshak wrote:
> To reproduce the above ctest in an actual LyX session, open
> EmbeddedObjects with write permission, go to Document Settings >
> Fonts, check "Use non-TeX fonts" and choose FreeSans for Roman, Sans,
> and Typewriter. Then save and go to File > Export > PDF (LuaTeX).
>
> A
On Sun, Jan 11, 2015 at 2:01 PM, Georg Baum wrote:
> commit eb121f99935579ca4c459cf0265b6f39dbddd6c1
> Author: Georg Baum
> Date: Sun Jan 11 20:00:45 2015 +0100
>
> Replace hardcoded hack with InsetLayout tag
This seems to have broken several of the tests for me.
A "g
Stephan Witt wrote:
> I tried this and it's ok. Thanks.
Thanks from me as well, I forgot to change that file.
Georg
Am 01.06.2013 um 09:44 schrieb Kornel Benko :
> commit 823ed6cf17aa62e66c958068ab762c9f5bbb5f12
> Author: Kornel Benko
> Date: Sat Jun 1 09:42:36 2013 +0200
>
>Remove ugly multiple definition hack (Georg)
>Enable APPLE again for test_layouts (Missed in commit ...48d
Am 20.11.2011 18:07, schrieb Georg Baum:
I suggest to postpone this until the backporting stops.
OK.
I made a few simple
changes that should allow some more conditions, so you could commit your
patch without the hack.
Thanks. The support for Spreadsheets and chess diagrams is in. For the
On 20.11.2011 16:45, Georg Baum wrote:
Peter Kümmel wrote:
The idea is nice, but the 4-character restriction makes it quite
unreadable IMHO.
Played around a bit and found this readable solution:
typedef boost::mpl::string<'\\end','_lay','out'> end_layout;
typedef boost::mpl::string<'\\end'
function.
I suggest to postpone this until the backporting stops. I made a few simple
changes that should allow some more conditions, so you could commit your
patch without the hack.
Georg
Peter Kümmel wrote:
The idea is nice, but the 4-character restriction makes it quite
unreadable IMHO.
>
> Played around a bit and found this readable solution:
>
>
> typedef boost::mpl::string<'\\end','_lay','out'> end_layout;
> typedef boost::mpl::string<'\\end','in','set'> end_ins
Am 17.11.2011 20:40, schrieb Georg Baum:
I like the principal idea (splitting parse_text() into smaller pieces), but
I don't like the way you do it, because the same limit will be quickly hit
again. I would propose something different: Move similar stuff into own
functions, e.g. all the font stu
The idea is nice, but the 4-character restriction makes it quite unreadable
IMHO.
Played around a bit and found this readable solution:
typedef boost::mpl::string<'\\end','_lay','out'> end_layout;
typedef boost::mpl::string<'\\end','in','set'> end_inset;
...
switch (boost::hash_va
On 19.11.2011 15:26, Peter Kümmel wrote:
On 17.11.2011 21:48, Georg Baum wrote:
Peter Kümmel wrote:
Isn't there a better C/C++ way of solving this? For instance, couldn't it
somehow be 'transformed' into a switch/case statement?
A proper parser would of course use something like an enum for
On 17.11.2011 21:48, Georg Baum wrote:
Peter Kümmel wrote:
Isn't there a better C/C++ way of solving this? For instance, couldn't it
somehow be 'transformed' into a switch/case statement?
A proper parser would of course use something like an enum for each string
literal (ideally automatically
Peter Kümmel wrote:
>> Isn't there a better C/C++ way of solving this? For instance, couldn't it
>> somehow be 'transformed' into a switch/case statement?
A proper parser would of course use something like an enum for each string
literal (ideally automatically generated from a formal grammar, as
On 17.11.2011 20:49, Peter Kümmel wrote:
On 17.11.2011 20:40, Georg Baum wrote:
Uwe Stöhr wrote:
The attached patch adds support for the template "chess", "Gnumeric" and
"PDFPages".
I had to introduce a trick to overcome MSVC's limitation of 128 else-if
statements per routine. OK with it?
I
On 17.11.2011 20:40, Georg Baum wrote:
Uwe Stöhr wrote:
The attached patch adds support for the template "chess", "Gnumeric" and
"PDFPages".
I had to introduce a trick to overcome MSVC's limitation of 128 else-if
statements per routine. OK with it?
I like the principal idea (splitting parse_
Uwe Stöhr wrote:
> The attached patch adds support for the template "chess", "Gnumeric" and
> "PDFPages".
>
> I had to introduce a trick to overcome MSVC's limitation of 128 else-if
> statements per routine. OK with it?
I like the principal idea (splitting parse_text() into smaller pieces), but
c/ticket/7897. If this is not a bug, I
will adjust the routine to make the .tex extension an extension the template understands. So I will
only commit the PDFPages and chess support if you agree to my 128 esle-if statements hack.
thanks
Jürgen Spitzmüller wrote:
Richard Heck wrote:
Ick. OK, then, we can do that.
I'm still not sure this is enough. I recall having seen (and even introduced)
uses of requires where the output is done at a completely different place.
The require("CJK") call in LaTeXFeatures::useLanguage
Richard Heck wrote:
> Ick. OK, then, we can do that.
I'm still not sure this is enough. I recall having seen (and even introduced)
uses of requires where the output is done at a completely different place.
The require("CJK") call in LaTeXFeatures::useLanguage is such a case. This
still would fa
Jürgen Spitzmüller wrote:
Richard Heck wrote:
This is a hack, and I haven't tested it, or even compiled it, since I
can't compile here at the moment. Just an idea in lieu of more
sophisticated packaging stuff.
Note that we are also requiering macros, such as "LyX&q
Richard Heck wrote:
> This is a hack, and I haven't tested it, or even compiled it, since I
> can't compile here at the moment. Just an idea in lieu of more
> sophisticated packaging stuff.
Note that we are also requiering macros, such as "LyX", "noun"
or
This is a hack, and I haven't tested it, or even compiled it, since I
can't compile here at the moment. Just an idea in lieu of more
sophisticated packaging stuff.
rh
Index: LaTeXFeatures.cpp
===
--- LaTeXFe
Abdelrazak Younes wrote:
> As you like but please note that testing is rather simple in this case:
> just put lots of inset nested one in each other and look for painting
> problems.
> Attached an updated patch that remove even more code :-) but is not
> fully working within inset... yet!
Please n
José Matos wrote:
On Saturday 29 September 2007 12:29:00 [EMAIL PROTECTED] wrote:
I'd say we wait with this until 1.5.2 is out and do
the change for 1.5.3. Then this has enough time for testing.
+1
+1
JMarc
PS: Abdel please don't be discouraged with this. If you finish the patch
soo
On Saturday 29 September 2007 12:29:00 [EMAIL PROTECTED] wrote:
> > I'd say we wait with this until 1.5.2 is out and do
> > the change for 1.5.3. Then this has enough time for testing.
>
> +1
+1
> JMarc
PS: Abdel please don't be discouraged with this. If you finish the patch
soon I(/we) wo
> I'd say we wait with this until 1.5.2 is out and do
> the change for 1.5.3. Then this has enough time for testing.
+1
JMarc
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Here is a better patch. There are some issues when the text is too close
to the right edge of an inset. But these issues are already in 1.5svn
and are not brought by my patch.
While I'm very much in favour of this change, I'm reluctant to shov
Abdelrazak Younes wrote:
> Here is a better patch. There are some issues when the text is too close
> to the right edge of an inset. But these issues are already in 1.5svn
> and are not brought by my patch.
While I'm very much in favour of this change, I'm reluctant to shove it in so
short before
gets rid of the wide() hack.
It works well and I've tested it with all kind of Text insets.
Hum, except tables...
Here is a better patch. There are some issues when the text is too close
to the right edge of an inset. But these issues are already in 1.5svn
and are not brought by my
Abdelrazak Younes wrote:
Juergen,
This patch back port the look and feel of text insets from trunk:
multi-rows or multi-paragraph Text will be automatically expanded to the
full width. This has two main benefits:
1) It optimize drawing in non-wide insets.
2) It gets rid of the wide() hack
Juergen,
This patch back port the look and feel of text insets from trunk:
multi-rows or multi-paragraph Text will be automatically expanded to the
full width. This has two main benefits:
1) It optimize drawing in non-wide insets.
2) It gets rid of the wide() hack.
It works well and I&#x
After updating to 1.5.0/1 from 1.4.4, I had this same issue:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg55698.html
which persisted even after upgrading ImageMagick to the latest version.
In the end, I solved this problem by editing the file:
/Applications/LyX-151.app/Contents/Resources/
I am going to commit the attached patch which is documenting the abuse of
docstrings to store code points of symbol fonts.
This is a bad hack IMO, and both Abdel and I where already fooled by it. To
my knowledge this is the only place where something else than UCS4 is
stored in a docstring or
Herbert Voss wrote:
> I have an image with an unknown format, so LyX returns user.
> If I save all these files as *.user then I am able to define
> a converter so that all these images can be previewed inside
> LyX. which is not possible when '' is returned, if I am not
> wrong here. Defining a co
Georg Baum wrote:
Am Dienstag, 9. November 2004 09:19 schrieb Lars Gullik Bjønnes:
I am quite happy with your patch...
Good.
with this fixed.
Of course ;-)
I am applying this now. I'll fix the "users" format later if it is needed
after Herberts explanation (which he hopefully gives).
I have an
Am Dienstag, 9. November 2004 09:19 schrieb Lars Gullik Bjønnes:
> I am quite happy with your patch...
Good.
> with this fixed.
Of course ;-)
I am applying this now. I'll fix the "users" format later if it is needed
after Herberts explanation (which he hopefully gives).
Georg
Georg Baum <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> Georg Baum <[EMAIL PROTECTED]>
>> writes:
>> This is a wrapper...
>
| Yes, it was a misunderstanding, I was thinking you suggested a wrapper
| around the wrapper, and I could not see why we want two wrappers ;-)
>
>> is forma
Lars Gullik Bjønnes wrote:
> Georg Baum <[EMAIL PROTECTED]>
> writes:
> This is a wrapper...
Yes, it was a misunderstanding, I was thinking you suggested a wrapper
around the wrapper, and I could not see why we want two wrappers ;-)
> is formatlist a member of something, or a global var?
It is
Herbert Voss wrote:
> Georg Baum wrote:
>
>> Here comes the patch. I removed the useless "user" format in the process.
>> Now getFormatFromContents() either returns a format name or an empty
>> string if it cannot determine the format. I even found two cases where
>> the return value of getFormat
Georg Baum <[EMAIL PROTECTED]> writes:
| +string Formats::getFormatFromFile(string const & filename) const
| +{
| + if (filename.empty())
| + return string();
| +
| + string const format =
| lyx::support::getFormatFromContents(filename)
This is a wrapper...
is formatlist a
Herbert Voss <[EMAIL PROTECTED]> writes:
| Georg Baum wrote:
>
>> Here comes the patch. I removed the useless "user" format in the process.
>> Now getFormatFromContents() either returns a format name or an empty string
>> if it cannot determine the format. I even found two cases where the return
>
Georg Baum <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> Georg Baum <[EMAIL PROTECTED]>
>> writes:
>> | Would it be ok with you to have something like
>> | Format const *Formats::getFormatFromFile(string filename)
>> | that does what getFormatFromContents() did before your patch?
>
Georg Baum wrote:
Here comes the patch. I removed the useless "user" format in the process.
Now getFormatFromContents() either returns a format name or an empty string
if it cannot determine the format. I even found two cases where the return
value of getFormatFromContents() needed to be checked.
t
///
int getNumber(std::string const & name) const;
///
Index: src/client/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/client/ChangeLog,v
retrieving revision 1.5
diff -u -p -r1.5 ChangeLog
--- src/client/ChangeLog
Georg Baum <[EMAIL PROTECTED]> writes:
| Am Sonntag, 7. November 2004 13:52 schrieb Lars Gullik Bjønnes:
>>
>> This hack (dummy Format object to make libsupport link), is not
>> acceptable.
>
| Then it needs to be removed from tex2lyx, too.
>
>> This means th
Am Sonntag, 7. November 2004 13:52 schrieb Lars Gullik Bjønnes:
>
> This hack (dummy Format object to make libsupport link), is not
> acceptable.
Then it needs to be removed from tex2lyx, too.
> This means that the usage for Format and format.h in
> support/filetools.C is not
This hack (dummy Format object to make libsupport link), is not
acceptable.
This means that the usage for Format and format.h in
support/filetools.C is not acceptable and must go away.
libsupport should should not include anything from "core". It is a
support library. I am going to
Alfredo Braunstein wrote:
> This is a quick-hacked inlined-in-open mode as Andre's proposal. Seems to
> work, but I didn't test it much.
>
> Comments?
It seems that no one really tried this.
Let me point out that it works well in the sense that it finds the way that
uses less space (label on th
Andre Poenitz wrote:
>> This is a quick-hacked inlined-in-open mode as Andre's proposal. Seems to
>> work, but I didn't test it much.
>>
>> Comments?
>
> If it works... I just wonder why it adds code...
Well it's just to accommodate two different ways of drawing things in the
place of one (and
On Thu, Mar 04, 2004 at 11:48:03AM +0100, Alfredo Braunstein wrote:
> This is a quick-hacked inlined-in-open mode as Andre's proposal. Seems to
> work, but I didn't test it much.
>
> Comments?
If it works... I just wonder why it adds code...
Andre'
This is a quick-hacked inlined-in-open mode as Andre's proposal. Seems to
work, but I didn't test it much.
Comments?
Alfredo
? insetcollapsable-save.C
? insettext-save.C
Index: insetcollapsable.C
===
RCS file: /usr/local/lyx/cvsroot/
On Fri, Jan 09, 2004 at 03:59:26PM +0200, Martin Vermeer spake thusly:
> > The question we need to answer is: setting aside implementation
> > details what kind of UI would we want to provide to enter this
> > information. Is the label/ref paradigm sound?
> >
> > JMarc
>
> Well, is it? I get th
On Fri, Jan 09, 2004 at 12:57:51PM +0100, Jean-Marc Lasgouttes spake thusly:
>
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> So, yes, this isn't a very good idea either. Especially since
> Martin> it isn't really a label ("internally" doesn't count, you
> Martin> cann
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> So, yes, this isn't a very good idea either. Especially since
Martin> it isn't really a label ("internally" doesn't count, you
Martin> cannot legally reference it from the rest of the text), just
Martin> label-like. A sui generis
On Fri, Jan 09, 2004 at 10:02:15AM +0100, Jean-Marc Lasgouttes spake thusly:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Actually not quite true. Docbook has had this
> Martin> label-in-first-position detection for a while. If a label is
> Martin> found, it is added
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Actually not quite true. Docbook has had this
Martin> label-in-first-position detection for a while. If a label is
Martin> found, it is added as, e.g., . And it
Martin> enters the referable label list in the usual way.
Martin> C
On Thursday 08 January 2004 16:41, Martin Vermeer wrote:
>
> Actually not quite true. Docbook has had this label-in-first-position
> detection for a while. If a label is found, it is added as, e.g.,
> . And it enters the referable label list in the
> usual way.
I guess there is a common denomina
On Thu, Jan 08, 2004 at 04:16:38PM +0100, Jean-Marc Lasgouttes spake thusly:
> Actually, these optargs in elsart are nothing more than label/ref
> pairs (it seems to use this internally). So a reasonable interface in
> LyX would be to add a label inset in the thanks paragraph and one or
> several
> "Jose'" == Jose' Matos <[EMAIL PROTECTED]> writes:
Jose'> I have a patch for that, an Jean-Marc is asking for comments
Jose'> on it. It seems that you favour that option, as I do do.
Jose'> The only grip with Jean-Marc is the fact the optional
Jose'> argument is a kind of label while th
On Thu, Jan 08, 2004 at 11:06:21AM +, Jose' Matos spake thusly:
> On Thursday 08 January 2004 10:42, Martin Vermeer wrote:
> >
> > Not having used elsart and not even having it installed, this is pure
> > theory... but!
> >
> > 1) What about adding a ShortTitle to the Author and Author_Addres
On Thursday 08 January 2004 10:42, Martin Vermeer wrote:
>
> Not having used elsart and not even having it installed, this is pure
> theory... but!
>
> 1) What about adding a ShortTitle to the Author and Author_Address
> styles? (OK, the name ShortTitle is inappropriate for this use)
I have a pa
On Wed, Jan 07, 2004 at 05:07:56PM +, Jose' Matos spake thusly:
> Hello,
> I want to give a concrete example why I don't like the InTitle hack in
> layouts. Take this with 1 Kg of salt, I only intend to show some places where
> I don't like the way LyX work
Hello,
I want to give a concrete example why I don't like the InTitle hack in
layouts. Take this with 1 Kg of salt, I only intend to show some places where
I don't like the way LyX works.
Ok, this is a corner case as LyX works for 99% of the other cases. My goal is
On Mon, Oct 27, 2003 at 08:34:04PM +0100, Alfredo Braunstein wrote:
> > rowBreakPoint() has changed beyond my recognition
>
> grumpy as always?
I didn't say it was necessarily a bad thing :L)
john
--
Khendon's Law:
If the same point is made twice by the same person, the thread is over.
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Can I apply this so it gets some testing besides mine?
Yes, why not.
--
Lgb
:18:37 - 1.488
+++ text.C 28 Oct 2003 13:27:38 -
@@ -525,8 +525,11 @@ void LyXText::rowBreakPoint(ParagraphLis
}
}
// exit on last registered breakpoint:
+#if 0
+ // hack removed
John Levon wrote:
> Have you tested a variety of deeply nested lists/descriptions ?
Seems to work ok. But "a variety..." is not very precise.
> rowBreakPoint() has changed beyond my recognition
grumpy as always?
Regards, Alfredo
On Mon, Oct 27, 2003 at 03:51:05PM +0100, Lars Gullik Bjønnes wrote:
> John Levon <[EMAIL PROTECTED]> writes:
>
> | On Mon, Oct 27, 2003 at 03:22:50PM +0100, Andre Poenitz wrote:
> >
> >> Ah... so you were the one called 'nobody'
> >
> | It's just like school all over again !
>
> John "Nobby" Lev
John Levon <[EMAIL PROTECTED]> writes:
| On Mon, Oct 27, 2003 at 03:22:50PM +0100, Andre Poenitz wrote:
>
>> Ah... so you were the one called 'nobody'
>
| It's just like school all over again !
John "Nobby" Levon.
--
Lgb
On Mon, Oct 27, 2003 at 03:22:50PM +0100, Andre Poenitz wrote:
> Ah... so you were the one called 'nobody'
It's just like school all over again !
john
--
Khendon's Law:
If the same point is made twice by the same person, the thread is over.
On Mon, Oct 27, 2003 at 02:14:22PM +, John Levon wrote:
> On Mon, Oct 27, 2003 at 03:10:46PM +0100, Andre Poenitz wrote:
>
> > I any case I think one has now a chance to understand what's going on
> > there, so bug hunting could be based on looking at code not the phase of
> > the moon.
>
>
On Mon, Oct 27, 2003 at 03:10:46PM +0100, Andre Poenitz wrote:
> I any case I think one has now a chance to understand what's going on
> there, so bug hunting could be based on looking at code not the phase of
> the moon.
Actually I understood it in its entirety ... not my fault others are so
la
patch applied). It
> > seems to me a hack that is not needed anymore. In exactly which situations
> > is/was it needed?
>
> Have you tested a variety of deeply nested lists/descriptions ?
>
> rowBreakPoint() has changed beyond my recognition
I do hope so ;-)
I any case I t
On Mon, Oct 27, 2003 at 12:57:51PM +0100, Alfredo Braunstein wrote:
> Does annyone knows what goes wrong if I remove the first '-' line in this
> diff? (alternatively, show bad rowbreaking with this patch applied). It
> seems to me a hack that is not needed anymore. In exact
Does annyone knows what goes wrong if I remove the first '-' line in this
diff? (alternatively, show bad rowbreaking with this patch applied). It
seems to me a hack that is not needed anymore. In exactly which situations
is/was it needed?
Regards, Alfredo
Ind
With graphviz's dot, and the following hack, I'm able to produce the
attached document dependency graphs automatically (please see the attached
out.ps.gz<-Extended.lyx and out2.ps.gz to understand what this is about).
I think that the graphs can be useful for checking the overall str
Andre Poenitz wrote:
On Mon, Mar 10, 2003 at 08:38:07AM +, Angus Leeming wrote:
Have you checked math?
No. I just assumed that you did the tight thing already ;-)
Juergen explained to me how edit() works and how it should work already
twice or so. Then I took another beer, and watched him f
On Mon, Mar 10, 2003 at 08:38:07AM +, Angus Leeming wrote:
> > Have you checked math?
>
> No. I just assumed that you did the tight thing already ;-)
Juergen explained to me how edit() works and how it should work already
twice or so. Then I took another beer, and watched him fixing the
curr
Andre Poenitz wrote:
> On Fri, Mar 07, 2003 at 10:14:43PM +, Angus Leeming wrote:
>> The attached patch works beautifully. Ok to apply?
>
> Have you checked math?
No. I just assumed that you did the tight thing already ;-)
--
Angus
On Fri, Mar 07, 2003 at 10:14:43PM +, Angus Leeming wrote:
> The attached patch works beautifully. Ok to apply?
Have you checked math?
[Actually I think all edit call should go through dispatch...]
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor
On Fri, Mar 07, 2003 at 10:14:43PM +, Angus Leeming wrote:
>
> The attached patch works beautifully. Ok to apply?
>
Nice :)
john
This cry for help caught my attention since I've been adding localDispatch
methods to insets.
// IMO this is a gross hack! Insets should be changed so that
// they call the actions they have to do with the insetButtonRel.
// function and not in the edit(). This shou
On Tue, Nov 26, 2002 at 05:28:03PM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | Quick'n'dirty fix for the "can't scroll over large insets" problem.
> | It makes sure that PageDown is at least as big a step as CursorDown.
> >
> | Ok?
>
> how is the rand cases
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Quick'n'dirty fix for the "can't scroll over large insets" problem.
| It makes sure that PageDown is at least as big a step as CursorDown.
>
| Ok?
how is the rand cases handled?
- inset at top/bottom of doc
- cursor at top/bottom
- cursor close to top/
Quick'n'dirty fix for the "can't scroll over large insets" problem.
It makes sure that PageDown is at least as big a step as CursorDown.
Ok?
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Index: text3.C
=
On Sat, Aug 25, 2001 at 05:14:10PM +0100, John Levon wrote:
> However, even changing it can't get it working satisfactorily. It cannot be
> done in the Qt2 frontend
yes it can. I'm busy compiling what should solve the problems. IT's hacky -
we have a bool that is set during update() that prevent
Angus, what you did doesn't work. The bc() stuff must come /after/
a view show/update.
However, even changing it can't get it working satisfactorily. It cannot be
done in the Qt2 frontend because it must distinguish betweencreateInset and showInset.
So this leads me to the conclusion that a bc(
On Tue, 13 Mar 2001, Angus Leeming wrote:
> John,
>
> why isn't there a patch for the broken rfind()/split() here, or is this fixed
> already?
>
> I'll apply it if the other is fixed already.
>
> Angus
I was a complete dumbarse, there is no bug :)
john
--
"Alan Turing thought about criter
1/03/13 12:40:03
> @@ -1,3 +1,7 @@
> +2001-03-13 John Levon <[EMAIL PROTECTED]>
> +
> + * FormGraphics.C: remove unnecessary hack
> +
> 2001-03-12 Dekel Tsur <[EMAIL PROTECTED]>
>
> * Menubar_pimpl.C (add_toc):
On 13 Mar 2001, Lars Gullik Bjønnes wrote:
> John Levon <[EMAIL PROTECTED]> writes:
>
> | - string const pattern = "*.(ps|png)| ";
> | + string const pattern = "*.(ps|png)|";
>
> what purpose has the second "|"?
> what cases does it avoid matching on?
>
> Lgb
In the KDE frontend,
1 - 100 of 104 matches
Mail list logo
