Hi,
I don't know why, but when i try to click on tools->perfences alert window
apears and write in it "unable to find the bind file".
Do you know why?
If you don't know, who did?
Thanks,
Or
--
>
On 1/9/2012 3:03 PM, Jean-Marc Lasgouttes wrote:
> Le 09/01/12 19:19, Rob Oakes a écrit :
>> I've tried to Google the source of this error, but can't figure it. The
>> code compiles fine on Mac OS X, Linux, and 32 bit Windows mingw.
>> Moreover, there are templates for const char *, and char * so I
On 01/09/2012 05:24 PM, Jean-Marc Lasgouttes wrote:
Le 09/01/12 21:08, Tommaso Cucinotta a écrit :
Guess the more-or-less standard behavior is:
-) if all selected text is already emphasized, then de-emphasize it
-) otherwise, emphasize the selected text
I experimented with Word and TextEdit.a
On 01/09/2012 03:08 PM, Tommaso Cucinotta wrote:
Il 09/01/2012 19:46, Guenter Milde ha scritto:
Well, "toggle" emphasis suggests that behavior, doesn't it? But I
agree the
behavior is irritating, and I would not oppose if we change that to
just
"emphasize".
However, I would like to keep it
Le 08/01/12 01:00, José Matos a écrit :
While we are at it, do you know whether fedora ships build of boost
compiled with _GLIBCXX_DEBUG defined? This is what is needed to be
compatible with stdlib-debug.
Where can I find this? In the include files?
Looking into the spec file (that generates t
Le 09/01/12 21:08, Tommaso Cucinotta a écrit :
Guess the more-or-less standard behavior is:
-) if all selected text is already emphasized, then de-emphasize it
-) otherwise, emphasize the selected text
I experimented with Word and TextEdit.app, and the algorithm seems
rather to be: take the f
Le 09/01/12 13:17, Stephan Witt a écrit :
The Mac part is only needed because Qt?Mac respects ligatures. The day this
happens on other architectures (why isn't it the case yet?), we will be in the
same trouble with our paint-strings-but-compute-on-chars approach.
AFAIK it's already on Linux t
Le 09/01/12 19:19, Rob Oakes a écrit :
I've tried to Google the source of this error, but can't figure it. The
code compiles fine on Mac OS X, Linux, and 32 bit Windows mingw.
Moreover, there are templates for const char *, and char * so I don't
understand why it's not happy. The version of gmake
Il 09/01/2012 19:46, Guenter Milde ha scritto:
Well, "toggle" emphasis suggests that behavior, doesn't it? But I agree the
behavior is irritating, and I would not oppose if we change that to just
"emphasize".
However, I would like to keep it toggling instead of a new keybinding to
de-emphasize
On 2012-01-08, Jürgen Spitzmüller wrote:
> Richard Heck wrote:
>> Here's the report:
>>
>> 1. create a new document and write 2 words
>> 2. select the first word and "toggle emphasis"
>> 3. then select both words and "toggle emphasis" again.
>> now the first word isn't emphasised but the se
Dear Developers,
I had a few minutes this morning so I thought that I would try and fix
some bugs related to XHTML output. However, I don't have access to my
normal laptop and was working on a Windows box with a 64 build of Qt
4.8, QtCreator (x64) and the mingw-w64 compiler.
In the process of try
On 01/09/2012 08:16 AM, jri...@lyx.org wrote:
Author: jrioux
Date: Mon Jan 9 14:16:38 2012
New Revision: 40592
URL: http://www.lyx.org/trac/changeset/40592
Log:
Buffer param \cite_engine_type (authoryear|numerical).
To avoid duplicity, remove natbib_authoryear and natbib_numerical
and replace
Am 09.01.2012 um 10:25 schrieb Jean-Marc Lasgouttes:
> Le 08/01/2012 21:51, Abdelrazak Younes a écrit :
It is needed for RTL text and for MacOS correct font rendering.
>>> It certainly _was_ needed. Whether it still is I don't know. What
>>> happens when someone puts some arabic text in a sim
Le 09/01/2012 02:07, Tommaso Cucinotta a écrit :
Hi,
if I split the LyX window (up/down or left/right), and I edit from one
of them, then the cursor on the other view keeps its paragraph and
position numerical values, not really its position, i.e., it is not
anchored to the text where it lies. F
Le 08/01/2012 22:16, Pavel Sanda a écrit :
I just stepped a bit through the code and there were tons of instances
where single characters were passed to drawText, each setting up the
text drawing machinery mostly from scratch. I do understand that this
might be needed for math, but it should not
Le 08/01/2012 21:51, Abdelrazak Younes a écrit :
It is needed for RTL text and for MacOS correct font rendering.
It certainly _was_ needed. Whether it still is I don't know. What
happens when someone puts some arabic text in a simple QTextEdit
on Mac? Are you saying that does not "just work"?
16 matches
Mail list logo
