Results 1 to 10 of 23

Thread: VS Code + Pascal : Editor for the future!

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    So, should we add that code to the end of the .vimrc file? That's all?
    No signature provided yet.

  2. #2
    Yes. Just copy those lines into your .vimrc and source it (:so %). Next time you create a unit (myUnit.pas or myUnit.pp for example) it will automatically insert the line 'unit myUnit' and {$MODE DELPHI}.

    Another quickie:
    Code:
    let g:primary_file=""
    
    function! CompilePascal(mode)
    python << endpython
    import vim
    mode=vim.eval("a:mode")
    primary_file=vim.eval("g:primary_file")
    if mode=='DEBUG':
        vim.command("set makeprg=ppcx64\ -dDEBUG\ @fp.cfg\ " + primary_file)
    elif mode=='NORMAL':
        vim.command("set makeprg=ppcx64\ -dNORMAL\ @fp.cfg\ " + primary_file)
    elif mode=='RELEASE':
        vim.command("set makeprg=ppcx64\ -dRELEASE\ @fp.cfg\ " + primary_file)
    vim.command("make")
    endpython
    endfunc
    Also, add these line to the Delphi augroup:
    Code:
    autocmd BufNewFile,BufRead *.pas,*.pp,*.dpr,*.lpr :compiler fpc
    autocmd QuickFixCmdPost [^l]* nested cwindow
    autocmd QuickFixCmdPost    l* nested lwindow
    This little snippet, which you can bind to a key if you like, build pascal projects using fp.cfg (created by the fp-ide).
    Usage:
    Code:
    :let g:primary_file="program.pas" // Only needed once. Subsequent runs will remember this
    :call CompilePascal("DEBUG") // replace with "RELEASE" or "NORMAL" for other build configurations
    I think I've made a function that scans the folder for a *.lpr or *.dpr file and automatically set it as the primary file. Can't find it right now. When the build is complete you'll be asked to press a key to return to vim, and when back there you'll see that a "quickfix" window has opened, showing errors and warnings issued by the compiler. If you click them, the cursor will be placed at the error, and if you like me doesn't like to use the mouse, you can either type ':cn' or ':cp', or bind them to a key of your choice to jump to next error (cn) or the previous one (cp)

  3. #3
    Got tons of tips and tricks for vim, some are a bit more advanced then others - ranging from remapping function keys to work in all modes (normal,insert and visual) to configuring Pyclewn for debugging inside vim. Got codecompletion, code generation, building and debugging all set up in a way I like it, and all in the same editor. Some of the more advanced stuff needs a bit of bash-hacking to work in a terminal, but I mainly use gvim (or vim -g), I only use terminal-based vim sessions for editing scripts and config files. Note that I don't know much about setting up vim on windows as I only work on Linux and OS/X. For C related stuff I prefer Emacs, but that's another story

  4. #4
    I did create my own color schema to be the same than good old Borland Turbo IDEs. That and setting a few odd edition stuff (show special characters, use two different back-up files...). That's all I did.

    Didn't test your code yet.
    No signature provided yet.

  5. #5
    Quote Originally Posted by Ñuño Martínez View Post
    I did create my own color schema to be the same than good old Borland Turbo IDEs. That and setting a few odd edition stuff (show special characters, use two different back-up files...). That's all I did.

    Didn't test your code yet.
    Code:
    :colorscheme borland


    If you want to I can try to tidy up my vimrc and post it here on the forums somewhere, or put it on github - either way is ok.
    What I can do with my vim settings:
    • Automatic insertion of 'header' in files (comment etc). Customized by filetype
    • Code completion - Provided by NeoComplete (plugin).
    • Browse tags with a keypress (actually Three ',tt')
    • Jump between declaration and implementation
    • Code generation for class procedures/functions/constructors/destructors
    • Extensive (ab)use of snippets
    • Build project (debug or release is set by a command)
    • Debug using Pyclewn and GDB
    • Send emails (Yeah, really )
    • Generate build scripts (really stupid at the moment, need improvements)
    • Calltips (also really stupid at the moment, but it's a WIP)


    Most of it is written in hackish python, with some extra lines of vimscript to spice it up.

  6. #6
    That would be great.

    You may post it at Lazarus forums too.
    No signature provided yet.

  7. #7
    Quote Originally Posted by Ñuño Martínez View Post
    That would be great.

    You may post it at Lazarus forums too.
    I'll drop it in here, just give me a few weeks to tie up all loose ends. Much of the scripts are scattered over a couple of files, so I need to sort them out and package them in a nice way, the ideal solution would be to create a plugin that you can use with Vundle and Pathogen, that would make it so much easier and more user friendly for others. The learning curve is steep, and we that have climbed almost to the top shouldn't keep pushing people down

    Got alot of issues with my code completion plugin as it tends to crash from time to time, most likely an out of range error, but as it just dies without issuing any errors, and the abilities to debug python running inside vim are limited (non-existant would maybe be a better word) it's hard to find out exactly where it bugs out. It's also quite slow when you open a project the size of Castle engine (python regex is kinda slow when it has lots of text to process), and the context awareness would need to be improved, so I don't think I'll include that. Now I'm just using NeoComplete and it does the job, but isn't perfect. I need to look into Lazarus CodeTools and try to write some sort of server backend that can talk to vim through a python script, ideally wrap some library calls to python, but my Pascal knowledge is far from the point where I could be able to pull that off. On the other hand, nobody remembers a coward!!

    Got a nice little hack that generates class function/procedures that can save you quite some time and it's quite stable, and so is the build/run/debug scripts. Then there are other more basic stuff like header insertions (comments, unit name, defines etc) and stuff like that.

    I'll get back to you

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •