Sometimes while I'm digging around the bowels of PLs, I find websites straight out of the 90s for seemingly active projects:

https://unicon.sourceforge.io/

My initial ~/.vimrc for #vim after 3-4 years of using #neovim:

filetype plugin indent on
syntax enable

let g:mapleader = ","

set autoindent
set autoread
set formatoptions+=j
set guifont=MesloLGM\ Nerd\ Font\ Mono\ 12
set hidden
set history=500
set hlsearch
set listchars=tab:→\ ,trail:•,extends:›,precedes:‹,nbsp:␣,eol:↲
set nobackup
set nonumber
set noswapfile
set nowrap
set path+=**
set scrolloff=1
set showbreak=↪\
set showmatch
set sidescroll=1
set smarttab
set tags=./tags;/
set termguicolors

nnoremap <silent> <C-l> :nohl<C-R>=has('diff')?'<Bar>diffupdate':''<CR><CR><C-L>
nnoremap <silent> <leader>lcd :lcd %:p:h<CR>:pwd<CR>
nnoremap <silent> <leader>n :set number!<CR>

if !empty(globpath(&rtp, 'autoload/plug.vim'))
  call plug#begin()
  Plug 'ap/vim-buftabline', { 'as': 'buftabline' }
  Plug 'dracula/vim', { 'as': 'dracula' }
  Plug 'editorconfig/editorconfig-vim', { 'as': 'editorconfig' }
  Plug 'kaarmu/typst.vim', { 'as': 'typst' }
  Plug 'tpope/vim-commentary', { 'as': 'commentary' }
  Plug 'vim-scripts/git_patch_tags.vim', { 'as': 'git_patch_tags' }
  call plug#end()
endif

silent! colorscheme dracula

It’s quite short but does pretty much what I would ever want from a text editor:

$ wc -l .vimrc 
42 .vimrc

Couple more OS/2 screenshots - one in which IBM is explaining us how an office works (or should/could work). See image captions for transcript.
We're in 1994 or thereabouts, if I'm not mistaken. That's 30-ish years ago. I still miss it.
#retrocomputing #os2 #operatingsystems #timeflies #ibm #oldfart #nostalgia

The OpenAI ChatGPT app on macOS is not sandboxed and stores all the conversations in **plain-text** in a non-protected location:

~/Library/Application\ Support/com.openai.chat/conversations-{uuid}/

So basically any other running app / process / malware can read all your ChatGPT conversations without any permission prompt:

@AndrewRadev @realestninja IPC and client-server decoupling = ridiculously overrated and zero gain for the end user

@AndrewRadev @realestninja IPC and client-server decoupling = ridiculously overrated and zero gain for the end user

@AndrewRadev @realestninja and both expect real-time feedback when the data is stimulated by the user 😅 so essentially same piece of software

@AndrewRadev @realestninja what works in digital audio workstations can be claimed to be work also in text editors because both are model data editors for different type of artifacts.

@AndrewRadev @realestninja And a C lib could be then provided for ”LSP host” which would be trivial to integrate to any text editor.

@AndrewRadev @realestninja IMHO plugin based system similar to VST3 and CLAP in audio could be much more ideal architecture. Editor can eg then decide how to organize threads and can have a clock and scheduler which can orchestrate dynamic or even real-time behavior.

Generally speaking, C is pretty straightforward. It takes about 20 days to learn 80% of it, and then no more than 20 years to cover the remaining 20%

@thomholwerda too much tolerance for uncosidered language results a toxic community.
The flip side is that too much intolerance results a toxic positive community where self-censorship blocks fluid technical communications.

@thomholwerda In Github Ive noticed in some project that rejection of a PR without comment is safe-play for a maintainer. Ive seen cases where a maintainer has taken time to go into details why something is a bad idea and that has resulted blog entries etc talking about toxic behavior.

In this case I’d vote for some tolerance for bad humor and uncosidered commentary. It is just one commit in a high-bandwidth project. Not a big deal, and Im one of those sad gray people.

I can also feel how much snappier vim is given that it does decouple UI and the editor. It is kind of thing that in architecture it is for sure fancy BUT the problem comes from that as a user it can only cause more latency.

I prefer modular code-base over modular run-time :-)

If you pile that up with LSP you have decouple text editor managing decoupled static analysis, i.e. two layers of IPC at run-time, which is crazy IMHO. And since I use mostly the terminal, being e.g. able to integrate to vscode has total zero value for me.

I added the vim LSP shenanigans because I want to see whether it feels different when the editor stack is more stable and simplified. I give it a shot for Rust.

@AndrewRadev @realestninja Well it took me about 30 minutes to rewrite a vim config as i used already quite minimal set of plugins. I know my way with Vimscript as I've used it 20+ years.

I did add 'prabirshrestha/vim-lsp' and 'mattn/vim-lsp-settings' so that i can check at some point if they are usable with Rust. If they do less but the overall experience feels more "stable" than then it might work ;-)

With Linux kernel tree any LSP is pretty much useless, as any time I change kernel config I need to also re-generate a new JSON file. I use ctags because it can carve the whole kernel tree and does not care about the configuration.

@realestninja Even macOS stock installation has vim right off the bat.

In addition Evolution allows to configure custom command for fetch. E.g one could execute IMAP in the remote server with ssh, and use that to fetch the email.

This is still IMHO a strong merit in #GNOME #Evolution, when having multiple identities.

In my case, I use a sub-address (RFC 5233) for bouncing kernel.org but it shares the account with my personal email address. Identities map to envelope addresses, and based on that msmtp will pick the correct SMTP server.

msmtp also allows to share SMTP configuration with #Git. E.g. for a freshly cloned repository, I might for instance:

git config from "Jarkko Sakkinen <jarkko@kernel.org>"
git config sendemail.envelopeSender "jarkko@kernel.org"
git config sendemail.sendmailCmd "/usr/bin/env msmtp"

#email #smtp

@realestninja I have not e.g. used auto-complete in my life. It slows down the phase to the level that I actually need to understand what I'm doing, which over longer period of time results in deeper understanding because you actually have study also the API documentation. Downshifting in production pays back with a huge interest, and usually tends to result more mature software.

track i did early winter. after that not much time for music but hopefully during my holiday i have some time to finish a few tracks :-) https://soundcloud.com/dopeda/robottien-siivouspaiva