Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23

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

  1. #11
    Trolledge ( looks very nice, pity it only has Windows and OS/X support. Any one tried it?

  2. #12
    Quote Originally Posted by Ñuño Martínez View Post
    I'm pretty happy with Vim. Actually I think it would be better but I can't back to those CUA editors.
    I did temper with an Emacs package that talked to Lazarus CodeTools for inteliisense and autocompletion and I actually made it work..sortof. When I finish my current project I'll try to get back into vim-script again and rewrite it. With Vim8 and asynchronous i/o support it would be if not easy, so atleast easier then working with Emacs and background processes.

    In short, it shouldn't be that much work involved in writing a vim plugin that talked to a CodeTools server running in the background. With Emacs you had to poll the server to get updates, and pipe them through a hidden buffer into the current buffer you where editing, and that caused lots and lots of overhead, and quite frequently a crash or two (might depend on my not-so-good pascal skills ). If you ever used the vim plugin YouCompleteMe when writing C/C++ code you got a pretty good picture on what I'm aiming for.

    Please let me know if you would be interested in testing it out, or maybe even give me a hand with it. We 'Vimmers' need to stand up for our editor

  3. #13
    I would try.

    I have no experience with vim-script, that is why I tried to create my own editor using Lazarus.
    No signature provided yet.

  4. #14
    Quote Originally Posted by Ñuño Martínez View Post
    I would try.

    I have no experience with vim-script, that is why I tried to create my own editor using Lazarus.
    Vim-script is the epiphany of bad design! It's absolutely awful..but if you manage to get your head around it, it's also very, very powerful. Every little aspect of the editor is scriptable. There is however the possibility to use python IF vim was compiled with support for it. I think that most mainstream versions of pre-compiled vim binaries atleast has support for Python2.6 baked into the executable. Another option is lua, or ruby (in the latter case I do think vim-script is tidier and more comprehensive..)

    Can't find the time for such a big undertaking atm, but when I finish of some other projects I promise that I'll give it a go, a prototype shouldn't take that much time to produce, but I surely could use some help with the backend, which will be written in Pascal. My Emacs 'server' piped string objects back and forth between the CodeTools interface and the Emacs buffer, but I'm pretty sure that there is another, more efficent way of doing this. The Vim-way of swap-files could be abused to achieve a better interface between the two (Vim and CodeTools).

    Disecting the YouCompleteMe source might give me a better understanding on how to proceed.

    Can't help it, but I feel like all 'modern' editors, apart from atom/code/sublime isn't really good at handling large amounts of source-code. One thing I hate is when the editor gives you the option to autoclose brackets/parens etc but doesn't do anything to actually match the pairs.. For example:

    constructor TSomeClass.Create(|)
    This happens in most editors when you turn on autoclose ('|' is used to display the cursor position).
    constructor TSomeClass.Create(text:string|)
    All is well
    constructor TSomeClass.Create(text:string)|)
    What? I typed a closing paren and the stupid editor didn't match parens, so instead of jumping over the closing paren, it inserted a new one. Mumblemumblemumbe. Hit 'del', move pinky to right arrow, move cursor over the stupid paren and insert that semicolon
    constructor TSomeClass.Create(text:string);
    In 'real' editors, that doesn't just autoclose, but actually match pairs of brackets/parens ets this would not have happened, and I would be churning out code instead of cursing and moving the cursor by using the arrow keys, which by the way are located far of where your fingertips should be to write fast and efficent.
    Last edited by Rickmeister; 04-02-2017 at 08:18 PM.

  5. #15
    Got some vim hacks I can share with you. If you want to change the default mode, just edit the script. Now it defaults to {$mode delphi}. I think the .vimrc file of my current installation is around 1500 lines long *phew*. This example script shows two things:
    1. Vim is a powerful editor, that you can customize as you like (almost)
    2. Vim-script syntax is horrible

    function! InsertModeLine()
    python << endpython
    import vim
    vim.current.buffer[0:0]=['unit '+unitname+';']
    vim.current.buffer[2:0]=['{$MODE DELPHI}']
    del vim
    augroup Delphi
        autocmd BufNewFile,BufRead *.pas,*.pp,*.dpr :set tabstop=4
        autocmd BufNewFile,BufRead *.pas,*.pp,*.dpr :set shiftwidth=2
        autocmd BufNewFile,BufRead *.pas,*.pp,*.dpr :set softtabstop=4
        autocmd BufNewFile,BufRead *.pas,*.pp,*.dpr :set expandtab
        autocmd BufNewFile,BufRead *.pas,*.pp,*.dpr :set nospell
        autocmd BufNewFile,BufRead *.pas,*.pp,*.dpr :let g:pascal_delphi=1
        autocmd BufNewFile *.pas,*.pp :call InsertModeLine()
    augroup END
    In short, it sets tabs to be equal to 4 spaces, and sets the auto indent tabstop at 2 spaces. The rest is just for show For some reason vim defaults to some late 60'ies syntax for pascal, but more modern delphi and fpc syntax is provided.

    If you want fpc syntax: do this changes
    // Change this line
    let g:pascal_delphi=1
    // to
    let g:pascal_fpc=1

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

  7. #17
    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:
    let g:primary_file=""
    function! CompilePascal(mode)
    python << endpython
    import vim
    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)
    Also, add these line to the Delphi augroup:
    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).
    :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)

  8. #18
    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

  9. #19
    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.

  10. #20
    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.
    :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.

Page 2 of 3 FirstFirst 123 LastLast


Posting Permissions

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