Customize each :PP call

Some providers like dpaste.org give the ability to chose syntax highlighting.
In the case of dpaste you'd add -F "lexer=lua" to your curl command.
I wanted :PP to automatically put the current filetype in there.

Maybe cmd() should take provider_options as an argument and set the dpaste provider to have a lexer provider option?

Keep in mind that I can't read fennel so if something like this was already implemented an example config would be very appreciated.

I actually did have that originally but dpaste would hard-fail if it didn't recognise the filetype:

paperplanes.nvim/fnl/paperplanes/providers/dpasteorg.fnl

Lines 3 to 6 in 568611e

    
           (fn provide [content metadata opts] 
        
             ;; dpaste accepts a lexer option, but will 400 error if it doesn't recognise 
        
             ;; it so we will instead rely on the filename sniffer, which falls back to 
        
             ;; text if doesn't recognise the extension.

dpaste should just be finding the correct lexer by extension. That did work when I first wrote the code but dpaste may have changed.

You could use this lua table I made, I got that list from the dpaste docs and formatted it into a lua table.
And only provide curl with -F "lexer=..." if filetype is in that table.

The logic can be later improved to be smarter and knows when to use more complex lexers.
For example if you were editing an html file in a django project it's probably a django template with many curly brackets:

-F "lexer=html"

-F "lexer=html+django"

Yep seems reasonable enough to include a lookup table for known types, not 100% sure how accurate the filetypes there map to what Neovim uses for filetypes though (i.e. "js+erb" might be "erb-js" in nvim, not sure).

I think :PP should take options too as I thought here #2 (comment) and you're suggesting.

:PP lexer=python which could probably be merged into the provider options.

You don't have to be sure about its accuracy for now, if neovim can't find erb-js in the table it won't set a lexer.

I'd say leave :PP the way it is and instead provide a lua function that takes provider_opts as a table, something like require 'paperplanes'.PP(provider_opts)

Will be fixed in #9, both lexer detection and you can now call any of the API functions with an optional provider name and provider options table.

The lexer list isn't actually as complete as you posted on the live site, only

  ;; list got by posting an unknown lexer to dpaste, returns list of supported types
  ;; yes, typ_o_script (???)
  (let [known-filetypes ["applescript" "arduino" "bash" "bat" "c" "clojure"
                         "cmake" "coffee-script" "common-lisp" "console" "cpp"
                         "cpp-objdump" "csharp" "css" "cuda" "d" "dart,
                         delphi" "diff" "django" "docker" "elixir" "erlang"
                         "go" "handlebars" "haskell" "html" "html+django"
                         "ini" "ipythonconsole" "irc" "java" "js" "json" "jsx"
                         "kotlin" "less" "lua" "make" "matlab" "nginx" "numpy"
                         "objective-c" "perl" "php" "postgresql" "python" "rb"
                         "rst" "rust" "sass" "scss" "sol" "sql" "swift" "tex"
                         "typoscript" "vim" "xml" "xslt" "yaml"]]

require 'paperplanes'.PP(provider_opts)

This would be done (when 0.1.2 is merged or if you checkout that branch) via

-- assumes you've just made a visual selection before running
:lua require("paperplanes").post_selection("my_provider", {opt = "tion"})

Or any of the other post_string, post_buffer or post_range.

	(fn provide [content metadata opts]
	;; dpaste accepts a lexer option, but will 400 error if it doesn't recognise
	;; it so we will instead rely on the filename sniffer, which falls back to
	;; text if doesn't recognise the extension.