> Am 22.10.2015 um 23:07 schrieb tisimst: > I think this thread has too many conflicting topics, and I'm > definitely > note sure what's causing some of the other issues that have been > brought up (sorry!), but let's jump back to the OP's original issue as > it relates to the GitHub thread you mentioned. If what I am about to > say is NOT new, please feel free to ignore it, but hopefully this will > help someone who is starting to use or is thinking about using > Frescobaldi to create their LilyPond files. > > Here are some things I've learned about the Frescobaldi workflow (as > they pertain to this topic): > 1. All open input files exist in one of two states: "edited" and > "saved" > 2. Creating a new file starts the file in an "edited" state. > 3. Opening an existing file starts the file in a "saved" state. > 4. Any file that has been changed in any way is put in an "edited" > state. Even if you make a single change and "undo" it to the > original text, it is still considered "edited". > 5. There are several compiling modes, but the most common are > "preview" (which enables point-and-click references in the PDF) > and > "publish" (which disables point-and-click in the PDF). On Windows > and Linux, "preview" mode has the keyboard shortcut "Ctrl + M" and > "publish mode has the keyboard shortcut "Ctrl + Shift + P". Not > sure for Mac. These are VERY USEFUL. > 6. Compiling the input file in the "edited" state creates a copy of > the input file (but no "included" files) and puts it in a > temporary > folder. Any files that are output from this are thus compiled to > that temporary directory and NOT in the original input file's > directory. This temporary folder and its contents will exist until > Frescobaldi closes, then the directory and its contents are > erased. > 7. Saving an input file does NOT save the PDF and/or MIDI files that > were previously compiled when the input file was in the "edited" > state. To update those, the input file (now in a "saved" state) > must be recompiled. The PDF and/or MIDI files will then be updated > and saved in the original input file's directory. > 8. Compiling the input file in the "saved" state puts all output > files > in the same directory as the input file, as expected. > 9. You can force Frescobaldi to save the input file to its original > directory (and thus the PDF and/or MIDI files) every time you > compile by going to "Edit" > "Preferences" > "LilyPond > Preferences" > > "Running LilyPond" and checking the box by "Save document if > possible". NOTE: This does not apply to any "included" files that > are also open, whether in the "saved" or "edited" state. It only > applies to the input file being compiled. > 10. If any files are "included" in the input file (e.g., \include > "layout/choralSATB.ly"), LilyPond will always look for the "saved" > versions of these files. Thus, if any "included" files are being > referenced in "relative" mode (and thus not normally in LilyPond's > include path), then their directory must be added to LilyPond's > include path for "edited" input files to compile since the > temporary input file is placed in a totally different location on > the hard drive and the relative references are not valid there. > You basically have to remember one thing: If you like the way the > input > file is, save it and re-compile (usually in the "publish" mode) one > last time before you close up shop. That's it! > > Those are my thoughts. Maybe you knew all that already, maybe not. > Maybe you just don't like that philosophy, which is fine. I totally > respect that. I just think that if you could get used to working with > these concepts, you'll find that they are pretty handy. I certainly > have grown to like it because if I need to prototype something or I > just want to try something out, I can do it without messing up a > single > file on my hard drive, knowing that anything I've made any potentially > damaging changes to my saved files. > > Anyway, take that for what it's worth. I'm just trying to be helpful.
Most helpful; thanks for spelling that out. > On Thu, Oct 22, 2015 at 3:18 PM, Urs Liska [via Lilypond] <[hidden email]> > wrote: > Maybe there are two things to add to your thoughts, Abraham: > > Between 2. and 3. I would add (it's implied but I'd make it explicit): > 2a. This new file in "edited" state does not have a proper file name and > not even a directory yet, it completely lives in a temporary folder. > > One simple thing could be added to Frescobaldi's behaviour, and if I'm not > mistaken this is something Wilbert saw quite favourably on the Github > issue: > When a file or Frescobaldi is closed it is checked if it is saved, and if > not a dialog asks you how to proceed. At this closing time Frescobaldi > could also check if the current state of the file has been compiled, and > if > not ask if it should do that before closing. > > Personally I've never stumbled over this, but I can see that it may be > confusing or non-intuitive. Quoting tisimst (tisimst.lilyp...@gmail.com): > Yes, you are exactly right. I'm not sure what the right way of going about > that > final check is, but something along those lines should do the trick for those > not expecting the current behavior. I certainly can't speak for other > experienced users, but I also haven't encountered the need for it once I knew > what Frescobaldi was doing. One natural way to help newbies but not trouble power users might be to have: "Edit" > "Preferences" > "LilyPond Preferences" > "Running LilyPond" and check a box "Quit without asking to Save/Engrave" with an unset default (for newbies). Maybe one for CloseFile and another for QuitApplication. My own workflow is to use the filesystem at all times. One of the reasons for this is that linux is a multiuser system, so you don't get the hand-holding that windows offers on shutdown, with every application asking in turn whether you want to save unsaved files. Also I was brought up on desktops, where you don't get the protection of a laptop's battery. (We had a one-second power outage this very afternoon.) Cheers, David. _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user