Re: Do we have to have both Installer and LyxWinInstaller?
On Sun, 21 Jan 2007, Bo Peng wrote: Joost and Uwe, Could you please try to merge the two windows installers? It is definitely confusing to have two installers so please at least put a README file explaining the differences between them. If you guys can not reach an agreement on some issues, please bring them up and let Michael make his decisions. I think the problem is that Uwe hasn't been able to reach Joost http://article.gmane.org/gmane.editors.lyx.devel/76189/match=joost AFAICT, it's exactly a month since Joost's last post http://article.gmane.org/gmane.editors.lyx.devel/74630/match=joost Maybe Joost is busy, does anyone know? cheers /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Do we have to have both Installer and LyxWinInstaller?
Joost and Uwe, Could you please try to merge the two windows installers? It is definitely confusing to have two installers so please at least put a README file explaining the differences between them. If you guys can not reach an agreement on some issues, please bring them up and let Michael make his decisions. Cheers, Bo
Re: getting rid of lyx.bat - Aiksaurus problem
On Mon, Jan 22, 2007 at 01:33:31AM +0100, Uwe Stöhr wrote: > Now I implemented in the installer that Aiksaurus is registered as standalone > program. The installer > sets the needed environment variable. > This has unfortunately the disadvantage that invoking the thesaurus, when LyX > is started the first > time directly after the installation, it crashes. This crash occurs because > the Aiksaurus data > couldn't be found. This is because the environment variable was set via the > registry and Windows > always needs some time to accept this change. > > Has anybody of the Windows people an idea? (Enrico?) Do you mean that you directly set the variable in HKCU\Environment? Instead, why don't you try setting the path to the Aiksaurus directory through "HKCU\Software\Aiksaurus\Data Path" (according to the patch in development/Win32/patches)? > besides this problem, lyx.bat is now only: > > @echo off > SET LANG=de_DE > start "LyX" "lyx.exe" %* Are you aware that the console hiding code is no more in place, such that using a lyx.bat doesn't hide the cmd window anymore? -- Enrico
getting rid of lyx.bat - Aiksaurus problem
Last week we discussed how to include the menu language setting to lyxrc. I think this would be an improvement because then we could get rid of the lyx.bat file that is currently used to start LyX on Windows. lyx.bat calls lyx.exe, sets temporarily the language environment variable and the environment variable for Aiksaurus. Now I implemented in the installer that Aiksaurus is registered as standalone program. The installer sets the needed environment variable. This has unfortunately the disadvantage that invoking the thesaurus, when LyX is started the first time directly after the installation, it crashes. This crash occurs because the Aiksaurus data couldn't be found. This is because the environment variable was set via the registry and Windows always needs some time to accept this change. Has anybody of the Windows people an idea? (Enrico?) besides this problem, lyx.bat is now only: @echo off SET LANG=de_DE start "LyX" "lyx.exe" %* So Abdel, if you could apply your patch to set the language in lyxrc, lyx.bat can go. regards Uwe Btw., I uploaded my installer source code to SVN under \development\Win32\packaging\LyXWinInstaller
Re: Converters and encodings
On Sun, Jan 21, 2007 at 10:41:29PM +0100, Georg Baum wrote: > Enrico Forestieri wrote: > > I had a look at the code and come to the conclusion that the FileName > > class with its toFilesystemEncoding method is not of help here. This > > is because we have to also deal with non-absolute paths and some > > arguments may also be in utf8. > > Why non-absolute paths? There's a comment in converter.C about the fact that some converters can only output files to the current directory, so makeRelPath is used with first and second arguments as utf8 encoded paths. Whereas the first argument can be easily converted to the file system encoding (it's a FileName), the second one is the path encoded as an utf8 string. > In the past we were moving to absolute paths > wherever possible in order to get rid of the Path class that is simply too > confusing to use. Really? I find it quite clever ;-) > And why would some arguments be in utf8? AFAIK commandline arguments should > always be in the current locale. I am talking about the parameters that are added to the command line to be executed. Due to lack of time, I was not able to ascertain how they are stored in the Converter class. AFAIK they could be in utf8 encoding. > > IMO we should have functions for directly converting from utf8 to the > > file system encoding and vice versa. I would like to hear opinions about > > this issue and, for discussion, attach here a patch solving these > > problems. > > As I already wrote to Abdel last week the fact that all our filename related > code does still use std::string and not docstring is only of temporary > nature. I did not convert it yet because that would mean a lot of > conversions e.g. in some bibtex related code that cannot be converted to > docstring easily. Oh, that's it. I was wondering why you chose to go through those double conversions... > Therefore I don't think that we should convert from/to utf8 directly. If a > function > > std::string const to_filesystem8bit(docstring const & s); > > is needed, then add it, but instead of direct conversion from/to utf8 I > would rather change all filename related code to docstring. I can do that > if you want, but not too soon (the next week will be busy). Yes, I thought about implementing to_filesystem8bit, but then realized that I would have not used it by alone but always in conjunction with from_utf8. Introducing to_filesystem8bit, only converter.C and the two python scripts should be changed. I'll try to do it. BTW, I never use anything but ascii paths ;-) -- Enrico
Bugs in 16795
The TOC defect is still present, where if you select an entry in the TOC window, when you re-select the TOC window the document jumps to the start. Also, Chapter Title spacing is off. The chapter title is over lapping the last sentence of the previous chapter.
Re: filename with space truncated n external insets dialog
Bernhard Roider wrote: > Hello! > > The attached patch fixes the problem in trunk. The problem was that for the filename one token was > retrieved from the lexer instead of the whole remaining line. Thanks a lot. The fix is correct (the same code is used in InsetGraphicsParams::Read), and I put it in. Jean-Marc, I guess this is for 1.4.4, too? > PS: I think the preferred way for contributing should be via a bug report? The mailing list is fine, especially if something requires discussion. It can happen that people are too busy with other stuff to answer. In that case use bugzilla to make sure that nothing gets forgotten. Christian Ridderström sent a better summary on friday. Is it on the wiki yet? Georgg
Re: Repost: Bullets menu on LyX/Mac
Stephen Buonopane wrote: Sorry for the repost, but the original thread seems to have been 'captured' by another poster who changed the topic. The problem with the bullets described below has been confirmed by two others on Mac. Does it occur in Windows? Linux? Not on Windows with LyX 1.4.3-4 -- bullets are black (in most cases) on gray background. /Paul
Re: Converters and encodings
Enrico Forestieri wrote: > Currently, a converter path cannot contain non-ascii characters on systems > not using utf8 as the local encoding. Moreover, arguments are also passed > in utf8 encoding. This is clearly wrong and produces assertions, eg. on > Windows but also on Solaris when using a locale different from utf8. This is wrong indeed. I thought that I converted all filenames given as commandline arguments, but obviously I missed some. > I had a look at the code and come to the conclusion that the FileName > class with its toFilesystemEncoding method is not of help here. This > is because we have to also deal with non-absolute paths and some > arguments may also be in utf8. Why non-absolute paths? In the past we were moving to absolute paths wherever possible in order to get rid of the Path class that is simply too confusing to use. And why would some arguments be in utf8? AFAIK commandline arguments should always be in the current locale. > IMO we should have functions for directly converting from utf8 to the > file system encoding and vice versa. I would like to hear opinions about > this issue and, for discussion, attach here a patch solving these > problems. As I already wrote to Abdel last week the fact that all our filename related code does still use std::string and not docstring is only of temporary nature. I did not convert it yet because that would mean a lot of conversions e.g. in some bibtex related code that cannot be converted to docstring easily. Therefore I don't think that we should convert from/to utf8 directly. If a function std::string const to_filesystem8bit(docstring const & s); is needed, then add it, but instead of direct conversion from/to utf8 I would rather change all filename related code to docstring. I can do that if you want, but not too soon (the next week will be busy). Georg
Re: [Cvslog] r16799 - /lyx-devel/trunk/src/text.C
Hello everybody,
this patch should cure all crashes related to accepting a change. I will
provide a similar patch for reject-change tomorrow (hopefully).
One thing that I am not very happy about is the invocation of DEPM,
because the latter makes use of cursors, calls the undo mechanism, etc.
(too much for this simple case).
I intend to write a simplified version of DEPM. What I would like to use
is a loop iterating over a range of paragraphs that (1) removes empty
lines, (2) strips leading spaces, and (3) removes double spaces.
Does anybody know whether there are already some methods that I can reuse?
Michael
[EMAIL PROTECTED] schrieb:
Author: schmitt
Date: Sun Jan 21 22:20:51 2007
New Revision: 16799
URL: http://www.lyx.org/trac/changeset/16799
Log:
* src/text.C: acceptChange(): complete rewrite; there should be no
crashes any more
Modified:
lyx-devel/trunk/src/text.C
Modified: lyx-devel/trunk/src/text.C
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/text.C?rev=16799
==
--- lyx-devel/trunk/src/text.C (original)
+++ lyx-devel/trunk/src/text.C Sun Jan 21 22:20:51 2007
@@ -847,42 +847,88 @@
void LyXText::acceptChange(LCursor & cur)
{
- // FIXME: change tracking (MG)
-
BOOST_ASSERT(this == cur.text());
- if (!cur.selection() && cur.lastpos() != 0)
+ if (!cur.selection())
return;
- // FIXME: we must handle start = end = 0
-
- recordUndoSelection(cur, Undo::INSERT);
-
- DocIterator it = cur.selectionBegin();
- DocIterator et = cur.selectionEnd();
- pit_type pit = it.pit();
- for (; pit <= et.pit(); ++pit) {
- pos_type left = (pit == it.pit() ? it.pos() : 0);
- pos_type right = (pit == et.pit() ? et.pos() :
pars_[pit].size());
-
- // handle imaginary end-of-par character first
- if (right == pars_[pit].size() &&
!pars_[pit].isUnchanged(right)) {
- if (pars_[pit].isInserted(right)) {
- pars_[pit].setChange(right,
Change(Change::UNCHANGED));
- } else {
- // if (pit + 1 < et.pit()) {
- // setCursorIntern(cur, pit + 1, 0);
- // backspacePos0(cur);
- // }
+ recordUndoSelection(cur, Undo::ATOMIC);
+
+ DocIterator beg = cur.selectionBegin();
+ DocIterator end = cur.selectionEnd();
+
+ // first, accept changes within each individual paragraph (do not
consider end-of-par)
+
+ for (pit_type pit = beg.pit(); pit <= end.pit(); ++pit) {
+ // ignore empty paragraphs; otherwise, an assertion will fail for acceptChanges(0, 0)
+ if (pars_[pit].size() == 0)
+ continue;
+
+ // do not consider first paragraph if the cursor starts at pos
size()
+ if (pit == beg.pit() && beg.pos() == pars_[pit].size())
+ continue;
+
+ // do not consider last paragraph if the cursor ends at pos 0
+ if (pit == end.pit() && end.pos() == 0)
+ break; // last iteration anyway
+
+ pos_type left = (pit == beg.pit() ? beg.pos() : 0);
+ pos_type right = (pit == end.pit() ? end.pos() :
pars_[pit].size());
+ pars_[pit].acceptChanges(left, right);
+ }
+
+ // next, accept imaginary end-of-par characters
+ // iterate from last to first paragraph such that we don't have to care for a changing 'end'
+
+ pos_type endpit = end.pit();
+ for (pit_type pit = endpit; pit >= beg.pit(); --pit) {
+ pos_type pos = pars_[pit].size();
+
+ // last paragraph of the selection requires special handling
+ if (pit == end.pit()) {
+ // skip if the selection ends before the end-of-par
+ if (end.pos < pos)
+ continue;
+
+ // skip if the selection ends with the end-of-par and
this is not the
+ // last paragraph of the document
+ // note: the user must be able to accept the end-of-par
of the last par!
+ if (end.pos == pos && pit != pars_.size() - 1)
+ continue;
+ }
+
+
+ if (!pars_[pit].isUnchanged(pos)) {
+ if (pars_[pit].isInserted(pos)) {
+ pars_[pit].setChange(pos,
Change(Change::UNCHANGED));
+ } else { // isDeleted
+ if (pit == pars_.size()) {
+ // we cannot remove a par break at the
end of the last paragraph
+ // instead, we mark it unchanged
+ pars_[pit].s
[patch] Get rid of InsetLaTeXAccent - finally
As announced I did some further work on the removal of InsetLaTeXAccent. The
lyx2lyx stuff is now finished and working, and I also got a replacement for
LaTeX output up and running (but it is very slow - don't try to output the
user guide, it will take many minutes).
It works like this:
lib/unicodesymbols contains a list of ucs4 code points and LaTeX commands.
This list is used to output characters that cannot be encoded in the
current encoding and replaces the hardcoded stuff for euro & co in
Paragraph::Pimpl::simpleTeXSpecialChars. It is also used for the characters
that were handled by InsetLaTeXAccent formerly, although I only added those
code points manually that the attached test file uses. Later we can
complete this list using similar existing databases like that of plastex.
The nice thing of this list is that we do not need to care anymore which
encoding has which characters - we are using iconv to get that information
(see below).
José had a different idea some time ago: Use a post processor on the
generated .tex file to convert it e.g. from utf8 to the proper LaTeX
commands. I don't think that this is feasible, since such a postprocessor
would need to parse the TeX code (e.g. scanning for \selectlanguage or
\inputencoding), and this can fail too easily. Therefore I think that we
should do this in LyX, because we have all needed information there (but of
course use an external character database, so that users can extend it if
needed).
The Encoding class queries iconv for a translation table from ucs4 to all
255 code points on startup (therefore you'll get a lot of iconv error
messages on startup - ignore them for now). This is done so that the
Encoding class can tell whether a ucs4 character can be encoded in this
encoding or not.
In order to properly output accents on spaces I had to remove an (IMO ugly)
hack that tries to do clever things with spaces and font changes (see
http://bugzilla.lyx.org/show_bug.cgi?id=1428). I am not sure whether this
is a file format change, but IMO we should not try to be clever here and
simply output what the user entered. If I don't want \textbf{xxx }, then I
should not mark the space as bold face.
Comments?
If this is OK in general I'll do some profiling, resolve the speed issues
and put this in.
Georg
latexaccent-all-257.lyx
Description: application/lyx
latexaccent-all.lyx
Description: application/lyx
Index: src/paragraph.h
===
--- src/paragraph.h (Revision 16797)
+++ src/paragraph.h (Arbeitskopie)
@@ -112,7 +112,7 @@ public:
void write(Buffer const &, std::ostream &, BufferParams const &,
depth_type & depth) const;
///
- void validate(LaTeXFeatures &) const;
+ void validate(LaTeXFeatures &, LyXFont const &) const;
///
int startTeXParParams(BufferParams const &, odocstream &, bool) const;
Index: src/insets/insettext.C
===
--- src/insets/insettext.C (Revision 16797)
+++ src/insets/insettext.C (Arbeitskopie)
@@ -338,8 +338,13 @@ int InsetText::docbook(Buffer const & bu
void InsetText::validate(LaTeXFeatures & features) const
{
- for_each(paragraphs().begin(), paragraphs().end(),
- bind(&Paragraph::validate, _1, ref(features)));
+ ParagraphList::const_iterator const begin = paragraphs().begin();
+ ParagraphList::const_iterator const end = paragraphs().end();
+ for (ParagraphList::const_iterator it = begin; it !=end; ++it) {
+ LyXFont const outerfont =
+ outerFont(std::distance(begin, it), paragraphs());
+ it->validate(features, outerfont);
+ }
}
Index: src/insets/Makefile.am
===
--- src/insets/Makefile.am (Revision 16797)
+++ src/insets/Makefile.am (Arbeitskopie)
@@ -77,8 +77,6 @@ libinsets_la_SOURCES = \
insetindex.h \
insetlabel.C \
insetlabel.h \
- insetlatexaccent.C \
- insetlatexaccent.h \
insetline.C \
insetline.h \
insetmarginal.h \
Index: src/encoding.h
===
--- src/encoding.h (Revision 16797)
+++ src/encoding.h (Arbeitskopie)
@@ -14,9 +14,8 @@
#define ENCODING_H
#include
-#include
-#include "support/types.h"
+#include "support/docstring.h"
namespace lyx {
@@ -29,16 +28,25 @@ public:
Encoding() {}
///
Encoding(std::string const & n, std::string const & l,
- std::string const & i)
- : Name_(n), LatexName_(l), iconvName_(i)
- {
- }
+ std::string const & i);
///
std::string const & name() const { return Name_; }
///
std::string const & latexName() const { return LatexName_; }
///
std::string const & iconvName() const { return iconvName_; }
+ /**
+ * Convert \p c to something that LaTeX can understand.
+ * This is either the character itself (if it is representable
+ * in this encoding), or a LaTeX macro.
+ * If the character is not representable in this encoding, but no
+ * LaTeX macro is known, a warn
Re: Problem stripLeadingSpaces()
Abdelrazak Younes schrieb: Right now, stripLeadingSpaces() returns the number of _physically_ deleted spaces. I can change this to return the number of physically and logically characters. Yes, I guess we should do that. Ok, the patch will be committed in a few minutes. Michael
Re: Problem stripLeadingSpaces()
Abdelrazak Younes schrieb: OK, IIUC, then you will have two deleted space then, right? Again, IIUC, the paragraph contents should still contain the two spaces but isDeleted(0) and (1) would return true, right? Yes & Yes. If yes, then as I said, there is a problem even before the screen update problem because while debugging I noticed that there was only _one_ leading space, not two. Hmmm. I see two (striked-out) spaces after moving around the cursor. Let's see how the situation changed with your latest patch. Michael
Re: filename with space truncated n external insets dialog
by the way 1.4.2 and 1.4.3 (that's all i have installed) also truncate the filename, but i have no source at my pc
Re: [PATCH] Branches and ToC bug
On Fri, Jan 19, 2007 at 08:55:06PM +, José Matos wrote: > On Friday 19 January 2007 4:02:43 pm Jean-Marc Lasgouttes wrote: > > OK, I'll apply it and tell Jose' that you made me do it if he > > complains. > > Abdel... hum. How were you capable of such thing? ;-) It's his pretty face. Who can resist? - Martin pgpPhcCDxFf3K.pgp Description: PGP signature
Re: filename with space truncated n external insets dialog
Hello!
The attached patch fixes the problem in trunk. The problem was that for the filename one token was
retrieved from the lexer instead of the whole remaining line.
Bernhard
PS: I think the preferred way for contributing should be via a bug report?
Abdelrazak Younes wrote:
Bernhard Roider wrote:
hi!
first of all: i took a look at 1.5.0 svn and i think it will be a
great piece of software!
i just recognized that if in the external insets dialog a file name
containing a space is inserted (or selected with the file open dialog)
then the name is truncated at the space character after pressing ok.
Confirmed. I guess the problem is in InsetExternalMailer::string2params().
Abdel.
Index: src/insets/insetexternal.C
===
--- src/insets/insetexternal.C (revision 16795)
+++ src/insets/insetexternal.C (working copy)
@@ -290,7 +290,7 @@
break;
case EX_FILENAME: {
- lex.next();
+ lex.eatLine();
string const name = lex.getString();
filename.set(name, buffer.filePath());
break;
Converters and encodings
Currently, a converter path cannot contain non-ascii characters on systems
not using utf8 as the local encoding. Moreover, arguments are also passed
in utf8 encoding. This is clearly wrong and produces assertions, eg. on
Windows but also on Solaris when using a locale different from utf8.
I had a look at the code and come to the conclusion that the FileName
class with its toFilesystemEncoding method is not of help here. This
is because we have to also deal with non-absolute paths and some
arguments may also be in utf8.
IMO we should have functions for directly converting from utf8 to the
file system encoding and vice versa. I would like to hear opinions about
this issue and, for discussion, attach here a patch solving these problems.
--
Enrico
Index: src/converter.C
===
--- src/converter.C (revision 16790)
+++ src/converter.C (working copy)
@@ -56,6 +56,7 @@ using support::removeExtension;
using support::split;
using support::subst;
using support::Systemcall;
+using support::utf8ToFSEncoding;
using std::endl;
using std::find_if;
@@ -426,9 +427,9 @@ bool Converters::convert(Buffer const *
int res;
if (conv.original_dir) {
Path p(buffer->filePath());
- res = one.startscript(type, command);
+ res = one.startscript(type,
utf8ToFSEncoding(command));
} else
- res = one.startscript(type, command);
+ res = one.startscript(type,
utf8ToFSEncoding(command));
if (!real_outfile.empty()) {
Mover const & mover = getMover(conv.to);
@@ -450,7 +451,7 @@ bool Converters::convert(Buffer const *
string const command2 = script +
" < " + quoteName(infile2 + ".out") +
" > " + quoteName(logfile);
- one.startscript(Systemcall::Wait, command2);
+ one.startscript(Systemcall::Wait,
utf8ToFSEncoding(command2));
if (!scanLog(*buffer, command,
makeAbsPath(logfile, path), errorList))
return false;
}
@@ -464,7 +465,7 @@ bool Converters::convert(Buffer const *
// it is a document (.lyx) or something else. Same goes for elsewhere.
Alert::error(_("Cannot convert file"),
bformat(_("An error occurred
whilst running %1$s"),
- from_ascii(command.substr(0,
50;
+ from_utf8(command.substr(0,
80;
}
return false;
}
@@ -487,7 +488,7 @@ bool Converters::convert(Buffer const *
if (!mover.rename(FileName(from), FileName(to))) {
Alert::error(_("Cannot convert file"),
bformat(_("Could not move a temporary
directory from %1$s to %2$s."),
- from_ascii(from),
from_ascii(to)));
+ from_utf8(from),
from_utf8(to)));
return false;
}
}
Index: src/LaTeX.C
===
--- src/LaTeX.C (revision 16790)
+++ src/LaTeX.C (working copy)
@@ -42,6 +42,7 @@ using support::changeExtension;
using support::contains;
using support::FileName;
using support::findtexfile;
+using support::fsEncodingToUtf8;
using support::getcwd;
using support::makeAbsPath;
using support::onlyFilename;
@@ -483,7 +484,7 @@ void LaTeX::scanAuxFile(FileName const &
smatch sub;
// FIXME UNICODE: We assume that citation keys and filenames
// in the aux file are in the file system encoding.
- token = to_utf8(from_filesystem8bit(token));
+ token = fsEncodingToUtf8(token);
if (regex_match(token, sub, reg1)) {
string data = sub.str(1);
while (!data.empty()) {
@@ -841,7 +842,7 @@ void LaTeX::deplog(DepTable & head)
// FIXME UNICODE: We assume that the file names in the log
// file are in the file system encoding.
- token = to_utf8(from_filesystem8bit(token));
+ token = fsEncodingToUtf8(token);
if (regex_match(token, sub, reg1)) {
static regex reg1_1("\\(([^()]+)");
Index: src/support/filetools.C
Re: About bug 3118: editing first row of long math insets is impossible
Andre Poenitz wrote: > On Fri, Jan 19, 2007 at 11:39:40AM +0100, Georg Baum wrote: >> If we make sure that the coord cache is always >> set in the metrics method as Abdel suggests, > > There must be a misunderstanding somewhere. The metrics phase only > determines _sizes_. The coord cache records _positions_. I know (at least roughly) how it used to work, but I think that Abdel had a different goal when he changed the metrics/draw machinery. Therefore I believe that we don't have a misunderstanding, but a mixture of two different approaches currently. Since 1.5 is quite a bit faster than 1.4 and crashes less because of a broken coord cache his approach can't be too bad. Georg
Re: [Cvslog] r16785 - /lyx-devel/trunk/src/paragraph_pimpl.C
Michael Gerz wrote: > Sure? Yes! > Looks like 4. 1 is always added somewhere else (this is the common case). Georg
Re: Problem stripLeadingSpaces()
Michael Gerz wrote: Abdelrazak Younes schrieb: Michael Gerz wrote: Abdelrazak Younes schrieb: Michael Gerz wrote: Abdelrazak Younes schrieb: I don't understand, why the space in the first line should be deleted? means a space that was marked as deleted. Use the attached lyx file. Press return after "hello". The leading spaces are marked as deleted but the screen is not updated. Well, I still don't understand because the screen seems fine here, see attached. No, the screen is not fine: the second space should be marked as deleted! Why is that? Before I hit "Enter", the second space was not deleted; was should it be deleted after? The semantics of stripLeadingSpaces() is, well, to strip _all_ leading spaces. Since the second space is a leading space, too, it is marked as deleted in CT mode. stripLeadingSpaces() works as intended but the screen is not updated afterwards. Right now, stripLeadingSpaces() returns the number of _physically_ deleted spaces. I can change this to return the number of physically and logically characters. Yes, I guess we should do that. This may help but may also prevent some optimizations in DEPM. I also don't understand why we return false at the end of deleteEmptyParMech() even if stripLeadingSpaces returns !0. I've change that and now the crash is gone because going up with the arrow key will trigger the DEPM and the metrics will then be updated. Still, I guess my commit only cures the symptom because the second paragraph is still wrong. At least it's now wrong in the paragraph contents also. If you want the space to be deleted as soon as the new paragraph is created, we need to call stripLeadingSpaces() on the new paragraph also, and we don't do that in DEPM. Ah, and we should clarify/document the meaning of the return value of deleteEmptyParMech... Yes. Abdel. What do you think? I am a bit lost without your assistance... Michael
Bugzilla and this list
Guys, I've learned how to use Bugzilla and I think it is useful. But I'm starting to think that the discussion should happen in the list rather than in Bugzilla. Could we automated that? I am thinking of Bugzilla sending a message to the devel list and update the bug entry with a link to the discussion thread in some archive (either gmane or mail-archive). Further comment in bugzilla should be reserved for better description of the bug. What do you think? Abdel.
Re: Problem stripLeadingSpaces()
Michael Gerz wrote: Abdelrazak Younes schrieb: Michael Gerz wrote: Abdelrazak Younes schrieb: Michael Gerz wrote: Abdelrazak Younes schrieb: I don't understand, why the space in the first line should be deleted? means a space that was marked as deleted. Use the attached lyx file. Press return after "hello". The leading spaces are marked as deleted but the screen is not updated. Well, I still don't understand because the screen seems fine here, see attached. No, the screen is not fine: the second space should be marked as deleted! Why is that? Before I hit "Enter", the second space was not deleted; was should it be deleted after? The semantics of stripLeadingSpaces() is, well, to strip _all_ leading spaces. Since the second space is a leading space, too, it is marked as deleted in CT mode. stripLeadingSpaces() works as intended but the screen is not updated afterwards. Right now, stripLeadingSpaces() returns the number of _physically_ deleted spaces. OK, IIUC, then you will have two deleted space then, right? Again, IIUC, the paragraph contents should still contain the two spaces but isDeleted(0) and (1) would return true, right? If yes, then as I said, there is a problem even before the screen update problem because while debugging I noticed that there was only _one_ leading space, not two. I can change this to return the number of physically and logically characters. This may help but may also prevent some optimizations in DEPM. I think that DEPM is indeed the culprit here and we have to teach it to disregard deleted spaces (and deleted paragraphs for the matter). I also don't understand why we return false at the end of deleteEmptyParMech() even if stripLeadingSpaces returns !0. Ah, and we should clarify/document the meaning of the return value of deleteEmptyParMech... What do you think? I am a bit lost without your assistance... I have to study the code before answering you. Maybe what I said above will help you. Abdel.
Re: About bug 3118: editing first row of long math insets is impossible
Andre Poenitz wrote: On Fri, Jan 19, 2007 at 11:39:40AM +0100, Georg Baum wrote: If we make sure that the coord cache is always set in the metrics method as Abdel suggests, There must be a misunderstanding somewhere. The metrics phase only determines _sizes_. The coord cache records _positions_. Right, see my other post. Abdel.
Re: About bug 3118: editing first row of long math insets is impossible
Andre Poenitz wrote: On Fri, Jan 19, 2007 at 12:18:35PM +0100, Abdelrazak Younes wrote: Georg Baum wrote: Abdelrazak Younes wrote: Indeed but first we have to make sure that the CoordCache is properly filled in for all insets. We can do that recursively as is done in the rowpainter. One have to extract the part that calls setPosCache() and transfer that in BufferView::updateMetris(). setPoscache is called in draw() for each inset. Do I understand you right the now the coord cache needs to be filled when the metrics are calculated? Yes. If that is the case we should simply transfer this call to the metrics() method of each inset That's what I said yes. How come the metrics() phase knows about positions? It doesn't. I didn't mean that, I meant that we should transfer the position calculation to BufferView::updateMetrics() because the positions are known at that point. Abdel.
Re: [Cvslog] r16795 - in /lyx-devel/trunk: lib/ui/stdtoolbars.inc po/b...
Hi,
this is the last in a series of commits to make the user interface
consistent.
All po files have been updated accordingly. I think it is time again to
draw the attention of the LyX translators.
The German translations are already complete (with the exception of a
couple of labels coming from layout files).
Regards, Michael
[EMAIL PROTECTED] schrieb:
Author: schmitt
Date: Sun Jan 21 12:48:21 2007
New Revision: 16795
URL: http://www.lyx.org/trac/changeset/16795
Log:
* lib/ui/stdttoolbars.inc: for the perfectionists: use a shorter
toolbar title ("View/Update") for consistency with the other
toolbars (e.g., we say "Table" rather than "Edit Table")
Modified:
lyx-devel/trunk/lib/ui/stdtoolbars.inc
lyx-devel/trunk/po/bg.po
lyx-devel/trunk/po/ca.po
lyx-devel/trunk/po/cs.po
lyx-devel/trunk/po/da.po
lyx-devel/trunk/po/de.po
lyx-devel/trunk/po/es.po
lyx-devel/trunk/po/eu.po
lyx-devel/trunk/po/fi.po
lyx-devel/trunk/po/fr.po
lyx-devel/trunk/po/gl.po
lyx-devel/trunk/po/he.po
lyx-devel/trunk/po/hu.po
lyx-devel/trunk/po/it.po
lyx-devel/trunk/po/nb.po
lyx-devel/trunk/po/nl.po
lyx-devel/trunk/po/nn.po
lyx-devel/trunk/po/pl.po
lyx-devel/trunk/po/pt.po
lyx-devel/trunk/po/ro.po
lyx-devel/trunk/po/ru.po
lyx-devel/trunk/po/sk.po
lyx-devel/trunk/po/sl.po
lyx-devel/trunk/po/sv.po
lyx-devel/trunk/po/tr.po
lyx-devel/trunk/po/wa.po
Modified: lyx-devel/trunk/lib/ui/stdtoolbars.inc
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/lib/ui/stdtoolbars.inc?rev=16795
==
--- lyx-devel/trunk/lib/ui/stdtoolbars.inc (original)
+++ lyx-devel/trunk/lib/ui/stdtoolbars.inc Sun Jan 21 12:48:21 2007
@@ -163,7 +163,7 @@
Item "Next note" "note-next"
End
-Toolbar "view/update" "View/Update Document"
+Toolbar "view/update" "View/Update"
Item "View DVI" "buffer-view dvi"
Item "Update DVI" "buffer-update dvi"
Item "View PDF (pdflatex)" "buffer-view pdf2"
Modified: lyx-devel/trunk/po/bg.po
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/po/bg.po?rev=16795
==
--- lyx-devel/trunk/po/bg.po (original)
+++ lyx-devel/trunk/po/bg.po Sun Jan 21 12:48:21 2007
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: LyX 1.1.6\n"
"Report-Msgid-Bugs-To: [EMAIL PROTECTED]"
-"POT-Creation-Date: 2007-01-21 12:01+0100\n"
+"POT-Creation-Date: 2007-01-21 12:35+0100\n"
"PO-Revision-Date: 2005-12-18 15:14+0100\n"
"Last-Translator: George Tellalov <[EMAIL PROTECTED]>\n"
"Language-Team: Bulgarian <[EMAIL PROTECTED]>\n"
@@ -11643,7 +11643,7 @@
# src/bufferlist.C:113 src/bufferlist.C:189
#: lib/ui/stdtoolbars.inc:166
#, fuzzy
-msgid "View/Update Document"
+msgid "View/Update"
msgstr "Çàïàçâàíå íà äîêóìåíòà?"
# src/ext_l10n.h:8
Modified: lyx-devel/trunk/po/ca.po
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/po/ca.po?rev=16795
==
--- lyx-devel/trunk/po/ca.po (original)
+++ lyx-devel/trunk/po/ca.po Sun Jan 21 12:48:21 2007
@@ -12,7 +12,7 @@
msgstr ""
"Project-Id-Version: LyX 1.0.0pre2\n"
"Report-Msgid-Bugs-To: [EMAIL PROTECTED]"
-"POT-Creation-Date: 2007-01-21 12:01+0100\n"
+"POT-Creation-Date: 2007-01-21 12:35+0100\n"
"PO-Revision-Date: 2005-12-18 15:14+0100\n"
"Last-Translator: Francesc Burrull i Mestres <>\n"
"Language-Team: Catalan <[EMAIL PROTECTED]>\n"
@@ -10051,7 +10051,7 @@
#: lib/ui/stdtoolbars.inc:166
#, fuzzy
-msgid "View/Update Document"
+msgid "View/Update"
msgstr "Vols salvar el document?"
#: lib/ui/stdtoolbars.inc:167
Modified: lyx-devel/trunk/po/cs.po
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/po/cs.po?rev=16795
==
--- lyx-devel/trunk/po/cs.po (original)
+++ lyx-devel/trunk/po/cs.po Sun Jan 21 12:48:21 2007
@@ -6,7 +6,7 @@
msgstr ""
"Project-Id-Version: Lyx 1.5.0svn\n"
"Report-Msgid-Bugs-To: [EMAIL PROTECTED]"
-"POT-Creation-Date: 2007-01-21 12:01+0100\n"
+"POT-Creation-Date: 2007-01-21 12:35+0100\n"
"PO-Revision-Date: 2006-11-02 00:42+0200\n"
"Last-Translator: Pavel Sanda <[EMAIL PROTECTED]>\n"
"Language-Team: Czech <[EMAIL PROTECTED]>\n"
@@ -8635,7 +8635,7 @@
#: lib/ui/stdtoolbars.inc:166
#, fuzzy
-msgid "View/Update Document"
+msgid "View/Update"
msgstr "Hlavní dokument"
#: lib/ui/stdtoolbars.inc:167
Modified: lyx-devel/trunk/po/da.po
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/po/da.po?rev=16795
==
--- lyx-devel/trunk/po/da.po (original)
+++ lyx-devel/trunk/po/da.po Sun Jan 21 12:48:21 2007
@@ -9,7 +9,7 @@
msgstr ""
"Project-Id-Version: da\n"
"Report-Msgid-Bugs-To: [EMAIL PROTECTED]"
-"POT-Creation-Date: 2007-01-21 12:01+0100\n"
+"POT-Creation-D
Re: [Cvslog] r16792 - /lyx-devel/trunk/lib/ui/stdtoolbars.inc
Uwe, I made a couple of minor change for the sake of consistency. Michael [EMAIL PROTECTED] schrieb: Author: schmitt Date: Sun Jan 21 11:20:39 2007 New Revision: 16792 URL: http://www.lyx.org/trac/changeset/16792 Log: * lib/ui/stdtoolbars.inc: fix typo; use Capitals in toolbar name; remove term "output" in "DVI output" for consistency with the other items Modified: lyx-devel/trunk/lib/ui/stdtoolbars.inc Modified: lyx-devel/trunk/lib/ui/stdtoolbars.inc URL: http://www.lyx.org/trac/file/lyx-devel/trunk/lib/ui/stdtoolbars.inc?rev=16792 == --- lyx-devel/trunk/lib/ui/stdtoolbars.inc (original) +++ lyx-devel/trunk/lib/ui/stdtoolbars.inc Sun Jan 21 11:20:39 2007 @@ -163,9 +163,9 @@ Item "Next note" "note-next" End -Toolbar "view/update" "View/update view document" - Item "View DVI output" "buffer-view dvi" - Item "Update DVI output" "buffer-update dvi" +Toolbar "view/update" "View/Update Document" + Item "View DVI" "buffer-view dvi" + Item "Update DVI" "buffer-update dvi" Item "View PDF (pdflatex)" "buffer-view pdf2" Item "Update PDF (pdflatex)" "buffer-update pdf2" Item "View PostScript" "buffer-view ps" ___ Cvslog mailing list [EMAIL PROTECTED] http://www.lyx.org/mailman/listinfo/cvslog
Re: [Cvslog] r16780 - /lyx-devel/trunk/src/output_plaintext.C
Angus Leeming schrieb:
- docstring const abst = _("Abstract: ");
+ docstring const abst = _("Abstract") + from_ascii(": ");
Not all languages will use ':' in the same way as the English and in
RtL languages the thing won't go to the right of the word either...
Hpmf $&§#!
Fixed/Reverted in r16791. Thank you very much for the hint, Angus
Michael
log messages missing
Lars, Uwe has committed two patches yesterday but I didn't receive corresponding [EMAIL PROTECTED] emails. I guess Uwe is not listed in one of the server scripts. Could you please check? Michael
Re: [Cvslog] r16788 - /lyx-devel/trunk/src/MenuBackend.C
Again, FYI.
Michael
[EMAIL PROTECTED] schrieb:
Author: schmitt
Date: Sat Jan 20 19:38:06 2007
New Revision: 16788
URL: http://www.lyx.org/trac/changeset/16788
Log:
* src/MenuBackend.C: Import plain text: align
labels with menu entries in stdmenus.inc
Modified:
lyx-devel/trunk/src/MenuBackend.C
Modified: lyx-devel/trunk/src/MenuBackend.C
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/MenuBackend.C?rev=16788
==
--- lyx-devel/trunk/src/MenuBackend.C (original)
+++ lyx-devel/trunk/src/MenuBackend.C Sat Jan 20 19:38:06 2007
@@ -537,9 +537,9 @@
switch (kind) {
case MenuItem::ImportFormats:
if ((*fit)->name() == "text")
- label = _("Plain Text as Lines");
+ label = _("Plain Text");
else if ((*fit)->name() == "textparagraph")
- label = _("Plain Text as Paragraphs");
+ label = _("Plain Text, Join Lines");
label += "...";
break;
case MenuItem::ViewFormats:
___
Cvslog mailing list
[EMAIL PROTECTED]
http://www.lyx.org/mailman/listinfo/cvslog
Re: [Cvslog] r16787 - /lyx-devel/trunk/lib/ui/classic.ui
FYI. Michael [EMAIL PROTECTED] schrieb: Author: schmitt Date: Sat Jan 20 19:35:27 2007 New Revision: 16787 URL: http://www.lyx.org/trac/changeset/16787 Log: * lib/ui/classic.ui: "Plain Text, Join Lines" - align with menu entries in stdmenus.ui Modified: lyx-devel/trunk/lib/ui/classic.ui Modified: lyx-devel/trunk/lib/ui/classic.ui URL: http://www.lyx.org/trac/file/lyx-devel/trunk/lib/ui/classic.ui?rev=16787 == --- lyx-devel/trunk/lib/ui/classic.ui (original) +++ lyx-devel/trunk/lib/ui/classic.ui Sat Jan 20 19:35:27 2007 @@ -317,8 +317,8 @@ Menu "insert_file" Item "LyX Document...|X" "file-insert" - Item "Plain Text as Lines...|L" "file-insert-plaintext" - Item "Plain Text as Paragraphs...|P" "file-insert-plaintext-para" + Item "Plain Text...|T" "file-insert-plaintext" + Item "Plain Text, Join Lines...|J" "file-insert-plaintext-para" End Menu "edit_change" ___ Cvslog mailing list [EMAIL PROTECTED] http://www.lyx.org/mailman/listinfo/cvslog
