Re: A new Vim Homepage

52 views
Skip to first unread message

shane qian

unread,
Oct 12, 2023, 10:04:19 PM10/12/23
to vim...@googlegroups.com, m...@256bit.org, Christian Brabandt
I think the more important is stable vs/than nice.
or if you'd like to rephrase its looking, I would  recommend other 'org' website, e.g 'GNU'.

and/but not really move vim help doc to website instead of native tui ':help', doc in web page did not always mean 'modern' as someone said in the repo, wish we insisted what is vim it was.

--
shane.xb.qian

Yee Cheng Chin

unread,
Oct 12, 2023, 11:46:32 PM10/12/23
to vim...@googlegroups.com, m...@256bit.org, Christian Brabandt
I think the most important thing to iron out first is what the short-term and long-term requirements are, and the basic technical design of the website.

In particular, what are the features that require a dynamic backend rather than a static site (e.g. something that could be hosted on a CDN or GitHub Pages)? Do those need to be hosted together with the main site? Having a static base site decoupled from the dynamic features would allow us to always be able to have a basic available website for download links, documentation, etc, even if the dynamic backend is broken / DDOSed. Even features like blog posts etc can be easily generated by a static site generator (e.g. Jekyll or other newer/fancier ones), but features like plugin scripts discovery would not really be possible as they would require an actual server.

I actually didn't know vim.org supported user accounts. What do those do? For uploading scripts?

I think it's worth also looking at Neovim's site for comparison. I know we don't want to just do what Neovim does, obviously, but they have spent quite a lot of effort on building up a modern site, and do some of what this new website proposal lists as goals, so I think it would be a good idea to at least look at what they do for comparison. The Neovim site has:
Nice-to-haves (as in, not needed immediately):
  • Personally I think having a nice script discovery page is actually quite useful. It's a nice-to-have but it helps people have a centralized place to find plugins to install (it's obviously an optional aspect to use plugins).
  • I also think Vim should eventually try to have something similar to the "This Week in Neovim", or just something that could communicate regular Vim updates (weekly or monthly or quarterly) and new features/bug fixes to the user. Right now when I write MacVim release notes (example) I have to scour through every Vim commit to distill what the interesting bits are to the end user. It would be nice if there's a centralized spot for Vim users who are not MacVim users. Not sure if this needs to be from the official page or not.
  • I also think having vim docs available on the web is really useful as I don't always have Vim available, and an URL is much easier to reference from Reddit and release notes (e.g. I link to online documentation in my releases notes for MacVim whenever it contains ":h <topic>"). We already have https://vimhelp.org so maybe it works as-is. There is a different discussion on Vim GitHub about the formatting but I'm more just talking about the availability of the documentation.

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/OS3P286MB09134F75A2F37803246CF51CEBD2A%40OS3P286MB0913.JPNP286.PROD.OUTLOOK.COM.

Christian Brabandt

unread,
Oct 13, 2023, 2:34:36 AM10/13/23
to vim...@googlegroups.com

On Do, 12 Okt 2023, Yee Cheng Chin wrote:

> I think the most important thing to iron out first is what the short-term and
> long-term requirements are, and the basic technical design of the website.

The most important goals are better maintainability and make the code
more stable. Refreshing the design is a plus.

> In particular, what are the features that require a dynamic backend rather than
> a static site (e.g. something that could be hosted on a CDN or GitHub Pages)?
> Do those need to be hosted together with the main site? Having a static base
> site decoupled from the dynamic features would allow us to always be able to
> have a basic available website for download links, documentation, etc, even if
> the dynamic backend is broken / DDOSed. Even features like blog posts etc can
> be easily generated by a static site generator (e.g. Jekyll or other newer/
> fancier ones), but features like plugin scripts discovery would not really be
> possible as they would require an actual server.

Yes, mainly uploading scripts nowadays, voting (not sure what will
happen with this feature), news (okay, this could be a static content),
tips (which we abandoned a few years ago because of spam)

> I actually didn't know vim.org supported user accounts. What do those do? For
> uploading scripts?

Yes.

>
> I think it's worth also looking at Neovim's site for comparison. I know we
> don't want to just do what Neovim does, obviously, but they have spent quite a
> lot of effort on building up a modern site, and do some of what this new
> website proposal lists as goals, so I think it would be a good idea to at least
> look at what they do for comparison. The Neovim site has:
>
> • news/blogs (https://neovim.io/news/)
> • builtin docs (https://neovim.io/doc/), whereas in Vim right now
> you have to
> go to a third party like https://vimhelp.org/, which is probably fine. They
> also put in a lot of work to create reflowable docs. This is a massive cans
> of worms that Shane is referring to above, which I don't think we have to
> do, but just something to be aware of.

We covered this quickly. I don't see it as a must-have and I don't want
to make the scope too big. It would be nice to have, but the vimhelp.org
page is nice and the japanese community also has this:
https://vim-jp.org/vimdoc-en/ so we can just link there.

> • It links to an external script discovery page (https://dotfyle.com/)
> • That site also has a "This Week in Neovim" (https://dotfyle.com/
> this-week-in-neovim/54) blog.

This week-in neovim is just a fancy news section? While this is nice to
have, the real problem is, we need someone to follow development closely
and condense it into a nice user form. That alone will be a lot of work.

> Nice-to-haves (as in, not needed immediately):
>
> • Personally I think having a nice script discovery page is actually quite
> useful. It's a nice-to-have but it helps people have a centralized place to
> find plugins to install (it's obviously an optional aspect to use plugins).
>
> • I also think Vim should eventually try to have something similar to the
> "This Week in Neovim", or just something that could communicate regular Vim
> updates (weekly or monthly or quarterly) and new features/bug fixes to the
> user. Right now when I write MacVim release notes (example) I have to scour
> through every Vim commit to distill what the interesting bits are to the
> end user. It would be nice if there's a centralized spot for Vim users who
> are not MacVim users. Not sure if this needs to be from the official page
> or not.
>
> • I also think having vim docs available on the web is really useful as I
> don't always have Vim available, and an URL is much easier to reference
> from Reddit and release notes (e.g. I link to online documentation in my
> releases notes for MacVim whenever it contains ":h <topic>"). We already
> have https://vimhelp.org so maybe it works as-is. There is a different
> discussion on Vim GitHub about the formatting but I'm more just talking
> about the availability of the documentation.

Yes agree.

Thanks,
Christian
--
Complex system:
One with real problems and imaginary profits.

Christian Brabandt

unread,
Oct 13, 2023, 2:42:05 AM10/13/23
to vim...@googlegroups.com

On Fr, 13 Okt 2023, shane qian wrote:

> I think the more important is stable vs/than nice.
> or if you'd like to rephrase its looking, I would recommend other 'org'
> website, e.g 'GNU'.

Yes, maintainability is a big goal.

> and/but not really move vim help doc to website instead of native tui ':help',
> doc in web page did not always mean 'modern' as someone said in the repo, wish
> we insisted what is vim it was.

This is a nice to have.

Thanks,
Christian
--
A father doesn't destroy his children.
-- Lt. Carolyn Palamas, "Who Mourns for Adonais?",
stardate 3468.1.
Reply all
Reply to author
Forward
0 new messages