Guenter Milde wrote:
> (besides the
> impossibility to mark inline text as LyX code).
Document > Settings > Modules > Logical Markup
Edit > Text Style > Code.
Jürgen
On 03/01/2010 07:07 AM, John McCabe-Dansted wrote:
On Sun, Feb 28, 2010 at 6:51 PM, John McCabe-Dansted wrote:
On Sun, Feb 28, 2010 at 6:46 PM, Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Hum, I'd prefer that you create a new Language model for the Buffer;
accessible
Guenter Milde wrote:
> While this is the "reine Lehre", it is often impractical (besides the
> impossibility to mark inline text as LyX code).
>
> * Quite a lot of acronyms are international and will not be hyphenated
> anyway.
Not true. Acronyms are language-dependent (cf. IPA vs. API). The
On 2010-03-01, Jürgen Spitzmüller wrote:
> Guenter Milde wrote:
>> But this is just one side. A filename, a C command or some Acronym in a
>> Greek document do not gain from beeing marked as another language but
>> still should keep Latin letters as such!
> Then, the user should still mark the cod
Guenter Milde wrote:
> But this is just one side. A filename, a C command or some Acronym in a
> Greek document do not gain from beeing marked as another language but
> still should keep Latin letters as such!
Then, the user should still mark the code semantically (as LyX code or
whatever), and t
Guenter Milde wrote:
> It is a feature that dates back to pre-Unicode times (actually even back
> to 7bit ASCII times). It is still handy for the occasional Greek quote
> for people without Greek keyboard, but stands in the way for others.
>
> This is why this feature should be optional.
I disag
On Sun, Feb 28, 2010 at 6:51 PM, John McCabe-Dansted wrote:
> On Sun, Feb 28, 2010 at 6:46 PM, Jürgen Spitzmüller wrote:
>> Abdelrazak Younes wrote:
>>> Hum, I'd prefer that you create a new Language model for the Buffer;
>>> accessible through GuiWorkArea::languageModel() or even better through
On Sun, 2010-02-28 at 23:47 +, Liviu Andronic wrote:
> Hello
>
> On 2/28/10, Νίκος Αλεξανδρής wrote:
> > I read almost all of the posts in http://www.mail-archive.com. I will
> > eventually register myself in lyx-dev but dunno if its worth it for only
> > one thread.
> >
> You could regist
Hello
On 2/28/10, Νίκος Αλεξανδρής wrote:
> I read almost all of the posts in http://www.mail-archive.com. I will
> eventually register myself in lyx-dev but dunno if its worth it for only
> one thread.
>
You could register for the thread, and unsubscribe when it's done.
Liviu
On 2010-02-28, Vincent van Ravesteijn - TNW wrote:
> I think we should output \textlatin for the latin characters as we do
> with \textgreek for greek characters.
I thought about this once, but this would make Greek even more the odd
one out, because e.g. Cyrillic does not work this way:
> Langu
On 2010-02-28, Jürgen Spitzmüller wrote:
> Vincent van Ravesteijn - TNW wrote:
>> Yes, that's exactly the point. If there are latin characters on screen
>> in LyX, we don't want to have greek letters appearing in the output
>> right ?
> No. If I use the transliteration, I want exactly this.
>> E
On 2010-02-28, Vincent van Ravesteijn - TNW wrote:
>>Vincent van Ravesteijn - TNW wrote:
>>> This is my interpretation of the problem: unexpected output of greek
>>> characters while there are latin characters on screen.
Yes, this is the OP's problem. Maybe it should rather be named: words
using
Hereby I grant permission to license my contributions to
LyX under the GNU General Public License, version 2 or later.
Ulysse Danglis
Vincent van Ravesteijn - TNW wrote:
> So, we show the characters in greek also on screen. That seems the best way
> to communicate to the user that these characters will be converted.
OK.
Jürgen
>Vincent van Ravesteijn - TNW wrote:
>> This is my interpretation of the problem: unexpected output of greek
>> characters while there are latin characters on screen.
>
>Which I would judge an information deficit. We should communicate better
>why languages need to be marked in LyX (and why this i
Folks,
I am glad to do some testing. I did not receive any further posts of
yours since I am not a member of lyx-dev (only registered in lyx-user).
This is why I did not reply yet.
I read almost all of the posts in http://www.mail-archive.com. I will
eventually register myself in lyx-dev but dunn
>Hi Abdel,
More bugs:
* Document Settings->Float Placement is a little bit broken, because it
reused the existing FloatPlacement widget, but now there is no Float
type set etc.
* Changing of float type does not work if you 'edit' a subfloat. If you
change the outer float, the subfloat is corre
Vincent van Ravesteijn - TNW wrote:
> This is my interpretation of the problem: unexpected output of greek
> characters while there are latin characters on screen.
Which I would judge an information deficit. We should communicate better why
languages need to be marked in LyX (and why this is a go
Jürgen Spitzmüller wrote:
> As I see it, the user wants a quick way to switch between two commonly
> used languages (a good shortcut for "language greek" and "language
> english" or bind that functions to the action Greek users perform to
> switch between English and Greek, if any).
I think the p
Hi Abdel,
the feature to change the float type is really cool! The only missing feature in this field is to
change the float type also from
table -> wrap table
warp graphics -> graphics
etc. But we need that have some work left for LyX 2.1 ;-).
Besides this, wouldn't it be good to have the flo
>> (Strange feature. The fact that this can be done in LaTeX is not a
>> valid reason to be the default behaviour of LyX. We could support this
>> of
>> course.)
>
>Why strange? It's a straighforward way to typeset Greek on a latin keyboard.
>
Now you speak of an input method, so in that case
Vincent van Ravesteijn - TNW wrote:
> Yes, that's exactly the point. If there are latin characters on screen in
> LyX, we don't want to have greek letters appearing in the output right ?
No. If I use the transliteration, I want exactly this.
> Even though the latin characters are marked as greek
Vincent van Ravesteijn - TNW wrote:
> (Strange feature. The fact that this can be done in LaTeX is not a valid
> reason to be the default behaviour of LyX. We could support this of
> course.)
Why strange? It's a straighforward way to typeset Greek on a latin keyboard.
Jürgen
> Or is this a feature ?
Apparently it is, reading your other mail.
(Strange feature. The fact that this can be done in LaTeX is not a valid reason
to be the default behaviour of LyX. We could support this of course.)
Vincent
>> Is this ok ?
>
>Note that \textlatin will only switch the font encoding, not the language.
>So \textlatin{text} on a Greek context will not input English text into
>Greek, but roman characters (the same is true for \textgreek in latin
>context;
Yes, that's exactly the point. If there are latin
Jürgen Spitzmüller wrote:
> Note that \textlatin will only switch the font encoding, not the language.
> So \textlatin{text} on a Greek context will not input English text into
> Greek, but roman characters (the same is true for \textgreek in latin
> context; that's why people who really want to w
Vincent van Ravesteijn - TNW wrote:
> If we know what the solution is, the implementation is straightforward I
> guess.
>
> I think we should output \textlatin for the latin characters as we do with
> \textgreek for greek characters.
>
> Language English:
> \textcyr{\char254} \textgreek{a
On Sun, 2010-02-28 at 02:33 +0100, Νίκος Αλεξανδρής wrote:
>
> The (only) problem which I face is the use of hyperref. It seems that
> there is a bug! The produced links in the pdf don't appear "Greek" (as
> they should and the use of the "unicode=true" option does not seem to
> work at all. I've
Nikos:
> >Are you interested in this feature as an end-user or as
> >a developer, if I may ask?
Vincent van Ravesteijn:
> I'm afraid that would be as a developer.
Well, I was hopping so (that you are a dev and not that you are
afraid ;-).
> >I would like to know if there is any dev out there who
>Hi Vincent!
>
>
>Are you interested in this feature as an end-user or as
>a developer, if I may ask?
I'm afraid that would be as a developer.
>I would like to know if there is any dev out there who
>is interested to cover this gap and get payed for it
>(+ having the coding pleasure which can't
On Saturday 27 February 2010 01:55:33 pm Vincent van Ravesteijn - TNW
wrote:
>> >Thanks a lot! This feature doesn't show up yet in the context menu
>>
>> though.
>>
>> It does for me.
>>
>> Vincent
>
>I just don't see the context menu options in eqnarray:
Me neither, but you didn't tell me you wer
On Saturday 27 February 2010 01:55:33 pm Vincent van Ravesteijn - TNW wrote:
> >Thanks a lot! This feature doesn't show up yet in the context menu
>
> though.
>
> It does for me.
>
> Vincent
I just don't see the context menu options in eqnarray: I see it for a
text-mode table. I see these opti
John McCabe-Dansted wrote:
> OK, I'm a little confused. We seem to use three types of language lists:
>
> 1) ./Language.h:typedef std::map
> LanguageList; 2) ./LaTeXFeatures.h: typedef std::set
> LanguageList; 3) void Buffer::getLanguages(std::set &
> languages) const
>
> 2 and 3 are ba
On Sun, Feb 28, 2010 at 6:36 PM, Abdelrazak Younes wrote:
> Hum, I'd prefer that you create a new Language model for the Buffer;
> accessible through GuiWorkArea::languageModel() or even better through
> GuiApplication::languageModel(Buffer * buf).
> Then sorting would be a matter of using QAbstra
On 28/02/2010 11:51, John McCabe-Dansted wrote:
On Sun, Feb 28, 2010 at 6:46 PM, Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
Hum, I'd prefer that you create a new Language model for the Buffer;
accessible through GuiWorkArea::languageModel() or even better through
GuiApplicati
On Sun, Feb 28, 2010 at 6:46 PM, Jürgen Spitzmüller wrote:
> Abdelrazak Younes wrote:
>> Hum, I'd prefer that you create a new Language model for the Buffer;
>> accessible through GuiWorkArea::languageModel() or even better through
>> GuiApplication::languageModel(Buffer * buf).
>> Then sorting wo
Abdelrazak Younes wrote:
> Hum, I'd prefer that you create a new Language model for the Buffer;
> accessible through GuiWorkArea::languageModel() or even better through
> GuiApplication::languageModel(Buffer * buf).
> Then sorting would be a matter of using QAbstractItemModel::sort() and
> this
Abdelrazak Younes wrote:
> Hum, yes, you have a point here. But my proposal would work reliably for
> two languages using two different unicode ranges like a latin one and
> Chinese or Japanese or Arabic, etc.
Yes, but for these, a proper input method framework (as outlined by Günther)
would wo
On 28/02/2010 11:31, Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
As Vincent already explained the idea would be to optionally define a
second (and maybe third) language for the document. The rule to
automatically set the language would be:
- first to check the unicode range: that woul
On 28/02/2010 11:06, sp...@lyx.org wrote:
Author: spitz
Date: Sun Feb 28 11:06:05 2010
New Revision: 33590
URL: http://www.lyx.org/trac/changeset/33590
Log:
" Menus.cpp: sort languages. Based on a patch by John McCabe-Dansted.
Modified:
lyx-devel/trunk/src/frontends/qt4/Menus.cpp
Modified:
Vincent van Ravesteijn wrote:
> For example, when I enter japanese, I get in
> my LaTeX if I don't mark it explicitly to japanese. Instead, can't we
> just set the language to some default language for which this character
> is encodable.
There is no such thing like a "default" language for a
Abdelrazak Younes wrote:
> As Vincent already explained the idea would be to optionally define a
> second (and maybe third) language for the document. The rule to
> automatically set the language would be:
> - first to check the unicode range: that would work when the two
> languages use two dif
On 27/02/2010 16:45, Guenter Milde wrote:
On 2010-02-27, Vincent van Ravesteijn wrote:
Νίκος Αλεξανδρής schreef:
Would it be possible to set the language automatically when recognizing
a certain unicode range ?
While possible, it is ambiguous (and therefore not helpful):
*
Jürgen Spitzmüller wrote:
> John McCabe-Dansted wrote:
> > OK, I have attached the patch
> >
> > Menus.cpp_sortLanguageByName.patch
> >
> > that implements
> >
> > "Sort the language selector submenu by name"
> >
> >
> > Does this look OK?
>
> Yes, it looks good.
But it did not work correctl
Richard Heck wrote:
> I was worried that we were eating too many characters, if we only have
> 25 (was it?) for the label. It can obviously be changed back.
Please don't change it for branch. It only generates translation work (for the
sake of one saved character).
> I guess if I should finish
John McCabe-Dansted wrote:
> OK, I have attached the patch
> Menus.cpp_sortLanguageByName.patch
> that implements
> "Sort the language selector submenu by name"
>
> Does this look OK?
Yes, it looks good.
> > I prefer the session approach. I often use languages for which I do not
> > have a s
46 matches
Mail list logo
