Jürgen Spitzmüller wrote:
> \textipa{\textepsilon{}kspl\textschwa{}ne\textsci{}\textesh{}\textschwa{}n}
>
> which is not only hardly readable (due to the macros), but also the kerning
> is broken by the {} which are appended after each macro.
The kerning problem is addressed by the attached patc
Stephan Witt wrote:
> I have another patch in my local branch checkout...
> It fixes a warning and a potential bug.
OK.
Jürgen
I have another patch in my local branch checkout...
It fixes a warning and a potential bug.
Stephan
Index: src/mathed/InsetMathHull.cpp
===
--- src/mathed/InsetMathHull.cpp(Revision 35627)
+++ src/mathed/InsetMathHull.cpp
On Thu, May 31, 2007 at 09:50:03AM +0200, Stefan Schimanski wrote:
>
> Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
>
> >>"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
> >
> >Stefan> This is fine, mostly. I don't like 7. There should be a
> >Stefan> position behind the c,
On Thu, May 31, 2007 at 09:25:15AM +0200, Stefan Schimanski wrote:
> So, removing the whole boundary business, we get this behavious:
>
> 1) abc| \ndef =right=> abc \n|def
> 2) ab|c\ndef =right=> abc\n|def =right=> abc\nd|ef
> 3) abc \nd|ef =left=> abc \n|def =left=> abc| \ndef
> 4) abc\nd|ef =lef
Stefan Schimanski schrieb:
Am 31.05.2007 um 10:56 schrieb Michael Gerz:
Abdelrazak Younes schrieb:
Isn't this related to change-tracking?
Change tracking adds meta information to a virtual (i.e.
non-existing) end-of-par character at the end of each paragraph.
It does not care for cursor st
Am 31.05.2007 um 10:56 schrieb Michael Gerz:
Abdelrazak Younes schrieb:
Isn't this related to change-tracking?
Change tracking adds meta information to a virtual (i.e. non-
existing) end-of-par character at the end of each paragraph.
It does not care for cursor stuff.
(I haven't follow the
Michael Gerz wrote:
Abdelrazak Younes schrieb:
Isn't this related to change-tracking?
Change tracking adds meta information to a virtual (i.e. non-existing)
end-of-par character at the end of each paragraph.
Ah yes I remembered something about a virtual end-of-par.
It does not care for cur
Abdelrazak Younes schrieb:
Isn't this related to change-tracking?
Change tracking adds meta information to a virtual (i.e. non-existing)
end-of-par character at the end of each paragraph.
It does not care for cursor stuff.
(I haven't follow the thread but I hope that you did not kill any
CT-
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Good question. In 1.4.x, the two positions exist. I am not sure
>> why the position in front of the display inset is deemed useful.
Abdelrazak> Isn't this related to change-tracking?
I think it is something else, but what?
Jean-Marc Lasgouttes wrote:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> This is fine, mostly. I don't like 7. There should be a
Stefan> position behind
Am 31.05.2007 um 10:13 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> The only case I can imagine is while selecting an inset like
Stefan> display math. It might seem more intuitive if you can select
Stefan> just the line of a display math.
Bu
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> The only case I can imagine is while selecting an inset like
Stefan> display math. It might seem more intuitive if you can select
Stefan> just the line of a display math.
But the visual effect will remain the same anyway.
I
Am 31.05.2007 um 09:57 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> This is fine, mostly. I don't like 7. There should
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
>>> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
>>
Stefan> This is fine, mostly. I don't like 7. There should be a
Stefan> position behind the c, because
Am 31.05.2007 um 09:43 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> This is fine, mostly. I don't like 7. There should be a
Stefan> position behind the c, because if you type with the cursor in
Stefan> front of the $$1$ $ the characters appea
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> This is fine, mostly. I don't like 7. There should be a
Stefan> position behind the c, because if you type with the cursor in
Stefan> front of the $$1$ $ the characters appear behind c. In fact
Stefan> the position in front of
So, removing the whole boundary business, we get this behavious:
1) abc| \ndef =right=> abc \n|def
2) ab|c\ndef =right=> abc\n|def =right=> abc\nd|ef
3) abc \nd|ef =left=> abc \n|def =left=> abc| \ndef
4) abc\nd|ef =left=> abc\ndef =left=> ab|c\ndef
5) abc|\ndef =right=> abc\n|def
6) abcd|ef =lef
On Thu, May 31, 2007 at 02:29:38AM +0300, Dov Feldstern wrote:
> At least cursorLeft and cursorRight are much simpler now...
I have no idea whether the patch is sound, but I certainly like the
structure...
Andre'
[This should be applied after the patch in
http://permalink.gmane.org/gmane.editors.lyx.devel/86074, which fixes
bug 3754.]
Okay, you guys (Stefan and Andre') are correct, as always ;) .
We really don't need the boundary almost anywhere. The comment on
boundary_ in DocIterator.h is (almost) r
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Please have a look at how emacs does this. (I am in favor of the
Lars> 'when in doubt do as emacs' camp.)
It uses a ~/.emacs-places file which contains a list of files and
offsets.
JMarc
Helge Hafting <[EMAIL PROTECTED]> writes:
| John McCabe-Dansted wrote:
|
| >>John> If LyX locked files which were open in a still running LyX
| >>John> process, that would have saved me some confusion.
| >>
| >>Yes, but I am sure this can cause a lot of confusion too...
| >>
| >
| >I am not sure
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> Anyway, I have an additional patch for this bug. Anyone
Jean-Marc> disagrees?
Applied.
JMarc
John McCabe-Dansted wrote:
John> If LyX locked files which were open in a still running LyX
John> process, that would have saved me some confusion.
Yes, but I am sure this can cause a lot of confusion too...
I am not sure why this would cause confusion. You could have a dialog
box warnin
> John> If LyX locked files which were open in a still running LyX
> John> process, that would have saved me some confusion.
>
> Yes, but I am sure this can cause a lot of confusion too...
I am not sure why this would cause confusion. You could have a dialog
box warning that "Another LyX window ha
> "John" == John McCabe-Dansted <[EMAIL PROTECTED]> writes:
>> Sure, the "extra trouble" only ever occur for power users.
John> Perhaps we could have a new minibuffer command save-unchanged
John> which would save the document even if it is unchanged. Such
John> power users could replace "save"
Hi folks,
Here is another set of cleanups for the lyx.spec.in:
Please apply.
---Kayvan
--
Kayvan A. Sylvan | Proud husband of | Father to my kids:
Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89)
http://sylvan.com/~kayvan | "
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> I think my lazy generation of LyXText could help on that. then
| Lars> we should only load the font metrics when first needed.
|
| Stupid question: are we forced to load
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> I think my lazy generation of LyXText could help on that. then
Lars> we should only load the font metrics when first needed.
Stupid question: are we forced to load the whole font metrics to use a
font? If not, caching would be
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
|
| Asger> Regarding improving the performance: I can only recommend using
| Asger> gprof. It's very easy, and it really helps when you want to
| Asger> find and address bottle
> "Mike" == <[EMAIL PROTECTED]> writes:
Mike> On 5 Mar 2001, Jean-Marc Lasgouttes wrote:
>> I tried the "benchmark" a bit here, and the times in successive
>> rune fluctuate enough that I do not see how you can interpret
>> them...
Mike> This wins the "Cool Typo" award. When reading your (
> "Asger" == Asger K Alstrup Nielsen <[EMAIL PROTECTED]> writes:
Asger> Regarding improving the performance: I can only recommend using
Asger> gprof. It's very easy, and it really helps when you want to
Asger> find and address bottlenecks.
Yes, profiling is often a better idea than trying to
On 5 Mar 2001, Jean-Marc Lasgouttes wrote:
> I tried the "benchmark" a bit here, and the times in successive rune
> fluctuate enough that I do not see how you can interpret them...
This wins the "Cool Typo" award. When reading your (the developers')
discussions of compilers, pragmas, etc. my head
Regarding improving the performance:
I can only recommend using gprof. It's very easy, and it really
helps when you want to find and address bottlenecks.
Also, I must confess that it was me that introduced the ugly integer
packed representation of the font information a long time ago.
That was d
On Mon, Mar 05, 2001 at 03:28:11PM +0100, Jean-Marc Lasgouttes wrote:
> > "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> Jean-Marc> I tried the "benchmark" a bit here, and the times in
> Jean-Marc> successive rune fluctuate enough that I do not see how you
> Jean-Marc> ca
On 05-Mar-2001 Jean-Marc Lasgouttes wrote:
> Something like
> time ./lyx -e latex ~/src/lyx/lyxdoc/UserGuide.lyx
> seems to give more consistent results across runs
But this doesn't load a LyXText instance, does it? And there the Fonts are
used most, isn't it?
Jürgen
--
-._-._-._-._-._
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Mon, Mar 05, 2001 at 02:52:00PM +0100, Lars Gullik Bjønnes wrote:
| > time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx
| > About to handle -x 'lyx-quit'
| >
| > real0m8.515s
| > user0m6.010s
| > sys 0m0.050s
|
| It still
On Mon, Mar 05, 2001 at 02:52:00PM +0100, Lars Gullik Bjønnes wrote:
> time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx
> About to handle -x 'lyx-quit'
>
> real0m8.515s
> user0m6.010s
> sys 0m0.050s
It still looks slow.
I still don't understand why we can't use my
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | time ./src/lyx -x
| Lars> lyx-quit ../../local/lyxdoc/UserGuide.lyx | About to handle -x
| Lars> 'lyx-quit' | | real 0m8.
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Jean-Marc> I tried the "benchmark" a bit here, and the times in
Jean-Marc> successive rune fluctuate enough that I do not see how you
Jean-Marc> can interpret them...
Something like
time ./lyx -e latex ~/src/lyx/lyxdoc/UserG
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | time ./src/lyx -x
Lars> lyx-quit ../../local/lyxdoc/UserGuide.lyx | About to handle -x
Lars> 'lyx-quit' | | real 0m8.495s | user 0m5.880s | sys 0m0.030s | |
Lars> On a PIII 700M
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx
| About to handle -x 'lyx-quit'
|
| real0m8.495s
| user0m5.880s
| sys 0m0.030s
|
| On a PIII 700Mhz (with primed cache)
With braindead use of push_heap:
time ./s
Dekel Tsur <[EMAIL PROTECTED]> writes:
| With the new patch, the Userguide loads very slowly: ~18 sec
| while with the old code (or the old patch) the UG loads in ~7sec
| (timed with 'time lyx -x lyx-quit UserGuide.lyx').
time ./src/lyx -x lyx-quit ../../local/lyxdoc/UserGuide.lyx
About to handl
Dekel Tsur <[EMAIL PROTECTED]> writes:
| > Oh, we had that earlier, the code was close to impossible to maintain,
| > won't happen. and I'd hate to loose the type information. btw. clever
| > compilers are free to use a byte for most of those enums.
|
| IIRC, we had something else: all the data
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| A map is not very good since we don't have a obvious key (for the same
| reason a hash_map would be hard to use since a hash function would be
| hard to get fast/right/uniue).
|
| I agree that the linear search is not good. (and this is what caus
On Mon, Mar 05, 2001 at 01:24:24PM +0100, Lars Gullik Bjønnes wrote:
> | The problem is that the data in a LyXText instance is changed frequently
> | (in the LyXParagraph::GetFont and LyXText::GetFont methods).
> | The solution is perhaps to keep the LyXFont class unchanged, but in
> | LyXParagra
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Mon, Mar 05, 2001 at 11:29:13AM +0100, Jean-Marc Lasgouttes wrote:
| > > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| >
| > Lars> Yes, I see the same here. So we have to decide if this is a slow
| > Lars> down that we can live with.
On Mon, Mar 05, 2001 at 11:29:13AM +0100, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
> Lars> Yes, I see the same here. So we have to decide if this is a slow
> Lars> down that we can live with. (on the cell phone the numbers above
> Lars> came
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
|
| Lars> Yes, I see the same here. So we have to decide if this is a slow
| Lars> down that we can live with. (on the cell phone the numbers above
| Lars> came out as 218 and 27 an
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Yes, I see the same here. So we have to decide if this is a slow
Lars> down that we can live with. (on the cell phone the numbers above
Lars> came out as 218 and 27 and I got really worried...)
Where does the slowdown come fro
Dekel Tsur <[EMAIL PROTECTED]> writes:
| On Sun, Mar 04, 2001 at 07:58:15PM +0100, Lars Gullik Bjønnes wrote:
| >
| >
| > This patch includes the previous one and adds the same memore saving
| > as with the paragraph parameters, but now also for LyXFont.
| >
| > It raises binary size a bit mor
On Mon, 5 Mar 2001, Dekel Tsur wrote:
[...]
> time lyx -x lyx-quit UserGuide.lyx
Cool! A LyX Benchmark!
Before too long we'll have a complete scripted benchmark and become the
WinStone of the free software world ;-)
Allan. (ARRae)
On Sun, Mar 04, 2001 at 07:58:15PM +0100, Lars Gullik Bjønnes wrote:
>
>
> This patch includes the previous one and adds the same memore saving
> as with the paragraph parameters, but now also for LyXFont.
>
> It raises binary size a bit more than I would like, but the memory
> footprint for Us
This patch includes the previous one and adds the same memore saving
as with the paragraph parameters, but now also for LyXFont.
It raises binary size a bit more than I would like, but the memory
footprint for Userguide is now ~500 Kb.
Comments?
Lgb
diffie
Dekel Tsur <[EMAIL PROTECTED]> writes:
| This patch adds a file "lib/languages_strings" tha contains translations to
| label strings (Figure, Abstract etc.). These translations are used to
| translate the label strings according to the language of the paragraph (no
| need to edit the layout files
This patch adds a file "lib/languages_strings" tha contains translations to
label strings (Figure, Abstract etc.). These translations are used to
translate the label strings according to the language of the paragraph (no
need to edit the layout files!).
Notes:
1. The implementation is not very ef
edscott <[EMAIL PROTECTED]> writes:
| Associated input tex files are created in the tmp directory,
This is only true when you include .lyx files, it is also possible to
include .tex files and they are not copied to the tmp dir.
Lgb
First, I apologize for saying that LyX creates .tex files behind your
back. It does not. I actually created them myself and then
forgot about it (duh). Second, I looked into the code and
found out some more about the spaces problem. Actually, there should be no
problem for LyX files which do not
58 matches
Mail list logo
