search

satyagraha / gfm_viewer

An Eclipse plugin providing an accurate view of GitHub Flavored Markdown (.md) files
94 stars 27 forks source link

option "Always save .html" #51

Closed paulvi closed 10 years ago

paulvi commented 10 years ago

As Always Generate in #47 has some other meaning, could there be Always save .html that would save all viewed HTML.

This will eliminate need to generate them.

satyagraha commented 10 years ago

That entry has been deleted, as its meaning was unclear, and the On/Off line mode covers what happens.

paulvi commented 10 years ago

There is misunderstanding.

How to have all previewed HTML automatically saved locally?

satyagraha commented 10 years ago

All previewed HTML is automatically saved locally, as the browser always views the contents of a created file on disk, i.e. there is never an in-memory-only transfer. There is no difference between the results of viewing via an editor save or via the context menu generation, the .html file is always there.

There is no mechanism provided by the plugin to delete the HTML files, which arguably could be an enhancement.

paulvi commented 10 years ago

Just checked again in 1.8.0:

  1. right-click .md file, show in GFM view
  2. See HTML
  3. There is no .*.md.html in the folder, so user needs once again request Generate Markdown Preview
  4. GFMV again requests transformation (even though the file is somewhere locally)

It would be nice to have option to have all previewed HTML automatically saved locally in .*.md.html next to .md.

paulvi commented 10 years ago

Have I said before that the plugin is close to perfect?

paulvi commented 10 years ago

BTW take a look at https://github.com/guari/eclipse-ui-theme

satyagraha commented 10 years ago

This is a visual effect only: see #52 for an explanation of what's happening.

Thanks for you comments about the plugin - for a relatively small amount of functionality it has needed a surprisingly complex codebase. The main issue I found is that the Eclipse view lifecycle has many possible different code paths, and this makes testing hard.

I have moved the project completely to a GitFlow - this is handled really well in SourceTree. The master branch remains on the front page of the GitHub project as this is where most users will come and expect to see stable information. So the develop branch is the leading-edge, not suitable for production use.

Make sure you try a local build of develop to see the new SWTBot stuff in action.

I use http://eclipsecolorthemes.org/ to have a consistent look across projects - it's not perfect but better than exporting and importing preferences all the time.