91–100 of 168 posts
Why do we need such things in 2019?
Non-inclusive-we 'need' it because we want it and will make it ourselves. Inclusive-we do not because your individual needs were never and should never be the concern of a project that you have no investment in.
What I do is mostly refactoring, finding files by name or contents and moving cursor to places I've been in which provides seamless navigation between files as well.
Earlier quoted context omitted.
That's precisely what every single python IDE does. They take isort, black, jedi or whatever other engine together and stitch them together in a user transparent way. Omnisharp was literally the attempt of MonoDevelop to create an open source alternative to the Resharper engine. The completion agents for VIM or VSCode do the presentation layer for the lower layer(the language server daemons, or custom completion agen…
Yeah well, it isn't like Python IDE are much better :-P. I think in general most languages with unix-ish background do not tend to have truly integrated development environments as unix was always about stitching together stuff. Only Borland somewhat managed to make real integrated environments for their C/C++ tools and even then it wasn't as good as the stuff they had better control over (turbo pascal, delphi, etc).…
Vim didn't allow integration because there was no way interface to it, and it's not an easy codebase. Neovims work is proof of that. C++ compilers didn't allow integration because they were big monstrous projects and when you need to do proper c++ indexing you basically need to compile the whole project.
For C++ this changed with clang and even for clang it took a lot of iterations and bugs inside of libclang to allow for this capability.
Naturally one of the best C++ IDE's was therefore also by the producer of their own compiler (Visual Studio).
These boundaries are slowly fading, so these arguments are kinda moot. A few examples:
https://clang.llvm.org/extra/clangd/
I'll just leave a shameless plug for my neovim GUI project here: https://github.com/vhakulinen/gnvim . It has a WIP PR[1] for implementing multigrid support, which would allow features such as scrollbars. There are many other GUIs too, such as oni/oni2, gonvim, neovim-gtk and neovim-qt. Extensive list can be found here: https://github.com/neovim/neovim/wiki/Related-projects#gui 1: https://github.com/vhakulinen/gnvim/…
I just tried this. I get rendering artifacts when scrolling. BUT! The scroll speed is absolutely wonderful. I've tried all the UIs and always find myself going back to the terminal, but this is something else. Although I have to say fvim looks tempting as well and vimr(I'm not on MacOS anymore). For those people mocking vim users and bragging about their IDE's. With languageserver and the other kind of refactoring da…
Visited its page to have a look... I'm not sure why they'd put a screenshot with a variable width font, which automatically puts lots of people off when it comes to coding...
It's like having a screenshot of your bitmap editor, and showing it editing goatse.cx...
Earlier quoted context omitted.
Both neovim-gtk & gnvim are great but don't integrate nicely with standard ctrl + c, ctrl + v actions which is super frustrating. VSCode with vim plugin handles this well with the Use Ctrl Keys option set. If you're in insert mode, ctrl + v will paste, otherwise ctrl + v will start visual mode. If you are selecting text, ctrl + c will copy.
set clipboard+=unnamedplus imap + vmap y Most probably you want this as well: cmap +
The C-v (Ctrl+lowercase v) is important for literal character insertion. (Insert a tab, escape, return, etc.)
Earlier quoted context omitted.
I'm not going to mock you, but why not just use an IDE with a vi(m) mode or plugin in the first place, if you really want all those features? Modern IDEs are following a platform + plugins architecture that is probably as flexible but more robust than whatever you can tape together around vim.
Because Vim modes usually don't support more than a handful of basic features, let alone plugins and custom keybindings. Vim also starts up without any noticable delay and can be used for every text file, no matter in what context.
Only if you run it without any plugins. Unfortunately if you have a lot of third party packages, vim startup times start to get closer to emacs startup times (both of which are still better than any IDE I have used, of course). I keep a vim.norc alias in my alias file which launches vim with an empty .vimrc for this very reason.
Earlier quoted context omitted.
Yeah well, it isn't like Python IDE are much better :-P. I think in general most languages with unix-ish background do not tend to have truly integrated development environments as unix was always about stitching together stuff. Only Borland somewhat managed to make real integrated environments for their C/C++ tools and even then it wasn't as good as the stuff they had better control over (turbo pascal, delphi, etc).…
I think this isn't about unix tools or philosophies. It's about the fact that for a very long time these big monolithic projects didn't really allow any integrations. Vim didn't allow integration because there was no way interface to it, and it's not an easy codebase. Neovims work is proof of that. C++ compilers didn't allow integration because they were big monstrous projects and when you need to do proper c++ index…
libclang might be a bit closer but it still is something separate from whatever IDE it is used for.
Honestly i do not believe it is even possible to what the sort of integration i'm talking about by stitching together separate projects no matter how many extension points and hooks those projects provide - by definition they aren't made with a singular coherent vision where everything is meant to work together, instead each project has its own idea of how it should work.
MSVC could in theory be able to do that since the IDE is made by the same company as the compiler, but in practice the teams behind it are probably acting as separate "sub-companies" inside the bigger organization. They're not seen as a single "C++ development environment" project but as two separate projects that happen to communicate with each other.
I'm not sure if 'philosophy' is the proper term here, but it is certainly about how you believe that software should be made and having that in mind at all times when designing it at all levels - be it the functionality to provide or how that will be implemented (e.g. a compiler that runs as a simple standalone application can just use globals for the state and perhaps not even free memory at shutdown - see dlang as an example - whereas a compiler meant to be integrated as a library cannot do that).
As an example, for a Borland-like approach (at least based on my understanding of it), adding a language extension to -say- provide meta-data for classes wouldn't be something that only the compiler developers cared about, but something that the developers of the compiler, the debugger (for being able to display the meta-data), the IDE (for editor auto-completion and automatic code editing - later Borland IDEs could modify the code - and debugger UI), the framework library (for taking advantage of it and providing a 'best use' scenario), etc. And all of those would influence the new functionality instead of being something that was added by the compiler team and then the rest would have to support (as it is done by pretty much every language that only exists as a standalone compiler or interpreter without any concern for IDEs, debuggers, UIs, etc nowadays).
Earlier quoted context omitted.
The terminal is common to many operating systems and keyboard shortcuts leant there are pretty universal. If you prefer a keyboard driven workflow learning to use a terminal and terminal based editor will give you a very portable solution. Vi's commands are somewhat like a language for manipulating text. This is a different philosophy to many non-modal editors. In vi you can say change the next 3 paragraphs to foo or…
I guess it depends on the usecase. You mention a lot of scripting, and also the terminal. Would you also recommend vim for working on large projects with 100+ files? I believe in this case, a full on IDE is suited better. Also I'm not so sure about the portability. Sure, some of the knowledge is reusable, but when all the vim installations are not "batteries included", every installation will be configured differentl…
You would be surprised by what Vim can do out of the box simply by turning features on. It's also very easy to move configs about. I use github for that job but I can use Vi/Vim without a config if needed.
However what I really mean by portability is that once set up I have exactly the same shortcuts on both my own mac, client's linux laptop and servers. Currently I use tmux for window management but I could use NeoVim for that now. If I want to open a split terminal window or move an existing one about it's exactly the same short cut on each machine.
> Another point: I think with strongly and statically typed languages one shouldn't think about writing code as writing text, but about building a syntax tree that happens to be text.
That's in no way tied to a GUI and there's nothing to stop you adding IDE like features to an editor like Vim. The terminal is just another way of representing tooling to the user.
However if you prefer a GUI interface then nothing stops you from using that in preference to the terminal either. I only point this out as the grand parent asked why we would bother in 2019.
Earlier quoted context omitted.
set clipboard+=unnamedplus imap + vmap y Most probably you want this as well: cmap +
Worth noting that this is Ctrl+Shift+v and Ctrl+Shift+c. The C-v (Ctrl+lowercase v) is important for literal character insertion. (Insert a tab, escape, return, etc.)
You can remap it to (L = literal), and then use and without shift:
inoremap
imap +
cmap +
xmap "+y