John C. Spray wrote:
> Do you mean things like "Was the math panel open?" and "Where was the
> math panel?". Seems like a good idea, although perhaps more basic
> things like allowing hiding/showing of toolbars from the View menu would
> be better done first.
No. What I mean are more basic thing
On Fri, 2006-03-24 at 15:29 +0100, Georg Baum wrote:
> I disagree a bit. Being able to open a file at the last position is not
> session management IMHO. session management is "recreate the exact same
> state as LyX was in before shutdown", and it should be implemented using
> the qt/gtk API.
Do y
> > Where you're at it Bo, could you implement the (optional) reloading of
> > all file that where opened on last exit? ;-)
>
> This is indeed session management.
If we only need to open files at their original positions, we do not
really need qt api etc. I can expand filepositions to something li
Georg Baum a écrit :
Abdelrazak Younes wrote:
IMHO this is session management and all session management should go
into a single file with a wide spread format (say XML or INI like).
I disagree a bit. Being able to open a file at the last position is not
session management IMHO. session manag
Abdelrazak Younes wrote:
> IMHO this is session management and all session management should go
> into a single file with a wide spread format (say XML or INI like).
I disagree a bit. Being able to open a file at the last position is not
session management IMHO. session management is "recreate th
On 3/24/06, Abdelrazak Younes <[EMAIL PROTECTED]> wrote:
> could you implement the (optional) reloading of
> all file that where opened on last exit? ;-)
That is a separate feature that is definitely nice to have. It is
possible though, to make $HOME/.lyx/lastfilepos something like
*, 32, file1
*,
Bo Peng a écrit :
We have 'lastfiles' and 'lastpos' as configurable filenames, I am not
sure that they should be. IMHO we should just hardcode them. Opinions
on that?
I just tried to make features of lastpos parallel to lastfiles. I do
not think these filenames need to be configured. lastfile::
Bo Peng wrote:
> I think lastpos is a better name to this feature
As long as it cannot be confused with cursor.lastpos()
(I didn't read your patch, so the comment might be irrelevant).
Jürgen
> We have 'lastfiles' and 'lastpos' as configurable filenames, I am not
> sure that they should be. IMHO we should just hardcode them. Opinions
> on that?
I just tried to make features of lastpos parallel to lastfiles. I do
not think these filenames need to be configured. lastfile::dostat may
not
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Angus Leeming <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes
| Does your regex work over multiple lines, for example?
Lars> It does not have to.
I even think it should not.
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| > I am still not sure.
| > boost::regex reg("([^,]+),[ ]+(.*)");
|
| Does your regex work over multiple lines, for example?
It does not have to.
| Regexes are expensive to construct and a pain to main
Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> I am still not sure.
> boost::regex reg("([^,]+),[ ]+(.*)");
Does your regex work over multiple lines, for example?
Regexes are expensive to construct and a pain to maintain.
As case in point, what is that (.*) group doing? If you
want to handle m
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| > | If this is meant to be code to read a comma-separated list, then it's not
| > | robust. This file can be edited by hand...
| >
| > If you edit it by hand you are on your own.
| > But sure if we can
Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> | If this is meant to be code to read a comma-separated list, then it's not
> | robust. This file can be edited by hand...
>
> If you edit it by hand you are on your own.
> But sure if we can make it more robust.
> | Bo, have a look at Boost.Token
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
| > "Bo Peng" <[EMAIL PROTECTED]> writes:
| > | +void FilePositions::readFile(string const & filename)
| > | +{
| > | + // we will not complain if we can't find filename nor will
| > | + // we issue a warn
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Just as a test... load a document move the cursor save. Exit
Lars> lyx. Start lyx. Load a different document. Load the first doc.
Lars> Where is the cursor placed now?
To make things fail you have to edit the file before saving
Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> "Bo Peng" <[EMAIL PROTECTED]> writes:
> | +void FilePositions::readFile(string const & filename)
> | +{
> | + // we will not complain if we can't find filename nor will
> | + // we issue a warning. (Lgb)
> | + ifstream ifs(filename.c_str());
>
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > No. We need to have the "last position" feature in addition, not mixed
| > with lastfile.
|
| OK, since you insist, here comes a much larger patch.
I like this patch a lot better. Thanks for doing this.
One thing we should think about though; not caused
> No. We need to have the "last position" feature in addition, not mixed
> with lastfile.
OK, since you insist, here comes a much larger patch.
The patch works on my system. However, there are two problems that
make this feature almost useless. Please help me resolve them.
1. Alt-F4 and close-bu
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > Just as a test... load a document move the cursor save.
| > Exit lyx. Start lyx. Load a different document. Load the first doc.
| > Where is the cursor placed now?
|
| It will move to the position when the first file was closed. My test
| goes well except
"Bo Peng" <[EMAIL PROTECTED]> writes:
| > I do not like this one bit.
| > IMO completely ortogonal feature that happens to share some of the
| > omplementation. IMHO you have just made a super simple LastFiles a lot
| > more complex.
|
| It is much more troublesome to have a separate implementati
> Alternatively, more similar to what you had earlier:
>
> int pit;
> int pos;
> boost::tie(pit, pos) = LyX::ref().lastfiles().loadFilePosition(s);
This is good to know.
> Can you please drop the bookmark part of the patch for now?
> If we decide that we do want bookmark[0
> I do not like this one bit.
> IMO completely ortogonal feature that happens to share some of the
> omplementation. IMHO you have just made a super simple LastFiles a lot
> more complex.
It is much more troublesome to have a separate implementation.
Afterall, lastfiles do mean information regardi
"Bo Peng" <[EMAIL PROTECTED]> writes:
| Index: src/BufferView_pimpl.C
| ===
| --- src/BufferView_pimpl.C(revision 13463)
| +++ src/BufferView_pimpl.C(working copy)
| @@ -293,6 +293,20 @@
|
| setBuffer(b);
| bv_->
On Thursday 23 March 2006 18:39, Lars Gullik Bjønnes wrote:
> Too old gcc. I think only gcc > 4.1 warns/errors about this.
gcc >= 4.1
:-)
> --
> Lgb
--
José Abílio
"Bo Peng" <[EMAIL PROTECTED]> writes:
| Dear list,
|
| This time, a formal patch. Here are the rationals:
|
| > I am not sure if I like lastfiles to be the files that store this
| > info. One of the reason is that we only store a very limited number of
| > files there... lastpostion info should
Dear list,
This time, a formal patch. Here are the rationals:
> I am not sure if I like lastfiles to be the files that store this
> info. One of the reason is that we only store a very limited number of
> files there... lastpostion info should hold more files.
Using a separate file like $HOME/.l
"Bo Peng" <[EMAIL PROTECTED]> writes:
| An updated patch that loads all position information while keeping
| only num_files Files entries.
|
| Question: is 0 a valid paragraph ID? I currently use -1 to indicate
| invalid ID.
As said, I'd prefere a separate file in .lyx/; but even if I didn't:
|
"Bo Peng" <[EMAIL PROTECTED]> writes:
| Dear list,
|
| It does not look so difficult to implement this feature so I tried to
| implement it by myself. Attached is my patch. Since I rarely submit a
| patch here so I am afraid that there might be many problems (format,
| logic, bugs). Please have a
An updated patch that loads all position information while keeping
only num_files Files entries.
Question: is 0 a valid paragraph ID? I currently use -1 to indicate invalid ID.
Bo
Index: src/BufferView_pimpl.C
===
--- src/BufferView_
> > src/lastfiles.C:
> > I do not want to change the Files structure so I use a map to store
> > position information. lastfile format is changed to "
> > filename" if position information is available, and "filename" if not.
>
> Would it be easier to always have the filename format? And id
> = po
Martin Vermeer wrote:
> On Wed, 2006-03-22 at 23:19 -0600, Bo Peng wrote:
>> Dear list,
>>
>> It does not look so difficult to implement this feature so I tried to
>> implement it by myself. Attached is my patch. Since I rarely submit a
>> patch here so I am afraid that there might be many proble
On Wed, 2006-03-22 at 23:19 -0600, Bo Peng wrote:
> Dear list,
>
> It does not look so difficult to implement this feature so I tried to
> implement it by myself. Attached is my patch. Since I rarely submit a
> patch here so I am afraid that there might be many problems (format,
> logic, bugs). Pl
Dear list,
It does not look so difficult to implement this feature so I tried to
implement it by myself. Attached is my patch. Since I rarely submit a
patch here so I am afraid that there might be many problems (format,
logic, bugs). Please have a look and give me some feedbacks.
Many files have
34 matches
Mail list logo
