Giter Club home page Giter Club logo

glslview-nvim's Introduction

glslView-nvim

When editing GLSL shaders, this plugin provides the command GlslView which will open glslViewer to the file being edited in the current buffer. By default, it is opened with the -l flag so that glslViewer will automatically listen for file changes, updating the preview as you save.

πŸ“¦ Installation

Install the plugin with your preferred package manager. For example, in packer simply:

  use { 'timtro/glslView-nvim', ft = 'glsl' }

Don't forget to PackerCompile after installation so that the plugin will only be loaded for glsl files. You'll also need a plugin to detect the glsl filetype.

Installing glslViewer

See installation in the glslViewer Wiki.

βš™οΈ Configuration

Configuration is done by passing options to setup(). The defaults are:

require('glslView').setup {
  viewer_path = 'glslViewer',
  args = { '-l' },
}

πŸ’ͺ Usage

Use the command :GlslView to open the current buffer in glslViewer.

Additional arguments will be passed to the executable after any arguments set in configuration.

For example, to start with a 128x256 window:

:GlslView -w 128 -h 256

More primitively, one can call directly through Lua:

:lua require('glslView').glslView({'-w', '128', '-h', '256'})

🧰 Alternatives

  • vim-GlslViewer - Version drift seems to have rendered it useless (at this time) since it laucnes the process with & to free up the UI, but this causes glslViewer to stop rendering (and then in my case, close).

glslview-nvim's People

Contributors

jakergrossman avatar scmeek avatar timtro avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar

glslview-nvim's Issues

Path Configuration

I'd like to add configuration for the glslViewer path. My motive was running glslViewer natively under Windows through WSL, without messing with installing a compatible X server.

I wanted your feedback on one of two implementation methods, both of which I've already pushed to my fork. Which would you prefer?

  1. Using a global Vim option (g:glslViewExePath/vim.g.glslViewExePath):
diff --git a/lua/glslView.lua b/lua/glslView.lua
index 12a404c..102efe8 100644
--- a/lua/glslView.lua
+++ b/lua/glslView.lua
@@ -6,7 +6,7 @@ M.glslView = function()
 
   local handle -- pre-declared to avoid diagnostic error.
   handle = vim.loop.spawn(
-    'glslViewer',
+    vim.g.glslViewExePath,
     { args = { full_file_path, '-l' } },
     function()
       handle:close()
diff --git a/plugin/glslView.vim b/plugin/glslView.vim
index 37b9de5..4f5feed 100644
--- a/plugin/glslView.vim
+++ b/plugin/glslView.vim
@@ -1,3 +1,7 @@
 
 command! -nargs=0 -bar GlslView :lua require'glslView'.glslView()
 " autocmd! BufNewFile,BufRead  *.frag GlslView
+
+if !exists('g:glslViewExePath')
+    let g:glslViewExePath = 'glslViewer'
+endif
  1. Using a setup function like I've seen some other neovim plugins use, and would allow future configuration (passing additional options to the executable, for example)
diff --git a/lua/glslView.lua b/lua/glslView.lua
index 12a404c..bdb438e 100644
--- a/lua/glslView.lua
+++ b/lua/glslView.lua
@@ -6,7 +6,7 @@ M.glslView = function()
 
   local handle -- pre-declared to avoid diagnostic error.
   handle = vim.loop.spawn(
-    'glslViewer',
+    M.config.exe_path,
     { args = { full_file_path, '-l' } },
     function()
       handle:close()
@@ -26,4 +26,14 @@ M.glslView = function()
   end
 end
 
+M.setup = function(opts)
+  M.config = {
+    exe_path = 'glslView',
+  }
+
+  if opts ~= nil then
+    M.config = vim.tbl_deep_extend('force', M.config, opts)
+  end
+end
+
 return M

Which would then be used like require('glslView').setup { exe_path = '/path/to/glslViewer' }

Let me know and I'll open the pull request for whichever you prefer.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.