On Wed, Oct 30, 2024 at 02:06:59AM +0100, Thibaut Cuvelier wrote:
> always returning a non-problematic value.
The only important one, thanks :)
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
https://lists.lyx.org/mailman/listinfo/lyx-devel
I have just pushed 110e654b. I tried to run with the hare and hunt with the
hounds: I'm not using default:, I'm adding runtime warnings in case
something unexpected happens, and I'm always returning a non-problematic
value.
Thibaut Cuvelier
On Tue, 29 Oct 2024 at 20:54, Pavel Sanda wrote:
> On
On Tue, Oct 29, 2024 at 08:22:29PM +0100, Jean-Marc Lasgouttes wrote:
> I am not sure what you mean, Pavel. Not using default: is better in general.
> We should use it only in cases where the number of enum members is too
> large(for example in dispatch+)).
I thought that we generally do default
I am not sure what you mean, Pavel. Not using default: is better in general. We
should use it only in cases where the number of enum members is too large(for
example in dispatch+)).
If somebody adds an enum value later, we'll get a warning about it.
JMarc
Le 29 octobre 2024 16:13:25 GMT+01:00
On Tue, Oct 29, 2024 at 01:26:18PM +0100, Thibaut Cuvelier wrote:
> > I think default switch clause with either return "" or some warning should
> > be here?
>
> If I add a default case, I get a warning, because I'm covering all cases. I
> can add a comment tonight.
I think it is safer to accept
On Tue, 29 Oct 2024, 10:36 Pavel Sanda, wrote:
> On Tue, Oct 29, 2024 at 03:31:52AM +, Thibaut Cuvelier wrote:
> > + std::string toMathVariantForMathML3() const
> > + {
> > + // mathvariant is the way MathML 3 encodes fonts.
> > + // Not all combinations are su
On Tue, Oct 29, 2024 at 03:31:52AM +, Thibaut Cuvelier wrote:
> + std::string toMathVariantForMathML3() const
> + {
> + // mathvariant is the way MathML 3 encodes fonts.
> + // Not all combinations are supported. Official list:
> + // https://www.w3.o
On Thu, 2024-07-04 at 15:06 +0200, Jean-Marc Lasgouttes wrote:
> Or just
> ./config.status --recheck
Thank you.
This is nice to know.
> > @Jean-Marc I see now that --no-create --no-recursion are no longer
> > the
> > default. Before when calling ~/SRC_DIR/configure those options were
> > always a
Le 04/07/2024 à 14:01, José Matos a écrit :
On Thu, 2024-07-04 at 13:47 +0200, Pavel Sanda wrote:
I would be concerned if running ./configure does not fix the Qt
version.
Does it fix it in your case?
Pavel
Yes, it works.
Since you do an out source dir build I always need to extract the
previ
On Thu, Jul 04, 2024 at 01:01:34PM +0100, José Matos wrote:
> Since you do an out source dir build I always need to extract the
> previous call from config.log file.
Workaround which I often use:
./autogen.sh
make
(configure is automatically triggered when you lauch make and it take
the paramete
On Thu, 2024-07-04 at 13:47 +0200, Pavel Sanda wrote:
> I would be concerned if running ./configure does not fix the Qt
> version.
> Does it fix it in your case?
>
> Pavel
Yes, it works.
Since you do an out source dir build I always need to extract the
previous call from config.log file.
For th
Le 04/07/2024 à 13:47, Pavel Sanda a écrit :
On Thu, Jul 04, 2024 at 12:29:13PM +0100, José Matos wrote:
There is some mechanism in action because all C++ files were recompiled
when the Qt version changed.
I would be concerned if running ./configure does not fix the Qt version.
Does it fix it
On Thu, Jul 04, 2024 at 12:29:13PM +0100, José Matos wrote:
> There is some mechanism in action because all C++ files were recompiled
> when the Qt version changed.
I would be concerned if running ./configure does not fix the Qt version.
Does it fix it in your case?
Pavel
--
lyx-devel mailing li
On Thu, 2024-07-04 at 12:16 +0200, Pavel Sanda wrote:
> But isn't it reasonable to run configure again when Qt changes?
> And it's not just QT, I think that if you don't rerun autogen
> you won't get correct lyx version when we bump the version.
>
> Pavel
There is some mechanism in action because
On Thu, Jul 04, 2024 at 10:47:00AM +0100, José Matos wrote:
> The Qt version is an old one, most likely the one used last time that
> configure ran.
But isn't it reasonable to run configure again when Qt changes?
And it's not just QT, I think that if you don't rerun autogen
you won't get correct l
Le 04/07/2024 à 11:47, José Matos a écrit :
The Qt version is an old one, most likely the one used last time that
configure ran.
Indeed. Not sure what to do about it. But the Qt version at configure
time may matter, if we did tricks according to it.
JMarc
--
lyx-devel mailing list
lyx-devel
ran.
Since the source of truth is Version, and that the information is
correct I suggest to leave this as it is.
As a packager I always pick the source and then follow the usual build
flow so that then both tabs will be in accordance.
Regards,
PS: I am using real unicode emojis to defeat
On Tue, Dec 06, 2022 at 10:19:18PM +0100, Stephan Witt wrote:
> Am 06.12.2022 um 22:12 schrieb Pavel Sanda :
> >
> > On Tue, Dec 06, 2022 at 12:25:53PM -0500, Scott Kostyshak wrote:
> >> For a macOS user, can we tell whether they are on Ventura or not?
> >
> > I???ll try QSysInfo::pro
Am 06.12.2022 um 22:12 schrieb Pavel Sanda :
>
> On Tue, Dec 06, 2022 at 12:25:53PM -0500, Scott Kostyshak wrote:
>> For a macOS user, can we tell whether they are on Ventura or not?
>
> I???ll try QSysInfo::productVersion() ???
This will show up like that:
On Tue, Dec 06, 2022 at 12:25:53PM -0500, Scott Kostyshak wrote:
> > >>> For a macOS user, can we tell whether they are on Ventura or not?
> > >>
> > >> I???ll try QSysInfo::productVersion() ???
> > >
> > > This will show up like that:
> > >
> > >
> > >
> > > With Ventura it should be: 13.0
>
;> On Sun, Dec 04, 2022 at 10:13:11PM +0100, Jean-Marc Lasgouttes wrote:
> >>>> Le 04/12/2022 à 21:41, Scott Kostyshak a écrit :
> >>>>> When collecting information, it might be nice to have OS information.
> >>>>> That way, the user only has to go t
22 à 21:41, Scott Kostyshak a écrit :
>>>>> When collecting information, it might be nice to have OS information.
>>>>> That way, the user only has to go to Help > About and click on "Copy
>>>>> Version Info" and all important information
Am 06.12.2022 um 17:15 schrieb Stephan Witt :
>
> Am 06.12.2022 um 16:34 schrieb Scott Kostyshak :
>>
>> On Sun, Dec 04, 2022 at 10:13:11PM +0100, Jean-Marc Lasgouttes wrote:
>>> Le 04/12/2022 à 21:41, Scott Kostyshak a écrit :
>>>> When collecting i
Am 06.12.2022 um 16:34 schrieb Scott Kostyshak :
>
> On Sun, Dec 04, 2022 at 10:13:11PM +0100, Jean-Marc Lasgouttes wrote:
>> Le 04/12/2022 à 21:41, Scott Kostyshak a écrit :
>>> When collecting information, it might be nice to have OS information.
>>> That way, t
On Sun, Dec 04, 2022 at 10:13:11PM +0100, Jean-Marc Lasgouttes wrote:
> Le 04/12/2022 à 21:41, Scott Kostyshak a écrit :
> > When collecting information, it might be nice to have OS information.
> > That way, the user only has to go to Help > About and click on "Copy
&g
Le 04/12/2022 à 21:41, Scott Kostyshak a écrit :
When collecting information, it might be nice to have OS information.
That way, the user only has to go to Help > About and click on "Copy
Version Info" and all important information is copied; rather than
having to ask them to separa
When collecting information, it might be nice to have OS information.
That way, the user only has to go to Help > About and click on "Copy
Version Info" and all important information is copied; rather than
having to ask them to separately state it.
Is it OK if I add OS information?
I updated to the last version but the problem remains. I does not even keep the size of the window. The file "session" in the user folder was changed recently but my changes just don't seem to reach it.
(Does it matter when a file is saved variantly in LyX 2.3.3 and 2.3.5?)
(After unsubscribing,
Le 15/06/2020 à 20:45, _johnny7_...@web.de a écrit :
With LyX 2.3.3 on Mac, the session information seems not to be saved or
restored properly. This applies to the cursor position in documents and
to the UI (window and icon size). Sometimes, the UI settings are kept
but I cannot reproduce in
With LyX 2.3.3 on Mac, the session information seems not to be saved or
restored properly. This applies to the cursor position in documents and
to the UI (window and icon size). Sometimes, the UI settings are kept
but I cannot reproduce in which cases (closing only the document,
quitting LyX, it
There is now "TexRow concatenation" which allows to write to a string
buffer and still have the TexRow information, so maybe the first issue
is easy to fix if it uses that kind of mechanism. (There's now accurate
reporting for subcaptions thanks to this.
Not sure. The texrow li
hich allows to write to a string
buffer and still have the TexRow information, so maybe the first issue
is easy to fix if it uses that kind of mechanism. (There's now accurate
reporting for subcaptions thanks to this.
Not sure. The texrow lines will refer to the Rnw file created by LyX,
and the
reverse search to take advantage of new this information...
The next thing that we need for line tracking is Sweave support; sweave
does rewrite some parts of the document, and therefore the line numbers
are not accurate anymore. It is however possible to ask sweave to output
a correspondence
Le 19/10/15 15:07, Pavel Sanda a écrit :
Guillaume Munch wrote:
This finishes adding line tracking for math in the source panel and for
forward
search.
Sweet :)
The next thing that we need for line tracking is Sweave support; sweave
does rewrite some parts of the document, and th
Guillaume Munch wrote:
> This finishes adding line tracking for math in the source panel and for
> forward
> search.
Sweet :)
P
On Tue, Aug 18, 2015 at 4:27 PM, Scott Kostyshak wrote:
> On Tue, Aug 18, 2015 at 4:21 PM, Richard Heck wrote:
>> On 08/18/2015 04:19 PM, Scott Kostyshak wrote:
>>>
>>> On Tue, Aug 18, 2015 at 11:12 AM, Richard Heck wrote:
On 08/17/2015 06:13 PM, Pavel Sanda wrote:
>
> Scott Ko
On Tue, Aug 18, 2015 at 4:21 PM, Richard Heck wrote:
> On 08/18/2015 04:19 PM, Scott Kostyshak wrote:
>>
>> On Tue, Aug 18, 2015 at 11:12 AM, Richard Heck wrote:
>>>
>>> On 08/17/2015 06:13 PM, Pavel Sanda wrote:
Scott Kostyshak wrote:
>
> OK good to know. Let's see if anyone el
On 08/18/2015 04:19 PM, Scott Kostyshak wrote:
On Tue, Aug 18, 2015 at 11:12 AM, Richard Heck wrote:
On 08/17/2015 06:13 PM, Pavel Sanda wrote:
Scott Kostyshak wrote:
OK good to know. Let's see if anyone else has an opinion about putting
refresh() into exists().
Is the only reason the bug de
On Tue, Aug 18, 2015 at 11:12 AM, Richard Heck wrote:
> On 08/17/2015 06:13 PM, Pavel Sanda wrote:
>>
>> Scott Kostyshak wrote:
>>>
>>> OK good to know. Let's see if anyone else has an opinion about putting
>>> refresh() into exists().
>>
>> Is the only reason the bug described in the begining of
On 08/17/2015 06:13 PM, Pavel Sanda wrote:
Scott Kostyshak wrote:
OK good to know. Let's see if anyone else has an opinion about putting
refresh() into exists().
Is the only reason the bug described in the begining of the thread?
Is adding refresh() into the LFUN you want enough to fix the prob
On Mon, Aug 17, 2015 at 6:13 PM, Pavel Sanda wrote:
> Scott Kostyshak wrote:
>> OK good to know. Let's see if anyone else has an opinion about putting
>> refresh() into exists().
>
> Is the only reason the bug described in the begining of the thread?
It's the only specific reason I have come acro
Scott Kostyshak wrote:
> OK good to know. Let's see if anyone else has an opinion about putting
> refresh() into exists().
Is the only reason the bug described in the begining of the thread?
Is adding refresh() into the LFUN you want enough to fix the problem.
(I'm one of the victims who need to
ter (5), the PDF viewer is opened for a file that does not exist.
>> This should not happen because LFUN_BUFFER_VIEW_CACHE is only enabled
>> if the file exists, but exists() returns true. I think the reason for
>> this is explained by the following:
>>
>> -
>> (so
, but exists() returns true. I think the reason for
this is explained by the following:
-
(source: http://doc.qt.io/qt-4.8/qfileinfo.html)
To speed up performance, QFileInfo caches information about the file.
Because files can be changed by other users or programs, or even by
other parts of the sam
n for
this is explained by the following:
-
(source: http://doc.qt.io/qt-4.8/qfileinfo.html)
To speed up performance, QFileInfo caches information about the file.
Because files can be changed by other users or programs, or even by
other parts of the same program, there is a function that refreshes
Indeed. Let's forget about it, then.
JMarc.
Le 16 mars 2015 12:32:08 CET, "Jürgen Spitzmüller" a écrit :
>2015-03-15 18:47 GMT+01:00 Jean-Marc Lasgouttes:
>
>> We do not have a use case yet, but you commit that minus the part
>that
>> defines the set<> version.
>
>I am not really sure it makes s
2015-03-15 18:47 GMT+01:00 Jean-Marc Lasgouttes:
> We do not have a use case yet, but you commit that minus the part that
> defines the set<> version.
I am not really sure it makes sense if we just need VectorFromString, since
the change replaces push_back with insert in the template (since Set
Le 19/02/15 12:36, Jürgen Spitzmüller a écrit :
Jean-Marc Lasgouttes wrote:
Note that if you used a set instead of a vector, you would not have to check
for duplicates.
Actually, I cannot do this, since the insertion order must be maintained.
Indeed.
Of course getVectorFrom string gives yo
Jean-Marc Lasgouttes wrote:
> Note that if you used a set instead of a vector, you would not have to check
> for duplicates.
Actually, I cannot do this, since the insertion order must be maintained.
> Of course getVectorFrom string gives you a vector, but it should be easy
> enough to create a g
this
>> > is the correct thing to do, I just wanted to provide you with this
>> > information).
>>
>> BTW: why is the language default LHE and not the newer 8-bit encoding HE8?
>
> Probably because we do not have active competent developers (competent for
> this par
some others glyphs).
> > Note that if I remove the line
> > FontEncoding "LHE"
> > from the Hebrew definition, the ctests pass (I am not suggesting this
> > is the correct thing to do, I just wanted to provide you with this
> > information).
>
> BT
On 2015-02-18, Scott Kostyshak wrote:
> On Sat, Jan 24, 2015 at 8:02 AM, Juergen Spitzmueller wrote:
>> commit 16c33b5f6e3fd5ff8f278542d6d12bc7c82ffb93
>> Author: Juergen Spitzmueller
>> Date: Sat Jan 24 14:02:16 2015 +0100
>> Move font encoding information
Scott Kostyshak wrote:
> Note that if I remove the line
> FontEncoding "LHE"
> from the Hebrew definition, the ctests pass (I am not suggesting this
> is the correct thing to do, I just wanted to provide you with this
> information).
Actually, this is probably co
Jean-Marc Lasgouttes wrote:
> Only a profiler can tell you that. Note that if you used a set instead
> of a vector, you would not have to check for duplicates. Of course
> getVectorFrom string gives you a vector, but it should be easy enough to
> create a getSetFromString or better to create a g
Le 18/02/2015 13:09, Jürgen Spitzmüller a écrit :
The attached patch implements such a check and fixes the problem. My only
concern is that the small vector of encodings is rebuild each time
font_encoding() is called (and thus each time
Paragraph::Private::latexSpecialChar is accessed). Is this s
eX Error: Command \textquotedbl unavailable in encoding LHE.
>
> Note that if I remove the line
> FontEncoding "LHE"
> from the Hebrew definition, the ctests pass (I am not suggesting this
> is the correct thing to do, I just wanted to provide you with this
>
On Sat, Jan 24, 2015 at 8:02 AM, Juergen Spitzmueller wrote:
> commit 16c33b5f6e3fd5ff8f278542d6d12bc7c82ffb93
> Author: Juergen Spitzmueller
> Date: Sat Jan 24 14:02:16 2015 +0100
>
> Move font encoding information to languages.
>
After this commit I can no longer expor
On Thu, Jan 22, 2015 at 5:50 PM, Kartheek kark wrote:
> Hi,
> I am sorry and forgot to introduce myself.
> I am undergraduate student from India . I know the languages Java, c,c++,
> python . I found Lyx interesting as it was related to document processing .
> Hence i would like to know the detai
On Thu, Jan 22, 2015 at 4:23 PM, Kartheek kark wrote:
> Hi.
> I am new to this organisation and wanted to know what are the exact projects
> that are going on.
Hi Kartheek,
Is this SPAM? If not, can you please introduce yourself and talk about
your experience and interest in LyX? Why are you int
Hi.
I am new to this organisation and wanted to know what are the exact
projects that are going on.
Thanks .
On 07/02/2014 04:29 PM, Paul A. Rubin wrote:
Scott Kostyshak lyx.org> writes:
On Wed, Jul 2, 2014 at 1:50 PM, Jean-Marc Lasgouttes
lyx.org> wrote:
Le 02/07/14 17:07, Richard Heck a écrit :
There was a report from someone who did not have autosave enabled.
The other possibility is to loo
Scott Kostyshak lyx.org> writes:
>
> On Wed, Jul 2, 2014 at 1:50 PM, Jean-Marc Lasgouttes
lyx.org> wrote:
> > Le 02/07/14 17:07, Richard Heck a écrit :
> >
> >> There was a report from someone who did not have autosave enabled.
> >
> >
> > The other possibility is to look at changes that occurr
On 07/02/2014 03:40 PM, Georg Baum wrote:
Jean-Marc Lasgouttes wrote:
Le 02/07/14 17:07, Richard Heck a écrit :
There was a report from someone who did not have autosave enabled.
Maybe there are two different triggers? When I find some time, I'll play a
bit with autosave.
The other report c
Jean-Marc Lasgouttes wrote:
> Le 02/07/14 17:07, Richard Heck a écrit :
>> There was a report from someone who did not have autosave enabled.
Maybe there are two different triggers? When I find some time, I'll play a
bit with autosave.
> The other possibility is to look at changes that occurred
Richard Heck wrote:
> On 07/01/2014 04:36 PM, Georg Baum wrote:
>> Richard Heck wrote:
>>
>>> That was what I was thinking, too. Just guessing at this point.
>> Yes. It would be really nice if we had a more reliable way to reproduce
>> the crash. OTOH it is good that it does not occur very often;-
On Wed, Jul 2, 2014 at 1:50 PM, Jean-Marc Lasgouttes wrote:
> Le 02/07/14 17:07, Richard Heck a écrit :
>
>> There was a report from someone who did not have autosave enabled.
>
>
> The other possibility is to look at changes that occurred in Tabular code.
> The main difference that I see is new s
Le 02/07/14 17:07, Richard Heck a écrit :
There was a report from someone who did not have autosave enabled.
The other possibility is to look at changes that occurred in Tabular
code. The main difference that I see is new support for
insert/duplicate-row. Do we have indications that people ha
On 07/01/2014 04:36 PM, Georg Baum wrote:
Richard Heck wrote:
That was what I was thinking, too. Just guessing at this point.
Yes. It would be really nice if we had a more reliable way to reproduce the
crash. OTOH it is good that it does not occur very often;-)
I went over the code again and
On 07/01/2014 04:50 PM, Georg Baum wrote:
Richard Heck wrote:
That was what I was thinking, too. Just guessing at this point.
Another wild guess: Since the backtrace shows autoSave(), and autoSave()
runs in a separate thread and operates on the cloned buffer: Could the non-
thread-safety of th
Richard Heck wrote:
> That was what I was thinking, too. Just guessing at this point.
Another wild guess: Since the backtrace shows autoSave(), and autoSave()
runs in a separate thread and operates on the cloned buffer: Could the non-
thread-safety of the cloning business be the real problem? At
Richard Heck wrote:
> That was what I was thinking, too. Just guessing at this point.
Yes. It would be really nice if we had a more reliable way to reproduce the
crash. OTOH it is good that it does not occur very often;-)
I went over the code again and found and fixed a memory leak (and missing
On 07/01/2014 02:38 PM, Georg Baum wrote:
Richard Heck wrote:
On 06/30/2014 06:54 PM, Pavel Sanda wrote:
Richard Heck wrote:
Paragraph::write, so the crashing call to to_utf8 could come in any of
them. The crashing call certainly isn't the first one, since
"\begin_inset
smells little bit lik
Richard Heck wrote:
> On 06/30/2014 06:54 PM, Pavel Sanda wrote:
>> Richard Heck wrote:
>>> Paragraph::write, so the crashing call to to_utf8 could come in any of
>>> them. The crashing call certainly isn't the first one, since
>>> "\begin_inset
>> smells little bit like concurrency problem inside
On 06/30/2014 06:54 PM, Pavel Sanda wrote:
Richard Heck wrote:
Paragraph::write, so the crashing call to to_utf8 could come in any of
them. The crashing call certainly isn't the first one, since "\begin_inset
smells little bit like concurrency problem inside to_utf8.
we might try doing autosave
On 06/30/2014 06:54 PM, Pavel Sanda wrote:
Richard Heck wrote:
Paragraph::write, so the crashing call to to_utf8 could come in any of
them. The crashing call certainly isn't the first one, since "\begin_inset
smells little bit like concurrency problem inside to_utf8.
we might try doing autosave
Richard Heck wrote:
> Paragraph::write, so the crashing call to to_utf8 could come in any of
> them. The crashing call certainly isn't the first one, since "\begin_inset
smells little bit like concurrency problem inside to_utf8.
we might try doing autosave while using to_utf8 somewhere in ui?
p
Richard Heck wrote:
> The key part is:
>
> #15 0x00a99af0 in lyx::to_utf8(std::basic_string #std::char_traits, std::allocator > const&) ()
> No symbol table info available.
> #16 0x005c6577 in lyx::Paragraph::write(std::ostream&,
> #lyx::BufferParams const&, unsigned long&) const
Not sure how important it is, but looking at
#15 0x00a99af0 in lyx::to_utf8(std::basic_stringstd::char_traits, std::allocator > const&) ()
#16 0x005c6577 in lyx::Paragraph::write(std::ostream&,
lyx::BufferParams const&, unsigned long&) const ()
#17 0x005ed142 in lyx::Te
On 06/29/2014 08:06 AM, Jean-Marc Lasgouttes wrote:
What is thé contents of thé truncated document ?
Here's a longer backtrace:
#0 0x00a99af0 in lyx::to_utf8(std::basic_string,
std::allocator > const&) ()
No symbol table info available.
#1 0x005c6577 in lyx::Paragraph::write
What is thé contents of thé truncated document ?
JMarc
On 29 juin 2014 13:01:08 UTC+02:00, "José Matos" wrote:
>Hi,
> a fedora user submitted the following report
>https://bugzilla.redhat.com/show_bug.cgi?id=1114263
>
>I hope that some of the debug information p
Hi,
a fedora user submitted the following report
https://bugzilla.redhat.com/show_bug.cgi?id=1114263
I hope that some of the debug information provided helps to find the cause of
the crash. :-(
Regards,
--
José Abílio
ith this
> tool, and I don't know anything about the source code of LyX, so I couldn't
> gather anything meaningful (other than repeated references to "Cursor :
> public DocIterator", which seems to be the most recurrent line).
>
> I would like to get tips how to gi
about the source code of LyX, so I couldn't
gather anything meaningful (other than repeated references to "Cursor :
public DocIterator", which seems to be the most recurrent line).
I would like to get tips how to give you meaningful information about this
bug the next time I enco
list, the developer said some works have already be done.
> Maybe I'm wrong in my vision of this project... but is it possible to have
> more information about it and about works already done ?
> (I try the irc channel but there's no one)
>
For more info on this project and ple
e... A search field could be
good to find an action in the list. And i think at the end the result is to
save in a configuration file.
In the ideas list, the developer said some works have already be done.
Maybe I'm wrong in my vision of this project... but is it possible to have
more inform
On 03/06/2012 01:23 PM, Rob Oakes wrote:
Dear Developers,
I'm getting ready to publish the source for Word2LyX, but ran into one
last problem. I created an input filter/filetype to completely automate
the conversion of Word documents.
However, when run, I'm getting an error:
An error occurred
Dear Developers,
I'm getting ready to publish the source for Word2LyX, but ran into one
last problem. I created an input filter/filetype to completely automate
the conversion of Word documents.
However, when run, I'm getting an error:
An error occurred while running:
python "inputfile.docx" "ou
LyX Ticket Tracker wrote:
> #4832: missing converter dialog gives no information about originating format
>
> Comment:
>
> this does not look like the cause. can you give us some recipe how to
> reproduce your problem?
>
I think perhaps the case where this arose co
Christian Ridderström wrote:
On Mon, 29 Jun 2009, Paul A. Rubin wrote:
Christian Ridderström wrote:
For a Windoze user, the '~\Application\...' is probably going to be
a bit
difficult to understand
Did we at some point have a separate document with this information,
lik
On Mon, 29 Jun 2009, Paul A. Rubin wrote:
Christian Ridderström wrote:
For a Windoze user, the '~\Application\...' is probably going to be a bit
difficult to understand
Did we at some point have a separate document with this information, like
how we have a document about
Christian Ridderström wrote:
For a Windoze user, the '~\Application\...' is probably going to be a
bit difficult to understand
Did we at some point have a separate document with this information,
like how we have a document about the LaTeX configuration?
I don't r
Pavel Sanda wrote:
> > You cannot copy from the preamble?
>
> both directions are problematic. if i select something in lyx window then i
> never get it into preamble. opposite direction works only sometimes, eg
> when something is already in the selection buffer it stays there and dont
> get updat
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > > PS. Btw, it's annoying that I can't do a copy and paste from this about
> > > window. That could be useful e.g. for people that want to do bug reports.
> >
> > this is even more annoying with preamble box... :)
>
> You cannot copy from the pream
Pavel Sanda wrote:
> > PS. Btw, it's annoying that I can't do a copy and paste from this about
> > window. That could be useful e.g. for people that want to do bug reports.
>
> this is even more annoying with preamble box... :)
You cannot copy from the preamble?
Jürgen
Christian Ridderström wrote:
> PS. Btw, it's annoying that I can't do a copy and paste from this about
> window. That could be useful e.g. for people that want to do bug reports.
this is even more annoying with preamble box... :)
pavel
Hi,
When about to install new .layout file in LyX, I was trying to figure
out where (as I'm on Windowz). The answer can be found through the dialog
Help->About LyX
However, the information isn't exactly... detailed. It just says:
LyX Version 1.6.2
Vincent van Ravesteijn - TNW wrote:
What's the smiley for blushing?
rh
It's this one :$
(I hope)
Well, http://messenger.yahoo.com/features/emoticons/ claims it's: :">,
but that makes no sense to me. :-$ is alleged to be "Don't tell anyone".
rh
> What's the smiley for blushing?
>
> rh
It's this one :$
(I hope)
Vincent
José Matos wrote:
On Friday 08 August 2008 17:32:58 Abdelrazak Younes wrote:
You're in good hands with Richard :-)
Indeed. :-)
What's the smiley for blushing?
rh
On Friday 08 August 2008 17:32:58 Abdelrazak Younes wrote:
> You're in good hands with Richard :-)
Indeed. :-)
> Abdel
--
José Abílio
1 - 100 of 184 matches
Mail list logo
