Sometimes not saving & compiling cha...

2012-06-16
2012-10-17
  • Otto Debals
    Otto Debals
    2012-06-16

    Hi,

    Maybe a software bug or maybe wrong settings or habbits due to myself, I don't
    know, but the following should not happen.

    Sometimes TeXstudio is not saving and compiling changed text in the source
    file. With sometimes I mean around 30% of the compilations, quite randomly
    (currently without further investigation). Following happens when the bug
    appears, and continuously happens until I apply my temporary solution (ref
    further): 1. Even if the source file is saved, the changes do not appear in
    the compiled pdf after compilation; and 2. even if the source file is saved,
    this 'bug' (if it is one) causes the file on disk to be the old version.
    Events 1 and 2 are of course probably linked because the compilation starts
    from the saved data on disk.

    Example: in the source file there's undeniably '\begin{itemize} \item Test:
    this is a test \item Test 2: this is a second test \end{itemize}' (but with
    line formatting of course), but in the compiled pdf as well as in the file on
    disk, there's only '1. Test: this is a test'. From then on, every change does
    not come through.

    Current temp solution I have to apply: if changes don't come through after
    compilation, copying the raw text in the source file, closing and reopening
    TeXStudio, pasting, and applying recompilation.

    Compilation happens with < pdflatex -shell-escape main -synctex=1
    -interaction=nonstopmode %.tex >, and the bug appeared for various documents.

    Summary: as if the changes made 'didn't happen' (not saved + not compiled),
    but are actually still visible in the open source file in TeXStudio.

    Any ideas ?

    Grtz

     
  • Tim Hoffmann
    Tim Hoffmann
    2012-06-16

    Can you provide an example file and (if possible) an instruction how to
    reproduce thementioned behaviour?

     
  • Otto Debals
    Otto Debals
    2012-06-16

    Sure, but I was thinking that it's not due to the example file because of the
    appearance for many documents, but of course wrong thinking of myself. Maybe
    it is. It happens to occur often when using enumerations or itemizations, and
    using ctrl+s while auto-completing the environment and the '\item' or
    something.

    I'll import the code here, apologies if it doesn't come through fine (not much
    experience with files + forum posts). The mainmatter is trivial.

    \documentclass[pdftex,10pt,a4paper]{article}
    
    \usepackage[dutch]{babel}
    \usepackage[babel=true,kerning=true]{microtype}
    
    \usepackage{titling}
        \title{Title} %
        \author{Name} %
        \date{\today} %
    \usepackage[pdftex,pdftitle={\thetitle},pdfauthor={\theauthor}]{hyperref}
    
    \usepackage{hyperref}
    % \usepackage{pdfpages}
    \usepackage{amsmath,amssymb}
    \usepackage{tikz,pgf}
    %\usepackage[numbered]{mcode}
    \usetikzlibrary{positioning,shapes,shadows,arrows}
    \usepackage{verbatim}
    \usepackage{graphicx}
    \usepackage{fancyhdr}
    
    \usepackage{caption}
        \captionsetup{labelfont=bf,font=small}
        \captionsetup[table]{position=top}
        \captionsetup[figure]{position=bottom}
    
    \addtolength{\textwidth}{2cm}
    \addtolength{\textheight}{1cm}
    \addtolength{\hoffset}{-1cm}
    \addtolength{\voffset}{-0.5cm}
    
    %\renewcommand{\topfraction}{1}
    %\renewcommand{\textfraction}{0}
    
    \pagestyle{fancy}
    \lhead{}
    \chead{}
    \rhead{}
    \lfoot{}
    \cfoot{\thepage}
    \rfoot{}
    
    \hyphenation{}
    
    \begin{document}
    
    \maketitle
    
    \begin{enumerate}
    \item Test
    \end{enumerate}
    
    \end{document}
    
     
  • Tim Hoffmann
    Tim Hoffmann
    2012-06-16

    It's likely not the document itself. But testing with the same document makes
    it easier to reproduce the problem.

    I tried various combinations of inserting enumerate environments, items (with
    and without auto-completion), ctrl+s and F1 (quick build), but I always get
    correct results.
    Is there a definitive step-by-step procedure to reproduce the problem?

    Additional clarification:
    - The problem is that TXS claims to have saved the file, but it did not change on disk?
    - What happens if you then save as.. to a new file?

     
  • Otto Debals
    Otto Debals
    2012-06-16

    Currently, there's no step-by-step procedure to reproduce the problem :) it
    happens quite randomly, in combination with the already listed enumeration +
    ...

    I currently have exams, so I can invest my time better than continuously
    trying to reproduce the problem, my apologies :) If it happens again, I'll
    indeed check your listed actions (i.e. currently try to save as a new file).
    Thanks in advance !

    And indeed, TXS claims to have saved the file (disappearing save icon on the
    .tex file itself left of the name, and fading save icon of TXS).

     
  • Otto Debals
    Otto Debals
    2012-06-16

    Update:
    - Saving to a new file keeps and saves the new changes.
    - The bug very often appears with the enumeration apparently. I get but '1.' with

    \begin{enumerate}
    \item This is a test
    \end{enumerate}
    
     
  • Another clarification:
    Is the following correct? Once the error occurs, a simple "Save" call does
    save to disk any more at all. This is also true when you additionally type or
    remove text from the document later.

    What OS and version of TXS are you using?

     
  • Otto Debals
    Otto Debals
    2012-06-17

    That is indeed correct. If the error appears: 1. although every time after I
    save the file, I can type something, and save it again, the actual changes are
    not saved to disk; and 2. new changes are not seen in the compiled pdf from
    that moment on.

    Look at it this way: it's as if you're just working in your TXS, and TXS is
    working just fine, but the link between TXS and the hard disk & reader is at
    some point suddenly gone.

    Using Windows 7 64bit, and copying from the 'About TeXstudio ...':

    TeXstudio 2.3 (SVN 2471)
    Using Qt Version 4.7.0, compiled with Qt 4.7.0
    Copyright (c) (original TexMaker) 2004-2010 by Pascal Brachet
    TeXstudio: Benito van der Zander, Jan Sundermeyer, Daniel Braun

     
  • Otto Debals
    Otto Debals
    2012-06-24

    Installed the latest version (looks good by the way!), but it still occurs.

    However, I was able to narrow it down: it happened also once when I only used
    \item without any environment around it.
    (I used a user-defined environment and I thought that in the definition there
    was an itemization but there wasn't any.)
    Anyway, the problem thus also occurs independent of the enumeration and
    itemization environments.

    Grtz

     
  • Tim Hoffmann
    Tim Hoffmann
    2012-06-24

    Because I can't reproduce the problem, I just keep asking questions to try to
    narrow it down.
    - Is the problem gone after "Save as temp.tex" and then "Save as .tex"?
    - Is the file standalone or part of the project? If the second, does saving for other files of the project still work?
    - Do you use any non-standard configuration or setup (e.g. saved on a network folder) that might affect accesibility or writability of the file.

     
  • Otto Debals
    Otto Debals
    2012-06-24

    Sure, I'll keep answering your questions. I also try to give you information
    myself, but of course I don't know what is relevant and what not.

    • Yes, the problem is gone if it is saved under a new name and then saved back to the original name. That is indeed an additional temporary solution.
    • The one with the \item only without environment was part of a project, the problem was solved after closing and reopening TXS. I forgot however to copy the text, so I lost part of my new changes :) However, the script in a couple of posts above also causes the bug. So project or not, it looks independent of that feature.
    • No I don't. Just plain hard disk. I use however ReadyBoost for Windows 7 with an additional USB key for direct RAM memory expansion (my laptop is getting rather slow). Hmm, I'll try to unplug it and see if the problem still exists ... Maybe TXS isn't fully compatible with the use of ReadyBoost, and changes sometimes get a back-up on the USB before saving to hard disk and therefore cause some crashing ?

    Grtz

     

  • Anonymous
    2012-07-21

    Maybe this is related to this bug I posted.

    Let's try to reproduce this not-saving error:
    1. Open up a window with a blank file.
    2. "Save as...": D:\test.tex
    3. Type "\beg" and select "\begin{environment-name}" for autocompletion
    4. Type "ite" and complete with Ctrl+Space, use Ctrl-Right to get to "content..." and Ctrl+S to save.
    5. Start typing anything (it hasn't to be "\item") and observe the undo button and the save button (even the file tab doesn't have its floppy (fav)icon.
    Every Ctrl+S does simply not work because TeXstudio seems to be thinking "I am
    saved."

    The not-saving error does not appear when I don't use the erroneous auto-
    completion on the environment-name.
    "\begin{ite" and completing work just fine.

     
  • Tim Hoffmann
    Tim Hoffmann
    2012-07-21

    Thanks for the clarification. Now we know where to look.

    Btw. I also noted that undo does not work correctly after the above procedure.
    But it's likely the same cause.

     
  • Tim Hoffmann
    Tim Hoffmann
    2012-07-27

    Should be fixed together with the bug mentioned by Qrrbrbirlbel (post 13).
    Now, the example you posted works correctly. Also undo is now doing what it
    should.