gt; files have not been available for several years and edit Makefile.am to
> reflect this change
Thanks John.
I am not going to apply this patch, because removing the layout might break
the old documents. In the long term we might want some attic or flag so we
don't offer these layouts fo
From 673a7b1786ecaea775d10ad9751a8630ab844b10 Mon Sep 17 00:00:00 2001
From: John R Hudson
Date: Wed, 4 Jan 2023 12:08:23 +
Subject: [PATCH] Delete iopart, kluwer and svjog layouts as the relevant cls
files have not been available for several years and edit Makefile.am to
reflect this
On Fri, Dec 02, 2022 at 02:45:17PM -0500, Richard Kimberly Heck wrote:
> On 12/2/22 14:33, Scott Kostyshak wrote:
> > Would it make sense to change these to "Edit Externally" ? Or is that too
> > verbose?
>
> I think that's fine, and makes sense.
Thanks, done
On 12/2/22 14:33, Scott Kostyshak wrote:
Would it make sense to change these to "Edit Externally" ? Or is that too
verbose?
I think that's fine, and makes sense.
Riki
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Would it make sense to change these to "Edit Externally" ? Or is that too
verbose?
The reason I ask is that "Edit" is not so clear if you don't already
know what it does. One might think that they need to click edit to
change the current contents (in LyX's editor)
ackexchange.com/questions/45301/in-lyx-is-there-a-way-to-toggle-the-display-of-tex-code-in-math-expressions/46328#46328
> >
> > I don't know anything about how LyX stores math in memory, but in the
> > file format if I remember correctly we essentially store LaTeX. Does
&
don't know anything about how LyX stores math in memory, but in the
file format if I remember correctly we essentially store LaTeX. Does
this mean we could allow "Edit externally" for math insets?
It would be pretty simple to do, I think. And probably useful in some
cases. But I&#
28
I don't know anything about how LyX stores math in memory, but in the
file format if I remember correctly we essentially store LaTeX. Does
this mean we could allow "Edit externally" for math insets?
Scott
Up to my limited understanding of this, Lyx internally stores math in
n
es math in memory, but in the
file format if I remember correctly we essentially store LaTeX. Does
this mean we could allow "Edit externally" for math insets?
Scott
signature.asc
Description: PGP signature
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On 12/6/20 3:35 PM, Jean-Marc Lasgouttes wrote:
> Le 06/12/2020 à 19:40, Richard Kimberly Heck a écrit :
>>> For example, suppose I do:
>>>
>>> 1. write "abc" outside an inset (just to have something to undo *to*).
>>> 2. edit an inset externally.
Le 06/12/2020 à 19:40, Richard Kimberly Heck a écrit :
For example, suppose I do:
1. write "abc" outside an inset (just to have something to undo *to*).
2. edit an inset externally.
3. without ending the external edit, do "undo".
4. now go to the text editor that opene
ested and works well!
One other thing I'm thinking about is: how should things work with undo?
For example, suppose I do:
1. write "abc" outside an inset (just to have something to undo *to*).
2. edit an inset externally.
3. without ending the external edit, do "undo".
4.
rks well!
One other thing I'm thinking about is: how should things work with undo?
For example, suppose I do:
1. write "abc" outside an inset (just to have something to undo *to*).
2. edit an inset externally.
3. without ending the external edit, do "undo".
4. now go to the
On 12/6/20 9:21 AM, Scott Kostyshak wrote:
>
> Strange, I still don't see the lock. Which commit fixed this?
Actually, I forgot to commit that! Should be fixed now.
Riki
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
gt;> Yes, I think this is the case I had in mind that requires manual
>>>>>> unlocking.
>>>>>> For the other case, I had in mind some version where you open the file in
>>>>>> one editor, then somehow open it again in another one and clos
I had in mind some version where you open the file in
> >>>> one editor, then somehow open it again in another one and close the
> >>>> original. Then I wouldn't want to unlock. But maybe that's also a weird
> >>>> case.
> >>> Inter
ion where you open the file in
>>>> one editor, then somehow open it again in another one and close the
>>>> original. Then I wouldn't want to unlock. But maybe that's also a weird
>>>> case.
>>> Interesting, I didn't think of that sit
ldn't want to unlock. But maybe that's also a weird
> >> case.
> > Interesting, I didn't think of that situation. Maybe the user would
> > indeed try to do that if the file didn't open in their preferred editor
> > if they're not sure how to chang
On 12/2/20 12:11 PM, Scott Kostyshak wrote:
> On Wed, Dec 02, 2020 at 11:56:26AM -0500, Richard Kimberly Heck wrote:
>> On 12/2/20 11:13 AM, Scott Kostyshak wrote:
>>> On Wed, Dec 02, 2020 at 10:56:16AM -0500, Richard Kimberly Heck wrote:
On 12/2/20 10:46 AM, Scott Kostyshak wrote:
> I jus
On Wed, Dec 02, 2020 at 11:56:26AM -0500, Richard Kimberly Heck wrote:
> On 12/2/20 11:13 AM, Scott Kostyshak wrote:
> > On Wed, Dec 02, 2020 at 10:56:16AM -0500, Richard Kimberly Heck wrote:
> > > On 12/2/20 10:46 AM, Scott Kostyshak wrote:
> > > > I just remembered this feature exists and it is f
On 12/2/20 11:13 AM, Scott Kostyshak wrote:
On Wed, Dec 02, 2020 at 10:56:16AM -0500, Richard Kimberly Heck wrote:
On 12/2/20 10:46 AM, Scott Kostyshak wrote:
I just remembered this feature exists and it is fun to test it. I have a
few questions/comments:
1. After I exit my text editor, should
erhaps
> > we could grey it out somehow, and/or put a "lock" symbol on the inset
> > label.
>
> Yes, that's an excellent idea!
>
>
> > 3. There are problems when the inset has arguments. For example, open
> > the file 'lib/examples/Modules
t out somehow, and/or put a "lock" symbol on the inset
label.
Yes, that's an excellent idea!
3. There are problems when the inset has arguments. For example, open
the file 'lib/examples/Modules/Rnw_%28knitr%29.lyx'. Edit something
in the chunk inset, save,
".
2. It might be nice to show visually that the inset is "locked". Perhaps
we could grey it out somehow, and/or put a "lock" symbol on the inset
label.
3. There are problems when the inset has arguments. For example, open
the file 'lib/examples/Modules/Rnw_%28
FYI, I just filed a ticket (#11640
<https://www.lyx.org/trac/ticket/11640>) on a bug in the new preamble
external edit feature. For some odd reason, the file path is
(tmp/lyx_tmpdir...) is passed correctly to one editor (xed), but the "t"
in "tmp" is lopped off
>>>
>>> Remove sections 6.7 and 6.4 from Additional manual
>>> (obsolete classes egs and aguplus)
>>> Edit LaTeXConfig.lyx accordingly
>>> Move teaplates/AGUTeX.lyx to teaplates/obsolete
>>
>> Richard, s
)
Edit LaTeXConfig.lyx accordingly
Move teaplates/AGUTeX.lyx to teaplates/obsolete
Richard, should this be ported to 2.2? I guess not for section 6.4, as
LyX-2.2.0 was released before aguplus was obsoleted. What about section
2.7? egs is obsolete since 2001, AFAIU.
I think
Le 12/02/2018 à 11:32, jpc a écrit :
commit 92adecb6e04024422930e7f7b60af1149d15c669
Author: jpc
Date: Mon Feb 12 11:30:18 2018 +0100
Remove sections 6.7 and 6.4 from Additional manual (obsolete
classes egs and aguplus)
Edit LaTeXConfig.lyx accordingly
On Fri, Dec 02, 2016 at 07:01:51PM +0100, Kornel Benko wrote:
> Like the attached. (prefTest.pl.in goes into lib/scripts, executable flags
> should be set)
I just took a quick look, but it looks good to me. Thanks for working on
this.
Scott
signature.asc
Description: PGP signature
Am Mittwoch, 30. November 2016 um 10:48:03, schrieb Scott Kostyshak
> On Wed, Nov 30, 2016 at 04:10:38PM +0100, Kornel Benko wrote:
>
> > Selected parameters in prefTest.pl will remain until next call to
> > prefTest.pl.
> > The call sequence could be:
> > # prefTest.pl ...
> > # ctest .
On Wed, Nov 30, 2016 at 04:10:38PM +0100, Kornel Benko wrote:
> Selected parameters in prefTest.pl will remain until next call to prefTest.pl.
> The call sequence could be:
> # prefTest.pl ...
> # ctest ... (this is the same as prefTest.pl with previous params)
> # ctest ...
>
On Wed, Nov 30, 2016 at 04:21:52PM +0100, Tommaso Cucinotta wrote:
> On 30/11/2016 11:12, Kornel Benko wrote:
> > Am Mittwoch, 30. November 2016 um 00:06:59, schrieb Scott Kostyshak
> >
> > > Do we currently have a way of specifying preferences when running
> > > ctests? I think after Tommaso's s
On 30/11/2016 11:12, Kornel Benko wrote:
Am Mittwoch, 30. November 2016 um 00:06:59, schrieb Scott Kostyshak
Do we currently have a way of specifying preferences when running
ctests? I think after Tommaso's security improvements, we need to put
the following in the Testing/.lyx/preferences:
\
Am Mittwoch, 30. November 2016 um 09:50:07, schrieb Scott Kostyshak
> On Wed, Nov 30, 2016 at 11:12:23AM +0100, Kornel Benko wrote:
>
> > Using extra control file for each document would make it easier.
> > But we cannot do parallel tests any more. We use same user-dir for all
> > tests ATM.
>
On Wed, Nov 30, 2016 at 11:12:23AM +0100, Kornel Benko wrote:
> Using extra control file for each document would make it easier.
> But we cannot do parallel tests any more. We use same user-dir for all tests
> ATM.
> Think how to use different dirs needs to recreate also their contents.
Ah I did
Am Mittwoch, 30. November 2016 um 00:06:59, schrieb Scott Kostyshak
> Do we currently have a way of specifying preferences when running
> ctests? I think after Tommaso's security improvements, we need to put
> the following in the Testing/.lyx/preferences:
>
> \use_converter_needauth_forbidden f
Do we currently have a way of specifying preferences when running
ctests? I think after Tommaso's security improvements, we need to put
the following in the Testing/.lyx/preferences:
\use_converter_needauth_forbidden false
\use_converter_needauth false
It might also be nice to have an easy way to
gt;> If I right-clock on the inset "BibTeX Generated Bibliography" ans select
> >> "Edit Database(s) Externally...",
> >> then I get the gvim as editing program (this I had set as Editor for
> >> text/plain in File Handling->FileFormats->Plain t
On 03/05/2012 09:01 AM, Kornel Benko wrote:
Am Montag, 5. März 2012 um 12:36:30, schrieb Kornel Benko
Hi,
it looks like the mime-type of *.bib were not recognized by lyx.
If I right-clock on the inset "BibTeX Generated Bibliography" ans select "Edit
Database(s) Externally...&q
Am Montag, 5. März 2012 um 12:36:30, schrieb Kornel Benko
> Hi,
> it looks like the mime-type of *.bib were not recognized by lyx.
>
> If I right-clock on the inset "BibTeX Generated Bibliography" ans select
> "Edit Database(s) Externally...",
> then I g
Hi,
it looks like the mime-type of *.bib were not recognized by lyx.
If I right-clock on the inset "BibTeX Generated Bibliography" ans select "Edit
Database(s) Externally...",
then I get the gvim as editing program (this I had set as Editor for text/plain
in File Handling
Am 15.08.2011 09:59, schrieb Vincent van Ravesteijn:
I will not fight over this, I'm just trying to figure out the most
applicable name.
I put your proposal in.
regards Uwe
On Mon, Aug 15, 2011 at 5:46 AM, Uwe Stöhr wrote:
> Am 14.08.2011 18:35, schrieb Vincent van Ravesteijn:
>
>
> I don't think this is confusing.
>>
>
> It confuses at least me because selecting the inset is what it does _not_.
> It was specially designed to select its content.
Every selection, s
Hello
On Sat, Aug 13, 2011 at 10:00 AM, Vincent van Ravesteijn wrote:
> I dont really like: select contents of inset. Maybe: select whole inset.
>
Would: "select all contents of inset" or "select all inset contents"
please everyone?
Liviu
Am 14.08.2011 18:35, schrieb Vincent van Ravesteijn:
I don't think this is confusing.
It confuses at least me because selecting the inset is what it does _not_. It was specially designed
to select its content. For example, the \printnomenclature inset can be selected, while
"inset-select-all
I don't think this is confusing.
I just want to stay as close as possible to "select all".
Vincent
Op 13 aug. 2011 16:44 schreef "Uwe Stöhr" het volgende:
> Am 13.08.2011 10:00, schrieb Vincent van Ravesteijn:
>
>> I dont really like: select contents of inset. Maybe: select whole inset.
>
> But
Am 13.08.2011 10:00, schrieb Vincent van Ravesteijn:
I dont really like: select contents of inset. Maybe: select whole inset.
But this would be wrong. The menu only selects the inset's content, not the inset itself. And this
is also the benefit of this menu.
regards Uwe
- if I only had known this before,
this would have eased up
> the work with the documentation files work a lot.
> I added now an info to the UserGuide, but also wants to have an entry in
the Edit menu. OK for trunk?
>
> regards Uwe
wants to have an entry in the
Edit menu. OK for trunk?
regards Uwe
Index: stdmenus.inc
===
--- stdmenus.inc (revision 39474)
+++ stdmenus.inc (working copy)
@@ -105,6 +105,7 @@
Submenu "Paste Recent|e" "edit_pasterec
Ramin Nakisa wrote:
> Could I please have a password so I can do this?
LyX
pavel
Hi,
I'd like to add my book, which I created using LyX, to the
ProducedPublications page.
Could I please have a password so I can do this?
Thanks.
uck when switching from Outline Window to Edit--+- Reporter: gregkise | Owner: lasgouttes Type: defect | Status: new Priority: normal | Milestone: Component: general |
Le 01/11/2010 14:16, Yann Disser a écrit :
Well, as I said, with automatic sync I do not think it would be so
much of a nightmare anymore. And, for me at least, editing
formula-heavy .tex is also not very enjoyable.
A typical example of when tex<->lyx breaks with formulas is when people
use ``h
implementation of LyX, so I'm sorry to be presumptuous, but it
seems to me that there's a design idea that hasn't been cosidered.
Putting the LyX editing LaTeX idea diagrammatically we have (requires
fixed-width font):
original.tex
|
| (edit in LyX)
v
updated
On 1. Nov 2010, at 14:22, Jürgen Spitzmüller wrote:
> Yann Disser wrote:
>> Your arguments make sense. However, I think many people must have my
>> problem. Perhaps it would be sufficient to provide a way to keep the .lyx
>> file and the .tex file in sync. Whenever one of the two would get change
On 01/11/2010 9:02 AM, Yann Disser wrote:
On 1. Nov 2010, at 14:42, Jürgen Spitzmüller wrote:
Yann Disser wrote:
I wish I had time to help you with that (sounds like fun ;-) )... Perhaps
sometime in the future.
Don't count on it. We have many reasons for not using the tex file format
native
t the generated preamble you may want to use
View->Source)
3) Prefix every line of the preamble with %PREAM
4) Edit the preamble as required.
--
John C. McCabe-Dansted
#!/usr/bin/env python
import sys
import os
import subprocess
import re
print "PWD: ",
os.system("pwd")
On 11/01/2010 09:16 AM, Yann Disser wrote:
On 1. Nov 2010, at 14:09, Pavel Sanda wrote:
Yann Disser wrote:
Your arguments make sense. However, I think many people must have my problem.
Perhaps it would be sufficient to provide a way to keep the .lyx file and the
.tex file in sync.
On 11/01/2010 09:16 AM, Yann Disser wrote:
On 1. Nov 2010, at 14:09, Pavel Sanda wrote:
Yann Disser wrote:
Your arguments make sense. However, I think many people must have my problem.
Perhaps it would be sufficient to provide a way to keep the .lyx file and the
.tex file in sync.
Yann Disser wrote:
> Your arguments make sense. However, I think many people must have my
> problem. Perhaps it would be sufficient to provide a way to keep the .lyx
> file and the .tex file in sync. Whenever one of the two would get changed,
> lyx would automatically import/export. This approach w
On 1. Nov 2010, at 14:09, Pavel Sanda wrote:
> Yann Disser wrote:
>> Your arguments make sense. However, I think many people must have my
>> problem. Perhaps it would be sufficient to provide a way to keep the .lyx
>> file and the .tex file in sync. Whenever one of the two would get changed,
>
Yann Disser wrote:
> Your arguments make sense. However, I think many people must have my problem.
> Perhaps it would be sufficient to provide a way to keep the .lyx file and the
> .tex file in sync. Whenever one of the two would get changed, lyx would
> automatically import/export. This approac
On 1. Nov 2010, at 14:42, Jürgen Spitzmüller wrote:
> Yann Disser wrote:
>> I wish I had time to help you with that (sounds like fun ;-) )... Perhaps
>> sometime in the future.
>
> Don't count on it. We have many reasons for not using the tex file format
> natively. For instance, LyX is storin
A slightly simpler problem is to allow users to modify the generated
preamble. Sort of the same problem, but simpler and useful as well.
Op 1 nov 2010 13:39 schreef "Yann Disser" :
On 1. Nov 2010, at 13:19, Richard Heck wrote:
> On 11/01/2010 07:56 AM, Yann Disser wrote:
>>
>> ...
I wish I had
Yann Disser wrote:
> I wish I had time to help you with that (sounds like fun ;-) )... Perhaps
> sometime in the future.
Don't count on it. We have many reasons for not using the tex file format
natively. For instance, LyX is storing some information for which no tex
syntax exists (and which do
On 1. Nov 2010, at 13:19, Richard Heck wrote:
> On 11/01/2010 07:56 AM, Yann Disser wrote:
>>
>> Thanks for your reply. I am sorry for duplicating a feature request, I did
>> not take the time to look through existing ones...
>>
> Not a problem. I just meant it wasn't something we'd overlooked
On 11/01/2010 07:56 AM, Yann Disser wrote:
Thanks for your reply. I am sorry for duplicating a feature request, I
did not take the time to look through existing ones...
Not a problem. I just meant it wasn't something we'd overlooked.
I hope that eventually somebody will implement it, though
orate a lot with people
that I cannot convince to use LyX: It would be awesome, if I could edit .tex
files directly with LyX, instead of going through an import-export cycle every
time.
This is a very old request, and there is a bug in trac about it. If you
search the list, you'll fi
(doing my PhD), and I am really really happy
>> with it!
>>
>> There is one thing I am missing though, since I collaborate a lot with
>> people that I cannot convince to use LyX: It would be awesome, if I could
>> edit .tex files directly with LyX, instead of going thr
ce to use LyX: It would be awesome, if I could edit .tex
files directly with LyX, instead of going through an import-export cycle every
time. First of all, import/export changes the preamble, which might be strange
to the guy who wrote it. And second, we usually work with svn, and there is no
saf
ge of providing neat editing features for a good deal of
languages *within* a LyX document, eliminating the overhead of using
an external editor (to read or edit the code). Having both options
would be a "perfect" solution, but having any of the two would be just
great.
Regards
Liviu
On 2010-04-01, rgheck wrote:
> On 04/01/2010 04:41 AM, Abdelrazak Younes wrote:
>> On 03/31/2010 05:53 PM, Liviu Andronic wrote:
>>> Dear LyX developers
>>> Would it be a good idea to allow users to edit ERT insets with an
>>> external editor? [snip]
>
On 04/01/2010 05:32 PM, rgheck wrote:
On 04/01/2010 04:41 AM, Abdelrazak Younes wrote:
On 03/31/2010 05:53 PM, Liviu Andronic wrote:
Dear LyX developers
Would it be a good idea to allow users to edit ERT insets with an
external editor? [snip]
It is a good idea but it sounds a bit complicated
On 04/01/2010 04:41 AM, Abdelrazak Younes wrote:
On 03/31/2010 05:53 PM, Liviu Andronic wrote:
Dear LyX developers
Would it be a good idea to allow users to edit ERT insets with an
external editor? [snip]
It is a good idea but it sounds a bit complicated to implement for the
communication of
On 03/31/2010 05:53 PM, Liviu Andronic wrote:
Dear LyX developers
Would it be a good idea to allow users to edit ERT insets with an
external editor? I am thinking of something similar to:
1. Have a "Edit with external editor" entry to the ERT inset context menu
2. When activated,
Dear LyX developers
Would it be a good idea to allow users to edit ERT insets with an
external editor? I am thinking of something similar to:
1. Have a "Edit with external editor" entry to the ERT inset context menu
2. When activated, LyX would export the current contents of the ERT
l that Lars didn't like dumping the user straight into the text
> style dialog box, but I don't like the idea of graying out the
> Languages dialog box, IMHO the user should always be able to set the
> Language from Edit->Languages.
No, we just removed that, and I think Jean-Marc put forward good reasons for
this.
Jürgen
t Lars didn't like dumping the user straight into the text
style dialog box, but I don't like the idea of graying out the
Languages dialog box, IMHO the user should always be able to set the
Language from Edit->Languages.
> However, this is something for later (at least as fa
On 02/26/2010 12:05 PM, Jean-Marc Lasgouttes wrote:
Guenter Milde writes:
Actually, I'd prefer to move the language setting out of the character
dialogue completely. Language is an important semantic feature, while all
other settings in this dialogue concern presentational markup.
It
Guenter Milde writes:
> Actually, I'd prefer to move the language setting out of the character
> dialogue completely. Language is an important semantic feature, while all
> other settings in this dialogue concern presentational markup.
It makes sense.
JMarc
On 2010-02-25, Jürgen Spitzmüller wrote:
> Jean-Marc Lasgouttes wrote:
Thanks for the work on the language menu, while there is still room for
improvement, I think it is going in the right direction.
>> in the rather usual case when only one language is used ...
...
>> This new menu entry is a
Vincent van Ravesteijn - TNW wrote:
>>Consider this a bug..
I understood ;-)
> I already did..
>
>>OK?
>
> Yes.
It's in.
Jürgen
>> And in the less usual case in which only languages are used other than
>> the document language, the document language is not in the list (which
>> I would expect of course).
>Consider this a bug..
I already did..
>OK?
Yes.
>Jürgen
Vincent
John McCabe-Dansted wrote:
> Perhaps the Languages menu should always have certain important
> languages available, including for example
> 1) The LyX Interface Language
> 2) The System default language
> 3) On Linux/Ubuntu Languages that the user has installed
> language-packs for (or maybe aspel
Jean-Marc Lasgouttes wrote:
> Thanks for changing that. Another solution could be to have at top-level
> the language that are used in the buffer and a submenu with all the
> other languages. This would allow easy selection of a still unused
> language too.
Yes, but we have a lot of languages. An
On Thu, Feb 25, 2010 at 8:56 PM, Jürgen Spitzmüller wrote:
> Jürgen Spitzmüller wrote:
>
>> I think we can do that better with Qt's help. I'll have a look.
>
> try revision 33566.
Looks good.
I notice that you've added an accelerator to "More Languages" too :).
"Malay" and "More Languages" sha
Jürgen Spitzmüller writes:
> Jean-Marc Lasgouttes wrote:
>
>> BTW, I just tried this language selector thing, only to find out that,
>> in the rather usual case when only one language is used, it adds an ugly
>> Language... entry that just opens the character dialog. I think it would
>> be better
On Thu, Feb 25, 2010 at 8:34 PM, Jürgen Spitzmüller wrote:
> Jean-Marc Lasgouttes wrote:
>
>> BTW, I just tried this language selector thing, only to find out that,
>> in the rather usual case when only one language is used, it adds an ugly
>> Language... entry that just opens the character dialog
Jürgen Spitzmüller wrote:
> I think we can do that better with Qt's help. I'll have a look.
try revision 33566.
Jürgen
John McCabe-Dansted wrote:
> In the worst case we could enumerate the options. Heck I'd even find
> 1: English
> 2: English (UK)
> 3: English (USA)
> 4: English (Canada)
> More meaningful than
> _English
> E_nglish (UK)
> En_glish (USA)
> Eng_lish (Canada)
I don't. Remember these are _menu_ acce
Jean-Marc Lasgouttes wrote:
> BTW, I just tried this language selector thing, only to find out that,
> in the rather usual case when only one language is used, it adds an ugly
> Language... entry that just opens the character dialog. I think it would
> be better the gray out of remove the entry in
Jürgen Spitzmüller writes:
>> A couple of questions:
>> 1) Is using _("(") enough to make the code sufficiently multilingual?
>
> I doubt it. But you can try yourself. Just try different LANG environments.
BTW, I just tried this language selector thing, only to find out that,
in the rather usual
On Thu, Feb 25, 2010 at 6:07 AM, Jürgen Spitzmüller wrote:
>> OK, but adding a couple of lines of code makes this much nicer for
>> English users.
>
> But we do not only have English users.
Right, but English is the language I can test with confidence.
> I'm not even sure my current approach
> i
John McCabe-Dansted wrote:
> OK, but adding a couple of lines of code makes this much nicer for
> English users.
But we do not only have English users. I'm not even sure my current approach
is suitable for all localizations. I think Japanese uses roman accelerators,
but the strings are non-rom
On Wed, Feb 24, 2010 at 10:08 PM, LyX Ticket Tracker wrote:
> #6558: Edit->Language lacks keyboard shortcuts.
> I implemented a simpler solution (ignoring the casing) at r33555.
> Ticket URL: <http://www.lyx.org/trac/ticket/6558#comment:2>
OK, but adding a couple of lines
On 2010-02-05, Pavel Sanda wrote:
> Guenter Milde wrote:
>> (Should the keydindings dialogue escape quotes automatically?)
> dunno, please put this into bugzilla.
Done. http://www.lyx.org/trac/ticket/6511
Günter
Guenter Milde wrote:
> Looking in the generated user.bind file, I found that the whole command
> is put into quotes. Trying again with escaped quotes:
>
> vc-command DR $$p \"my-editor $$i\"
>
> solved this issue. (Should the keydindings dialogue insert the quotes
> automatically?)
dunno, plea
uotes
automatically?)
I bound the function to F4. Is there a preferred/usual keybinding for
"external edit" in CUA-aware applications?
Günter
On Sunday 23 August 2009 17:16:24 LyX Ticket Tracker wrote:
> #6174: Insert and Edit buttons for outline mode
> -+-
>- Reporter: stevelitt| Owner: nob...@…
> Type: enhancement | Status: new
OpenSuse do not seem to offer something called latex-xft, but I think
the latex-xft contains the Bakomo fonts? In anycase, my system has the
Bakomo fonts installed (as I understand this is what one needs for
math symbol rendering in edit mode)- so I am assuming that OpenSuse
packages the contents
1 - 100 of 392 matches
Mail list logo
