Edward Garbowski | 13 Dec 17:09

Unicode issue

I am having an issue with opening a text file with no BOM.  I have a
text file that opens fine in Notepad, but if I open it in VIM I just
get garbage.

If I look at the hex code, there is no BOM in the beginning.  If I put
a BOM in, it works.

How can I make VIM work with no BOM on reading a file?  Or is this a
bug of some kind?

I am using version 7.3.46

Ed
_______________________________________________
Vim-l mailing list
Vim-l@...
http://lists.wikia.com/mailman/listinfo/vim-l
Brett | 17 Apr 09:00
Favicon

auto complete help

Hi guys, I’m wondering how I can get VIM autocomplete to list all the mysqli functions in PHP.
It has some but not all, for (e.g.) mysqli_connect_error is there but mysqli_connect is not is there a way to fix this??
I’ve just compiled VIM and a fresh copy of php that does have all the mysqli functions.... Am I missing something??
 
I’m brand new to  vim...... I’ve decided windows sucks  and I’m running debian now
_______________________________________________
Vim-l mailing list
Vim-l@...
http://lists.wikia.com/mailman/listinfo/vim-l
John Beckett | 3 Mar 05:07
Picon

Candidates for deletion

Please consider the pages recommended for deletion:
http://vim.wikia.com/wiki/Category:Candidates_for_deletion

Next Tuesday I intend deleting the pages listed.

There are a couple of particularly unhelpful old tips in the
list, but I now have a new way of dealing with unwanted existing
tips: I just replace the tip with a redirect to another tip
which covers the same topic.

In the future, I think I will just delete any pages listed for
deletion for at least 28 days, without giving any other notice,
particularly when the deletion looks routine.

Please reply if you see any problems, or edit the talk page of
the above.

John
Benjamin Fritz | 26 Nov 07:16
Picon

Need good tab-page tips on Vim Tips wiki

I sometimes hang out on the #vim channel on Freenode, where use of tab
pages is often discouraged in favor of efficient use of the
buffer/argument lists, split windows, and the 'hidden' option.

Personally, I prefer using tab pages in many circumstances, but have
never really had any specific advantages or features of tab pages that
I can bring up to support my preference.

On the Vim Tips Wiki, we have in the category description of
http://vim.wikia.com/wiki/Category:Tabs an indication that the
category contains tips that "exploit Vim's tab page design to do
clever things you can't do in other editors", but there are very few
tips in this category that actually offer this.

I'm sure there are clever ideas out there that leverage the power of
tab pages in Vim, that are difficult or impossible to accomplish
otherwise. I'd like to add some of these ideas to the Tabs category on
the wiki.

Please add these ideas to the wiki directly, or respond to this
thread. You don't need to make the tip perfect before adding it, there
are other editors that can improve on your work. At the moment, I'd
just like to get a few tips out there! If I see a lot of wiki
submissions without much discussion in the thread, I'll probably post
links to the new tips or collect a list somewhere on the wiki.

Here are a couple of simple ideas. Some of these are probably not
worth a tip on their own, but perhaps may make a nice "quick tips"
list:
* Opening a diff window for a buffer that you are also editing in
another tab, without messing up window layout or options set by
:diffthis
* Opening a full-screen window on a buffer without messing up buffer
layout or messing with :mkview/:mksession
* Running a command on a limited selection of buffers without using
the argument list (see
http://vim.wikia.com/wiki/User:Fritzophrenic/Repeat_a_command_on_a_selection_of_buffers
for some notes on this and a potentially acceptable tip stub)

If you don't like the idea of using tab pages, this is not the thread
to say so. We all know that Vim tabs don't act like the tabs in other
editors. I'm starting this thread to find some good reasons why this
is so. Criticism of specific ideas or a brief discussion of
alternative methods is fine.

Let's get the ideas flowing!

Ben Fritz (fritzophrenic)
John Beckett | 4 Sep 05:55
Picon

News: RTE, SEO, Syntax highlighting

Some Vim Tips wiki news and requests for opinions:

RTE: Wikia introduced a "Rich Text Editor" for new users who
want to type pure text with bold and italics. The RTE is very
unhelpful when editing a Vim Tip and I want to ask Wikia to
remove the editor.

I need people to quickly say "*Remove ~~~~" or "*Keep ~~~~"
(click "edit" on the Comments line at the bottom) at
http://vim.wikia.com/wiki/User:JohnBeckett/Rich_text_editor

SEO: I am hoping to boost the wiki's Google rank with some
changes. SEO ideas are needed:
http://vim.wikia.com/wiki/User:JohnBeckett/Search_engine_optimization

Syntax highlighting: MediaWiki has been upgraded to 1.15.1 and
it is likely that we will have syntax highlighting for Vim
scripts in about a week from now.
http://vim.wikia.com/wiki/User:JohnBeckett/Syntax_highlighting

Minor irritation: Date stamps are now U.S. That applies to
signatures on talk pages, and history pages. It's an irritation
for those of us who also spend some time at Wikipedia where we
get used to searching for "4 sep" to find dates on September 4.

John
Benjamin Fritz | 16 Jul 16:30
Picon

Rich text editor

Recently, the rich text editor has been making some annoying changes
automatically. Mostly, I've noticed the automatic conversion of all
'<' and '>' characters into the corresponding html entities, even
where this is not needed. In a wiki with a lot of code, often
containing quite a few '<' and '>' characters, this often makes tips
unreadable when viewing the source.

Additionally, from http://help.wikia.com/wiki/Help:Rich_text_editor I
see the following:

"Please note that the editor is not currently supported on the Safari,
Opera and Chrome browsers"

Since these are the three browsers I have used most often at home
recently, that sentence holds a special level of "ugh" for me.

John has reversed a few of these changes.

I wonder if it is worth disabling the rich text editor entirely? From
http://help.wikia.com/wiki/Help:Rich_text_editor we see the following:

"To disable the new editor for a single article you can use the
special word __NOWYSIWYG__ (Note: The new editor system will still be
loaded, but will be locked to 'source' mode.)"

I imagine we could put this keyword in our TipNew, TipImported, and
TipProposed templates as a quick way to mostly disable the rich text
editor on our wiki, since these templates occur on almost every page
where the rich text editor would cause problems.

Thoughts, anyone?
John Beckett | 12 Jul 10:56
Picon

Candidates for deletion

Next weekend I intend deleting all the stuff at:
http://vim.wikia.com/wiki/Category:Candidates_for_deletion

Please reply if you see any problems, or edit the talk page of
the above.

Progress on the wiki is slow but steady. One positive sign is
that it is now relatively easy to find reasonable tips for the
"Did you know?" section on the main page.
http://vim.wikia.com/

John
John Beckett | 3 Apr 12:42
Picon

Candidates for deletion

Please consider the pages recommended for deletion:
http://vim.wikia.com/wiki/Category:Candidates_for_deletion

On Wednesday 8 April I intend deleting the following obsolete
pages (I anticipate this won't be controversial):
  All 11 "Forum:xxx" pages, and
  all 2 "Talk:xxx" pages, as currently listed.

On Sunday 12 April I intend deleting the remaining currently
listed pages (subject to the discussion page).

For tips that are deleted because of being merged to another
tip, I will use the following strategy:
- Proposed new tips will just be deleted.
- An established tip will be replaced with a redirect to the
  tip containing the merged information.

This should ensure that links to the wiki from the outside will
still work, except, I do not intend trying to keep links for:
- Proposed new tips that are not wanted.
- Any of the obsolete titles from the October 2007 renaming.

The tips were imported from vim.org in July 2007.
In October 2007, 578 tips with broken titles were renamed.
They are listed in black here (the blue titles show the current
names that will be kept):
http://vim.wikia.com/wiki/User:JohnBeckett/Titles_to_be_changed

I'm not going out of my way to delete the 578 obsolete
redirects, but when I encounter them I intend deleting them.

Please reply if you see any problems, or edit the talk page of
the above.

John
John Beckett | 19 Mar 02:13
Picon

Auto welcome

Any thoughts on the new auto-welcome system Wikia has introduced? We can
configure the text it uses, and we can disable it (I'm a bit suspicious
of anything cutsey, and my inclination is to disable it, but maybe I'm
too curmudgeonly).

One minute after a new user (registered or just an IP address) edits a
page, their user page is automatically created (if a registered user),
and a message is put on their talk page. Example:
http://vim.wikia.com/wiki/User_talk:83.83.187.191

These four settings configure how it works:

http://vim.wikia.com/wiki/MediaWiki:Welcome-message-user
http://vim.wikia.com/wiki/MediaWiki:Welcome-message-anon
http://vim.wikia.com/wiki/MediaWiki:Welcome-user-page
http://vim.wikia.com/wiki/MediaWiki:Welcome-user

Welcome-message-user: Text put on new user's Talk page.
Welcome-message-anon: Same, for IP addresses (not registered).
Welcome-user-page: Text put on new user's User page.

Welcome-user: configuration; one of following:
  "@latest" = message signed by admin who did most-recent edit
  Username = message signed by this user
  "@disabled" = no welcome messages

Details (also two other new "features"):
http://www.wikia.com/wiki/Forum:New_features_coming_on_Wednesday

John
David T. Kerns | 18 Mar 19:28

smart parsing preprocessor #if for comment highlighting

I looked through archive (2007-August - 2009-February) but didn't find this question/topic addressed:

I really like the way vim highlights the code

#if 0
this is colored as a comment
#else
this is not
#endif

however, the converse is not true

#if 1
this has no special highlighting
#else
this also has no special highlighting
#endif

It seems pretty straight forward that the phrase "this also has no special highlighting" could safely be
highlighted as a comment.

Along these lines, what would REALLY be nice is if vim could be "handed" a project file with definitions like:
OPTION3=true
FEATURE29=false
MYDEBUG=true

and then highlight the following code as appropriate (pre-processed code as a comment)

#if defined(OPTION3) && defined(FEATURE29)
this is commented
#else
this is not
#endif
#ifndef MYDEBUG
this is a comment
#endif

Is any of this possible today?

***************************************************************************************
This e-mail and its attachments are a private communication sent from Westell Technologies, Inc., 
a telecommunications company.  Its contents may contain confidential and proprietary information that
is protected.  
If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution
or use of the 
information contained in or attached to this message is strictly prohibited.  If you have received this
e-mail in error, 
please notify the sender by replying to this message, and then delete it from your system.  Thank you.
John Beckett | 22 Feb 01:24
Picon

Vim Tips Wiki - Remove author?

Each tip on the wiki has a header. We've pruned some of the information
that was originally imported from vim.org, and now we're wondering
whether to also remove the author field.

The wiki way of dealing with authorship is to use "History", which
records the edit summary, user name, and changes performed by each user.
Wikipedia has thousands of magnificent pages where there is no visible
author.

On the Vim Tips wiki there are lots of cases where the original tip was
pretty weak, and it's only the subsequent editing on the wiki that has
provided polish. Sometimes we manually remove the author when we notice
that removal appears appropriate, but it's a fairly arbitrary and
time-consuming process.

To summarise discussions (most recent being [1]):

* It is unfair to credit some authors when the original tip was
simplistic or defective, and it's been fixed by wiki editors (sometimes
by merging in the imported comments). We should either credit every
significant contributor or none.

* We could replace "author" with "original author" to clarify its
meaning. The idea is that a contributor shouldn't be discouraged from
editing because some author "owns" the tip, or wonder whether to add
their own name as an author if substantial edits are performed. Of
course, if a tip does have an active author (someone who cares about
it), they are welcome to clean up or remove any inappropriate edits, but
no one owns a tip (if they do, it should be removed from the wiki).

* I have done a temporary manual edit of one tip[2] to show what
"original author" looks like.

* Adding words to the header doesn't help the tip. We should clarify
that "version" in the header means "minimum version of Vim required to
use the tip, we think". It might be useful to say "minimum version", but
"original author" doesn't help.

* We could remove the author field after ensuring that the author's name
is shown in the edit history (by having a script edit each tip to put
"original author NAME" in the summary).

I am posting to the vim-l (Vim Tips Wiki) and vim_use (Google Groups)
mailing lists to seek opinions on the future of the author field. You
might like to comment on other fields in the header as well.

The current position favoured by the discussion[1] is that the name of
each author should be copied to an edit summary in the history, and then
the author field should be removed.

[1] http://vim.wikia.com/wiki/User_talk:JohnBeckett
[2] http://vim.wikia.com/wiki/Moving_to_matching_braces

John

Gmane