Il 09/09/2011 21:51, Julien Rioux ha scritto:
On 09/09/2011 8:57 PM, Tommaso Cucinotta wrote:
I also checked the front-end part by Guenter, and I have to say we had
that potential issue
that
lyx -o path -e latex
would work, but
lyx -e latex -o path
This is a better syntax, isn'
Il 09/09/2011 22:58, Richard Heck ha scritto:
I have a worry here about what happens to associated files. E.g., if you
export a master document, where do the exported children go, and with
what names? This makes me wonder whether all we should really allow the
user to provide is a directory, and
Il 09/09/2011 23:55, Tommaso Cucinotta ha scritto:
Thinking aloud:
-) a destination folder might be inferred from the destination
file-name, i.e., its immediately containing folder.
And this is done in the attached patch.
Example of usage:
I have master.lyx including c/child.lyx (by relative
Il 10/09/2011 01:39, Tommaso Cucinotta ha scritto:
However, graphics files are not copied, so the exported latex cannot
compile unless you copy the additionally needed external files.
Independently on whether the output folder is explicitly provider or
automatically inferred from an output
Il 11/09/2011 19:24, Tommaso Cucinotta ha scritto:
Il 10/09/2011 01:39, Tommaso Cucinotta ha scritto:
However, graphics files are not copied, so the exported latex cannot
compile unless you copy the additionally needed external files.
Independently on whether the output folder is explicitly
Il 13/09/2011 14:43, Richard Heck ha scritto:
On 09/12/2011 07:52 PM, Tommaso Cucinotta wrote:
-bool Buffer::doExport(string const& format, bool put_in_tempdir,
- bool includeall, string& result_file) const
+bool Buffer::doExport(string const& target, bool pu
Il 13/09/2011 14:43, Richard Heck ha scritto:
I guess I'd prefer to a separate LFUN_BUFFER_EXPORT_TO routine here,
rather than this sort of trick with the arguments. There might one day
be other differences one wants. I think that would also make it easier
later to add the possibility to the fr
Il 14/09/2011 00:20, Julien Rioux ha scritto:
On 13/09/2011 1:52 AM, Tommaso Cucinotta wrote:
-bool doExport(std::string const& format, bool put_in_tempdir,
+bool doExport(std::string const& target, bool put_in_tempdir,
bool includeall = false) const;
Can
Il 15/09/2011 00:47, Julien Rioux ha scritto:
So that's how LFUN's with more than one argument are handled then, as
one string. No need to change the patch, I see your stance.
Ok, let me check whether further clean-ups are needed, and commit.
On a related note, check out the point 3) at the bo
Il 13/09/2011 14:43, Richard Heck ha scritto:
Anyway, some thoughts.
This will be very nice to have.
It's in: r39678.
There may be some additional work needed in order to deal with all the
possible cases (relative paths, absolute paths), but it seems to me that
it's mostly there. I tried ex
One last remark: I just found a SEGFAULT while exporting, that was there
already before my last export patch:
$ gdb --args ./src/lyx -e xhtml ./lib/doc/EmbeddedObjects.lyx
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version
Il 15/09/2011 03:54, Richard Heck ha scritto:
On 09/14/2011 09:21 PM, Tommaso Cucinotta wrote:
One last remark: I just found a SEGFAULT while exporting, that was
there already before my last export patch:
I get an assertion at line 192 of RenderPreview.cpp. I take it the
problem is that
Hi,
I just noticed I cannot start anymore the system-provided LyX on my
Ubuntu 11.04.
It say "Cannot read the configuration file".
AFAICGuess, this might be due to the new multi-format-extension patch.
The problem is that I cannot start LyX anymore, so I cannot reconfigure
(of course I can
Il 15/09/2011 15:13, Julien Rioux ha scritto:
Let's say I have a document, where all my figures are in ../images and
I want to export latex to out/latex and xhtml to out/xhtml and have my
images in out/images:
out/images <-- image files
out/latex <-- latex source
out/xhtml <-- xhtml source
Ho
Il 15/09/2011 14:08, Richard Heck ha scritto:
On 09/15/2011 05:31 AM, Tommaso Cucinotta wrote:
Hi,
I just noticed I cannot start anymore the system-provided LyX on my
Ubuntu 11.04.
It say "Cannot read the configuration file".
AFAICGuess, this might be due to the new multi-format
spaces, it should just work fine.
Thanks,
T.
Il 08/09/2011 02:55, Tommaso Cucinotta ha scritto:
Il 08/09/2011 02:24, Julien Rioux ha scritto:
Well, looking at your script again, we don't really need a script.
We just need to set up a odg->ps converter, then let LyX do the
ps2eps part
spaces, it should just work fine (I hope).
Thanks,
T.
Il 08/09/2011 02:55, Tommaso Cucinotta ha scritto:
Il 08/09/2011 02:24, Julien Rioux ha scritto:
Well, looking at your script again, we don't really need a script.
We just need to set up a odg->ps converter, then let LyX do the
ps2
tommaso@mobiletom:~/lyx-trunk-ws/lyx-trunk$ svn up
U src/Buffer.cpp
Aggiornato alla revisione 39680.
$ make
[...]
make[4]: ingresso nella directory "/home/tommaso/lyx-trunk-ws/lyx-trunk/src"
CXX Buffer.o
Buffer.cpp: In member function ‘void
lyx::Buffer::writeLyXHTMLSource(lyx::odocstream&, const
Hi,
what is the exporting to a LyX archive supposed to produce ?
I get this error (trunk):
tommaso@mobiletom:~/lyx-trunk-ws/lyx-trunk$ ./src/lyx
lib/doc/EmbeddedObjects.lyx
Menus.cpp(693): Menu warning: menu entries "Interruzione di pagina|I"
and "Visible Space|i" share the same shortcut.
Tr
Il 15/09/2011 03:54, Richard Heck ha scritto:
I get an assertion at line 192 of RenderPreview.cpp. I take it the
problem is that, without a GUI, we do not have a PreviewLoader, which is
what I use to create math images. I'll have to figure out what to do
about this.
The attached patch gets rid
Il 16/09/2011 01:07, Richard Heck ha scritto:
On 09/15/2011 06:45 PM, Tommaso Cucinotta wrote:
What is the intended invocation of the lyxpak.py script ?
It's supposed to produce a tar.gz or zip file that contains both the LyX
file and all associated files, too, e.g., images, and even
Il 07/09/2011 15:41, Richard Heck ha scritto:
Perhaps Julien and I can sort that out after your patch goes in.
There's even logic to that. This version could go to branch, whereas
Julien's idea would have to be trunk-only, due to the format changes.
Let's file an enhancement bug with 2.1.0 targ
Il 17/09/2011 02:18, Tommaso Cucinotta ha scritto:
which is used to set a corresponding boolean into the Format
structure, that is retrieved through Format::zippedNative().
The logic was not integrated directly within
FileName::guessFormatFromContents(),
I meant to say "The logic wa
too -- so, please, feel free to propose the best solution in this ODG case.
T.
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# file libreoffice2eps.py
# This file is part of LyX, the document processor.
# Licence details can be found in the file COPYING.
#
# \author Tommaso Cucinotta
#
Il 17/09/2011 17:29, Julien Rioux ha scritto:
I reworked your patch to do what I just described.
I didn't try it yet, a preliminary comment is: do we need to go to the
rc fileformat = 3 ? (AFAICR, the switch to 2 is still in trunk and is
not "public" yet)
It also makes your patch compile.
Il 17/09/2011 17:29, Julien Rioux ha scritto:
I think the logic about formats should be in Format.cpp, not in
FileName.cpp. FileName.cpp does not know about formats.
Hi,
I think this whole format detection logic in LyX is relatively "fragile".
FileName.cpp should not know about formats, but i
Il 18/09/2011 16:03, Tommaso Cucinotta ha scritto:
Please test.
I will later today, thanks.
Made a few tests including a sample dia. If it is included as external
material, then it works.
If it is included as a graphics inset, then it doesn't show on the
screen and I have this
o
Il 18/09/2011 20:37, Julien Rioux ha scritto:
On 18/09/2011 8:22 PM, Tommaso Cucinotta wrote:
Il 18/09/2011 16:03, Tommaso Cucinotta ha scritto:
Please test.
I will later today, thanks.
Made a few tests including a sample dia. If it is included as external
material, then it works.
If it
Il 18/09/2011 23:48, Pavel Sanda ha scritto:
atters.\n"
+ "\t-E [--export-to] fmt filename\n"
+ " where fmt is the export format of choice (see
--export),\n"
+ " and filename is the destination
filename.\n"
[apologies if you get this twice]
Il 18/09/2011 23:53, Julien Rioux ha scritto:
On 18/09/2011 10:36 PM, Tommaso Cucinotta wrote:
Would you like to change further things in this patch, or can it be
committed ?
No time to test unfortunately, but your patch looks quite good.
One small point
Il 19/09/2011 02:38, Julien Rioux ha scritto:
On 19/09/2011 1:52 AM, Tommaso Cucinotta wrote:
Done, thanks. Is a command-line guide included also within the on-line
docs (UserGuide.lyx) ?
While you're at it could you please have a look at
http://www.lyx.org/trac/ticket/4312
Done (li
Hi,
probably I'm repeating myself, but AFAICS tolerating future file-formats
in lyx would not be a bad idea.
In the last editing of a paper in these days, I had to instruct a PhD
student using an old Debian with LyX 1.6 to:
1) open the .lyx file with an editor
2) replace the 413 with 345 "ma
Il 19/09/2011 08:04, Pavel Sanda ha scritto:
Tommaso Cucinotta wrote:
Done, thanks. Is a command-line guide included also within the on-line docs
(UserGuide.lyx) ?
don't we have the new nifty advsearch feature of skimming through manuals
only? :)
Isn't asking on the list faster
Il 19/09/2011 08:47, Guenter Milde ha scritto:
On 2011-09-19, Vincent van Ravesteijn wrote:
You should not let the development LyX interfere with your system-wide LyX.
For me, the following works:
./configure --with-version-suffix=-svn --enable-build-type=release
The "--with-version-su
Il 19/09/2011 08:20, Pavel Sanda ha scritto:
+#include
+#include
the unfortunate thing is that this format.h is widely used elsewhere.
if there is a way how to not use them or move to less exposed place
it would be worth it.
I took the freedom to commit a patch (r39709) that hides all the
Z
Il 19/09/2011 13:00, Pavel Sanda ha scritto:
thats actually more complicated. for svn tree we have
RELEASE-NOTES for trunk
status.20x for branch
and in wiki we have
http://wiki.lyx.org/LyX/NewInLyX21 for trunk
http://wiki.lyx.org/LyX/NewInLyX20 for backported things in branch (special section
"
Il 19/09/2011 17:56, Vincent van Ravesteijn ha scritto:
Op 19-9-2011 12:08, Tommaso Cucinotta schreef:
I took the freedom to commit a patch (r39709) that hides all the
ZippedInfo and zipped_ cache inside Format.cpp, making this zipped_
cache a static variable. I don't think there'
Il 19/09/2011 15:12, Julien Rioux ha scritto:
Please read my entire emails.
I asked for a second opinion on the cache.
doesn't seem a big issue -- if it's unneeded, we can entirely get rid of
it (see the few benchmarks I sent).
I said the libreoffice2eps.py script is not necessary.
ok, ok
Il 19/09/2011 21:52, Vincent van Ravesteijn ha scritto:
So, we agree that Format::iszippedfile should be in filename.
Especially when the filenames are cached.
My initial patch was a modification of the isZipped() method of
FileName.cpp, with the problem that, in the end, we need to query
Hi all,
I'm forwarding the experienced problems of a colleague of mine trying to
use LyX 2.0.0 on a Mac -- I don't know whether these are known issues
and have been fixed, or if it's useful to report them.
Bye,
T.
When I open lyx v2.0 on my mac os 10.4, I get the following message:
"Ly
Il 19/09/2011 15:34, Richard Heck ha scritto:
In its present state, too, LyX is likely to do very weird things
(e.g., interpret inset arguments as plain text), if not crash, since
it will get confused about where it is in the parsing. If we had a
structured (e.g., XML) format, then we could ign
Il 19/09/2011 23:15, Julien Rioux ha scritto:
how LyX detects the format ? i.e., try this patch to Format.cpp:
Index: src/Format.cpp
===
--- src/Format.cpp(revisione 39709)
+++ src/Format.cpp(copia locale)
@@ -159,6 +159,7
Il 20/09/2011 17:13, Richard Heck ha scritto:
All of that said, the issue that started this, as I recall, had to do
with a failure to parse the preferences file. In that case, surely,
LyX should just start, throwing a warning, and perhaps asking if the
user would like to erase the invalid file an
Il 19/09/2011 20:41, Vincent van Ravesteijn ha scritto:
Op 19-9-2011 20:05, Tommaso Cucinotta schreef:
I don't know whether 1.5ms of saved time (per query) is enough to
justify the existence of the cache. Please, comment.
Not if there are 6 queries.
The previous benchmarks were r
Il 19/09/2011 15:12, Julien Rioux ha scritto:
Anyway, I now get this error when I open the graphics dialog in your
example file:
gzip: /home/jrioux/dropbox/lyx/tests/kk.odg has more than one
entry--rest ignored
../../../src/support/Systemcall.cpp(259): Systemcall: 'gunzip -c
/home/jrioux/drop
Il 20/09/2011 17:13, Richard Heck ha scritto:
If you want to file a bug for this, cc'ing me, I will get to it.
The non-sophisticated fix seems as easy as the attached. User gets a
warning on the console in case of problems.
T.
Index: src/LyX.cpp
=
Il 27/09/2011 15:51, Julien Rioux ha scritto:
On 20/09/2011 12:05 AM, Tommaso Cucinotta wrote:
Il 19/09/2011 23:15, Julien Rioux ha scritto:
Sorry, not much time. Don't you also get this behavior?
Not of course: for me, it works like a charm! I can insert dia files (as
graphics) an
Il 27/09/2011 23:49, Richard Heck ha scritto:
On 09/27/2011 05:27 PM, Tommaso Cucinotta wrote:
AFAICS, it doesn't find a direct converter from ODG to PNG, so it
gives up. So, my big question:
*) Does LyX embed any (even naive) algorithm for automatically finding
a "conversion pa
Il 28/09/2011 01:02, Tommaso Cucinotta ha scritto:
Il 27/09/2011 23:49, Richard Heck ha scritto:
The mystery is why the fall-back to convert isn't employed here.
From my little investigation:
1) there's no path in the graph from ODG to EPS (pls, find attached
the dumped list of
Il 28/09/2011 16:36, Rudi Gaelzer ha scritto:
I don't know if this has already been reported. I made a quick scan
through both the user and devel lists and couldn't find anything related.
While editing a text riddled with mathematical formulae, I had to use
advanced search several times to
Il 28/09/2011 20:40, Rudi Gaelzer ha scritto:
The document I'm working right now has thousands of formulas and I've
been using the advanced search pretty heavily. I can detect the
increasing memory load even with the very simple text that I attached
(memory.lyx). I was continually searching for
Hi,
if I start LyX with -dbg undo, why do I get the creation of 3 undo
groups for each single (read-only) cursor movement ?
For example, just moving right over a letter, gives me:
Undo.cpp(498): +++Creating new group 11
Undo.cpp(511): ---End of group 11
Undo.cpp(498): +++Creating
Il 29/09/2011 00:30, Jean-Marc Lasgouttes ha scritto:
Le 29/09/2011 00:05, Tommaso Cucinotta a écrit :
Also, I noticed a monotonic memory usage increase while editing the
document and especially creating math insets and deleting them later. I
guess this is due to the Undo feature, that keeps
Il 28/09/2011 06:02, Julien Rioux ha scritto:
On 28/09/2011 1:02 AM, Tommaso Cucinotta wrote:
Now, AFAICS, there are 2 possibilities:
a) flood the graph with "low-priority" (or, if you prefer, high-cost)
fake edges, basically from
each node (handled by convert) to any other node (
Il 29/09/2011 16:24, Alex Fernandez ha scritto:
Luckily, eLyXer is highly configurable. You can add a new converter
line in src/conf/base.conf:
[ImageConfig.converters]
myconverter:binary "$input" --export "$output"
and use it from the command line:
$ eLyXer --converter myconverter inpu
Il 29/09/2011 16:25, Richard Heck ha scritto:
Now, adding the EPS to PNG conversion explicitly allows LyX to find
the conversion path.
This is fine for branch. Note that it should also allow previews of ODG
pictures in LyX.
I can't remember whether we added ODG (and the "zipped=native" flag in
Il 29/09/2011 23:37, Alex Fernandez ha scritto:
Alternatively, one could think of pulling all the conversion logic
(along with configuration files, graph path discovery, etc.) *out of LyX*,
and make it a powerful independent tool for image and file conversion,
over which LyX would depend (and ely
Il 30/09/2011 12:15, Jean-Marc Lasgouttes ha scritto:
What do we see?
1/ there is a continuous drift of memory use
2/ the most important part is the agregation of small allocations (not
very useful...)
3/ the second one is related to font loading by qt (remains stable)
4/ the third one is the
Il 30/09/2011 08:36, Tommaso Cucinotta ha scritto:
Il 29/09/2011 23:37, Alex Fernandez ha scritto:
Alternatively, one could think of pulling all the conversion logic
(along with configuration files, graph path discovery, etc.) *out of
LyX*,
and make it a powerful independent tool for image
Hi,
the attached patch adds the "-C" option to LyX, allowing to use its
converters
for arbitrary files conversions, e.g.:
lyx -C /path/to/source.dia /path/to/dest.eps
lyx --convert-to /path/to/source.dia /path/to/dest.eps
Despite being useful in general (as this is more powerful than
Ima
Il 01/10/2011 19:01, Rudi Gaelzer ha scritto:
On Friday 30 September 2011 21:04:35 Tommaso Cucinotta wrote:
> For the increased memory usage notified by Rudi, if there were any
> problem with handling the Undo instances, then we should have seen
> something about Undo into the val
Il 02/10/2011 22:18, Alex Fernandez ha scritto:
I have uploaded to Savannah a test version which uses this feature:
http://download-mirror.savannah.gnu.org/releases/elyxer/older/elyxer-lyx-C.py
To use LyX as a converter:
$ elyxer --converter=lyx input.lyx output.html
It is a bit experimenta
Hi Vincent,
do we have currently any git branch on gitorious that tracks closely the
svn trunk ? i.e., such that any svn commit is immediately reflected
(pushed) on it ?
Thanks,
T.
Il 04/10/2011 10:02, Alex Fernandez ha scritto:
Hi Tommaso,
On Mon, Oct 3, 2011 at 8:48 AM, Tommaso Cucinotta wrote:
On a related note, when trying to use the --destdirectory option, I get:
Exception: Unused arguments: ['--destdirectory', '/tmp']
Strange, I
Il 04/10/2011 10:08, Vincent van Ravesteijn - TNW ha scritto:
Hi Tommaso,
No, we don't have one yet. Uptil now it is all manual labor.
However, I happen to have installed a git repo on my own server now,
to which I will gradually add more functionality.
Also, I think in the end I probably fo
Il 04/10/2011 15:28, Jean-Marc Lasgouttes ha scritto:
Le 01/10/2011 02:04, Tommaso Cucinotta a écrit :
These are just cleanup ops that are not explicitly done on program exit,
but not a big deal, actually. They could help in having a better cleanup
of LyX at exit, but I'm not sure any of
Il 04/10/2011 17:26, Alex Fernandez ha scritto:
It is the same option as before. But now, if the argument is found in
ImageConfig.converters then it is used as a shortcut to the configured
command line; otherwise the whole command supplied is used. For
example the new option:
[ImageConfig.conv
Il 05/10/2011 10:06, Alex Fernandez ha scritto:
On Tue, Oct 4, 2011 at 7:29 PM, Tommaso Cucinotta wrote:
Very nice. One last thing. I guess I'd need a test in configure.py about the
version of elyxer currently installed, so probably there's someway to
issue a "elyxer --version&q
Il 05/10/2011 12:13, Alex Fernandez ha scritto:
As this option is new, only use it as default if you detect a LyX version
that supports it (currently only the development version).
Is there any way to get a simple version string from the command line?
The LyX format number would be ideal, as it
Il 05/10/2011 20:37, Rudi Gaelzer ha scritto:
All right, I installed valgrind and ran it as per instructions.
When it finally opened the text, the process massif-amd64-li... was
using 13.5%MEM and the demand was increasing very slowly without any
operation on the text.
When I opened the A
Il 05/10/2011 22:54, Tommaso Cucinotta ha scritto:
2) try to recompile LyX from the sources, to check whether the problem
still shows up on your system or not in the current trunk. Shortly
(but it's going to take half an hour or so):
svn co svn://svn.lyx.org/lyx/lyx-devel/trunk lyx-tru
Hi,
I was a bit unhappy with the current command-line syntax for the new
--export-to (-E) option, and the presumably well-accepted --convert-to
(-C) one I sent on the list a few days ago. Let me recap:
lyx -E [--export-to] fmt filename
lyx -C [--convert-to] sourcefile destfile
on a relat
Il 06/10/2011 10:27, Guenter Milde ha scritto:
Maybe the current discussion can give some momentum to the
long standing issue?
http://www.lyx.org/trac/ticket/3402
Please, try the committed version, it should fix the mentioned ticket.
T.
Il 06/10/2011 15:50, Tommaso Cucinotta ha scritto:
Il 06/10/2011 10:27, Guenter Milde ha scritto:
Maybe the current discussion can give some momentum to the
long standing issue?
http://www.lyx.org/trac/ticket/3402
Please, try the committed version, it should fix the mentioned ticket
Il 06/10/2011 18:58, Julien Rioux ha scritto:
We have "Export as..." at the top of the menu and "More options..." at
the bottom, could they be moved together?
I struggle at getting the rationale behind the "More Options..." entry.
You are supposed to enter a custom command that performs the ac
Il 06/10/2011 19:02, Julien Rioux ha scritto:
By the way I still get this, and it happens whether I have the
converter cache enabled or not. Could you please look into it?
Sure, let's re-make the point. Can you, please, open that "odg.lyx" file
with "-dbg any", and send the whole output, alo
Il 06/10/2011 21:02, Richard Heck ha scritto:
On 10/06/2011 02:27 PM, Julien Rioux wrote:
On 05/10/2011 11:49 PM, Tommaso Cucinotta wrote:
lyx -c source.svg -o dest.eps # convert arbitrary formats
(extension-based format detection for output)
lyx -c -i svg source.svg -e eps -o dest.eps
Il 06/10/2011 19:52, Julien Rioux ha scritto:
On 06/10/2011 7:36 PM, Tommaso Cucinotta wrote:
Il 06/10/2011 19:02, Julien Rioux ha scritto:
By the way I still get this, and it happens whether I have the
converter cache enabled or not. Could you please look into it?
A few questions:
1) what
Il 06/10/2011 23:21, Julien Rioux ha scritto:
On 06/10/2011 11:05 PM, Tommaso Cucinotta wrote:
A few questions:
1) what was exactly the visible problem ? (from your log I can't see
anything
different from what I can see in my own log -- the only problem is
that it
probably still fai
Il 06/10/2011 23:53, Julien Rioux ha scritto:
My easy fix would be to query formats and not even try to call
readBB_from_PSFile() unless the file is actually eps or eps.gz. Can I
ask why is this reading of the bounding box done ? Note that it may also
imply unzipping the file and searching for
Il 07/10/2011 00:03, Uwe Stöhr ha scritto:
Hi Tommaso,
I get this error:
D:\LyXSVN\lyx-devel\src\frontends\qt4\FileDialog.cpp(99) : error
C2664: 'QFileDialog::getSaveFileName' : cannot convert parameter 5
from 'QString' to 'QString *'
No user-defined-conversion operator available that
Il 07/10/2011 00:51, Richard Heck ha scritto:
On 10/06/2011 04:42 PM, Tommaso Cucinotta wrote:
I'm sure you have some concrete "trouble scenario" in your
mind. Please, explicit it.
The only scenario I have in mind is users complaining when such things fail
and it's got no
Il 07/10/2011 01:32, Uwe Stöhr ha scritto:
Thanks, this compiles. I'm using Qt 4.7.4.
pls, let me know as well whether the Export->Export As... dialog works
fine or you have any problems or suggestions.
T.
Il 07/10/2011 00:17, Julien Rioux ha scritto:
On 07/10/2011 12:10 AM, Tommaso Cucinotta wrote:
I must be missing some piece of the puzzle here. Is this related to DPI
settings and the possibility for the user to crop in cm/mm/in, rather
than pixels ?
So, are you suggesting to ditch
Current trunk gives these warnings, which seem related to me.
Buffer.cpp:4197:42: warning: suggest parentheses around ‘&&’ within ‘||’
int Buffer::spellCheck(DocIterator & from, DocIterator & to,
[...]
// If from is at the end of the document (which is possible
// when leaving the mathed) LyX wi
Il 07/10/2011 09:01, Guenter Milde ha scritto:
Any supported format (*.*)
ps (*.ps)
pdf (*.pdf)
pdf2 (*.pdf)
pdf3 (*.pdf)
LyX should know a "user level" name of these formats and present it to the
user (also in the preferences GUI). This is what we do with e.g. tex-source
encoding, where utf8-pl
Il 07/10/2011 09:20, Vincent van Ravesteijn ha scritto:
> FileDialog::Result FileDialog::save(QString const& path,
> -QStringList const& filters, QString const& suggested)
> +QStringList const& filters, QString const& suggested,
> +QString& selectedFilter)
[...]
It's anyway a
Hi all,
in the recently added Export As... dialog, we need to enumerate the
possible export formats for the current LyX document.
Originally I had thought this was achievable by checking the
Format::document()
method, however it was returning true also for XLS, ODS, CSV and other
formats for w
Il 08/10/2011 01:08, Lars Gullik Bjønnes ha scritto:
One thing I'd like your input on: Do you want the reference to the svn
commit revisions kept in the git commit messages? Or should I prune them
as well?
What happens with Trac integration ? We used to refer to commits
from the wiki, from other
Hi all,
I just dropped a ticket about an assertion triggered as follows (on
current trunk r39819):
0) Activate instant preview from prefs
1) C-S-f (open the find advanced panel)
2) C-m (start math inset)
3) Menu: Insert->Regular Expression->Anything
4) C-Home
5) Cursor right twice
For details
Hi,
still looking at cleanup code on exit, I found a few TODOs about the
GuiProgress
singleton instance created by GuiView, that we never knew when to delete.
The attached patch fixes this by using a shared_ptr.
Any comment ? Would it be useful to have this in ? The rationale is as
usual to
Il 19/10/2011 04:02, Richard Heck ha scritto:
This fixes the assertion,
yes, I thought this was priority #1 for stability reasons, that's why I
committed without discussing on the list.
but isn't the layout combo still out of sync with the Advanced F&R
dialog's work area? In the test case,
Il 19/10/2011 15:06, Pavel Sanda ha scritto:
tomm...@lyx.org wrote:
+ LFUN_BUFFER_EXPORT_AS, // tommaso 20111006
just a glitch but unless this is intended for branch backporting its good
to keep RELEASE-NOTES in sync...
Done in r39888.
T.
I just updated the patch adding the "paste as unformatted text"
capability to LyX.
It fixes enhancement #7226, and it partially addresses #6731.
It is attached. Comments are very welcome.
Thx,
T.
Index: src/LyXAction.cpp
===
Il 29/10/2011 03:05, Richard Heck ha scritto:
On 10/28/11 6:30 PM, Tommaso Cucinotta wrote:
I just updated the patch adding the "paste as unformatted text"
capability to LyX.
It fixes enhancement #7226, and it partially addresses #6731.
It is attached. Comments are very welcome.
Il 29/10/2011 23:00, rgh...@lyx.org ha scritto:
Author: rgheck
Date: Sat Oct 29 23:00:23 2011
New Revision: 40073
URL: http://www.lyx.org/trac/changeset/40073
Log:
Initial work for view source improvements.
Just to add a comment to the initial posting: I can remember that,
apparently,
I was m
Il 29/10/2011 23:29, Uwe Stöhr ha scritto:
If this will not be backported to branch, can you please add an entry
here:
http://wiki.lyx.org/LyX/NewInLyX21
If should go to branch can you please give me a short description what
the new menu entries do exactly so that I can update the docs?
AFAI
Il 29/10/2011 23:29, Uwe Stöhr ha scritto:
If should go to branch can you please give me a short description what
the new menu entries do exactly so that I can update the docs?
I have a couple of suggestions for menus and shortcuts:
1) The [Edit]->[Paste Special...]->[Plain Text] seems to me s
Il 30/10/2011 02:29, PhilipPirrip ha scritto:
I hoped to have my grace files included into a document and being able
to produce a pdf (by pdflatex), but that seems not to work. Grace
simply does not export to PDF.
I tried to chain the conversion process in LyX under Linux, but that
seemed not t
Il 30/10/2011 12:08, Vincent van Ravesteijn ha scritto:
Op 30-10-2011 10:40, Tommaso Cucinotta schreef:
LyX can "chain" converters automatically for you. You can see the
graph of converters here:
http://retis.sssup.it/~tommaso/lyx-converters.pdf
Maybe it would be nice to imple
801 - 900 of 1309 matches
Mail list logo