Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

vimdev · Vim (Vi IMproved) text editor developers list

The Yahoo! Groups Product Blog

Check it out!

Group Information

? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Message search is now enhanced, find messages faster. Take it for a spin.

Messages

Advanced
Messages Help
Messages 45808 - 45837 of 70061   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#45808 From: "A.J.Mechelynck" <antoine.mechelynck@...>
Date: Sun Jan 7, 2007 2:55 am
Subject: Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
antoine.mechelynck@...
Send Email Send Email
 
Edward Catmur wrote:
> Hi,
>
> This patch improves HIG compliance when compiled with FEAT_GUI_GNOME:
>
> * Close confirmation dialogs use "Save/Discard/Cancel" instead of
> "Yes/No/Cancel"
> * GTK_STOCK_SAVE used for "Save"
> * Default button placed at end of message dialog, with order passed in
> set as alternative button order
>
> vim_dialog_yesnocancel() is renamed to vim_dialog_savediscardcancel(),
> because that's all it's used for. Same for vim_dialog_yesnoallcancel().

Yes/No seems more intuitive to me. And what about consistency with other
flavours of Vim?

>
> Also attached is a patch to disable guioptions="t" (tearoff menus) when
> compiled with FEAT_GUI_GNOME, also for desktop consistency.
>
> Ed
>

Hey, wait! Even gvim for Windows has tearoff menus, which is a great feature,
available in no other Windows programs AFAIK. Why disable it in Gnome versions
on the pretext that other Gnome programs don't have it? If you don't like the
availability of tearoff menus, include ":set guioptions-=t" in your vimrc, but
don't deprive me of this feature. And don't tell me that I can just compile
"with GTK but without Gnome": I want a Gnome gvim for other reasons, such as
the ability to save its session when the KDE window manager closes.

This sounds to me like "I don't want it, therefore you cannot have it", a form
of totalitarianism completely out of place in Vim.


Best regards,
Tony.

#45809 From: "Nikolai Weibull" <now@...>
Date: Sun Jan 7, 2007 3:09 am
Subject: Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
now@...
Send Email Send Email
 
On 1/7/07, A.J.Mechelynck <antoine.mechelynck@...> wrote:

> > Also attached is a patch to disable guioptions="t" (tearoff menus) when
> > compiled with FEAT_GUI_GNOME, also for desktop consistency.

> Hey, wait! Even gvim for Windows has tearoff menus, which is a great feature,
> available in no other Windows programs AFAIK. Why disable it in Gnome versions
> on the pretext that other Gnome programs don't have it? If you don't like the
> availability of tearoff menus, include ":set guioptions-=t" in your vimrc, but
> don't deprive me of this feature. And don't tell me that I can just compile
> "with GTK but without Gnome": I want a Gnome gvim for other reasons, such as
> the ability to save its session when the KDE window manager closes.

Eh, you who want tearoff menus (perhaps the most stupid GUI design
choice ever) can include ":set guioptions+=t" in your vimrc.  Not that
I'd include 'm' in my guioptions either.  Not that I'd run the gui for
that matter.

> This sounds to me like "I don't want it, therefore you cannot have it", a form
> of totalitarianism completely out of place in Vim.

Last time I checked, we had a benevolent dictator for a ruler that has
ruled to that effect, many times in the past.

   nikolai

#45810 From: "A.J.Mechelynck" <antoine.mechelynck@...>
Date: Sun Jan 7, 2007 3:19 am
Subject: Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
antoine.mechelynck@...
Send Email Send Email
 
Nikolai Weibull wrote:
> On 1/7/07, A.J.Mechelynck <antoine.mechelynck@...> wrote:
>
>> > Also attached is a patch to disable guioptions="t" (tearoff menus) when
>> > compiled with FEAT_GUI_GNOME, also for desktop consistency.
>
>> Hey, wait! Even gvim for Windows has tearoff menus, which is a great
>> feature,
>> available in no other Windows programs AFAIK. Why disable it in Gnome
>> versions
>> on the pretext that other Gnome programs don't have it? If you don't
>> like the
>> availability of tearoff menus, include ":set guioptions-=t" in your
>> vimrc, but
>> don't deprive me of this feature. And don't tell me that I can just
>> compile
>> "with GTK but without Gnome": I want a Gnome gvim for other reasons,
>> such as
>> the ability to save its session when the KDE window manager closes.
>
> Eh, you who want tearoff menus (perhaps the most stupid GUI design
> choice ever) can include ":set guioptions+=t" in your vimrc.  Not that
> I'd include 'm' in my guioptions either.  Not that I'd run the gui for
> that matter.

At the moment I can. If the OP's patch makes it to the "official"
distributions (Bram forbid!) it won't work anymore

>
>> This sounds to me like "I don't want it, therefore you cannot have
>> it", a form
>> of totalitarianism completely out of place in Vim.
>
> Last time I checked, we had a benevolent dictator for a ruler that has
> ruled to that effect, many times in the past.
>
>  nikolai
>

"Benevolent dictator" is a contradiction in terms. There used to be
"enlightened despots", but even with that I have a problem: there are no
safeguards to prevent an "enlightened" despot from becoming a despot plain and
simple.

Removing features sounds extremely un-Vim-like to me.


Best regards,
Tony.

#45811 From: Edward Catmur <ed@...>
Date: Sun Jan 7, 2007 2:23 am
Subject: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
ed@...
Send Email Send Email
 
Hi,

This patch improves HIG compliance when compiled with FEAT_GUI_GNOME:

* Close confirmation dialogs use "Save/Discard/Cancel" instead of
"Yes/No/Cancel"
* GTK_STOCK_SAVE used for "Save"
* Default button placed at end of message dialog, with order passed in
set as alternative button order

vim_dialog_yesnocancel() is renamed to vim_dialog_savediscardcancel(),
because that's all it's used for. Same for vim_dialog_yesnoallcancel().

Also attached is a patch to disable guioptions="t" (tearoff menus) when
compiled with FEAT_GUI_GNOME, also for desktop consistency.

Ed

#45812 From: "Nikolai Weibull" <now@...>
Date: Sun Jan 7, 2007 5:19 am
Subject: Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
now@...
Send Email Send Email
 
On 1/7/07, A.J.Mechelynck <antoine.mechelynck@...> wrote:

> Nikolai Weibull wrote:

> > On 1/7/07, A.J.Mechelynck <antoine.mechelynck@...> wrote:

> > > > Also attached is a patch to disable guioptions="t" (tearoff menus) when
> > > > compiled with FEAT_GUI_GNOME, also for desktop consistency.

> > > Hey, wait! Even gvim for Windows has tearoff menus, which is a great
> > > feature,
> > > available in no other Windows programs AFAIK. Why disable it in Gnome
> > > versions
> > > on the pretext that other Gnome programs don't have it? If you don't
> > > like the
> > > availability of tearoff menus, include ":set guioptions-=t" in your
> > > vimrc, but
> > > don't deprive me of this feature. And don't tell me that I can just
> > > compile
> > > "with GTK but without Gnome": I want a Gnome gvim for other reasons,
> > > such as
> > > the ability to save its session when the KDE window manager closes.

> > Eh, you who want tearoff menus (perhaps the most stupid GUI design
> > choice ever) can include ":set guioptions+=t" in your vimrc.  Not that
> > I'd include 'm' in my guioptions either.  Not that I'd run the gui for
> > that matter.

> At the moment I can. If the OP's patch makes it to the "official"
> distributions (Bram forbid!) it won't work anymore

(Seriously, does it really make sense to write "OP", which I assume
means "Original Poster", instead of "Ed"?  We're not in the
military...we don't need acronyms and abbreviations for everything.
It's not cool and it's not helpful.  It just makes reading what you've
written more difficult.  I'm not trying to police this mailing list,
but come on, what's the point?  And if I ever see something like YMMV,
IANAL (hey, if you're not a lawyer, then why are you giving legal
advice in the first place?), or IAHFRTOUAAATEM (I Am , However, A
Fucking Retard That Only Uses Acronyms And Abbreviations To Express
Myself) on this list, I'll seriously consider unsubscribing.)

All his patch does is remove 't' from the default value of
'guioptions' for UNIX GUI builds that aren't Mac OS builds that have
GNOME support enabled.  It's quite clear if you look at the diff.

> > > This sounds to me like "I don't want it, therefore you cannot have
> > > it", a form
> > > of totalitarianism completely out of place in Vim.

> > Last time I checked, we had a benevolent dictator for a ruler that has
> > ruled to that effect, many times in the past.

> "Benevolent dictator" is a contradiction in terms.

And that's the joke.  (And if Bram ever goes off the deep end, we'll
always have the source - although I don't see who'd pick it up.)

> Removing features sounds extremely un-Vim-like to me.

Again, nothing is being removed.

(Coincidentally, I consider not adding features extremely Vim-like.)

   nikolai

#45813 From: Bram Moolenaar <Bram@...>
Date: Sun Jan 7, 2007 12:03 pm
Subject: Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
Bram@...
Send Email Send Email
 
Edward Catmur wrote:

> This patch improves HIG compliance when compiled with FEAT_GUI_GNOME:
>
> * Close confirmation dialogs use "Save/Discard/Cancel" instead of
> "Yes/No/Cancel"
> * GTK_STOCK_SAVE used for "Save"
> * Default button placed at end of message dialog, with order passed in
> set as alternative button order
>
> vim_dialog_yesnocancel() is renamed to vim_dialog_savediscardcancel(),
> because that's all it's used for. Same for vim_dialog_yesnoallcancel().

I'll look into this later.  Perhaps Save/Discard/Cancel is better for
all GUIs, since you don't need to read the text to know whether "yes"
means "save" or "discard".  But it will break the translations.

> Also attached is a patch to disable guioptions="t" (tearoff menus) when
> compiled with FEAT_GUI_GNOME, also for desktop consistency.

You mean that the default is not to use tearoff menus, one can still
have them when wanted.

--
Managers are like cats in a litter box.  They instinctively shuffle things
around to conceal what they've done.
				 (Scott Adams - The Dilbert principle)

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

#45814 From: Bram Moolenaar <Bram@...>
Date: Sun Jan 7, 2007 7:51 pm
Subject: Re: [PATCH] count for CR in quickfix window
Bram@...
Send Email Send Email
 
Shotaro Aoyama wrote:

> Here is a small patch for specifying a window in which vim opens
> an error when you hit ENTER in a quickfix window.
> With this patch, you may hit "3<CR>" in the quickfix window,
> then the selected error is displayed in the window #3.
>
> Often I face a situation that I want to display an error,
> but don't want to hide a buffer in the above window
> or open a new window and break window layout.
> I think this feature would be helpful in such time.
>
> What do you people think about this?

Thanks for making this patch.  It looks useful.

I think it would be good to add some error handling: what if the number
entered is out of range for the number of windows?

One problem: when the count is not given it should still use ".cc" and
".ll" as before.

--
Every engineer dreams about saving the universe and having sex with aliens.
This is much more glamorous than the real life of an engineer, which consists
of hiding from the universe and having sex without the participation of other
life forms.                     (Scott Adams - The Dilbert principle)

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

#45815 From: "Nikolai Weibull" <now@...>
Date: Sun Jan 7, 2007 7:59 pm
Subject: Re: [Feature Request] Vim should respond to WM_PASTE
now@...
Send Email Send Email
 
On 1/7/07, Bram Moolenaar <Bram@...> wrote:
>
> Nikolai Weibull wrote:
>
> > It seems GVim doesn't respond to the WM_PASTE message on Windows.  It
> > would be really sweet if it did.  I sadly have no intention of
> > implementing this myself, but would appreciate it if this could be
> > added to the TODO.
>
> Who would send a WM_PASTE message to Vim?

I would.  I have a Autohotkey script that emulates Vim's digraph
support so that I can type ^K'6 to get a LEFT SINGLE QUOTATION MARK.
Sadly, the best way to send Unicode characters to Windows applications
through a Autohotkey script is through the use of the clipboard (might
not work otherwise).  Thus, the character is stored in the clipboard
and then a PostMessage of WM_PASTE is sent to the active application.
However, if the application doesn't respond to WM_PASTE, this won't
work.

(I'll gladly post the script if anyone wants it, by they way.)

   nikolai

#45816 From: Bram Moolenaar <Bram@...>
Date: Sun Jan 7, 2007 7:51 pm
Subject: Re: [Feature Request] Vim should respond to WM_PASTE
Bram@...
Send Email Send Email
 
Nikolai Weibull wrote:

> It seems GVim doesn't respond to the WM_PASTE message on Windows.  It
> would be really sweet if it did.  I sadly have no intention of
> implementing this myself, but would appreciate it if this could be
> added to the TODO.

Who would send a WM_PASTE message to Vim?

--
An alien life briefly visits earth.  Just before departing it leaves a
message in the dust on the back of a white van.  The world is shocked
and wants to know what it means.  After months of studies the worlds
best linguistic scientists are able to decipher the message: "Wash me!".

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

#45817 From: Edward Catmur <ed@...>
Date: Mon Jan 8, 2007 3:46 am
Subject: Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
ed@...
Send Email Send Email
 
On Sun, 2007-01-07 at 13:03 +0100, Bram Moolenaar wrote:
> Edward Catmur wrote:
> > * Close confirmation dialogs use "Save/Discard/Cancel" instead of
> > "Yes/No/Cancel"
> I'll look into this later.  Perhaps Save/Discard/Cancel is better for
> all GUIs, since you don't need to read the text to know whether "yes"
> means "save" or "discard".  But it will break the translations.
Thanks.  I know some GUIs are replete with message dialogs where you
have to read the text to know which button to press, but they stick out
like a sore thumb in Gnome.  As for the string break: looking at the
pofiles, a guessed translation (from the existing "Save all", "Discard
all") looks feasible in almost all cases; would it be acceptable for me
to attempt that?

> > Also attached is a patch to disable guioptions="t" (tearoff menus) when
> > compiled with FEAT_GUI_GNOME, also for desktop consistency.
> You mean that the default is not to use tearoff menus, one can still
> have them when wanted.
Yes.  Sorry for the confusion.

Ed

#45818 From: AOYAMA Shotaro <jod@...>
Date: Mon Jan 8, 2007 5:59 am
Subject: Re: [PATCH] count for CR in quickfix window
jod@...
Send Email Send Email
 
Bram Moolenaar wrote:

>Thanks for making this patch.  It looks useful.
>
>I think it would be good to add some error handling: what if the number
>entered is out of range for the number of windows?

Giving out of range number to <C-w>w, vim shows no error and
goes to the window that has the largest number.
Same for <CR> in that patch. I think it's consistent.

>One problem: when the count is not given it should still use ".cc" and
>".ll" as before.

Yes, the patch works that way.

Regards,

--
AOYAMA Shotaro
mailto:jod@...

#45819 From: Trenton Schulz <twschulz@...>
Date: Mon Jan 8, 2007 11:14 am
Subject: Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
twschulz@...
Send Email Send Email
 
On Jan 7, 2007, at 1:03 PM, Bram Moolenaar wrote:

>
> Edward Catmur wrote:
>
>> This patch improves HIG compliance when compiled with FEAT_GUI_GNOME:
>>
>> * Close confirmation dialogs use "Save/Discard/Cancel" instead of
>> "Yes/No/Cancel"
>> * GTK_STOCK_SAVE used for "Save"
>> * Default button placed at end of message dialog, with order
>> passed in
>> set as alternative button order
>>
>> vim_dialog_yesnocancel() is renamed to vim_dialog_savediscardcancel
>> (),
>> because that's all it's used for. Same for
>> vim_dialog_yesnoallcancel().
>
> I'll look into this later.  Perhaps Save/Discard/Cancel is better for
> all GUIs, since you don't need to read the text to know whether "yes"
> means "save" or "discard".  But it will break the translations.

Just being a lurker here, I would vote for this being in all GUIs
(not that we get votes here). Having the actual save/discard vs. yes/
no makes it much simpler to look at a message box and know which
button to press (probably why the "File Changed" dialog in Vim is a
bit easier to decide what to do than the "Save Changes" dialog IMO).

FWIW, the OS X guidelines also recommend this as well, (though they
seem to prefer "Don't Save", Discard is better than "No").

Breaking translations is unfortunate though, but it is a one-time
cost (hopefully)... Vim 7.1-type thing?

-- Trenton

#45820 From: Martin Stubenschrott <stubenschrott@...>
Date: Mon Jan 8, 2007 11:39 am
Subject: Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
stubenschrott@...
Send Email Send Email
 
On Mon, Jan 08, 2007 at 12:14:05PM +0100, Trenton Schulz wrote:
> >I'll look into this later.  Perhaps Save/Discard/Cancel is better for
> >all GUIs, since you don't need to read the text to know whether "yes"
> >means "save" or "discard".  But it will break the translations.
>
> Just being a lurker here, I would vote for this being in all GUIs
> (not that we get votes here). Having the actual save/discard vs. yes/
> no makes it much simpler to look at a message box and know which
> button to press (probably why the "File Changed" dialog in Vim is a
> bit easier to decide what to do than the "Save Changes" dialog IMO).

Would you also vote for changing the console style dialogs? I mean,
console users are normally used to press y or n, when answering these
kind of questions.

--
Martin

#45821 From: Trenton Schulz <twschulz@...>
Date: Mon Jan 8, 2007 4:05 pm
Subject: Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
twschulz@...
Send Email Send Email
 
On Jan 8, 2007, at 12:39 PM, Martin Stubenschrott wrote:

> On Mon, Jan 08, 2007 at 12:14:05PM +0100, Trenton Schulz wrote:
>>> I'll look into this later.  Perhaps Save/Discard/Cancel is better
>>> for
>>> all GUIs, since you don't need to read the text to know whether
>>> "yes"
>>> means "save" or "discard".  But it will break the translations.
>>
>> Just being a lurker here, I would vote for this being in all GUIs
>> (not that we get votes here). Having the actual save/discard vs. yes/
>> no makes it much simpler to look at a message box and know which
>> button to press (probably why the "File Changed" dialog in Vim is a
>> bit easier to decide what to do than the "Save Changes" dialog IMO).
>
> Would you also vote for changing the console style dialogs? I mean,
> console users are normally used to press y or n, when answering these
> kind of questions.

Well, don't you do that by typing :wq/:wq! or ZZ or whatever? Most of
the other "dialogs" on the console version don't ask yes/no questions
as far as I have encountered. I think it is a non-issue for the
console version...

-- Trenton

#45822 From: Martin Stubenschrott <stubenschrott@...>
Date: Mon Jan 8, 2007 5:08 pm
Subject: Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
stubenschrott@...
Send Email Send Email
 
On Mon, Jan 08, 2007 at 05:05:31PM +0100, Trenton Schulz wrote:
> >Would you also vote for changing the console style dialogs? I mean,
> >console users are normally used to press y or n, when answering these
> >kind of questions.
>
> Well, don't you do that by typing :wq/:wq! or ZZ or whatever? Most of
> the other "dialogs" on the console version don't ask yes/no questions
> as far as I have encountered. I think it is a non-issue for the
> console version...

Well, mostly I use ZZ, but sometimes :q, but have :set confirm on, so
when there are unsaved changes, there is no need to press :q!, but just
y to save the changes, or n do discard them.

--
Martin

#45823 From: "Nikolai Weibull" <now@...>
Date: Mon Jan 8, 2007 5:11 pm
Subject: Re: GNOME HIG compliance in gvim: button order in close confirmation dialogs (PATCH)
now@...
Send Email Send Email
 
On 1/8/07, Trenton Schulz <twschulz@...> wrote:
>
> On Jan 8, 2007, at 12:39 PM, Martin Stubenschrott wrote:

> > Would you also vote for changing the console style dialogs? I mean,
> > console users are normally used to press y or n, when answering these
> > kind of questions.
>
> Well, don't you do that by typing :wq/:wq! or ZZ or whatever? Most of
> the other "dialogs" on the console version don't ask yes/no questions
> as far as I have encountered. I think it is a non-issue for the
> console version...

% vim
   :set confirm
   iHello, Vim!<Esc>
   :q
   Save changes to "Untitled"?
   [Y]es, (N)o, (C)ancel:

Sure, [S]ave, (D)iscard, (C)ancel would work - and is better, as it
better describes what would happen - but I'd venture so far as to say
that 'Y', 'N' are so deeply engrained in peoples minds by now that it
would be very irritating to have to hit 'S' or 'D' instead.  I know I
would be annoyed.  Still, perhaps it makes sense to change these as
well. And one could allow the user to type 'Y' or 'N' with the old
behavior as well.

   nikolai

#45824 From: Bram Moolenaar <Bram@...>
Date: Mon Jan 8, 2007 9:16 pm
Subject: Re: compile vim7 with different or without local prefix /usr/local
Bram@...
Send Email Send Email
 
Michael Haubenwallner wrote:

> maybe I've overlooked something in configure.in, but to me it seems that
> it is impossible to compile vim7 without searching /usr/local/include
> and /usr/local/lib.
>
> Thing is, on solaris fex, if iconv.h is found in /usr/local/include,
> /usr/local/lib/libiconv.so get linked too.
> But the rpath for libiconv.so.3 does not get encoded into the binary,
> and I really don't want to set LD_LIBRARY_PATH (hmm, maybe this should
> be in system loader path).
>
> Additionally, I also want to be able to compile completely independent
> of /usr/local, with a gcc built --with-local-prefix=/another/prefix, and
> with libiconv and others from that prefix.
>
> So I have two new requirements for the /usr/local search:
>
> 1) Of course, I want to keep the default as is.
> 2) completely disable adding /usr/local/include and /usr/local/lib
> 3) set a different path to be used instead of /usr/local
>
> Attached is a patch for src/configure.in to accept "--with-local-prefix"
> flag, which solves above requirements:
>
> 1) default: do not pass any --with-local-prefix argument.
> 2) disable: use --without-local-prefix or even --with-local-prefix=no
> 3) change:  use --with-local-prefix=/another/prefix

It make sense to support using another directory than
/usr/local/[lib|include].

It appears that after your patch have_local_include and have_local_lib
are set to "yes" without checking gcc.  The test for gcc with "grep"
should also use ${local_prefix} instead of /usr/local.

I'm missing documentation, especially for the "no" value.

--
If someone questions your market projections, simply point out that your
target market is "People who are nuts" and "People who will buy any damn
thing".  Nobody is going to tell you there aren't enough of those people
to go around.
				 (Scott Adams - The Dilbert principle)

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

#45825 From: Michael Haubenwallner <michael.haubenwallner@...>
Date: Mon Jan 8, 2007 10:06 pm
Subject: Re: compile vim7 with different or without local prefix /usr/local
michael.haubenwallner@...
Send Email Send Email
 
On Mon, 2007-01-08 at 22:16 +0100, Bram Moolenaar wrote:
> Michael Haubenwallner wrote:
>
> > maybe I've overlooked something in configure.in, but to me it seems that
> > it is impossible to compile vim7 without searching /usr/local/include
> > and /usr/local/lib.
> >
> > Thing is, on solaris fex, if iconv.h is found in /usr/local/include,
> > /usr/local/lib/libiconv.so get linked too.
> > But the rpath for libiconv.so.3 does not get encoded into the binary,
> > and I really don't want to set LD_LIBRARY_PATH (hmm, maybe this should
> > be in system loader path).
> >
> > Additionally, I also want to be able to compile completely independent
> > of /usr/local, with a gcc built --with-local-prefix=/another/prefix, and
> > with libiconv and others from that prefix.
> >
> > So I have two new requirements for the /usr/local search:
> >
> > 1) Of course, I want to keep the default as is.
> > 2) completely disable adding /usr/local/include and /usr/local/lib
> > 3) set a different path to be used instead of /usr/local
> >
> > Attached is a patch for src/configure.in to accept "--with-local-prefix"
> > flag, which solves above requirements:
> >
> > 1) default: do not pass any --with-local-prefix argument.
> > 2) disable: use --without-local-prefix or even --with-local-prefix=no
> > 3) change:  use --with-local-prefix=/another/prefix
>
> It make sense to support using another directory than
> /usr/local/[lib|include].
>
> It appears that after your patch have_local_include and have_local_lib
> are set to "yes" without checking gcc.  The test for gcc with "grep"
> should also use ${local_prefix} instead of /usr/local.

Well, they are set to "yes" in the "--without-local-prefix" or
"--with-local-prefix=no" case only to avoid appending to CPPFLAGS/
LDFLAGS lateron (they are not used any more in configure script).

The grep-test on gcc only applies if there is no "--with-local-prefix"
argument on configure line at all, to use the defaults.

Well, if one explicitly specifies "--with-local-prefix" on configure-
cmdline, I'm unsure if the compiler should be checked if it already
searches that path.

Hmm, thinking more of it, it makes sense, as the compiler could be
confused when explicitly passing its builtin search dirs...

>
> I'm missing documentation, especially for the "no" value.

I don't know how to type two lines of documentation into the autoconf-
macro to keep some good alignment in the help-output, but maybe this
text could appear:
--with-local-prefix=/prefix  build against /prefix instead of /usr/local
--without-local-prefix       do not build against any additional prefix

Thank you (especially for accepting the idea behind),
  haubi

#45826 From: Bram Moolenaar <Bram@...>
Date: Tue Jan 9, 2007 9:23 am
Subject: Re: compile vim7 with different or without local prefix /usr/local
Bram@...
Send Email Send Email
 
Michael Haubenwallner wrote:

> > > maybe I've overlooked something in configure.in, but to me it seems that
> > > it is impossible to compile vim7 without searching /usr/local/include
> > > and /usr/local/lib.
> > >
> > > Thing is, on solaris fex, if iconv.h is found in /usr/local/include,
> > > /usr/local/lib/libiconv.so get linked too.
> > > But the rpath for libiconv.so.3 does not get encoded into the binary,
> > > and I really don't want to set LD_LIBRARY_PATH (hmm, maybe this should
> > > be in system loader path).
> > >
> > > Additionally, I also want to be able to compile completely independent
> > > of /usr/local, with a gcc built --with-local-prefix=/another/prefix, and
> > > with libiconv and others from that prefix.
> > >
> > > So I have two new requirements for the /usr/local search:
> > >
> > > 1) Of course, I want to keep the default as is.
> > > 2) completely disable adding /usr/local/include and /usr/local/lib
> > > 3) set a different path to be used instead of /usr/local
> > >
> > > Attached is a patch for src/configure.in to accept "--with-local-prefix"
> > > flag, which solves above requirements:
> > >
> > > 1) default: do not pass any --with-local-prefix argument.
> > > 2) disable: use --without-local-prefix or even --with-local-prefix=no
> > > 3) change:  use --with-local-prefix=/another/prefix
> >
> > It make sense to support using another directory than
> > /usr/local/[lib|include].
> >
> > It appears that after your patch have_local_include and have_local_lib
> > are set to "yes" without checking gcc.  The test for gcc with "grep"
> > should also use ${local_prefix} instead of /usr/local.
>
> Well, they are set to "yes" in the "--without-local-prefix" or
> "--with-local-prefix=no" case only to avoid appending to CPPFLAGS/
> LDFLAGS lateron (they are not used any more in configure script).
>
> The grep-test on gcc only applies if there is no "--with-local-prefix"
> argument on configure line at all, to use the defaults.
>
> Well, if one explicitly specifies "--with-local-prefix" on configure-
> cmdline, I'm unsure if the compiler should be checked if it already
> searches that path.
>
> Hmm, thinking more of it, it makes sense, as the compiler could be
> confused when explicitly passing its builtin search dirs...

I thought the idea of this configure argument was that you specify
another place than /usr/local, one that the compiler might already look
in.  Anyway, I think the behavior shouldn't change, only the path used.

> > I'm missing documentation, especially for the "no" value.
>
> I don't know how to type two lines of documentation into the autoconf-
> macro to keep some good alignment in the help-output, but maybe this
> text could appear:
> --with-local-prefix=/prefix  build against /prefix instead of /usr/local
> --without-local-prefix       do not build against any additional prefix

Unusual configure options should be documented in src/INSTALL, in the
Unix section.

--
hundred-and-one symptoms of being an internet addict:
2. You kiss your girlfriend's home page.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

#45827 From: Bram Moolenaar <Bram@...>
Date: Tue Jan 9, 2007 1:38 pm
Subject: patch 7.0.179
Bram@...
Send Email Send Email
 
Patch 7.0.179
Problem:    Using ":recover" or "vim -r" without a swapfile crashes Vim.
Solution:   Check for "buf" to be unequal NULL. (Yukihiro Nakadaira)
Files:     src/memline.c


*** ../vim-7.0.178/src/memline.c Tue Nov 21 20:57:21 2006
--- src/memline.c Tue Jan  9 14:33:44 2007
***************
*** 1329,1336 ****
  	     mf_put(mfp, hp, FALSE, FALSE);
  	 mf_close(mfp, FALSE);     /* will also vim_free(mfp->mf_fname) */
       }
!     vim_free(buf->b_ml.ml_stack);
!     vim_free(buf);
       if (serious_error && called_from_main)
  	 ml_close(curbuf, TRUE);
   #ifdef FEAT_AUTOCMD
--- 1329,1339 ----
  	     mf_put(mfp, hp, FALSE, FALSE);
  	 mf_close(mfp, FALSE);     /* will also vim_free(mfp->mf_fname) */
       }
!     if (buf != NULL)
!     {
!  vim_free(buf->b_ml.ml_stack);
!  vim_free(buf);
!     }
       if (serious_error && called_from_main)
  	 ml_close(curbuf, TRUE);
   #ifdef FEAT_AUTOCMD
*** ../vim-7.0.178/src/version.c Tue Dec  5 22:09:02 2006
--- src/version.c Tue Jan  9 14:35:59 2007
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     179,
   /**/

--
hundred-and-one symptoms of being an internet addict:
10. And even your night dreams are in HTML.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

#45828 From: Bram Moolenaar <Bram@...>
Date: Tue Jan 9, 2007 2:02 pm
Subject: patch 7.0.180 (extra)
Bram@...
Send Email Send Email
 
Patch 7.0.180 (extra, after 7.0.171)
Problem:    VMS: build failed.  Problem with swapfiles.
Solution:   Add "compiled_arch".  Always expand path and pass it to
	     buf_modname().  (Zoltan Arpadffy)
Files:     src/globals.h, src/memline.c, src/os_unix.c, runtime/menu.vim


*** ../vim-7.0.179/src/globals.h Sat Oct 14 14:33:21 2006
--- src/globals.h Tue Jan  9 14:26:51 2007
***************
*** 1092,1097 ****
--- 1092,1098 ----
   extern char_u *all_lflags;
   # ifdef VMS
   extern char_u *compiler_version;
+ extern char_u *compiled_arch;
   # endif
   extern char_u *compiled_user;
   extern char_u *compiled_sys;
*** ../vim-7.0.179/src/memline.c Tue Jan  9 14:37:10 2007
--- src/memline.c Tue Jan  9 14:33:44 2007
***************
*** 3572,3579 ****
   #else
  	     (buf->b_p_sn || buf->b_shortname),
   #endif
! #ifdef RISCOS
! 	    /* Avoid problems if fname has special chars, eg <Wimp$Scrap> */
  	     ffname,
   #else
   # ifdef HAVE_READLINK
--- 3572,3580 ----
   #else
  	     (buf->b_p_sn || buf->b_shortname),
   #endif
! #if defined(VMS) || defined(RISCOS)
! 	    /* Avoid problems if fname has special chars, eg <Wimp$Scrap>.
! 	     * For VMS always use full path for swapfile. */
  	     ffname,
   #else
   # ifdef HAVE_READLINK
*** ../vim-7.0.179/src/os_unix.c Tue Nov 28 17:44:51 2006
--- src/os_unix.c Tue Jan  9 14:31:08 2007
***************
*** 2221,2227 ****
        * behaviour should be avoided for the existing files and we need to find
        * the exact path of the edited file.
        */
-     if (force || !mch_isFullName(fname))
       {
  	 char_u *fixed_fname = vms_fixfilename(fname);
  	 int fd = mch_open((char *)fixed_fname, O_RDONLY | O_EXTRA, 0);
--- 2221,2226 ----
*** ../vim-7.0.179/runtime/menu.vim Thu Sep 14 13:35:17 2006
--- runtime/menu.vim Tue Jan  9 14:31:40 2007
***************
*** 384,390 ****
   " Programming menu
   if !exists("g:ctags_command")
     if has("vms")
!     let g:ctags_command = "mc vim:ctags ."
     else
       let g:ctags_command = "ctags -R ."
     endif
--- 384,390 ----
   " Programming menu
   if !exists("g:ctags_command")
     if has("vms")
!     let g:ctags_command = "mc vim:ctags *.*"
     else
       let g:ctags_command = "ctags -R ."
     endif
*** ../vim-7.0.179/src/version.c Tue Jan  9 14:37:10 2007
--- src/version.c Tue Jan  9 15:00:57 2007
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     180,
   /**/

--
The Feynman problem solving Algorithm:
	 1) Write down the problem
	 2) Think real hard
	 3) Write down the answer

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

#45829 From: Bram Moolenaar <Bram@...>
Date: Tue Jan 9, 2007 2:44 pm
Subject: patch 7.0.181
Bram@...
Send Email Send Email
 
Patch 7.0.181
Problem:    When reloading a file that starts with an empty line, the reloaded
	     buffer has an extra empty line at the end. (Motty Lentzitzky)
Solution:   Delete all lines, don't use bufempty().
Files:     src/fileio.c


*** ../vim-7.0.180/src/fileio.c Thu Oct 12 21:15:04 2006
--- src/fileio.c Tue Jan  9 15:38:13 2007
***************
*** 6178,6185 ****
       if (retval != FAIL)
       {
  	 curbuf = frombuf;
!  while (!bufempty())
! 	    if (ml_delete(curbuf->b_ml.ml_line_count, FALSE) == FAIL)
  	     {
  		 /* Oops!  We could try putting back the saved lines, but that
  		  * might fail again... */
--- 6179,6186 ----
       if (retval != FAIL)
       {
  	 curbuf = frombuf;
!  for (lnum = curbuf->b_ml.ml_line_count; lnum > 0; --lnum)
! 	    if (ml_delete(lnum, FALSE) == FAIL)
  	     {
  		 /* Oops!  We could try putting back the saved lines, but that
  		  * might fail again... */
*** ../vim-7.0.180/src/version.c Tue Jan  9 15:15:36 2007
--- src/version.c Tue Jan  9 15:41:55 2007
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     181,
   /**/

--
hundred-and-one symptoms of being an internet addict:
11. You find yourself typing "com" after every period when using a word
     processor.com

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

#45830 From: Ali Akcaagac <aliakc@...>
Date: Tue Jan 9, 2007 7:49 pm
Subject: Re: patch 7.0.182
aliakc@...
Send Email Send Email
 
Hi Bram,

may you tell us, when you plan to release VIM 7.1 ?

mfg,

Ali Akcaagac

On Tue, 2007-01-09 at 20:30 +0100, Bram Moolenaar wrote:
> Patch 7.0.182
> Problem:    When using a mix of undo and "g-" it may no longer be possible to
> 	    go to every point in the undo tree.  (Andy Wokula)
> Solution:   Correctly update pointers in the undo tree.
> Files:     src/undo.c
>
>
> *** ../vim-7.0.181/src/undo.c Tue Aug 29 17:28:56 2006
> --- src/undo.c Tue Jan  9 20:18:27 2007
> ***************
> *** 341,351 ****
>    uhp->uh_alt_next = old_curhead;
>    if (old_curhead != NULL)
>    {
>   	    old_curhead->uh_alt_prev = uhp;
>   	    if (curbuf->b_u_oldhead == old_curhead)
>   	 curbuf->b_u_oldhead = uhp;
>    }
> !  uhp->uh_alt_prev = NULL;
>    if (curbuf->b_u_newhead != NULL)
>   	    curbuf->b_u_newhead->uh_prev = uhp;
>
> --- 341,355 ----
>    uhp->uh_alt_next = old_curhead;
>    if (old_curhead != NULL)
>    {
> + 	    uhp->uh_alt_prev = old_curhead->uh_alt_prev;
> + 	    if (uhp->uh_alt_prev != NULL)
> + 	 uhp->uh_alt_prev->uh_alt_next = uhp;
>   	    old_curhead->uh_alt_prev = uhp;
>   	    if (curbuf->b_u_oldhead == old_curhead)
>   	 curbuf->b_u_oldhead = uhp;
>    }
> !  else
> ! 	    uhp->uh_alt_prev = NULL;
>    if (curbuf->b_u_newhead != NULL)
>   	    curbuf->b_u_newhead->uh_prev = uhp;
>
> ***************
> *** 856,861 ****
> --- 860,870 ----
>    uhp = curbuf->b_u_curhead;
>    while (uhp != NULL)
>    {
> + 	    /* Go back to the first branch with a mark. */
> + 	    while (uhp->uh_alt_prev != NULL
> + 				 && uhp->uh_alt_prev->uh_walk == mark)
> + 	 uhp = uhp->uh_alt_prev;
> +
>   	    /* Find the last branch with a mark, that's the one. */
>   	    last = uhp;
>   	    while (last->uh_alt_next != NULL
> ***************
> *** 865,870 ****
> --- 874,881 ----
>   	    {
>   	 /* Make the used branch the first entry in the list of
>   		 * alternatives to make "u" and CTRL-R take this branch. */
> + 	 while (uhp->uh_alt_prev != NULL)
> + 		    uhp = uhp->uh_alt_prev;
>   	 if (last->uh_alt_next != NULL)
>   		    last->uh_alt_next->uh_alt_prev = last->uh_alt_prev;
>   	 last->uh_alt_prev->uh_alt_next = last->uh_alt_next;
> *** ../vim-7.0.181/src/version.c Tue Jan  9 15:43:39 2007
> --- src/version.c Tue Jan  9 20:26:47 2007
> ***************
> *** 668,669 ****
> --- 668,671 ----
>   {   /* Add new patch number below this line */
> + /**/
> +     182,
>   /**/
>

#45831 From: Bram Moolenaar <Bram@...>
Date: Tue Jan 9, 2007 7:30 pm
Subject: patch 7.0.182
Bram@...
Send Email Send Email
 
Patch 7.0.182
Problem:    When using a mix of undo and "g-" it may no longer be possible to
	     go to every point in the undo tree.  (Andy Wokula)
Solution:   Correctly update pointers in the undo tree.
Files:     src/undo.c


*** ../vim-7.0.181/src/undo.c Tue Aug 29 17:28:56 2006
--- src/undo.c Tue Jan  9 20:18:27 2007
***************
*** 341,351 ****
  	 uhp->uh_alt_next = old_curhead;
  	 if (old_curhead != NULL)
  	 {
  	     old_curhead->uh_alt_prev = uhp;
  	     if (curbuf->b_u_oldhead == old_curhead)
  		 curbuf->b_u_oldhead = uhp;
  	 }
!  uhp->uh_alt_prev = NULL;
  	 if (curbuf->b_u_newhead != NULL)
  	     curbuf->b_u_newhead->uh_prev = uhp;

--- 341,355 ----
  	 uhp->uh_alt_next = old_curhead;
  	 if (old_curhead != NULL)
  	 {
+ 	    uhp->uh_alt_prev = old_curhead->uh_alt_prev;
+ 	    if (uhp->uh_alt_prev != NULL)
+ 	 uhp->uh_alt_prev->uh_alt_next = uhp;
  	     old_curhead->uh_alt_prev = uhp;
  	     if (curbuf->b_u_oldhead == old_curhead)
  		 curbuf->b_u_oldhead = uhp;
  	 }
!  else
! 	    uhp->uh_alt_prev = NULL;
  	 if (curbuf->b_u_newhead != NULL)
  	     curbuf->b_u_newhead->uh_prev = uhp;

***************
*** 856,861 ****
--- 860,870 ----
  	 uhp = curbuf->b_u_curhead;
  	 while (uhp != NULL)
  	 {
+ 	    /* Go back to the first branch with a mark. */
+ 	    while (uhp->uh_alt_prev != NULL
+ 				 && uhp->uh_alt_prev->uh_walk == mark)
+ 	 uhp = uhp->uh_alt_prev;
+
  	     /* Find the last branch with a mark, that's the one. */
  	     last = uhp;
  	     while (last->uh_alt_next != NULL
***************
*** 865,870 ****
--- 874,881 ----
  	     {
  		 /* Make the used branch the first entry in the list of
  		  * alternatives to make "u" and CTRL-R take this branch. */
+ 	 while (uhp->uh_alt_prev != NULL)
+ 		    uhp = uhp->uh_alt_prev;
  		 if (last->uh_alt_next != NULL)
  		     last->uh_alt_next->uh_alt_prev = last->uh_alt_prev;
  		 last->uh_alt_prev->uh_alt_next = last->uh_alt_next;
*** ../vim-7.0.181/src/version.c Tue Jan  9 15:43:39 2007
--- src/version.c Tue Jan  9 20:26:47 2007
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     182,
   /**/

--
hundred-and-one symptoms of being an internet addict:
13. You refer to going to the bathroom as downloading.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

#45832 From: Bram Moolenaar <Bram@...>
Date: Tue Jan 9, 2007 9:02 pm
Subject: Re: patch 7.0.182
Bram@...
Send Email Send Email
 
Ali Akcaagac wrote:

> may you tell us, when you plan to release VIM 7.1 ?

I don't know.  I still have quite a few bugs to fix.

--
hundred-and-one symptoms of being an internet addict:
15. Your heart races faster and beats irregularly each time you see a new WWW
     site address in print or on TV, even though you've never had heart
     problems before.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

#45833 From: Ilia N Ternovich <ternovich@...>
Date: Wed Jan 10, 2007 5:51 am
Subject: recent.vim plugin
ternovich@...
Send Email Send Email
 
Hi all!

I'm trying to make recent.vim plguin working with vim-7.0
There is some kind of problem with mapping keys inside plugin:

function! OptionFiles()
     "let file = bufname("%")
     if bufname("")=="recent_files"
         map <Enter> gf
         set number
         set noswapfile
     else
         set nonumber
         set swapfile
        if hasmapto('gf')
             unmap gf
        endif
     endif
endfunction

command Recent edit ~/.vim/recent_files
autocmd BufEnter * :call OptionFiles()

I wonder why this function doesn't map Enter key to "gf" combination, when
I start vim... There is succesfully created "recent_files" buffer... But
keybinding doesn't work :(

Can anybody help me with this question

--
God bless you!
Ilia

2.6.18-gentoo-r4 AMD Athlon(tm) XP 2600+

mailto: ternovich@...
icq: 198233378

VegaTrek Developer: http://wcuniverse.sourceforge.net/vegatrek/
VegaTrek Forum Moderator:
http://vegastrike.sourceforge.net/forums/viewforum.php?f=13
============================================================================
You know you're using the computer too much when: you are trying to fetch
the cup of coffee on your desk with the mouse pointer. -- jwj
============================================================================
$gpg --keyserver cryptonomicon.mit.edu --search-keys tillias

#45834 From: Ilya Bobir <ilya@...>
Date: Wed Jan 10, 2007 12:31 pm
Subject: Re: recent.vim plugin
ilya@...
Send Email Send Email
 
Ilia N Ternovich wrote:
> Hi all!
>
> I'm trying to make recent.vim plguin working with vim-7.0
> There is some kind of problem with mapping keys inside plugin:
>
> function! OptionFiles()
>     "let file = bufname("%")
>     if bufname("")=="recent_files"
>         map <Enter> gf
>         set number
>         set noswapfile
>     else
>         set nonumber
>         set swapfile
>        if hasmapto('gf')
>             unmap gf
>        endif
>     endif
> endfunction
>
> command Recent edit ~/.vim/recent_files
> autocmd BufEnter * :call OptionFiles()
>
> I wonder why this function doesn't map Enter key to "gf" combination, when
> I start vim... There is succesfully created "recent_files" buffer... But
> keybinding doesn't work :(
>
> Can anybody help me with this question
>
>
This is a bit off topic, but you probably want your function to look
like this:

function! OptionFiles()
     "let file = bufname("%")
     if bufname("")=="recent_files"
         map <buffer> <Enter> gf
         setlocal number
         setlocal noswapfile
     endif
endfunction

Not sure it will help with your problem, but this way all the changes are buffer
local.

#45835 From: Charles E Campbell Jr <drchip@...>
Date: Wed Jan 10, 2007 2:18 pm
Subject: garbage "notes" in vim.sf.net's tips section
drchip@...
Send Email Send Email
 
Hello, Scott!

I mentioned how there were lots of garbage "notes" that have been
appended to nearly all tips; as an example, I gave out tip#1.  I see
that the garbage has been cleaned from tip#1, but tips #12-1393 also
need cleaning.  Seems like it needs some automation to do it, especially
if the &#()& who obviously used a program/script to do it the first time
repeats  his/her vandalism.

Regards,
Chip Campbell

#45836 From: Ilya Sher <ilya-vim@...>
Date: Wed Jan 10, 2007 5:50 pm
Subject: Re: garbage "notes" in vim.sf.net's tips section
ilya-vim@...
Send Email Send Email
 
Charles E Campbell Jr wrote:
> Hello, Scott!
>
> I mentioned how there were lots of garbage "notes" that have been
> appended to nearly all tips; as an example, I gave out tip#1.  I see
> that the garbage has been cleaned from tip#1, but tips #12-1393 also
> need cleaning.  Seems like it needs some automation to do it,
I'd like to assist with the cleanup.
Please email me with further details
if my help is needed.
> especially if the &#()& who obviously used a program/script to do it
> the first time repeats  his/her vandalism.
>
> Regards,
> Chip Campbell
>


--
For robots (please don't mail me there): part-maps@...
My real email is ilya @ same domain

#45837 From: Bram Moolenaar <Bram@...>
Date: Wed Jan 10, 2007 9:36 pm
Subject: Re: garbage "notes" in vim.sf.net's tips section
Bram@...
Send Email Send Email
 
Charles Campbell wrote:

> I mentioned how there were lots of garbage "notes" that have been
> appended to nearly all tips; as an example, I gave out tip#1.  I see
> that the garbage has been cleaned from tip#1, but tips #12-1393 also
> need cleaning.  Seems like it needs some automation to do it, especially
> if the &#()& who obviously used a program/script to do it the first time
> repeats  his/her vandalism.

I added the PHP stuff to remove individual tip notes.  The moderators
that can remove tips can now also remove notes.

Obviously there are many more notes than tips and spam may appear for
every tip, not just for the newest one.  Thus it's harder to get rid of,
the moderators have to do more work.  So please be patient while this is
being done.

Automating the moderation is tricky.  And I don't really have time for
it.  Perhaps someone can make a script on his own computer to go through
all the tips to identify the ones where there still appears to be spam.
And then publish the list with links on his website, so that moderators
can quickly jump to them, inspect the text and delete the ones that are
really spam.

--
hundred-and-one symptoms of being an internet addict:
23. You can't call your mother...she doesn't have a modem.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Messages 45808 - 45837 of 70061   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help