Forwarding to lyx-devel...
-------- Original Message -------- Subject: Re: feature request: named sessions Date: Fri, 20 Feb 2009 13:39:10 +0100 From: G. Milde <g.mi...@quantentunnel.de> To: Manoj Rajagopalan <rma...@umich.edu> On 19.02.09, Manoj Rajagopalan wrote:
Guenter Milde wrote:
* implement as separate app and use the lyxserver. (I can open lyx files, re-using a running LyX session from within my text editor, it would be very simple to add a function to open all files given in a plain text document.)
I am not familiar with lyxserver interaction. Could you please elaborate on this use-case, perhaps with an example?
There is info about it in the wiki: http://wiki.lyx.org/LyX/LyXServer My example is the Python interface to the LyXServer I wrote back in 2005. Its a Python package, available from the wiki (description + download): http://wiki.lyx.org/Tools/PyClient I use the example "end-user" script "lyx-remote" on a daily basis to open a file in a running LyX or start LyX with the file from my file manager (midnight commander) or the text editors Jed "filelist" mode.
From the command line,
#> lyx-remote file1.lyx ~/path/file2.lyx /absolute/file3.lyx would open the three files in a running LyX session or open a new LyX with them. Doint this for a set of files stored (with path) in a simple text file should be trivial.
The last-session info currently stored in LyX saves bookmark and other info about each document as opposed to simply storing document names.
If this information is kept for more than just the up-to-nine documents in the Files>Recent menu, it could automatically be used even for documents opened via the file-open lfun.
So this suggestion seems like a new piece of functionality that could co-exist with the current proposal.
... or replace it if the current proposal turns out to be too ambitious or not supported by the main developers.
I was thinking of not allowing users to create custom session files and leave them lying around - that would create support issues if some user makes a mistake editing the files using a text editor.
If the format is just a list of paths external editing could be allowed and the result of invalid entries would be simple-to-spot "file not found" errors.
I was suggesting a centralized flat-file database like storage with manipulation through lyx menus and commands. Power-users who'd like to hack at the settings file with ~/.lyx/ in this case are also likely to be able to fix any mistakes they make.
I could imagine simple text files in a ~/.lyx/named-sessions/ directory.
* use "local recent file lists" instead of explicitely named sessions.
jed-like behavior would require creating something like .lyxsession in the PWD to maintain the local file list. The following thoughts come to mind when considering this:
(a) LyX users may want to work with documents from multiple directories in one session,
(b) IIUC there can only be one global file list so this would permit only one group of files that can reside in different locations outside PWD,
No problem: You start LyX from PROJECT-DIRECTORY to use PROJECT-DIRECTORY/.lyxsession but the .lyxsession file can of course point to files everywhere on the system.
(c) the .lyxsession files would 'pollute' various directories when LyX is uninstalled. With a central file-list (aka sessions) database the user could opt for removal of application-data at uninstall time and this will not require iteration over all user dirs to clear out the .lyxsession files.
This is true (and a disadvantage of the proposed scheme). But: * on Unix, .lyxsession is a "hidden" file, so pollution is not that big. * With my Jed, I use M-x locate to find all of them and place them in a "filelist" (analog to Emacs' diredit or a mc panel) and then delete either all or a selected sub-set. The advantage of this scheme is that it does not require a manual session-naming and no manual selection of documents to add to the named sessions. Günter
