Le 27/05/2024 à 13:18, fcana...@gmail.com a écrit :
\documentclass{article}
\begin{document}
\[
x = y.
% u= v.
\]
\end{document}
It's actually worse than not showing correctly in the work area. Consider:
\[
x = y.
% u= v.
u= v.
\]
Daniel
Indeed. It can be observed not only when importing b
> > \documentclass{article}
> > \begin{document}
> > \[
> > x = y.
> > % u= v.
> > \]
> > \end{document}
>
> It's actually worse than not showing correctly in the work area. Consider:
>
> \[
> x = y.
> % u= v.
> u= v.
> \]
>
> Daniel
Indeed. It can be observed not only when importing but also
On 2024-05-26 16:12, fcana...@gmail.com wrote:
\documentclass{article}
\begin{document}
\[
x = y.
% u= v.
\]
\end{document}
It's actually worse than not showing correctly in the work area. Consider:
\[
x = y.
% u= v.
u= v.
\]
Daniel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://li
Greetings,
I am not sure whether what I am about to report is a bug or intended behavior.
I searched on the web and couldn't find anything related. I hope this is not
the wrong list to mention this. Here goes:
There seems to be a confusing behavior with imported LaTeX documents that
co
Am Sonntag, dem 20.08.2023 um 00:52 +0300 schrieb Udicoudco:
> Should the second input encoding be changed from latin9 to utf8,
> now that utf8 is the default encoding?
I'm not sure I follow. We have utf8 as default in 2.4. We only use the
8bit encodings if people chose that (in languages).
--
J
On Sun, Aug 20, 2023 at 12:52 AM Udicoudco wrote:
>
>
> Should the second input encoding be changed from latin9 to utf8,
> now that utf8 is the default encoding?
>
or are we separating traditional and unicode encoding
entirely?
> > --
> > lyx-devel mailing list
> > lyx-devel@lists.lyx.org
> > http
On Sat, Dec 17, 2022 at 10:44 AM Jürgen Spitzmüller wrote:
>
> Am Freitag, dem 16.12.2022 um 10:32 -0500 schrieb Scott Kostyshak:
> > Attached is a .lyx file that produces the following code when
> > exported
> > with LaTeX (pdflatex):
> >
> > \usepackage[latin9,cp1255]{inputenc}
> >
> > Ulrike
On Sat, Dec 17, 2022 at 03:14:11PM +0100, Jürgen Spitzmüller wrote:
> Am Samstag, dem 17.12.2022 um 09:44 +0100 schrieb Jürgen Spitzmüller:
> > The inputenc package, however,
> > only expects one option. It sets the latter to the inputencoding at
> > at package loading time, which is cp1255 here.
>
Am Samstag, dem 17.12.2022 um 09:44 +0100 schrieb Jürgen Spitzmüller:
> The inputenc package, however,
> only expects one option. It sets the latter to the inputencoding at
> at package loading time, which is cp1255 here.
I fixed it in master. Since the bug is supposedly decades old, I would
leave
Am Freitag, dem 16.12.2022 um 10:32 -0500 schrieb Scott Kostyshak:
> Attached is a .lyx file that produces the following code when
> exported
> with LaTeX (pdflatex):
>
> \usepackage[latin9,cp1255]{inputenc}
>
> Ulrike Fisher points out the following [1]:
>
> \usepackage[latin9,cp1255]{input
On Fri, Dec 16, 2022 at 5:32 PM Scott Kostyshak wrote:
>
> Attached is a .lyx file that produces the following code when exported
> with LaTeX (pdflatex):
>
> \usepackage[latin9,cp1255]{inputenc}
>
> Ulrike Fisher points out the following [1]:
>
> \usepackage[latin9,cp1255]{inputenc} doesn't m
Attached is a .lyx file that produces the following code when exported
with LaTeX (pdflatex):
\usepackage[latin9,cp1255]{inputenc}
Ulrike Fisher points out the following [1]:
\usepackage[latin9,cp1255]{inputenc} doesn't make any sense, your
files can't have two encodings at the same time.
ot; (note the space at the end)
> >
> > In 2.3.0, the cursor is placed inside the mathbf inset. In current
> > master, the cursor is placed after the mathbf inset. However, I don't
> > know if this is a good use case. It is a bit strange to do \mathbf in
> > t
is placed after the mathbf inset. However, I don't
know if this is a good use case. It is a bit strange to do \mathbf in
text-within-math mode isn't it? I did it by mistake.
This looks like a bug indeed, even if it is not of the most ugly sort.
JMarc
--
lyx-devel mailing list
lyx-deve
To reproduce:
1. ctrl + m to enter math mode.
2. ctrl + m (again) to enter text-within-math mode.
3. Type "\mathbf " (note the space at the end)
In 2.3.0, the cursor is placed inside the mathbf inset. In current
master, the cursor is placed after the mathbf inset. However, I don't
know if this is
On Sun, May 31, 2015 at 7:28 PM, Richard Heck wrote:
> On 05/31/2015 05:35 PM, Scott Kostyshak wrote:
>>
>> The following ticket seems to be fixed to me:
>> http://www.lyx.org/trac/ticket/6047
>>
>> It was marked as fixed, but trac still shows it as open
>> (http://www.lyx.org/trac/query?status=!c
On 05/31/2015 05:35 PM, Scott Kostyshak wrote:
The following ticket seems to be fixed to me:
http://www.lyx.org/trac/ticket/6047
It was marked as fixed, but trac still shows it as open
(http://www.lyx.org/trac/query?status=!closed&component=mathed)
I will try to mark it as fixed again (if you w
The following ticket seems to be fixed to me:
http://www.lyx.org/trac/ticket/6047
It was marked as fixed, but trac still shows it as open
(http://www.lyx.org/trac/query?status=!closed&component=mathed)
I will try to mark it as fixed again (if you would like to, please
feel free), but first I woul
Am 07.02.2015 um 21:46 schrieb Vadim Marmer :
> It happens every other time I quit LyX
>
> Process: lyx [31542]
> Path:/Applications/LyX.app/Contents/MacOS/lyx
> Identifier: org.lyx.lyx
> Version: 2.1.1 (???)
> Code Type: X86-64 (Native)
> Parent Process: l
It happens every other time I quit LyX
Process: lyx [31542]
Path:/Applications/LyX.app/Contents/MacOS/lyx
Identifier: org.lyx.lyx
Version: 2.1.1 (???)
Code Type: X86-64 (Native)
Parent Process: launchd [180]
Responsible: lyx [31542]
User ID: 501
On Wed, Dec 12, 2012 at 9:40 AM, Richard Heck wrote:
>
> These three patches are fine for branch, too.
They're in.
Scott
: Wed Dec 12 03:44:38 2012 -0500
Fix a bug when selecting a cell in InsetTabular
Fix the following bug:
When in tabular, enter "ab" in a cell. Place the cursor before "b". Hold
shift and press , then (still holding shift) again. On
the second
I use -shell-escape with pdflatex to enable TiKZ to call Gnuplot for function
plots. I've had no problems with that.
Paul
Hello,
I have some old Latex documents with PSTricks diagrams. I am converting
them to Lyx and it works quite nicely, except one problem:
I use pdftricks for automatically converting the figure to pdf and use with
pdflatex.
I have changed the configuration of the pdflatex converter to put pdflate
Le 25 oct. 09 à 09:42, Gyorgy SZEIDL a écrit :
After installation I made an attempt at importing some standard
LaTeX documents as LaTeX (plain) files created by WinEdt. I failed
in each case by receiving the following error message:
tex2lyx.exe has encountered a problem and needs to close. W
(plain) file under Lyx 1.4.1.
This behavior of Lyx 1.4.1. is very disappointing and in all probability is
a bug.
By the way: I have just removed Lyx 1.4.1 then I reinstalled Lyx 1.3.1.
I was again able to import the LaTeX (plain) files in question.
I am emphasizing that the files in question were
es are needed (i.e. removing any
of them also removes the italics). It seems that entering "Notation*"
env is somehow important.
Hope it helps, good luck!
Michał Skrzypek
It is a bug, and your report was very helpful in pinning it down.
I have a zip archive containing some
fixed
removes the italics). It seems that entering "Notation*"
env is somehow important.
Hope it helps, good luck!
Michał Skrzypek
It is a bug, and your report was very helpful in pinning it down.
I have a zip archive containing some
fixed modules, along with a few new ones (numbering t
> I don't reproduce that here (same setup minus the Polish). What
> document class are you using? Any other modules besides "Theorems"
> and "Theorems (By Section)"?
The class is "article (AMS)", also "Theorems (AMS-Extended)" module.
After further investigation I narrowed it down to a simp
section in the file theorems-sec.module changes the style back to bold.
Is this intentional, or is it a bug?
Regards,
Michał Skrzypek
I don't reproduce that here (same setup minus the Polish). What
document class are you using? Any other modules besides "Theorems" and
"Theorems (By Section)"?
/Paul
ec.module changes the style back to bold.
Is this intentional, or is it a bug?
Regards,
Michał Skrzypek
Andre Poenitz wrote:
On Mon, Apr 07, 2008 at 03:45:03PM -0400, Paul A. Rubin wrote:
Hi,
I was going to put this into bugzilla, but I'm uncertain whether it's
really a bug, a feature-enhancement or just one of those vicissitudes we
have to live with.
I copied some output from
On Mon, Apr 07, 2008 at 03:45:03PM -0400, Paul A. Rubin wrote:
> Hi,
>
> I was going to put this into bugzilla, but I'm uncertain whether it's
> really a bug, a feature-enhancement or just one of those vicissitudes we
> have to live with.
>
> I copied some outp
Hi,
I was going to put this into bugzilla, but I'm uncertain whether it's
really a bug, a feature-enhancement or just one of those vicissitudes we
have to live with.
I copied some output from R (a stats package) and pasted it into a
lyx-code environment in an article. The c
Michal Skrzypek wrote:
> I wanted to report something relatively harmless, but strange. I am
> currently using LyX 1.5.2 (XP SP2, Polish version). I apologize that I
> cannot check this with the current version, but for now I cannot
> upgrade/test it due to time constraints, as I am nearing the com
Mark S. wrote:
A bug in LyX 1.5.1 (now distributed with Gutsy Gibbon):
When working in formulas within the document, the arrow buttons behave the
opposite way. Meaning, if one wants to go left in the formula, the left
button will actually make him go right and the right one will make him go
A bug in LyX 1.5.1 (now distributed with Gutsy Gibbon):
When working in formulas within the document, the arrow buttons behave the
opposite way. Meaning, if one wants to go left in the formula, the left
button will actually make him go right and the right one will make him go
left.
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> I will put this patch in tomorrow unless I get objections.
Go ahead.
JMarc
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> I set up my keyboard with dead keys, and that works with gnome
Georg> and kde applications and LANG=C. Nedit requires LANG=de_DE, and
Georg> LyX works with LANG=de_DE and LANG=de_DE.UTF-8, so this looks
Georg> like a LyX problem to me.
Georg Baum wrote:
Am Sonntag, 25. Februar 2007 16:06 schrieb Enrico Forestieri:
On Sun, Feb 25, 2007 at 10:31:16AM +0100, Georg Baum wrote:
Here is the patch, please test.
With this patch, LyX asserts when loading some documents:
assertion "ucs4 < 65536" failed:
file "../../../src/support/
Am Sonntag, 25. Februar 2007 16:06 schrieb Enrico Forestieri:
> On Sun, Feb 25, 2007 at 10:31:16AM +0100, Georg Baum wrote:
>
> > Here is the patch, please test.
>
> With this patch, LyX asserts when loading some documents:
>
> assertion "ucs4 < 65536" failed:
file "../../../src/support/../supp
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> I think that you meant the stix fonts:
Enrico> http://www.stixfonts.org/
Enrico> http://www.ams.org/STIX/stix-glyphs.html
Enrico> and not the styx fonts: http://bystyx.com/wiki/fonts
I thought briefly about checking first, a
On Sun, Feb 25, 2007 at 04:39:38PM +0100, Jean-Marc Lasgouttes wrote:
> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> Enrico> I still wonder what is the benefit/cost ratio of using ucs4
> Enrico> instead of ucs2...
>
> When we adapt mathed to use the styx fonts, we will nee
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> I still wonder what is the benefit/cost ratio of using ucs4
Enrico> instead of ucs2...
When we adapt mathed to use the styx fonts, we will need ucs4 to use
the fonts.
JMarc
On Sun, Feb 25, 2007 at 10:31:16AM +0100, Georg Baum wrote:
> Here is the patch, please test.
With this patch, LyX asserts when loading some documents:
assertion "ucs4 < 65536" failed: file
"../../../src/support/../support/qstring_helpers.h", line 74
> It fixes bug 3270 for me (did not test
>
Am Sonntag, 25. Februar 2007 10:01 schrieb Georg Baum:
> Am Sonntag, 25. Februar 2007 03:52 schrieb Enrico Forestieri:
> > On Sat, Feb 24, 2007 at 07:00:42PM +0100, Jean-Marc Lasgouttes wrote:
> >
> > > Bug 1247 is about recognizing properly letters in non-latin1 text.
> > > This is fixed on linux
Am Sonntag, 25. Februar 2007 03:52 schrieb Enrico Forestieri:
> On Sat, Feb 24, 2007 at 07:00:42PM +0100, Jean-Marc Lasgouttes wrote:
>
> > Bug 1247 is about recognizing properly letters in non-latin1 text.
> > This is fixed on linux using 32bits wchar_t. However, on windows
> > another strategy h
On Sat, Feb 24, 2007 at 07:00:42PM +0100, Jean-Marc Lasgouttes wrote:
> Bug 1247 is about recognizing properly letters in non-latin1 text.
> This is fixed on linux using 32bits wchar_t. However, on windows
> another strategy has to be found, as discussed here
> http://bugzilla.lyx.org/show_bug.cgi
Oops - forgot to actually attach ;)
Hello again,
I'm attaching to this email a .lyx file that will help you reproduce the
conditions triggering the bug.
Have in mind that the bug seems related to some mishap while building the latex
input while generating previews, because compiling with Ctrl+D
Hello again,
I'm attaching to this email a .lyx file that will help you reproduce the
conditions triggering the bug.
Have in mind that the bug seems related to some mishap while building the latex
input while generating previews, because compiling with Ctrl+D works as
expected, and this does not
ment should not be needed at all, neither for DVI output
nor for PDF.
> IMHO it's a bit
> user-unfriendly to make the user do it, plus it requires the user to
> know enough about LyX's internal workings to know that the file name
> munging and conversion are going on in th
Georg Baum wrote:
Am Donnerstag, 19. Januar 2006 16:54 schrieb Paul A. Rubin:
Poking around with this led me to what I think is a second, related bug.
(I'm not sure the first problem is a LyX bug versus a LaTeX
limitation, but I'm pretty sure the second one is a LyX bug.) I tried
adding the
Am Donnerstag, 19. Januar 2006 16:54 schrieb Paul A. Rubin:
> Poking around with this led me to what I think is a second, related bug.
> (I'm not sure the first problem is a LyX bug versus a LaTeX
> limitation, but I'm pretty sure the second one is a LyX bug.) I tried
> adding the option 'typ
Staubach. Martin wrote:
Hello,
add a jpeg file in your document and have the file-extension of this
image in capitals. Hit the adobe-pdf button to convert it to pdf and you
will receive an error message like the following:
LaTeX Error: Unknown graphics extension: .JPG.
...eImages_modul
Hello,
add a jpeg file in your document and have the file-extension of this
image in capitals. Hit the adobe-pdf button to convert it to pdf and you
will receive an error message like the following:
LaTeX Error: Unknown graphics extension: .JPG.
...eImages_modulverzeichnis\string".JPG}
> "Giorgio" == Giorgio Zavarise <[EMAIL PROTECTED]> writes:
Giorgio> If I don't have any "environment.plist file then I found the
Giorgio> Lyx preferences as first choice under the LyX menu, BUT if I
Giorgio> use the above environment. plist then the "preferences" menu
Giorgio> under LyX simpl
Hi all,
I would like to inform you about something strange about the
preferences menu that happens to me with LyX. I am using Lix/MAC
1.3.6 on a powerbook with OSX 10.4.3. Everything is fine if I use LyX
"as it is, but if I set the language to ITALIAN with the above
attached environment.p
in 1.3.5cvs. This indeed a bad behaviour. I
tried with 1.4.0cvs and got a different bad behaviour, and eventually
a crash (but it may be that the problem is different...)
Actually, the same happens with other displayed insets like table of
contents. So this is more a bug with displayed insets than a maths
bug.
JMarc
Hello, LyX developers. I'm a theoretical physicist in Brazil, and I'm happily
using Lyx to write my PhD thesis. You will certainly be in my
acknowledgements page when I'm done!
Well, I'm using LyX 1.3.4 on a Debian Sarge system, and I've noticed a small
"bug" which may interest you.
Conside
.
I have some problems with version 1.3.4-1 (and maybe 1.3.4-0). I'm used
to write '$$$' to indicate there is still some work needed on the text.
Searching on $ signs results finding Math formulas instead of finding
literal $-s in the text (not as in 1.16fix4-2). It seems a bug tha
Create a new document, insert a table:
==11853== Conditional jump or move depends on uninitialised value(s)
==11853==at 0x8204B7A: InsetText::saveLyXTextState() const
(insettext.C:90)
==11853==by 0x820BDE5: InsetText::reinitLyXText() const
(insettext.C:2004)
==11853==by 0x81FAC59
On Thu, 3 Apr 2003, John Levon wrote:
> On Thu, Apr 03, 2003 at 02:04:51PM +0200, Christian Ridderstr?m wrote:
>
> > This might be the correct behaviour, but it's a bit unintuitive - maybe
>
> It is correct, and it is a bit unintuitive.
>
> > it would be better if you got an error message or a
On Thu, Apr 03, 2003 at 07:54:15PM +0300, Dekel Tsur wrote:
> > > 3. Now repopen the "Float settings" and note that the "Bottom of page"
> > >settings is not selected anymore!
> >
> > Some latex guy tell me what should be happening here ? I assume 'b' is
> > ok for a wide float ?
>
> In sta
On Thu, Apr 03, 2003 at 06:41:51PM +, Angus Leeming wrote:
> So you loop over all widgets after a signal is received? Then indeed it is
Erm, no, why would I do that ? I check what needs to be checked,
directly inside TheDialog::isValid()
regards
john
John Levon wrote:
> On Thu, Apr 03, 2003 at 06:21:27PM +, Angus Leeming wrote:
>
>> Well then, derive a class from checked_widget that does _not_ change the
>> colour but does ensure that the Ok,Apply buttons retain a "memory" of
>> this invalid entry.
>
> Well, the qt2/ way is just to add a
On Thu, Apr 03, 2003 at 06:21:27PM +, Angus Leeming wrote:
> Well then, derive a class from checked_widget that does _not_ change the
> colour but does ensure that the Ok,Apply buttons retain a "memory" of this
> invalid entry.
Well, the qt2/ way is just to add an isValid() to FloatPlacemen
John Levon wrote:
> On Thu, Apr 03, 2003 at 06:13:05PM +, Angus Leeming wrote:
>
>> Make use of my checked_widget class. For example, try and enter an
>> invalid LyXGlueLength in the paragraph dialog, xforms frontend. You'll
>> get visual feedback that the thing is invalid and the Ok,Apply bu
On Thu, Apr 03, 2003 at 06:13:05PM +, Angus Leeming wrote:
> Make use of my checked_widget class. For example, try and enter an invalid
> LyXGlueLength in the paragraph dialog, xforms frontend. You'll get visual
> feedback that the thing is invalid and the Ok,Apply buttons will be
> disable
John Levon wrote:
> Instead, we could disable ok/apply if a non-valid set of optioons is
> chosen ... I'm dubious about that.
Make use of my checked_widget class. For example, try and enter an invalid
LyXGlueLength in the paragraph dialog, xforms frontend. You'll get visual
feedback that the th
On Thu, Apr 03, 2003 at 07:54:15PM +0300, Dekel Tsur wrote:
> > > 3. Now repopen the "Float settings" and note that the "Bottom of page"
> > >settings is not selected anymore!
> >
> > Some latex guy tell me what should be happening here ? I assume 'b' is
> > ok for a wide float ?
>
> In sta
On Thu, Apr 03, 2003 at 05:45:38PM +0100, John Levon wrote:
> >
> > 3. Now repopen the "Float settings" and note that the "Bottom of page"
> >settings is not selected anymore!
>
> Some latex guy tell me what should be happening here ? I assume 'b' is
> ok for a wide float ?
In standard late
On Thu, Apr 03, 2003 at 02:04:51PM +0200, Christian Ridderstr?m wrote:
> This might be the correct behaviour, but it's a bit unintuitive - maybe
It is correct, and it is a bit unintuitive.
> it would be better if you got an error message or a warning, instead of
> LyX just automatically re-sel
> "Christian" == Christian Ridderström <[EMAIL PROTECTED]> writes:
Christian> I'm also curious... does the order of the "Advanced
Christian> placement options" matter. And if they do, how is that
Christian> controlled from this dialog?
The order does not matter.
JMarc
ive - maybe
it would be better if you got an error message or a warning, instead of
LyX just automatically re-selecting "Use default placement"
I'm also curious... does the order of the "Advanced placement options"
matter. And if they do, how is that controlled from
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> No, I like your way. I just like explanations too. I'll make the change.
>
> Sorry if I was rude. I have searched this bug for a while. (it keeped
> giving me "Timeout::start: already running" while loading images, and I
> was convinced that
Angus Leeming wrote:
> No, I like your way. I just like explanations too. I'll make the change.
Sorry if I was rude. I have searched this bug for a while. (it keeped giving
me "Timeout::start: already running" while loading images, and I was
convinced that it was LoaderQueue's timer: I have had t
Alfredo Braunstein wrote:
> The problem is not the erase in timer(), but the erase in kill().
>
> If want to do it this way, I think you will have to modify the kill()
> method, making not to erase elements of the list, but to put them to zero.
>
> Or... why you don't like my way? Efficiency?
No
Hi Angus,
Angus Leeming wrote:
> Ooo, that's devious. In that case I think we really need a two pass
> algorithm:
>
> ListType::iterator it = forkedCalls.begin();
> ListType::iterator end = forkedCalls.end();
> for (; it != end; ++it) {
> bool remove_
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> I don't see the bug. You return to the start of the list, I move to the
>> next itme in the list. The 'prev' stuff is safe if ugly, as I understand
>> list.
>
> Sorry, I was away.
> What if for instance, *prev has dissapeared in the time bein
Angus Leeming wrote:
> I don't see the bug. You return to the start of the list, I move to the
> next itme in the list. The 'prev' stuff is safe if ugly, as I understand
> list.
Sorry, I was away.
What if for instance, *prev has dissapeared in the time being? (because of
multiple calls to kill()
On Tue, Feb 25, 2003 at 12:10:29PM +, Angus Leeming wrote:
> while (it != end) {
this is what I always do. It's a bit ugly, but I'm not all sure your
code before is strictly allowed ...
john
John Levon wrote:
> On Tue, Feb 25, 2003 at 11:33:07AM +, Angus Leeming wrote:
>
>> > - ListType::iterator prev = it;
>> > - --prev;
>> > forkedCalls.erase(it);
>> > - it = prev;
>>
>> I don't see the bu
On Tue, Feb 25, 2003 at 11:33:07AM +, Angus Leeming wrote:
> > - ListType::iterator prev = it;
> > - --prev;
> > forkedCalls.erase(it);
> > - it = prev;
>
> I don't see the bug. You return to the start of
Alfredo Braunstein wrote:
> I've added the explanation in a comment.
>
> --- forkedcontr.C 2003/02/13 16:53:14 1.7
> +++ forkedcontr.C 2003/02/25 10:26:02
> @@ -130,19 +130,19 @@
> }
>
> if (remove_it) {
> - // Emit signal and
ms like a good idea. Applied.
>
> Angus and other Xforms gurus,
>
> Why is double-clicking sometimes so troublesome in Xforms?
> The File dialog has such trouble also. It's a bug in Xforms,
> or is the double-click feature wrongly coded in LyX ?
It's an xforms bug. Someone submitted a patch to the xforms list recently.
Angus
I've added the explanation in a comment.
--- forkedcontr.C 2003/02/13 16:53:14 1.7
+++ forkedcontr.C 2003/02/25 10:26:02
@@ -130,19 +130,19 @@
}
if (remove_it) {
- // Emit signal and remove the item from the list
-
John Levon wrote:
> On Sun, Feb 23, 2003 at 02:03:26PM +0900, Rob Lahaye wrote:
>
>
>>Why is double-clicking sometimes so troublesome in Xforms?
>>The File dialog has such trouble also. It's a bug in Xforms,
>>or is the double-click feature wrongly coded in Ly
On Sun, Feb 23, 2003 at 02:03:26PM +0900, Rob Lahaye wrote:
> Why is double-clicking sometimes so troublesome in Xforms?
> The File dialog has such trouble also. It's a bug in Xforms,
> or is the double-click feature wrongly coded in LyX ?
If you could fix the xforms file dialog, t
ouble-clicking sometimes so troublesome in Xforms?
The File dialog has such trouble also. It's a bug in Xforms,
or is the double-click feature wrongly coded in LyX ?
This bug should not stop us/me to implement double-clicking
instead of having to select first and then click another button.
Well
On Thu, Mar 07, 2002 at 12:53:11PM +0100, Juergen Vigna wrote:
> ??? what do you wanted to fix in there?
http://bugzilla.lyx.org/show_bug.cgi?id=93
> And don't you look at the patch
> files before you send them?
I did (unless there was about 40 lines of "? randomstuff.diff" in it.
I just miss
On 07-Mar-2002 John Levon wrote:
> try LFUN_INSET_TEXT without the patch and LFUN_CORE shall be revealed
> unto you.
#:O)
> Did I accidentally leave the changes to insertInsetAndEdit in the patch
> ?
> please don't apply that bit, it's for turning the selection into an
> inset (and is probably
On Thu, Mar 07, 2002 at 10:59:10AM +0100, Juergen Vigna wrote:
> > can exist by itself. But let's hear what Jürgen says.
>
> Well it CAN exist by itself but I agree that now it is not neccessary
> anymore to have it. I needed this for testing the insettext, but I think
> we now have enough testi
On 07-Mar-2002 Lars Gullik Bjønnes wrote:
> Anyway I pretty much agree with this patch since an InsetText never
> can exist by itself. But let's hear what Jürgen says.
Well it CAN exist by itself but I agree that now it is not neccessary
anymore to have it. I needed this for testing the insette
John Levon <[EMAIL PROTECTED]> writes:
| without removing this, you can make lyx core with it. So let's get
| rid of it (what was it supposed to do anyway ?)
What is the LFUN_CORE you talk about?
Anyway I pretty much agree with this patch since an InsetText never
can exist by itself. But let's
without removing this, you can make lyx core with it. So let's get
rid of it (what was it supposed to do anyway ?)
john
--
I am a complete moron for forgetting about endianness. May I be
forever marked as such.
Index: src/BufferView_pimpl.C
===
On Thu, 21 Feb 2002, Jose Abilio Oliveira Matos wrote:
> valid docbook preamble. The bug that I refer to was the indication of latex
> preamble when it should refer to docbook preamble.
>
> If you remove your preamble all should be ok.
>
I see. Thanks.
--cghan
On Friday 22 February 2002 04:42, cghan wrote:
>
> If I apply "db2dvi" to the exported sgml file, it gives the same error.
> Doesn't this mean that there is something wrong in the exported sgml file?
Nope. What I intend to say is that your preamble is a latex preamble, not a
valid docbook prea
On Thu, 21 Feb 2002, Jose Abilio Oliveira Matos wrote:
>
> > The exported sgml file is the following:
>
> That is not a bug a but a feature, the bug as I told is elsewhere. ;-)
>
If I apply "db2dvi" to the exported sgml file, it gives the same error.
Doe
On 21 Feb 2002, Jean-Marc Lasgouttes wrote:
[...]
> However, it is probably easier to change the entry to something like
> 'Preamble...'. I understand that this does not mean much to many
> people, but I'm sure that our fellow english-speking-list-readers will
> propose a formulation which is outp
> "Jose" == Jose Abilio Oliveira Matos <[EMAIL PROTECTED]> writes:
Jose> So here the it should say Layout->docbook preamble, since that
Jose> is the correct name for it.
Jose> Jean-Marc would it be too dificult to change the menu entries,
Jose> depending on the buffer type?
That would b
1 - 100 of 174 matches
Mail list logo
