On Wed, Jun 20, 2007 at 10:00:54PM +0200, Enrico Forestieri wrote:
> On Wed, Jun 20, 2007 at 09:44:12AM +0100, José Matos wrote:
> > On Wednesday 20 June 2007 00:00:06 Enrico Forestieri wrote:
> > > The attached patch fixes it. José, OK to commit?
> >
> > The patch seems right. If you someone t
Edwin Leuven wrote:
Richard Heck wrote:
This patch addresses the usability bugs discussed in this thread:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg121160.html
and largely implements Helge's suggestions. (Helge often seems to have
good ideas on these things.) The main change
Alfredo Braunstein wrote:
Bo Peng wrote:
I don't know Bo, I think that latex_code() is a reasonably efficient way
of having a signature of the math inset (to check if it has changed). I
would be surprised if this had a real performance impact (typically O(1)
operations per user interaction, we
On Fri, Jun 22, 2007 at 08:00:04AM +0200, Edwin Leuven wrote:
> Andre Poenitz wrote:
> >Pretty trivial patch attached.
> >
> >Ok?
>
> can you add a comment?
The feature (inserting a space via lfun) was asked for twice during the
last few weeks. Now that is possible using M-x unicode-insert 0x20.
Andre Poenitz wrote:
Pretty trivial patch attached.
Ok?
can you add a comment?
Pretty trivial patch attached.
Ok?
Andre'
Index: Text3.cpp
===
--- Text3.cpp (revision 18813)
+++ Text3.cpp (working copy)
@@ -973,7 +973,7 @@
docstring hexstring = cmd.argument();
if (lyx::sup
Am 22.06.2007 um 02:22 schrieb Roger Mc Murtrie:
In testing lyx1.5.0rc1 math block problems on a Mac under OSX 10.4,
I have found that starting lyx using src/lyx results in math blocks
not displaying symbols, instead, for example Greek letters display
as English letters with the Greek char
Dov Feldstern schrieb:
and one of them has been supported for
a long time, so suddenly switching to the other and breaking
compatibility with the traditionally supported one doesn't seem right.
As I said we never supported arabTeX directly. So we don't switch to something.
Mostafa, what is yo
In testing lyx1.5.0rc1 math block problems on a Mac under OSX 10.4, I
have found that starting lyx using src/lyx results in math blocks not
displaying symbols, instead, for example Greek letters display as
English letters with the Greek character mu displaying as English m.
However, if I ma
I don't think that bug 3902 should stop you committing your valuable
solution to bug 1942 as, in the Mac case, it provides a considerable
improvement.
I'm not sure that the bug 1942 solution has "introduced" the problem
of bug 3902 but, rather, has provided visibility to bug 1942.
The impr
Uwe Stöhr wrote:
Dov Feldstern schrieb:
To repeat myself: ArabTeX without arabi can't be used due to the
missing babel interface and
ArabTeX is not babel-based, and therefore doesn't require a babel
interface.
But LyX currenly uses babel to handle the different languages. Therefore
arabi
Dov Feldstern schrieb:
To repeat myself: ArabTeX without arabi can't be used due to the
missing babel interface and
ArabTeX is not babel-based, and therefore doesn't require a babel
interface.
But LyX currenly uses babel to handle the different languages. Therefore arabi will be used when L
Uwe Stöhr wrote:
Dov Feldstern schrieb:
So my patch can't break arabTeX as it is already not used.
Correct me when I'm wrong.
see http://permalink.gmane.org/gmane.editors.lyx.devel/88100. If you
follow the instructions there, ArabTeX works perfectly alright in LyX.
You procedure requires a
I'm resending this message, as only about half my emails seem to be
getting through tonight. My apologies if you're receiving it twice...
Uwe Stöhr wrote:
Dov Feldstern schrieb:
I will test this now. But even if it all works, this is *not* OK as it
is --- it breaks ArabTeX Arabic.
I don't u
Dov Feldstern schrieb:
So my patch can't break arabTeX as it is already not used.
Correct me when I'm wrong.
see http://permalink.gmane.org/gmane.editors.lyx.devel/88100. If you
follow the instructions there, ArabTeX works perfectly alright in LyX.
You procedure requires a lot of manual cha
> I have attached the Farsi keyboard based on Linux Farsi keymap which can be
> added to directory "LYX_DEVEL/lib/kbd/". The only problem I have is the last
> line in which I tried to assign a letter to the double quote, i.e. \", and it
> did not work.
" couldn't be mapped because it's reserved f
Uwe Stöhr wrote:
Uwe Stöhr schrieb:
I don't understand. Currently ArabTeX is never loaded by LyX for
Arabic documents so it is also not used.
Bug 2928 is the prove for my statement. Bug 2928 occurs because the \R
command is not defined. But when ArabTeX was loaded \R would have been
defined
Uwe Stöhr schrieb:
I don't understand. Currently ArabTeX is never loaded by LyX for Arabic
documents so it is also not used.
Bug 2928 is the prove for my statement. Bug 2928 occurs because the \R command is not defined. But
when ArabTeX was loaded \R would have been defined. When you load Ara
Uwe Stöhr wrote:
Dov Feldstern schrieb:
I will test this now. But even if it all works, this is *not* OK as it
is --- it breaks ArabTeX Arabic.
I don't understand. Currently ArabTeX is never loaded by LyX for Arabic
documents so it is also not used. My patch requires arabi for both
langua
Dov Feldstern schrieb:
I will test this now. But even if it all works, this is *not* OK as it
is --- it breaks ArabTeX Arabic.
I don't understand. Currently ArabTeX is never loaded by LyX for Arabic documents so it is also not
used. My patch requires arabi for both languages.
To repeat myse
Attached is a patch from Georg that fixes the regression bug 1942:
Inconsistent look of integral symbols.
I tested it thoroughly will all combinations of the packages esint, wasysym,
and amsmath.
A Mac user has reported a perhaps related problem that I and Georg couldn't reproduce as consequ
I will test this now. But even if it all works, this is *not* OK as it
is --- it breaks ArabTeX Arabic. Please see the email I sent earlier
tonight for a patch which separates between arabi and arabtex. This
patch should be implemented over the arabic_arabi language.
I'll get back to you regar
Dov Feldstern schrieb:
I haven't read this entire thread thoroughly yet, but you might want to
see if this specific issue is related to
http://bugzilla.lyx.org/show_bug.cgi?id=3555 (only relevant in mixed
language documents, I think, but I'm not sure...)
We don't have this problem here becau
Mostafa Vahedi schrieb:
But if you put the command "\TOCLanguage{farsi}" then
if you do not put "\selectlanguage{farsi}" as the first
command after the "\begin{document}" or in other words
as an ERT at the first line of the document then you
will receive several complains from LyX about some
und
Attached is a better patch where everything is implemented:
- correct encoding for the fontenc package. Mostafa tested this and gave his OK
for this issue.
- special quotation mark definitions for Farsi. Mostafa tested this and gave
his OK for this issue.
- fix for bug 2929 - use \textAR and
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Andre> Have you checked less direct flights? There still seems to be
Andre> Helsinki-Berlin for available ~100 EUR on Tuesday.
Jean-Marc> I may not understand their site, but they do not tell me on
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>> Looking at the timetables, only Finnair gives me an arrival date
>> of 11h40 on Thursday (which is OK to catch the bus),
Andre> I'll be there at 11:55.
OK.
>> but the return would have to be on monday (12h15) or wednesday.
>>
>> La
Edwin Leuven wrote:
> Alfredo Braunstein wrote:
>> Edwin Leuven wrote:
>>
>>> case 2 is in my opinion not so relevant because i don't see why (in the
>>> current solution) one would have default unchecked and then choose the
>>> explicit alignment that matches default behavior
>>
>> One such cas
Mostafa Vahedi wrote:
Currently (only) Unicode is used for Farsi as the input encoding. Moreover in Unicode the openning parenthesis is always the left one (independent of the language) I have modified the code to reverse the direction of the character-pairs when it wants to display the characters
Alfredo Braunstein wrote:
Edwin Leuven wrote:
case 2 is in my opinion not so relevant because i don't see why (in the
current solution) one would have default unchecked and then choose the
explicit alignment that matches default behavior
One such cases: I'm in Standard Layout and I want my pa
Uwe Stöhr wrote:
Actually, Mostafa has fixed the last *two* issues for Farsi, but not
for Arabic, so as not to interfere with ArabTex. But at least the
know-how is already in the sources. We only need to figure out how to
allow the option of either Arabi or ArabTeX, so that one doesn't break
Edwin Leuven wrote:
> case 2 is in my opinion not so relevant because i don't see why (in the
> current solution) one would have default unchecked and then choose the
> explicit alignment that matches default behavior
One such cases: I'm in Standard Layout and I want my par centered so I set
it e
:-) You patch seems to work but I do not really understand what is
going on. Could you explain a bit?
Sure, the standalone notifyCursorLeaves calls
Inset::notifyCursorLeaves of
all insets in the cursor stack; so this catches the parent
MathHullInset.
I was about to write such a function, on
if i creat a selection that spans more than one line and then type
something (so that the selection gets replace with my new text), the
selection before the line where cursor is isn't crossed out. there is a
missing screen update here.
second thing is when i delete a collapsed footnote. the c
Richard Heck wrote:
This patch addresses the usability bugs discussed in this thread:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg121160.html
and largely implements Helge's suggestions. (Helge often seems to have
good ideas on these things.) The main change is that the "Default"
b
Uwe Stöhr wrote:
Mostafa Vahedi schrieb:
> See the attached patch. I implemented this but disabled it because
> \TOCLanguage gives me the error
> "unknown command". Therefore your example-lyxified doesn't compile.
The command "\TOCLanguage{}" is defined after the call to BABEL in
Latex Pre
Alfredo Braunstein wrote:
This is bad. What if the user changes layout (or worse document class) and
the new layout has different default alignment? You are losing information
here.
ah, i see the problem now.
there seem to be 2 problem cases:
1 x is set and we change the default to x:
2 x (de
Bo Peng wrote:
>> I don't know Bo, I think that latex_code() is a reasonably efficient way
>> of having a signature of the math inset (to check if it has changed). I
>> would be surprised if this had a real performance impact (typically O(1)
>> operations per user interaction, we do much worse els
On Tue, Jun 19, 2007 at 06:15:24PM +0200, Jean-Marc Lasgouttes wrote:
> > "christian" == christian ridderstrom <[EMAIL PROTECTED]> writes:
>
> christian> On Mon, 18 Jun 2007, Andre Poenitz wrote:
> >> Now that I was too stupid to get my booking right the first time, I
> >> again have a choice
I don't know Bo, I think that latex_code() is a reasonably efficient way of
having a signature of the math inset (to check if it has changed). I would
be surprised if this had a real performance impact (typically O(1)
operations per user interaction, we do much worse elsewhere in the code)
OK. D
That's a great usability improvement!
+1
Bo
Bo Peng wrote:
>> You patch seems to work but I do not really understand what is
>> going on. Could you explain a bit?
>
> I found this notifyCursorLeaves(old, new) function and see what is
> going on. If Abdel does not see any side effect of calling too many
> notifyCursorLeaves, your patch has
Richard Heck wrote:
This patch addresses the usability bugs discussed in this thread:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg121160.html
and largely implements Helge's suggestions. (Helge often seems to have
good ideas on these things.) The main change is that the "Default"
> Have you fixed 1486 yet. Jose has Oked it so you can commit now,
> please remember to close the bug as well.
I don't have commit rights yet. Could you do that for me?
I will do that.
Sure, the standalone notifyCursorLeaves calls Inset::notifyCursorLeaves of
all insets in the cursor stack; s
You patch seems to work but I do not really understand what is
going on. Could you explain a bit?
I found this notifyCursorLeaves(old, new) function and see what is
going on. If Abdel does not see any side effect of calling too many
notifyCursorLeaves, your patch has my OK.
I, starting from the
Bo Peng wrote:
>> The following fix (based on your nice explanation) seems to cure the
>> problem without major rearrangements, but I didn't tested it well.
>
> Have you fixed 1486 yet. Jose has Oked it so you can commit now,
> please remember to close the bug as well.
I don't have commit rights
The following fix (based on your nice explanation) seems to cure the problem
without major rearrangements, but I didn't tested it well.
Have you fixed 1486 yet. Jose has Oked it so you can commit now,
please remember to close the bug as well.
It is amazing that you can always find better fixes
i think frac can go (as in attached) since there are only 2 entries
which are already on the main math toolbar
gonna commit unless someone objects
...
something else entirely:
the panels can be easily added to the toolbar list by putting the
following in default.ui:
"latex_deco" "
On Jun 21, 2007, at 17:28 , Richard Heck wrote:
Anders Ekberg wrote:
On 21 jun 2007, at 13.12, Helge Hafting wrote:
Bennett Helm wrote:
It shouldn't be a radio button just like the others, since it's
not an option in the way that the others are.
Sorry, but I consider that a bad argument. Sur
Bo Peng wrote:
> The problem with bug 3903
> (http://bugzilla.lyx.org/show_bug.cgi?id=3903) is clear, there is no
> notifyCursorLeave when you are not in an InsetMathHull (the outer
> level of the inset). Therefore, after you edit in, for example, super
> or subscript, math preview is not updated.
Bo Peng wrote:
This is the unfinished part. Numerous LFUNC can contaminate an
inset, what is the best way to know if an inset is modified? I am
thinking of doing an markDiry after each recordUndo, but there are too
many recordUndo's. Is there any way to know if recordUndo() is called?
Why don
Bennett Helm wrote:
> On Jun 21, 2007, at 11:38 AM, Edwin Leuven wrote:
>
>> and this one doesn't make sense:
>>
>> if we could tell beforehand what the default was because then we
>> could show something like:
>>
>> o Justified (default)
>> o Left
>> o Center
>> o Right
>>
>>
>> ?
>>
>
> Of the
This patch addresses the usability bugs discussed in this thread:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg121160.html
and largely implements Helge's suggestions. (Helge often seems to have
good ideas on these things.) The main change is that the "Default"
button is now a radio
Bennett Helm wrote:
On Jun 21, 2007, at 11:38 AM, Edwin Leuven wrote:
and this one doesn't make sense:
if we could tell beforehand what the default was because then we
could show something like:
o Justified (default)
o Left
o Center
o Right
?
Of the options I've seen, I agree that this is th
The problem with bug 3903
(http://bugzilla.lyx.org/show_bug.cgi?id=3903) is clear, there is no
notifyCursorLeave when you are not in an InsetMathHull (the outer
level of the inset). Therefore, after you edit in, for example, super
or subscript, math preview is not updated.
There is another proble
On Jun 21, 2007, at 11:38 AM, Edwin Leuven wrote:
and this one doesn't make sense:
if we could tell beforehand what the default was because then we
could show something like:
o Justified (default)
o Left
o Center
o Right
?
Of the options I've seen, I agree that this is the best.
Benne
and this one doesn't make sense:
if we could tell beforehand what the default was because then we could
show something like:
o Justified (default)
o Left
o Center
o Right
?
> When editing a nested element in an math inset and clicking outside
> the complete formula the preview never (not slowly, never) gets
> updated. But this is so far the only case where I can really
> reproduce it.
This is now bug 3903.
Bo
Anders Ekberg wrote:
On 21 jun 2007, at 13.12, Helge Hafting wrote:
Bennett Helm wrote:
It shouldn't be a radio button just like the others, since it's not
an option in the way that the others are.
Sorry, but I consider that a bad argument. Sure, "default" is a bit
different. That does NOT imp
On 21 jun 2007, at 13.12, Helge Hafting wrote:
Bennett Helm wrote:
It shouldn't be a radio button just like the others, since it's
not an option in the way that the others are.
Sorry, but I consider that a bad argument. Sure, "default" is a bit
different. That does NOT imply it can't be a ra
> Maybe I am lacking an icon?
There should be an icon. And then Qt renders it small AFAIK. Have you
updated your resource folder?
I have added closetab.xmp to scons_manifest.py.
Cheers,
Bo
Bob Alvarez wrote:
I hope this is the right place to send this.
You can post such things at bugzilla.lyx.org, but I've added a note to
2714 about it, so no need now.
I usually do not want to start a new paragraph after a display
equation, so I have been setting the next paragraph to \noindent
Am 21.06.2007 um 16:16 schrieb Bo Peng:
New doc1 | New doc2 | | Close |
My close button is huge here, please correct it. This is qt422, linux.
Maybe I am lacking an icon?
Cheers,
Bo
There should be an icon. And then Qt renders it small AFAIK. Have you
updated your resource fold
New doc1 | New doc2 | | Close |
My close button is huge here, please correct it. This is qt422, linux.
Maybe I am lacking an icon?
Cheers,
Bo
On Thursday 21 June 2007 14:36:33 Bo Peng wrote:
> Anyway, your patch fixes this specific problem with less code, so it can go
> in.
>
> Cheers,
> Bo
OK.
--
José Abílio
Helge Hafting wrote:
> The problem is solved. I had a custom makeindex script in order to
> support index styles and still use indexes from within lyx-1.3
> This script did not work with glossaries though. Removing it
> fixed everything.
You know that you can customize the makeindex call now in
I wonder if there is any side-effect of using something like the attached
instead.
Your patch is better, so you have my OK.
My original thought was to remove outside addPreview so that all
MathHull (and other previewable insets) get their preview in this way
(if preview empty, add snippet). I m
Same problem here:
When editing a nested element in an math inset and clicking outside
the complete formula the preview never (not slowly, never) gets
updated. But this is so far the only case where I can really
reproduce it.
Please file a bugzilla report about it since Jose dictated that every
Stefan Schimanski wrote:
> This is a critical bug for quite some time in bugzilla without a
> clear explanation what the problem is. I added this now as a comment.
> It has not much to do with the source view, but with encoding changes
> in general, also during TeX export. You basically cannot exp
On 20.06.2007, at 23:30, Bernhard Roider wrote:
Bo Peng schrieb:
On 6/20/07, Neal Becker <[EMAIL PROTECTED]> wrote:
1.50rc1
When I edit math, previews don't update until I fiddle around a bit.
1. Edit math
2. Click outside math - no update
3. Click inside math again
4. Click outside math aga
Helge Hafting wrote:
I discovered another bug while trying to get nomencl.sty to work for me.
(The latter may be a latex problem - I get no glossary whatsoever,
but no error message either.)
The glossary problem is now solved (bad local makeindex)
but the .aux problem remains.
The rater annoy
Georg Baum wrote:
Helge Hafting wrote:
I noticed the glossary stuff while translating.
Inserting a few entries as well as a glossary don't
do anything though. No errors - and no glossary.
This should not happen. Glossaries are supposed to work.
I exported the file to tex, and ra
Mostafa Vahedi schrieb:
OK. So which way are we going to follow? The manual one or
the other one?
The automatic one if possible.
I tested, but it doesn't work for me,
no matter where I call \TOCLanguage.
We should load the babel package this way:
"\usepackage[farsi,arabic,english]{babel
I discovered another bug while trying to get nomencl.sty to work for me.
(The latter may be a latex problem - I get no glossary whatsoever,
but no error message either.)
The rater annoying error is that I get latex compile errors whenever
I change the document language!
I.e. view->dvi once, chan
6)(One other bug!). We should add the command
"\selectlanguage{farsi}" as an ERT as the first
line of the
document.
>>> I can see no difference. With and without the
>>> ERT command, the result is identical.
>> I checked this issue after applying the patches.
>> Still I ha
Bennett Helm wrote:
It shouldn't be a radio button just like the others, since it's not an
option in the way that the others are.
Sorry, but I consider that a bad argument. Sure, "default" is a bit
different. That does NOT imply it can't be a radio button like the rest.
To me, "default" mean
Neal Becker wrote:
Actually, it's not table. If I put the cursor anywhere in the document, I
have the same result. All the options for alignment are greyed out, and
default is checked.
Uncheck default then.
Default sets the alignment to whatever is preferred for
the paragraph type in questi
>> Mostafa Vahedi schrieb:
>> I can not give any guarantee about the fix. The author
>> is extermely busy sometimes. I prefer the manual one for
>> the time being. Then if it stays more we can do something
>> about it. I have submitted many bug fixes to the author
>> and I am waiting for his
Mostafa Vahedi schrieb:
I can not give any guarantee about the fix. The author is extermely busy
sometimes. I prefer the manual one for the time being. Then if it stays
more we can do something about it. I have submitted many bug fixes to
the author and I am waiting for his reply.
OK, but th
Alfredo wrote:
>> Edwin Leuven wrote:
>> unless someone shouts out i am gonna put this in by noon tomorrow (thu 21)
>
> (shouting) You have my ok :-)
enjoy:
http://www.lyx.org/trac/changeset/18842
6) (One other bug!). We should add the command
"\selectlanguage{farsi}" as an ERT as the first line of the
document.
>>> No need for this. When the document language is Farsi, no switch is
>>> needed. For later switches, this
>>> is currently correctly done by LyX.
>> Agai
May I point you to http://bugzilla.lyx.org/show_bug.cgi?id=3561 again?
This is a critical bug for quite some time in bugzilla without a
clear explanation what the problem is. I added this now as a comment.
It has not much to do with the source view, but with encoding changes
in general, als
Bo Peng wrote:
>> Waiting for two OKs.
>
> Please use this version.
I wonder if there is any side-effect of using something like the attached
instead.
A/
Index: InsetMathHull.cpp
===
--- InsetMathHull.cpp (revision 18837)
+++ Inse
Bennett Helm wrote:
X Default
o Justified
o Left
o Center
o Right
maybe giving the choice between "default" or "environment default" and
"custom" or "force" makes it more explicit?
o Default
o Custom
o Justified
o Left
o Center
o Right
it would of course be nicer if we could
2) Due to the current bugs or limitations of the ARABI package
whenever we want to use Farsi we should use Arabic too (because
some of the
shared definitions are defined in Arabic definitions files only).
Moreover Farsi should be called before Arabic. Again there are tw
85 matches
Mail list logo
