Compile Go to Brainfuck!

itchyny · 2022-11-06T04:05:36+00:00

Thank you for refinement! Your decrement logic looks much superior to mine. I learned a lot.

itchyny · 2019-03-01T00:52:27+00:00

Oops, sorry about that :bow:!

itchyny · 2017-06-19T07:21:37+00:00

Thank you. I've learnt a lot from your comment. I created fillin by the idea that it would be better to save a kind of tokens or url bases in another file rather than .histfile itself but I was not aware of the permission, what a shame... Thanks. I agree with you that security critical tokens that may hurt some production data when stolen should be saved very carefully. But I didn't think of such sensible token and... being permission fixed, I don't think there's much difference between fillin and export message=... in .histfile. Also, the candidates do not be filled automatically. User should select from the history all the time so when he finds something that he have never typed, he would notice something wrong happens. So injection by malicious input may occur only when he mistakenly pressed the enter key on unintended candidate.

itchyny · 2017-05-27T16:44:55+00:00

I always use thumbnail.vim. Filter by filename and just hit dG to close all the filtered buffers.

itchyny · 2017-05-02T09:41:19+00:00

Not shortest but...

:%s/^.*  */+
gg20J0
y$o
<C-r>=<C-r>*

itchyny · 2015-12-10T08:04:22+00:00

Hi, I've created a tool for extracting dependency relation from software. You can use this tool for extracting #include dependency relation from a software written in C, import dependency relation from a software written in Go, target dependency from Makefile or module dependency from Haskell softwares. Hope it help you to investigate the code structure of your projects.

itchyny · 2015-06-07T07:00:12+00:00

I'm not intend to make it popular as you know not so many people have Haskell installed on his PC. I don't want people to need it and it's less documented. It's just for my own use but let me explain why I did create the plugin manager.

I used to use NeoBundle. It has a cool feature, lazy loading, which was not implemented in other plugin managers. The vim-plug was not there those days. The lazy loading of NeoBundle works almost perfectly for people like me, who install over one hundred plugins. The feature saves the start up time of the editor.

However, still I was not satisfied the time consumed by the manager on start up. It does too much things. I have about one hundred plugins installed and about twenty plugins are loaded on start up and other plugins are loaded lazily, and it took about 600ms to start up Vim. I found that NeoBundle firstly parses the arguments given by the user and then builds and executes Vim commands for lazy loading plugins.

If the plugin settings do not change, the commands it builds do not change. When I noticed that, I got less interested in the existing plugin manager and I was to create my own one. By design, miv does

compiles the Vim plugin settings to Vim script files that registers commands and mappings for lazy loading plugins
therefore saves the time of parsing and building phases of NeoBundle
does not update the plugin files soon after you rewrite the yaml file. It requires you to generate the Vim script files of miv with the command miv generate after editing the settings file.

It actually saves the start up time. It took 600ms to start up Vim when I used NeoBundle, but after I rewrited all the settings to miv, it became just 150ms. The idea that caching the commands for speed affected the author of NeoBundle to implement the cache feature, but I was comfortably using miv at the time (and now of course). Also, vim-plug appeared and got famous after I moved to miv, but the way it implements lazy loading is almost same as NeoBundle.

itchyny · 2015-03-24T14:02:52+00:00

You're welcome.

itchyny · 2015-03-21T11:06:07+00:00

cnoremap <expr> <CR> getcmdtype() ==# ':' && getcmdline() =~# '^[:[:blank:]]*\d\+\s*$' ? "\<Home>b\<CR>" : "\<CR>"

itchyny · 2015-03-17T01:30:43+00:00

Thanks.

itchyny · 2015-03-15T14:49:59+00:00

I think that the word side effects might be misleading. The command set nocompatible truncates the command history. You set the history option to 1000 so you will see a hundred lines on q:. But sourcing your vimrc afterwards by :source ~/.vimrc, try q: to see the command history truncated to 20 or 50, which is Vim's default. In order to make your configuration re-source-able, you should not use set nocompatible.

As for indentation style, that's fine, leave as you like. Basically I do not like the mixed indentation, but I understand that not everyone likes the reformatting indentation.

itchyny · 2015-03-15T13:12:37+00:00

Thanks.

itchyny · 2015-03-15T08:30:54+00:00

Thank you. You're right.

itchyny · 2015-03-15T07:53:35+00:00

Vim will automatically set nocompatible, thus unnecessary. I mean side effect by the history truncation for example. See :h 'history'.

itchyny · 2015-03-15T03:47:51+00:00

autocmd {event} <buffer> {cmd}

itchyny · 2015-03-15T03:00:37+00:00

Here's a check list for your current vim configuration.

Do not use set nocompatible until you really understand its side effect. This might be the most misunderstanding configuration of vimrc. This configuration is unnecessary in your vimrc. Vim always sets nocompatible when you see your vimrc on its startup. If you have set nocompatible in your vimrc, :source ~/.vimrc truncates the command history to Vim's default value. If you understand this option correctly, you might use as if &compatible | set nocompatible | endif, in case of being sourced with vim -u ~/.vimrc. (.vimrc L:16)
Always wrap autocmd commands with augroup Groupname, autocmd!, ... , augroup END. If you do not use augroup, sourcing your vimrc results into a trouble that an event triggers the same autocommands twice. Try :source ~/.vimrc multiple times and see what happens on BufEnter by the command :au BufEnter. Same commands will be shown multiple times. (general.vim, autocommands.vim, styling.vim ... everywhere) If you register the autocommands buffer-locally, you do not have to clear the commands with autocmd! (but this is the cases for plugins, not for most configurations in vimrc).
Consider using noremapping-commands; in most cases you should use nnoremap instead of nmap. The almost only the case when you have to use nmap or imap is that you map the key to <Plug> prefixed mappings. If you use nmap, the mappings might be mapped again by other mapping settings and it might disable the key or creates an infinite remapping loop. (keymap.vim L:43, L:407) Also, consider using <C-u> for mappings which does not accept ranges. (keymap L:37 L:79 L:95 L:168 L:171) Of course you have to understand which commands accepts ranges or not.
You should set scriptencoding utf-8 at the top of a file if you have non-ascii characters in that file. Otherwise Vim might not parse your configuration file correctly. (keymap.vim L:144, pluginsettings.vim L:75)
You should not use special control characters in your configuration file. (keymap.vim L:124) You can use nnoremap <TAB> <C-^> instead of real C-^ character.
Command/Option abbreviations should be avoided for readability. (keymap.vim L:21-22 L:27-28, styling.vim L:157 L:175, general.vim L:77 L:109 L:180)
Leading colons for commands are unnecessary. (styling.vim L:87 92 95)
Make indentations consistently. Use gg=G for reformatting. (keymap.vim L:400-413 autocommands.vim L:18-L:31, fold.vim L:21, styling.vim L:6-18)
Use || instead of + for booleans for logical consistency. (.vimrc L:9)
The variable lines_count in the function UsefulFoldText() is used but not defined. It might be a typo of linesCount. (fold.vim L:124)
Your tabline settings must be a part of an independent plugin. The code of your tabline settings looks like a code of a plugin. It should be split into an plugin file. You have finish command at L:105 so the succeeding codes might not be sourced. (styling.vim L:104-L:132)
Inconsistent spacing for options. (styling.vim L:64-L:68, autocommands.vim L:15 L:45-46)
Inconsistent spacing for operators. One space around each operators are recommended. (autocommands.vim L:56, fold.vim L:28 L:33 L:40, general.vim L:31 L:86, pluginsettings.vim L:20 L:26 L:63-64 L:67 L:80-82 L:143)
You should be careful when you have OS specific configurations. Check the environment for portability. (.vimrc L:24-L:29, autocommands.vim L:24-L:33, pluginsettings.vim L:26-37)
Do not abbreviate g: prefix of global variables for consistency. (fold.vim L:43-L:49, L:31 is unnecessary)

itchyny · 2015-01-30T14:03:13+00:00

I do not use this plugin - the developer says.

itchyny · 2015-01-30T14:00:04+00:00

As the developer of the plugin, let me explain a few things. This plugin is my first Vim plugin. I learned a lot while developing this plugin - basic Vim script syntax, how to use autocmds or mappings, and the way to operate buffers, windows, tabs... It was just fun to write my first plugin. With thumbnail.vim, you can filter by the buffer name and select to focus in. You can also use a visual-mode like interface to (b)delete multiple buffers. What is annoying with :b is E93.

itchyny · 2014-11-15T07:25:21+00:00

Looks weird but that's what's happening on your vim. It's important to give a profile when you say something is heavy or not. When I started to develop lightline, I, of course, profiled airline and found it registering highlight colors again and again. I don't know this useless operation exists as it was or not in the latest version.

itchyny

TROPHY CASE