331–340 of 420 posts
Earlier quoted context omitted.
Are they merging code from neovim, or is it a parallel implementation?
I think the former---from what I've heard neovim and vim are on very good relations, and here is the fruit of that.
With the age of their respective codebases, I'd love to know what lurks beneath? Immaculate, well factored code? A hornets nest of hacks - what do you expect from such old codebases - or have they been re-written so many times you'd never guess their ages from the codebase.
Pfft on immaculate, well factored code. All glory to battle hardened code that does the business everyday. Of course it would be better to have both. But don't dismiss code that survived the withering infernos of real world use. All those edge hacks are there because they probably need to be.
Remember to donate to uganda guys it's the only thing Bram asks for in return for this software.
Earlier quoted context omitted.
The fact that I can customize VIM to suit my needs with modern methods and plugins that bring same kind of functionality found in more modern editors/development envs to the powerhouse that is VIM. For example, these are some of my favorites: https://valloric.github.io/YouCompleteMe/ - Code completion for C/C++ and other languages https://github.com/ctrlpvim/ctrlp.vim - TextMate style ctrl+p fuzzy file finder https:/…
One of the things that keeps me in VS (with VsVim) versus actual Vim for C# is that, for strictly typed languages, the autocomplete can't be beat. AFAIK, Vim autocomplete solutions use a relatively dumb autocomplete, while VS knows the types of everything and shows you all of the things you can access and nothing you can't, including changes that haven't actually been compiled yet. I also think that interactive debug…
Earlier quoted context omitted.
What about groff?
How does groff do formulas?
Earlier quoted context omitted.
It's not dead, it's finished. It's got all the features of the original vi, therefore mission accomplished. Software doesn't need to be developed ad-aeternum to remain 'alive'.
> Software doesn't need to be developed ad-aeternum to remain 'alive'. I have to politely but firmly disagree. Software rots if it's not being actively maintained. Underlying API/ABI's get deprecated and eventually dropped, dependencies reach end-of-life and need to be replaced, and so on. Take one program today and try to run it in 10 years, as is. I bet it won't work. I'm talking of course, of any non-trivial piece…
But BSD vim (nvi) is maintained as part of the base systems of the BSDs, so it changes with system changes although it's in maintenance mode. E.g.:
Earlier quoted context omitted.
Well, for various reasons both of them don't really have any competition. Xcode, especially, is the IE6 of Mac coding. Only recently some competition has emerged, from Intellij.
I can't say anything about Xcode, but I can say that VS hasn't stagnated in that way, every new release seems to bring something worth having.
Earlier quoted context omitted.
Yes, but writing a Visual Studio extension (or Eclipse, etc.) is much higher friction than Emacs. In emacs, I can just open a buffer in emacs-lisp-mode, write a quick function, immediately eval it and start using it. The instant feedback means that quick, small customizations are very low cost. It's like the difference between writing a code generator for Java vs using macros in Lisp.
I see. Can you give me an example of a function you wrote in that way?
I could've edited the Emmet source code in place, but to do so would've meant losing my customizations next time I upgraded the package. I could have forked it, but that would mean having to manually merge changes into the fork every time a new release comes out.
Instead, after a couple hours of reading the Emmet source and fiddling around in an Emacs Lisp buffer, I ended up with this:
(defcustom emmet-verticalize-html-attributes nil
"Whether to verticalize attributes in HTML tags.
\"Verticalize\" here means to separate each pair of attributes by
newline and enough indentation to line up the first character of
attribute names. For example, the unverticalized production
when verticalized becomes
"
:type 'boolean
:group 'emmet)
(defcustom emmet-verticalize-minimum-attributes 3
"The minimum number of attributes required for
verticalization. If a tag has fewer than this many
attributes. they will not be verticalized, even when
verticalization is enabled.
Values less than 2 have no effect, since verticalization only has
an effect on tags with at least two attributes."
:type 'integer
:group 'emmet)
(defun emmet-verticalize-html-tag (orig &rest args)
(let ((html (apply orig args))
(attribute-count 0))
(if (null emmet-verticalize-html-attributes)
html
(save-match-data
(with-temp-buffer
(insert html)
(html-mode)
(goto-char (point-min))
(while (re-search-forward (pcre-to-elisp "^\\")))
(re-search-forward (pcre-to-elisp "\\w[\\w\\d_-]+\\=\\\".*?\\\"" ) nil t))
(setq attribute-count (1+ attribute-count))
(and (not (looking-at (pcre-to-elisp "\\/?>")))
(newline-and-indent))))
(indent-region (point-min) (point-max))
(if (>= attribute-count emmet-verticalize-minimum-attributes)
(buffer-substring-no-properties (point-min) (point-max))
html))))))
(advice-add 'emmet-make-html-tag :around #'emmet-verticalize-html-tag)
(defcustom emmet-indent-html t
"Whether or not to indent generated HTML according to the same rules
used by `html-mode'.
When non-nil, Emmet-generated HTML will be indented via
`html-mode', with a newline after every closing angle bracket.
When nil, Emmet-generated HTML won't be post-processed in this
way. (The version of Emmet I'm using, 1.0.8, applies no
indentation whatsoever.)"
:type 'boolean
:group 'emmet)
(defun emmet-indent-html-snippet (html)
(if (not emmet-indent-html)
html
(save-match-data
(with-temp-buffer
(insert html)
(goto-char (point-min))
(while (and (re-search-forward (pcre-to-elisp "\\>") nil t)
(not (eobp)))
(newline))
(goto-char (point-min))
(while (search-forward "\n\n" nil t)
(replace-match "\n" nil t))
(html-mode)
(indent-region (point-min) (point-max))
(buffer-substring-no-properties (point-min) (point-max))))))
(advice-add 'emmet-make-html-tag :filter-return #'emmet-indent-html-snippet)
Shortly after I copied that code into the Emacs buffer I'm using (via Firefox's "It's All Text!" extension) to edit this comment, but before posting, I inadvertently killed Emacs's message buffer, which contains a running log of everything displayed in the editor's echo area. I wasn't prompted for confirmation before killing that buffer, but I felt I should've been. So I opened an Emacs Lisp buffer and wrote this:
(defun defend-message-buffer (kill-fun &rest args)
(let* ((buf (car args))
(buf-name (if (stringp buf)
buf
(substring-no-properties (buffer-name buf)))))
(if (string= buf-name "*Messages*")
(and (yes-or-no-p "Really kill the message buffer? ")
(funcall kill-fun buf))
(funcall kill-fun buf))))
(advice-add 'kill-buffer :around #'defend-message-buffer)
Earlier quoted context omitted.
Well, from my previous not great experience with terminal inside Emacs I don't really need that. I would be much happier if Emacs and Vim just had correct color support in the console so that I could use both from the console in a Tmux terminal and have a real terminal open side-by-side with the editor. I can do that in Vim nicely after hacking the console colors, and Neovim without having to care about the colors an…
I don't personally use the terminal support. Except it turns out that I actually did, implicitly. I use fzf for opening files, and I noticed recently that it's not actually 'integrated' into neovim, it just spawns within its terminal emulator. I tried fzf in vim, and the result was less than satisfactory, to say the least.
I tried fzf after thinking it was just a vim plugin and the install-process immediately drove me away.
Don't edit my dotfiles and change my $PATH with your installer. That shouldn't ever have to be said.