I'm reviewing the patch at this ticket:
https://www.lyx.org/trac/ticket/12781
I like its feature and plan to commit it unless there's an objection. See the
screenshot attached to the ticket to quickly understand the feature.
I had a question there about efficiency. Basically, for each functio
On Fri, Mar 20, 2020 at 03:08:20PM +0100, Jean-Marc Lasgouttes wrote:
> Le 20/03/2020 à 14:49, Scott Kostyshak a écrit :
> > > I would say that we don't care, so width() is better since is is shorter
> > > and
> > > easier to understand :)
> >
> > Just to double-check: By width() you mean boundin
Le 20/03/2020 à 14:49, Scott Kostyshak a écrit :
I would say that we don't care, so width() is better since is is shorter and
easier to understand :)
Just to double-check: By width() you mean boundingRect().width(), and
yes
you are saying it is shorter than horizontalAdvance() because we do n
On Fri, Mar 20, 2020 at 10:17:51AM +0100, Jean-Marc Lasgouttes wrote:
> Le 20/03/2020 à 03:41, Scott Kostyshak a écrit :
> > > The entry in the change log hints (from my understanding) that it is a
> > > renaming, but the blog article I linked to suggests things could be more
> > > complicated.
> >
Le 20/03/2020 à 03:41, Scott Kostyshak a écrit :
The entry in the change log hints (from my understanding) that it is a
renaming, but the blog article I linked to suggests things could be more
complicated.
Looking at the code, it does seem to be equivalent:
qreal QFontMetricsF::width(const
> From what I understand, we are indeed writing custom text
> > > shaping/layouting code.
> >
> > Yes, but mostly for the code in GuiFontMetrics.
> >
> > > Attached is a patch. I don't propose to commit this patch; I just attach
> > > it to gi
Fix deprecation warnings from use of qSort() in master at 14f369b4.
Scott
signature.asc
Description: PGP signature
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Tue, Mar 03, 2020 at 02:24:39PM -0500, Scott Kostyshak wrote:
> On Fri, Feb 28, 2020 at 02:35:18PM -0500, Scott Kostyshak wrote:
> > Compiling LyX with Qt 5.14.1 gives deprecation warnings, which breaks
> > compilation of LyX with -Werror. I'm working on a patch to ad
On Thu, Mar 05, 2020 at 12:00:32PM +0100, Pavel Sanda wrote:
> On Tue, Mar 03, 2020 at 08:40:38PM -0500, Scott Kostyshak wrote:
> > When you dereference an iterator, isn't it usually expected to return the
> > object, not a pointer to the object?
>
> It might be we don't use that in lyx codebase,
On Tue, Mar 03, 2020 at 08:40:38PM -0500, Scott Kostyshak wrote:
> When you dereference an iterator, isn't it usually expected to return the
> object, not a pointer to the object?
It might be we don't use that in lyx codebase, but I don't have any particular
expectations for the underlying type.
On Tue, Mar 03, 2020 at 11:32:51PM +0100, Pavel Sanda wrote:
> On Tue, Mar 03, 2020 at 02:24:39PM -0500, Scott Kostyshak wrote:
> > understand what "**it" is, or how it works. Does this mean that somehow
> > a QTreeWidgetItem::operator* is defined or something like that?
>
> Yes, https://doc.qt.i
On Tue, Mar 03, 2020 at 02:24:39PM -0500, Scott Kostyshak wrote:
> understand what "**it" is, or how it works. Does this mean that somehow
> a QTreeWidgetItem::operator* is defined or something like that?
Yes, https://doc.qt.io/qt-5/qtreewidgetitemiterator.html#operator-2a
P
--
lyx-devel mailing
On Fri, Feb 28, 2020 at 02:35:18PM -0500, Scott Kostyshak wrote:
> Compiling LyX with Qt 5.14.1 gives deprecation warnings, which breaks
> compilation of LyX with -Werror. I'm working on a patch to address
> these. I'm sending this message just to avoid duplication of effort in
t; > shaping/layouting code.
>
> Yes, but mostly for the code in GuiFontMetrics.
>
> > Attached is a patch. I don't propose to commit this patch; I just attach
> > it to give an idea of how many replacements are needed and in case
> > someone can check that we do indeed want h
, but mostly for the code in GuiFontMetrics.
Attached is a patch. I don't propose to commit this patch; I just attach
it to give an idea of how many replacements are needed and in case
someone can check that we do indeed want horizontalAdvance() as the
replacement in all cases and not boundin
On Fri, Feb 28, 2020 at 02:35:18PM -0500, Scott Kostyshak wrote:
> Compiling LyX with Qt 5.14.1 gives deprecation warnings, which breaks
> compilation of LyX with -Werror. I'm working on a patch to address
> these. I'm sending this message just to avoid duplication of effort in
Compiling LyX with Qt 5.14.1 gives deprecation warnings, which breaks
compilation of LyX with -Werror. I'm working on a patch to address
these. I'm sending this message just to avoid duplication of effort in
case anyone else comes across these warnings. I'll hopefully finish the
On 12.07.2016 21:23, Georg Baum wrote:
racoon wrote:
On 12.07.2016 14:58, Stephan Witt wrote:
Am 12.07.2016 um 14:20 schrieb racoon :
I really don't like the windows command line.
The native cmd.exe is indeed too limited. IMHO it does not matter whether
you use git via a gui or from comma
racoon wrote:
> On 12.07.2016 14:58, Stephan Witt wrote:
>>
>>> Am 12.07.2016 um 14:20 schrieb racoon :
>>>
>>> I really don't like the windows command line.
The native cmd.exe is indeed too limited. IMHO it does not matter whether
you use git via a gui or from command line. This is to a high de
On 12.07.2016 14:58, Stephan Witt wrote:
Am 12.07.2016 um 14:20 schrieb racoon :
On 12.07.2016 12:20, Guillaume Munch wrote:
[...] patches with detailed commit log are better.
What is a "commit log"?
Honestly, I think most people use git from the command line. It would be
easier for you t
On 07/12/2016 08:20 AM, racoon wrote:
> On 12.07.2016 12:20, Guillaume Munch wrote:
>> [...] patches with detailed commit log are better.
>
> What is a "commit log"?
He just means the message you write when you commit.
>
>> Honestly, I think most people use git from the command line. It would be
> Am 12.07.2016 um 14:20 schrieb racoon :
>
> On 12.07.2016 12:20, Guillaume Munch wrote:
>> [...] patches with detailed commit log are better.
>
> What is a "commit log"?
>
>> Honestly, I think most people use git from the command line. It would be
>> easier for you to find guides on the inter
On 12.07.2016 12:20, Guillaume Munch wrote:
[...] patches with detailed commit log are better.
What is a "commit log"?
Honestly, I think most people use git from the command line. It would be
easier for you to find guides on the internet and for us to help you. In
this case the command is git
Le 12/07/2016 07:11, Daniel a écrit :
Thanks. I think it worked (patch and screenshot of gitk attached).
On 12.07.2016 00:10, Richard Heck wrote:
[...] Then right-click on the commit for which you want to
make the patch.
You will have the option "Make patch". Choose that and then choose where
t
Thanks. I think it worked (patch and screenshot of gitk attached).
On 12.07.2016 00:10, Richard Heck wrote:
[...] Then right-click on the commit for which you want to
make the patch.
You will have the option "Make patch". Choose that and then choose where
to save it.
Should I try to commit the
On 07/11/2016 05:31 PM, Daniel wrote:
> On 11.07.2016 23:04, Richard Heck wrote:
>> On 07/11/2016 03:57 PM, racoon wrote:
>>> Does anyone know how to output a patch with the standard git gui?
>>
>> What is the standard git gui? gitk?
>
> Don't know. I
On 11.07.2016 23:04, Richard Heck wrote:
On 07/11/2016 03:57 PM, racoon wrote:
Does anyone know how to output a patch with the standard git gui?
What is the standard git gui? gitk?
Don't know. It came with git and is called git-gui.exe (screen capture
attached).
Daniel
---
Diese E
On 07/11/2016 03:57 PM, racoon wrote:
> Does anyone know how to output a patch with the standard git gui?
What is the standard git gui? gitk?
Richard
Does anyone know how to output a patch with the standard git gui?
Daniel
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
In Unicode there is a strict convention, for both Hebrew and Arabic:
The character for open braces is the same as in English, and the same with
"close braces", and it mirrored in the display.
** Standard "English" keyboard layout, Shift+9 creates (, ASCII code #41
and Shift+0 creates ), ASCII code
Am 19.03.2012 19:15, schrieb Richard Heck:
Use 'git format-patch' to create patches.
I.e., so something like:
git format-patch HEAD-2
which will give you two patches, corresponding to your last two commits.
Thanks but I don't know where to enter this command. The Git GUI is in German (cannot
On 03/19/2012 03:46 AM, Lars Gullik Bjønnes wrote:
Tommaso Cucinotta writes:
| git show HEAD~2..HEAD> cool.patch
| (assuming your committed patches sit on top of everything else, in
| your local branch)
Use 'git format-patch' to create patches.
I.e., so something like:
git format-pa
Tommaso Cucinotta writes:
| Il 19/03/2012 01:02, Uwe Stöhr ha scritto:
>> As suggested I branched the Git master to develop a new feature. Now
>> I think this feature is now ready and I want to show it on the list
>> but how can I do that?
>>
>> I tried to generat
Il 19/03/2012 01:02, Uwe Stöhr ha scritto:
As suggested I branched the Git master to develop a new feature. Now I
think this feature is now ready and I want to show it on the list but
how can I do that?
I tried to generate a patch from my branch but I only get a success
message and no file
As suggested I branched the Git master to develop a new feature. Now I think this feature is now
ready and I want to show it on the list but how can I do that?
I tried to generate a patch from my branch but I only get a success message and
no file is generated.
I can also not push it to
On 09/24/2011 05:03 PM, Richard Heck wrote:
The solution, I'd think, would be to let users choose what appears in
the TOC under Preferences.
The whole thing, I think, could be done at a lower level of inheritance.
There are many insets that repeat (almost) the same code over and over
again.
I
On Sun, Sep 25, 2011 at 10:44 PM, Jean-Marc Lasgouttes
wrote:
> Why do you need ERT for sweave (just curious) ?
>
I always put the code chunks
<<>>=
2+2
@
in ERT insets: the ERT "environment" makes it much easier to write and
edit code than the Chunk environments (as defined by the module). The
Le 24/09/2011 18:02, Liviu Andronic a écrit :
On Sat, Sep 24, 2011 at 5:58 PM, Julien Rioux
wrote:
Besides, the terminology ERT has dropped out of favour a long time ago.
What should we use instead then? As far as I'm concerned, ERT is the
only term that accurately describes the inset. 'LaTe
On Sat, Sep 24, 2011 at 9:41 PM, Richard Heck wrote:
> I think maybe we commit this for 2.1.0, but only when we've done what
> needs doing in the Preferences.
>
[..]
> But for the rest of us, it is a waste of CPU.
>
This makes sense. I haven't anticipated that this could be creating
performance i
On 09/24/2011 03:03 PM, PhilipPirrip wrote:
>
>> I'm starting to worry a little about how many things are in the TOC,
>> mostly because calculating them may start to get expensive.
>> The solution, I'd think, would be to let users choose what appears in
>> the TOC under Preferences.
>> Richard
>
>
I'm starting to worry a little about how many things are in the TOC,
mostly because calculating them may start to get expensive.
The solution, I'd think, would be to let users choose what appears in
the TOC under Preferences.
Richard
I agree with you, Richard. I took it as an exercize (quite a
On 09/24/2011 12:02 PM, Liviu Andronic wrote:
> On Sat, Sep 24, 2011 at 5:58 PM, Julien Rioux
> wrote:
>> Besides, the terminology ERT has dropped out of favour a long time ago.
>>
> What should we use instead then? As far as I'm concerned, ERT is the
> only term that accurately describes the inse
On Sat, Sep 24, 2011 at 5:58 PM, Julien Rioux
wrote:
> Besides, the terminology ERT has dropped out of favour a long time ago.
>
What should we use instead then? As far as I'm concerned, ERT is the
only term that accurately describes the inset. 'LaTeX code' or 'TeX
code' are inaccurate, since the
On 24/09/2011 5:03 PM, Richard Heck wrote:
It's been suggested we drop "List of". That's worth considering, since
they're all lists.
+1
Besides, the terminology ERT has dropped out of favour a long time ago.
--
Julien
On 09/24/2011 02:40 PM, Liviu Andronic wrote:
Hello Philip
You clearly robbed me of the opportunity to try to provide my first
code-related patch for LyX. But I cannot be too mad: I wouldn't have
pulled it through. :)
Hi Liviu. So, you and I are two rookies trying to find what to patch.
Let's
On Sat, Sep 24, 2011 at 5:03 PM, Richard Heck wrote:
> It's been suggested we drop "List of". That's worth considering, since
> they're all lists.
>
Although it is clearly redundant, I feel that "List of" adds some
clarity to the dropbox list. For users not familiar with these lists,
a dropbox lis
On 09/24/2011 08:40 AM, Liviu Andronic wrote:
> Hello Philip
> You clearly robbed me of the opportunity to try to provide my first
> code-related patch for LyX. But I cannot be too mad: I wouldn't have
> pulled it through. :)
>
> A few suggestions below:
>
>
> 2011/9/24 PhilipPirrip :
>> qt_helpers
Hello Philip
You clearly robbed me of the opportunity to try to provide my first
code-related patch for LyX. But I cannot be too mad: I wouldn't have
pulled it through. :)
A few suggestions below:
2011/9/24 PhilipPirrip :
> qt_helpers.cpp
> Added support for "List of ERT's"
>
I would suggest "Li
Following Richard's suggestion at http://www.lyx.org/trac/ticket/7790,
I've made a few patches regarding some insets in TOC (Document Outline).
Can someone please check, and commit if everything's fine.
InsetERT.cpp (+InsetERT.h)
Added InsetERT::addToToc, mostly by copying from InsetNote.cpp
Mostafa Vahedi wrote:
What is the internal encoding of a LyX file?
UTF8, in any case and whatever encoding is used for LateX. UTF32 (aka
ucs4) is used internally.
Abdel.
Mostafa Vahedi wrote:
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 want
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 dis
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
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 whenever the langua
>> There are two possibilities to support ArabTeX and ARABI together in
>> LyX: 1) to specify which one we would like to use througout the file
>> 2) to specify that we like to use ArabTeX for some part of the file
>> instead of ARABI (note that the other way is not possible)
>>
>> The question i
Mostafa Vahedi wrote:
Mostafa> The question is: which one to use?
You said above that the two packages are fully compatible. Can't we
require both then?
Indeed :) Especially sine most of the arabic support is built
with arabtex in mind, I guess. Unfortunately, I do not have a
good answer to
>> Mostafa> The question is: which one to use?
>
>You said above that the two packages are fully compatible. Can't we
>require both then?
>
>>
>> Indeed :) Especially sine most of the arabic support is built with
>> arabtex in mind, I guess. Unfortunately, I do not have a good answer
>> to this
Jean-Marc Lasgouttes wrote:
"Mostafa" == Mostafa Vahedi <[EMAIL PROTECTED]> writes:
Mostafa> 1) The few fonts defined in ArabTeX are not beautiful and I
Mostafa> don't know of any other fonts can be used with ArabTeX, while
Mostafa> ARABI uses the many free fonts available on the Internet and
> "Mostafa" == Mostafa Vahedi <[EMAIL PROTECTED]> writes:
Mostafa> 1) The few fonts defined in ArabTeX are not beautiful and I
Mostafa> don't know of any other fonts can be used with ArabTeX, while
Mostafa> ARABI uses the many free fonts available on the Internet and
Mostafa> it is possible
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
> I seemed to me that LyX' arabic format was supposed to rely on
> arabtex. Could you comment on the differences between those two
> packages?
> JMarc
1) The few fonts defined in ArabTeX are not beautiful and I don't know of any
other fonts ca
> "Mostafa" == Mostafa Vahedi <[EMAIL PROTECTED]> writes:
>> Mostafa Vahedi wrote: > Two set of changes to "src/Font.cpp" > 1)
>> In Hebrew, Arabic, and Farsi (Right-to-Left) languages the numbers
>> > are written from left to write.
>>
>> I will commit this part as it is obviously correct.
>
Mostafa Vahedi wrote:
Mostafa Vahedi wrote:
Two set of changes to "src/Font.cpp"
1) In Hebrew, Arabic, and Farsi (Right-to-Left) languages the numbers
are written from left to write.
I will commit this part as it is obviously correct.
2) Mixing Farsi & Arabic with english "\textFR{phrase}" an
There are other places with special casing for "hebrew" in the code,
could you please have a look at this Mostafa?
BufferParam::writeLaTeX() line 839:
// language should be a parameter to \documentclass
if (language->babel() == "hebrew"
&& default_language->babel()
> Mostafa Vahedi wrote:
> > Two set of changes to "src/Font.cpp"
> > 1) In Hebrew, Arabic, and Farsi (Right-to-Left) languages the numbers
> > are written from left to write.
>
> I will commit this part as it is obviously correct.
>
> > 2) Mixing Farsi & Arabic with english "\textFR{phrase}" and
Mostafa Vahedi wrote:
Two set of changes to "src/Font.cpp"
1) In Hebrew, Arabic, and Farsi (Right-to-Left) languages the numbers
are written from left to write.
I will commit this part as it is obviously correct.
2) Mixing Farsi & Arabic with english "\textFR{phrase}" and
"\textAR{phrase}" a
Two set of changes to "src/Font.cpp"
1) In Hebrew, Arabic, and Farsi (Right-to-Left) languages the numbers are
written from left to write.
2) Mixing Farsi & Arabic with english "\textFR{phrase}" and "\textAR{phrase}"
are used respectively.
-
8:00? 8:25? 8:40? F
I've figured out what's causing bug 3144 and posted a comment to
bugzilla about it. Someone who knows the code well should now be able to
solve the problem. I don't understand it well enough myself.
Richard
Am Sonntag, 5. Februar 2006 13:51 schrieb Martin Vermeer:
> What's the countdown to 1.4.0?
There is still the problem with the wrongly named preferences file that I
encountered with pre4. And tex2lyx does get installed without the version
suffix, but configure searches for for it with the versio
On Sun, Feb 05, 2006 at 11:59:32AM +0100, Lars Gullik Bjønnes wrote:
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> | > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> |
> | Martin> Yes... and it does fix the most annoying, original bug: those
> | Martin> default langauge blu
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
|
| Martin> Yes... and it does fix the most annoying, original bug: those
| Martin> default langauge bluelines popping up all over the place if
| Martin> the doc language is different.
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Yes... and it does fix the most annoying, original bug: those
Martin> default langauge bluelines popping up all over the place if
Martin> the doc language is different.
Martin> Jean-Marc, Lars? Can this go in?
It is OK with me
On Sat, Feb 04, 2006 at 04:33:35PM +0100, Georg Baum wrote:
> Am Samstag, 4. Februar 2006 09:43 schrieb Martin Vermeer:
> > I gave this patch some testing, and it seems to address what it claims
> > to address, and introduces no new bugs that I could see.
>
> Good.
>
> > I would say, check it in.
Am Samstag, 4. Februar 2006 09:43 schrieb Martin Vermeer:
> I gave this patch some testing, and it seems to address what it claims
> to address, and introduces no new bugs that I could see.
Good.
> I would say, check it in.
Don't you want to do it (+ ChangeLog)? After all, I only picked those
c
On Fri, Feb 03, 2006 at 10:19:45PM +0100, Georg Baum wrote:
> Am Freitag, 3. Februar 2006 10:34 schrieb Martin Vermeer:
> > OK in principle... but could you list in detail which pieces of the
> > patch you want included and which excluded?
>
> Here is the patch. It is IMO safe for 1.4.0, and it fi
On Fri, Feb 03, 2006 at 10:19:45PM +0100, Georg Baum wrote:
> Am Freitag, 3. Februar 2006 10:34 schrieb Martin Vermeer:
> > OK in principle... but could you list in detail which pieces of the
> > patch you want included and which excluded?
>
> Here is the patch. It is IMO safe for 1.4.0, and it fi
Georg Baum wrote:
I also think that something should be done here, but if you read Martins
latest post then you'll see that the current patch makes things better for
tables etc, and worse for quotes and other special characters that are
implemented as an inset.
I see. Quotes, ellipsis and
Am Freitag, 3. Februar 2006 10:34 schrieb Martin Vermeer:
> OK in principle... but could you list in detail which pieces of the
> patch you want included and which excluded?
Here is the patch. It is IMO safe for 1.4.0, and it fixes all language
related problems I could think of except changing la
On Fri, Feb 03, 2006 at 06:27:13PM +0100, Georg Baum wrote:
> Martin Vermeer wrote:
>
> > Hmmm, I think that you are correct. Patched 1.4. applies the "outside"
> > font at an inset to the inset content, and (if I understand you
> > correctly) then writes the change back to the .lyx file on save.
Martin Vermeer wrote:
> Hmmm, I think that you are correct. Patched 1.4. applies the "outside"
> font at an inset to the inset content, and (if I understand you
> correctly) then writes the change back to the .lyx file on save.
> Unacceptable, as a document will look different when loaded the seco
On Fri, Feb 03, 2006 at 04:08:49PM +0100, Jean-Marc Lasgouttes wrote:
> > "Helge" == Helge Hafting <[EMAIL PROTECTED]> writes:
>
> Helge> * Selecting lots of text (that includes insets) and changing
> Helge> the language on the selection has problems.
>
> This a more general problem with fon
On Fri, Feb 03, 2006 at 04:05:11PM +0100, Georg Baum wrote:
> Helge Hafting wrote:
...
> Martins patch fixes this bug for the language case by redefining the
> semantics of font language in insets (correct me if I understood something
> wrong). This is the wrong way IMHO, see the patch in bugzil
On Fri, Feb 03, 2006 at 04:45:46PM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> >> Yes, but how do we determine the value of this parameter? We
> >> basically need a list of insets that need the blue line at the
> >> bottom -> huge switch or
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>> Yes, but how do we determine the value of this parameter? We
>> basically need a list of insets that need the blue line at the
>> bottom -> huge switch or virtual method, or do you see any other
>> possibility?
Martin> This is an ind
Why +2 for insets and +1 for normal text? I'd prefer
Martin Vermeer wrote:
> -void paintForeignMark(double orig_x, LyXFont const & font);
> +void paintForeignMark(double orig_x, LyXFont const & font, int
> desc = 1);
desc = 0);
> -int const y = yo_ + 1;
> +int
> "Helge" == Helge Hafting <[EMAIL PROTECTED]> writes:
Helge> * Selecting lots of text (that includes insets) and changing
Helge> the language on the selection has problems.
This a more general problem with fonts over a selection.
JMarc
Helge Hafting wrote:
> I have no idea of compatibility problems. My problem has always been
> bugs with multilingual files, such as:
>
> * Set the document language to something else than the default language
> configured in lyx. Notice that some insets either have, or seem to
> have, the l
On Fri, 2006-02-03 at 11:28 +0100, Georg Baum wrote:
> Martin Vermeer wrote:
...
> > I did. Quotes etc. indeed do not get underlined with my patch. So it is
> > wrong. A solution might be to give paintForeignMark an additional
> > "descent" parameter and use that to put the line at the right leve
Georg Baum wrote:
Martin Vermeer wrote:
Hmmm. Actually this is straightforwardly fixable. It's just a policy
choice, how we understand noFontChange(). See attached. Only text.C and
rowpainter.C were changed. Works for me... 1.3 does it this way too (in
fact, it has *only* noFontChange-type
uld not be changed, since it is wrong
>> already.
>
> OK in principle... but could you list in detail which pieces of the
> patch you want included and which excluded?
I'll create a patch this evening.
> BTW being both
> bug-compatible with 1.3 and reasonably well behave
On Fri, 2006-02-03 at 09:29 +0100, Georg Baum wrote:
> Martin Vermeer wrote:
>
> > Hmmm. Actually this is straightforwardly fixable. It's just a policy
> > choice, how we understand noFontChange(). See attached. Only text.C and
> > rowpainter.C were changed. Works for me... 1.3 does it this way to
Martin Vermeer wrote:
> Hmmm. Actually this is straightforwardly fixable. It's just a policy
> choice, how we understand noFontChange(). See attached. Only text.C and
> rowpainter.C were changed. Works for me... 1.3 does it this way too (in
> fact, it has *only* noFontChange-type insets; but langu
On Thu, Feb 02, 2006 at 04:56:39PM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Jean-Marc, I think this is the version of reference to review.
> Martin> (Do we still make 1.4.0, or shall we play safe? But it's quite
> Martin> irritat
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Jean-Marc, I think this is the version of reference to review.
Martin> (Do we still make 1.4.0, or shall we play safe? But it's quite
Martin> irritating as it is. Do we want the possible embarrassment or
Martin> the certain annoy
On Thu, 2006-02-02 at 13:47 +0100, Helge Hafting wrote:
> Martin Vermeer wrote:
>
> >Hmmm. Actually this is straightforwardly fixable. It's just a policy
> >choice, how we understand noFontChange(). See attached. Only text.C and
> >rowpainter.C were changed. Works for me... 1.3 does it this way to
Martin Vermeer wrote:
Hmmm. Actually this is straightforwardly fixable. It's just a policy
choice, how we understand noFontChange(). See attached. Only text.C and
rowpainter.C were changed. Works for me... 1.3 does it this way too (in
fact, it has *only* noFontChange-type insets; but language is
On Thu, 2006-02-02 at 11:13 +0100, Helge Hafting wrote:
> Martin Vermeer wrote:
>
> >Attached. Hopefully more luck this time.
> >
> >
> This is much better!
> I have tested with text, footnote, marginal note, branch, ERT, float,
> table and minipage.
> All of them uses correct language now, the
Martin Vermeer wrote:
Attached. Hopefully more luck this time.
This is much better!
I have tested with text, footnote, marginal note, branch, ERT, float,
table and minipage.
All of them uses correct language now, there are no wrong blue lines or L-
cursors.
There is still the smaller issu
On Thu, 2006-02-02 at 00:35 +0100, Helge Hafting wrote:
...
> > Try the above, works for me. Or wait for a *really* carefully produced
> > patch Real Soon Now.
>
> Think I have to wait for that patch, for this didn't change anything at all.
> footnotes, margin notes and table cells still believe
On Wed, Feb 01, 2006 at 07:21:03PM +0200, Martin Vermeer wrote:
>> > Incidentally, applying "bold"
> > works the same way: mark a word bold but not the rest.
> > Then, make a selection that spans the minipage and more.
> > Apply bold - everything is then bold. Revert bold, and everything
> > except
On Wed, Feb 01, 2006 at 04:03:50PM +0100, Helge Hafting wrote:
...
> >Helge, see if you can live with this one.
> >
> >
> Not trying to be difficult, but unfortunately not.
>
> Make a document, set a nondefault document language, type some text.
> Insert a footnote, notice that it gets blue lin
1 - 100 of 163 matches
Mail list logo
