Dear all, Richard Stallman started a thread on emacs-devel on how to let Emacs do WYSIWG word processing: https://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00515.html "25 years ago I hoped we would extend Emacs to do WYSIWG word processing. That is why we added text properties and variable width fonts. However, more features are still needed to achieve this. Could people please start working on the features that are needed?" This hit the news: https://news.ycombinator.com/item?id=6773529 I don't want to fork the thread and import the discussion here, instead I'd like to discuss a feature for Org that I think would be useful*. How far are we from allowing users to preview an exported Org buffer into a separate window, and displaying either a PDF or an ODT document through DocView? Since Org can already perform export asynchronously, maybe all what we need is to create a function for `write-file-hooks' that exports in the background and display the document in another window. Maybe someone already have such a setup? Would you be interested in having it? Thanks in advance for your feedback! * See http://article.gmane.org/gmane.emacs.devel/165543 -- Bastien
Bastien <bzg@gnu.org> writes:
> Dear all,
>
> Richard Stallman started a thread on emacs-devel on how to let Emacs
> do WYSIWG word processing:
>
> https://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00515.html
>
> "25 years ago I hoped we would extend Emacs to do WYSIWG word
> processing. That is why we added text properties and variable width
> fonts. However, more features are still needed to achieve this.
>
> Could people please start working on the features that are needed?"
>
> This hit the news: https://news.ycombinator.com/item?id=6773529
>
> I don't want to fork the thread and import the discussion here,
> instead I'd like to discuss a feature for Org that I think would be
> useful*.
>
> How far are we from allowing users to preview an exported Org buffer
> into a separate window, and displaying either a PDF or an ODT document
> through DocView?
>
> Since Org can already perform export asynchronously, maybe all what we
> need is to create a function for `write-file-hooks' that exports in the
> background and display the document in another window.
So with LaTeX it should be pretty easy using latexmk. Latexmk can
watch for changes in the .tex file and recompile the pdf
intelligently. For windows there's a program called LaTeXDaemon.
Thus, what would be needed would be to write the tex file when stuff
changes and it wasn't exported in the last t seconds. Perhaps it
would require some caching, e.g. with heavy babel blocks.
Personally, I'd want to use Evince and not Docview. Does Docview
notice changes in the pdf?
–Rasmus
--
⠠⠵
Bastien <bzg@gnu.org> writes:
Hi Bastien
> How far are we from allowing users to preview an exported Org buffer
> into a separate window, and displaying either a PDF or an ODT document
> through DocView?
not sure about Org preview, but when using AucTex, Evince updates
automatically when re-compiling the doc, the display looks nicer, and
the first display of an entire (big) pdf is definitely faster than with
DocView.
Using my window-manager to put the Emacs and Evince frames side-by-side
gives me direct feedback about the resulting pdf each time I do C-c C-c
in the .tex buffer.
I don't know if this would work in Org-mode with re-exporting just like
in AucTex with re-compiling. But anyway, I guess you are looking for an
Emacs solution without external programs like Evince.
--
cheers,
Thorsten
On Fri, Nov 22, 2013 at 03:30:18PM +0100, Rasmus wrote:
>
> Personally, I'd want to use Evince and not Docview. Does Docview
> notice changes in the pdf?
Only with auto-revert-mode on. I prefer Evince over Docview too.
Docview wait times can be significant when the pdf is large (~30), or
when there is a large vector drawing in the pdf.
--
Suvayu
Open source is the future. It sets us free.
Hi, just in a coincidence, I looked into Whizzytex [1] a few days ago. This minor mode opens up a pdf-viewer and keeps it updated with literally every keystroke within the tex-file. (Yes xpdf works, albeit the website and emacswiki only describe dvi and ps as backends). In addition, it adds some marks in the PDF to show the actual cursor position wihin the tex-file. You could see it as some sort of pdf-preview on drugs. That is a realtime-update instead of an update after each compilation. WhizzyTex tries to be smart and only seems to compile the region which is needed to give you the output you would like to see. This is very useful esp. if you do small corrections (like revising a manuscript). Since you can see what effect your spellcheck corrections and grammar twisting has on the document outcome. On the other hand, if you receive a hand-annotated version of an manuscript is much easier to find the parts which needs to be corrected having a life-update beside the TeX-file. Another area where I really like it is in conjunction with TikZ. WhizzyTex gives you a online-update of your drawing. As people who worked with TikZ now, it can be very cumbersome to get the right coordinates for something. With WhizzyTex the position of drawings, nodes and whatever, change instantly as you type it. This makes drawing really easy. On the downside, it seems a bit outdated. At least the installer gave me a headache. The manual describes a manual installation method which after some tweaking worked for me. There is no package on ELPA thus, I have no idea about the actual status of it. Last update was on January 2013, not that long ago. Would it be an option to implement something like WhizzyTex for org-mode? Thus you would have the easiness of org-mode syntax (which is enough for many cases) with an realtime update of the export to PDF. [1] http://cristal.inria.fr/whizzytex/whizzytex.html On 22 November 2013 15:51, Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote: > On Fri, Nov 22, 2013 at 03:30:18PM +0100, Rasmus wrote: >> >> Personally, I'd want to use Evince and not Docview. Does Docview >> notice changes in the pdf? > > Only with auto-revert-mode on. I prefer Evince over Docview too. > Docview wait times can be significant when the pdf is large (~30), or > when there is a large vector drawing in the pdf. > > -- > Suvayu > > Open source is the future. It sets us free. >
Hello,
torsten.wagner@gmail.com writes:
> Would it be an option to implement something like WhizzyTex for org-mode?
> Thus you would have the easiness of org-mode syntax (which is enough
> for many cases) with an realtime update of the export to PDF.
This would be wonderful.
I happen to know Didier Rémy (the author of WhizzyTex). If there are
changes needed in WhizzyTex to make this happen, I could try to contact
him.
Alan
[-- Attachment #1: Type: text/plain, Size: 572 bytes --] On Nov 22 2013, Bastien <bzg@gnu.org> wrote: Hello all, I have been using a simple bash script with a Makefile to make pdf file to be updated with org source on each save while I am editing. It is working fine for me. Of course its not exactly real time but fast enough feedback for me. I am attaching my files hoping that they may be useful for others. one may need to edit init.el and Makefile for their use case. I run something like this. $ watcher.sh paper.org make Watcher script checks every second to see if the org file is modified and runs make command. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: watcher.sh --] [-- Type: text/x-sh, Size: 385 bytes --] #!/bin/bash FILE="$1" CMD="$2" LAST=`ls -l "$FILE"` while true; do sleep 1 NEW=`ls -l "$FILE"` if [ "$NEW" != "$LAST" ]; then t="$(date +%s)" echo "watcher action started at " $(date) "$CMD" 2>&1 | tee /tmp/wathcer.log.$$ LAST="$NEW" t="$(($(date +%s)-t))" printf "done; %02d:%02d\n" "$((t/60%60))" "$((t%60))" fi done [-- Attachment #3: Makefile --] [-- Type: application/octet-stream, Size: 712 bytes --] EMACS=emacs BATCH_EMACS=$(EMACS) --batch -Q -l init.el MAINDOC = paper RM = rm %.tex: $(BATCH_EMACS) $*.org -f org-latex-export-to-latex %.pdf: %.tex if pdflatex $*.tex </dev/null; then \ true; \ else \ stat=$$?; touch $*.pdf; exit $$stat; \ fi bibtex $* while grep "Rerun to get" $*.log; do \ if pdflatex $*.tex </dev/null; then \ true; \ else \ stat=$$?; touch $*.pdf; exit $$stat; \ fi; \ done all: pdf tex: $(MAINDOC).tex pdf: $(MAINDOC).pdf html: $(BATCH_EMACS) $(MAINDOC).org -f org-html-export-as-html clean: $(RM) -f *.aux *.bbl *.blg *.log cleanall : clean $(RM) -f *.dvi *.cfg *.idx *.ilg *.ind *.toc *.lot *.lof *.pdf *.out $(RM) -rf $(MAINDOC) .PHONY: clean cleanall [-- Attachment #4: init.el --] [-- Type: application/emacs-lisp, Size: 1020 bytes --] [-- Attachment #5: Type: text/plain, Size: 116 bytes --] Thanks., -- ఎందరో మహానుభావులు అందరికి వందనములు. YYR
Hi Alan,
nice, you might can start easily asking him to solve the installer
problem and provide an package for a ELPA repository. That alone would
allow much more people to use it.
I think the main problem for org-mode would be the fact that
org-mode->PDF is a two step approach. Org-mode exports converts the
org-mode syntax into a TeX file which then gets compiled into PDF by a
LaTeX system. To preserve the cursor position, the org-mode exporter
would have to add the necessary code already within the Tex-file.
That means whatever whizzytex.el is doing to the final latex code,
parts of it would need to move to org-mode export for PDF.
After that, I believe one could use whizzytex as it is.
However, I guess the author Didier Rémy can forsee already very
clearly what kind of feature would be needed in the org-mode exporter
to make it working with whizzytex.
Since we have now a modular exporting system, we could have a
ox-whizzytex which mainly base on ox-latex and only adds the
additional requirements for whizzytex. this requirements as far as I
can see would be:
1. Cursor position
2. Automatic definition of an export region (in the same way,
Whizzytex works on a subset of the TeX-buffer to allow fast
compilation).
3. Create a function outside the exporter which calls ox-whizzytex
exporter for each change in the org-file.
Point 2 would be necessary within org-export to avoid long processing
times of org-export on large documents.
All in all, it would require to implement the functions defined in
whizzytex.el to org-mode resp. the org-exporter.
Alternatively, one could make whizzytex aware of org-mode and calling
the org-exporter for an region first before processing the generated
TeX file.
This would lead to the decision whether to have a
org-mode exporter for whizzytex
or to make
whizzytex aware of org-mode
All the best
Torsten
On 25 November 2013 11:35, Alan Schmitt <alan.schmitt@polytechnique.org> wrote:
> Hello,
>
> torsten.wagner@gmail.com writes:
>
>> Would it be an option to implement something like WhizzyTex for org-mode?
>> Thus you would have the easiness of org-mode syntax (which is enough
>> for many cases) with an realtime update of the export to PDF.
>
> This would be wonderful.
>
> I happen to know Didier Rémy (the author of WhizzyTex). If there are
> changes needed in WhizzyTex to make this happen, I could try to contact
> him.
>
> Alan
Hi Torsten, torsten.wagner@gmail.com writes: > Hi Alan, > > nice, you might can start easily asking him to solve the installer > problem and provide an package for a ELPA repository. That alone would > allow much more people to use it. Regarding this very first request: where can I find documentation about creating a package? I searched for "create ELPA package", and I got links such as http://tromey.com/elpa/upload.html which tells me "package.el is pedantic about the header and footer comments, please make sure you have the correct number of semicolons and hyphens." but not what I should put. Is there a tutorial somewhere? Thanks, Alan
Alan Schmitt <alan.schmitt@polytechnique.org> writes:
> where can I find documentation about creating a package?
(info "(elisp) Packaging")
Alan Schmitt writes: > Regarding this very first request: where can I find documentation about > creating a package? I searched for "create ELPA package", and I got > links such as http://tromey.com/elpa/upload.html which tells me > "package.el is pedantic about the header and footer comments, please > make sure you have the correct number of semicolons and hyphens." but > not what I should put. Is there a tutorial somewhere? Assuming that we are talking about a package that has more than a single source file, you could start by looking at the orgmode ELPA package and take it from there. In a nutshell, package.el expects all files in a flat single directory, a package definition file that contains the name and dependencies of the package to be installed and that it doesn't need to build anything except for the .elc files (in other words, you need to precompile any texi source to info files). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Yagnesh Raghava Yakkala <hi@yagnesh.org> writes: > On Nov 22 2013, Bastien <bzg@gnu.org> wrote: > > Hello all, > > I have been using a simple bash script with a Makefile to make pdf file to be > updated with org source on each save while I am editing. It is working fine > for me. Of course its not exactly real time but fast enough feedback for me. > > I am attaching my files hoping that they may be useful for others. one may > need to edit init.el and Makefile for their use case. I run something like > this. > > $ watcher.sh paper.org make > > Watcher script checks every second to see if the org file is modified and runs > make command. > We can use auto-shell-command [[https://github.com/ongaeshi/auto-shell-command][auto-shell-command]] > > > > Thanks., --
kjambunathan@gmail.com writes:
> Alan Schmitt <alan.schmitt@polytechnique.org> writes:
>
>> where can I find documentation about creating a package?
>
> (info "(elisp) Packaging")
Double thanks: for the links, and for making me notice that my info was
showing me some things from an old emacs.
Alan