Re: Code completion and entries with duplicate 'word' attributes.

2006-04-21 Thread Martin Stubenschrott
On Thu, Apr 20, 2006 at 06:52:44PM -0700, Eric Van wrote:
 My code completion function returns a list with the following entries:
   kind: 'f', word: 'toCharArray', menu: 'toCharArray()  char[] - String'
   kind: 'f', word: 'toString', menu: 'toString()  String - String'
   kind: 'f', word: 'toUpperCase', menu: 'toUpperCase()  String - String'
   kind: 'f', word: 'toUpperCase', menu: 'toUpperCase(Locale locale) 
 String - String'
   kind: 'f', word: 'toLowerCase', menu: 'toLowerCase()  String - String'
   kind: 'f', word: 'toLowerCase', menu: 'toLowerCase(Locale locale) 
 String - String'

snip

 So I suggest either removing duplicate checking when results are in
 the dictionary format, or at the very least, check the 'menu'
 attribute along with the 'word' attribute to determine if an entry is
 a duplicate, however that may or may not work for everyone.
 
 Thoughts? Comments?

Yes, use the 'info' field for further information on a single 'word'. In
your case you should write all different functions signatures in the
'info' field of just one 'word'.

kind: 'f', word: 'toString',menu: 'toString()  String - String',
info: 'String toString()'

kind: 'f', word: 'toUpperCase', menu: 'toUpperCase()  String - String'
info: 'String toUpperCase()\n
   String toUpperCase(Locale locale)'

...


BTW: how complete is your java support? Does it work good enough for a
public release, or is it for your own usage only?

--
Martin


Re: Mappings fail me, yet again

2006-04-21 Thread Nikolai Weibull
On 4/21/06, sean [EMAIL PROTECTED] wrote:
 On Fri, 21 Apr 2006 10:05:18 +0200
 Nikolai Weibull [EMAIL PROTECTED] wrote:

  How do you define the region to be from the current line to the last
  line?  You can't press G.  All you can give is a number prefix.  Or
  perhaps there's some command I've missed?

 G works here,   VG:deleteenter   deletes everything from the current
 line down to and including the last line of the file.   Is  VG:  good
 enough for what you want?

I guess I should have put , without starting visual mode at the end
of the first sentence.

 Also, you can type it manually:
[...]

I'm not dumb.

 nikolai


Re: Coulpe of odd [repeatable] crashes in vim 7

2006-04-21 Thread Bram Moolenaar

Neil Bird wrote:

 Around about 19/04/06 20:03, Bram Moolenaar typed ...
  Main issue is: Do you open another buffer or window?
 
I don't believe so.  Apart from some tricky indirection (the srcctl
 plugin has a generic set up, then calls the relevant real script
 functions depending upon the SCM S/W being used, SourceSafe in my
 case), the sequence is pretty much as you describe below.
 
The process does involve at least 2, maybe three system() calls [one 'cat' 
 of the config. file, one to deduce the status of the file in an initial 
 check-out attempt, and a potential third if this fails or requires 
 interaction:  the script parses the output and if a question is asked (say, 
 are you sure?), converts this into a vim dialogue [is *that* the issue? 
 interactivity during the autocmd?].
 
I then have a bit that forcibly reloads the file (otherwise the edit that 
 triggered the autocmd happens in the to-be-forgotten read-only version of the 
 file), then finally the 'syntax on' which for some reason is required to make 
 the freshly loaded file have syntax highlighting.
 
 
  I guess the basic sequence is:
  - you do z= and select a suggestion, this is to be inserted
  - your file is RO, thus the FileChangedRO autocmd is triggered
  - your FileChangedRO autocmd uses sourcesafe to get the file
Hmm, does this then trigger the timestamp check and
trigger a FileChangedShell autocmd?
  - your FileChangedRO autocmd reloads the file
 
As above;  I don't know about the FileChangedShell autocmd;  I can set a 
 dummy one up to see if it's happening if it'll help.

I still don't see a hint about what causes the problem.

Note that I have added a few extra checks in the code that you mentioned
in the previous stack trace.  You could try the latest snapshot if it
works any better.

-- 
The amigos also appear to be guilty of not citing the work of others who had
gone before them.  Even worse, they have a chapter about modeling time and
space without making a single reference to Star Trek!
(Scott Ambler, reviewing the UML User Guide)

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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://www.ICCF.nl ///


Re: 7.0e: Problem with vertical splits on windows xp

2006-04-21 Thread Georg Dahn
Hi!

Well, this problem is older, since Vim 6.4 behaved like that, too. If a
vertical split is created and guioptions contain L, a scrollbar is
added which makes the windows wider by the amount of the scrollbar. I
have removed the L from the guioptions and don't miss it.

Best wishes,
Georg


--- Cory Echols [EMAIL PROTECTED] wrote:

 On a windows xp multimonitor system, if I do the following:
 
 1. Ensure 'guioptions' contains 'L'.
 2. Postion the gvim window such that it is at least partly drawn on
 the secondary monitor.
 3. Create a vertical split or close a vertical split.
 
 The gvim window will move horizontally such that the gvim window's
 right edge is on the right most edge of my primary monitor.  (My
 primary monitor is on the left, my secondary is on the right.)  Also,
 (and this is a very minor nit) the whole gvim window will widen by an
 amount equal to the thickness of the vertical scrollbar.
 
 In addition, if the windows taskbar is at the top of the primary
 monitor, the gvim window will also move downward by an amount equal
 to
 the thickness of the taskbar.
 




___ 
Introducing the new Yahoo! Answers Beta – A new place to get answers to your 
questions – Try it http://uk.answers.yahoo.com


Re: Code completion and entries with duplicate 'word' attributes.

2006-04-21 Thread Eric Van Dewoestine
On 4/21/06, Bram Moolenaar [EMAIL PROTECTED] wrote:

 Eric Van wrote:

  It appears that code completion is removing any entries that have
  duplicate 'word' attributes.
 
  For completion results not using the dictionary format I fully agree
  that duplicates can safely be removed, but when using the dictionary
  format two or more entries sharing the same 'word' attribute should
  not be considered duplicates.
 
  For instance, performing code completion on the following java code
String name = ...
name.toC-XC-U
 
  My code completion function returns a list with the following entries:
kind: 'f', word: 'toCharArray', menu: 'toCharArray()  char[] - String'
kind: 'f', word: 'toString', menu: 'toString()  String - String'
kind: 'f', word: 'toUpperCase', menu: 'toUpperCase()  String - String'
kind: 'f', word: 'toUpperCase', menu: 'toUpperCase(Locale locale)
  String - String'
kind: 'f', word: 'toLowerCase', menu: 'toLowerCase()  String - String'
kind: 'f', word: 'toLowerCase', menu: 'toLowerCase(Locale locale)
  String - String'
 
  But vim removes the 4th and 5th entry since they have the same 'word'
  value as the entry before them (at least I assume that is why they are
  removed).  As a user I then never get to see that String has a
  toUpperCase and toLowerCase that take a Locale as an argument.
 
  So I suggest either removing duplicate checking when results are in
  the dictionary format, or at the very least, check the 'menu'
  attribute along with the 'word' attribute to determine if an entry is
  a duplicate, however that may or may not work for everyone.
 
  Thoughts? Comments?

 Since we are talking about completion, there is only one word to be
 completed toLowerCase.  That it can have different arguments doesn't
 matter for inserting toLowerCase.  You could have a function name ten
 times and need to type CTRL-N ten times to get to another word.

 I suggest you put alternate function arguments together with one word.
 Thus toLowerCase would have a menu item and info that shows both
 possible forms of arguments.

Should vim be dictating this?  I've never used an IDE that behaved in
this fashion.

If vim leaves duplicate handling up to the script developer then we
can decide which form is most appropriate for the situation, and
perhaps provide our own configuration for letting the user decide
which they prefer.

While I agree that providing the sigurature for all variations in a
single 'info' would work, what about if I want to use 'info' for a
description of the method?  If I have ten variations how much is the
user going to have to sift through to get a description of the method
their looking for?  Instead of Ctrl-N x amount of times, they have to
exit completion mode, switch to the preview window and begin
searching.  Which do think would be more convient?


To Martin:
  http://eclim.sourceforge.net
  A new release should be out in the next week or two once I resolve
some of these completion peculiarities.

--
eric


vim70e bug -- visual mode, pink on pink is not seen

2006-04-21 Thread Milan Berta
Hello,

I want to report a behavior that is pretty strange for me.

When there is a syntax highlighting on and VISUAL mode is used, then the
pink color disappear where the VISUAL block extends. I know, if there
would be a VISUAL mode in another color than the same happens somewhere
else. Is it a normal behavior or is this a bug? Can it be set (or
suppressed) that the underlaying (in this case) pink writing will have
a different color then (in this case) the pink VISUAL block?

I just report it as a bug.

I wanted to report a simple example as a JPEG (as I've seen it as an
E-mail while forwarding), but it was sent back as non-deliverable :(

Regards,
Milan

-- 
* Milan Berta
* Institute of Physics
* Academy of Sciences of the Czech Republic
* Na Slovance 2
* CZ-182 21 Prague 8
* Czech Republic
* 
* mailto: [EMAIL PROTECTED]
* phone:  +420 266 052 650, +420 266 052 748
* fax:+420 286 890 416
* URL:http://www.fzu.cz/


Re: pushkeys() patch, add keys to typeahead buffer, simple

2006-04-21 Thread Bram Moolenaar

Yakov Lerner wrote:

 At the request of Nikolai Weibull, I made a patch, the
 pushkeys({string}) function which add keys sequence to the
 typeahead bufer.
 
 My point is that absence of such function puts console vim
 users at disadvantage. Gui vim users always have this
 functionality by means of remote_send(v:serername,{string});
 
 Implementation is exceptionally simple, it's 1-liner. We just
 call existing server_to_input_buf(). It's same thing as receiving end
 of  remote_send(v:serer_name,{string}) does, but works for any vim,
 even if vim has no server name.
 
 The doc patch is included.
 
 I realize it's release time and feature addition is unlikely at this
 point.

This breaks a few things:
- server_to_input_buf() is only present when FEAT_CLIENTSERVER is defined.
- it changes the text cr to a CR character
- it deletes characters from a previous mapping

Should use ins_typebuf() directly.

Docs could be better...

-- 
hundred-and-one symptoms of being an internet addict:
251. You've never seen your closest friends who usually live WAY too far away.

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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://www.ICCF.nl ///


Re: vim70e bug -- visual mode, pink on pink is not seen

2006-04-21 Thread Georg Dahn
Hi!

What's your operating system?
Do you use GUI or console Vim?
Which version of vim?
Which color scheme?

Best wishes,
Georg



--- Milan Berta [EMAIL PROTECTED] wrote:

 Hello,
 
 I want to report a behavior that is pretty strange for me.
 
 When there is a syntax highlighting on and VISUAL mode is used, then
 the
 pink color disappear where the VISUAL block extends. I know, if there
 would be a VISUAL mode in another color than the same happens
 somewhere
 else. Is it a normal behavior or is this a bug? Can it be set (or
 suppressed) that the underlaying (in this case) pink writing will
 have
 a different color then (in this case) the pink VISUAL block?
 
 I just report it as a bug.
 
 I wanted to report a simple example as a JPEG (as I've seen it as an
 E-mail while forwarding), but it was sent back as non-deliverable :(
 
 Regards,
 Milan
 
 -- 
 * Milan Berta
 * Institute of Physics
 * Academy of Sciences of the Czech Republic
 * Na Slovance 2
 * CZ-182 21 Prague 8
 * Czech Republic
 * 
 * mailto: [EMAIL PROTECTED]
 * phone:  +420 266 052 650, +420 266 052 748
 * fax:+420 286 890 416
 * URL:http://www.fzu.cz/
 




___ 
24 FIFA World Cup tickets to be won with Yahoo! Mail http://uk.mail.yahoo.com


vim70e -- spell, one-touch selection

2006-04-21 Thread Milan Berta
Hello,

Would it be possible to set (or implement) such a behavior of the spell
functions, that while selecting from the suggestion (from the suggested
list) and typing the digits for a number of the item the typing will end
at the moment when the number of the digits reaches the maximum number
in the list. For example, when I have set spellsuggest=9 then after
typing any digit of [1-9] the selection and replacement will be made
without entering the ENTER key. If the spellsuggest=20 then it would
happen after two digits. The idea is to spare some time without typing
the ENTER key.

Regards,
Milan

-- 
* Milan Berta
* Institute of Physics
* Academy of Sciences of the Czech Republic
* Na Slovance 2
* CZ-182 21 Prague 8
* Czech Republic
* 
* mailto: [EMAIL PROTECTED]
* phone:  +420 266 052 650, +420 266 052 748
* fax:+420 286 890 416
* URL:http://www.fzu.cz/


Re: a[M:N]

2006-04-21 Thread Georg Dahn

Hi!

 I think trying to get items from an empty list should produce an error
 message.

IMHO it would be a serious error if no error were produced in this case.

Best wishes,
Georg







___ 
24 FIFA World Cup tickets to be won with Yahoo! Mail http://uk.mail.yahoo.com


Re: pushkeys() patch, add keys to typeahead buffer, simple

2006-04-21 Thread Yakov Lerner
On 4/21/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
 Yakov Lerner wrote:
  On 4/21/06, Bram Moolenaar [EMAIL PROTECTED] wrote:
   Yakov Lerner wrote:
At the request of Nikolai Weibull, I made a patch, the
pushkeys({string}) function which add keys sequence to the
typeahead bufer.
   This breaks a few things:
   - server_to_input_buf() is only present when FEAT_CLIENTSERVER is defined=
  .
   - it changes the text cr to a CR character
   - it deletes characters from a previous mapping
  
   Should use ins_typebuf() directly.
  
   Docs could be better...
 
  I fixed these issues
  - Docs expanded.
  - We use  ins_typebuf() directly now.
  - Specals keys are now recognized as \cr not cr.
  - It's not dependent on FEAT_CLIENTSERVER now.
 
  Added remap/noremap flag argument.

 The second argument is optional, you should check if it's there.

 I don't want to change input_available() this way, I can't oversee what
 the implications are.

 Also, it's not clear what was already in the input buffer, that makes
 the effect rather unpredictable.

 This will have to wait until later.

Ok, let me know when you want to get back to this.

For the record, I don't understand why variable 'received_from_client'
is needed. And why (typebuf.tb_len!=0) can't be used in its place
as simpler equivalent. I think it's simpler.

Yakov


Re: a[M:N]

2006-04-21 Thread sean
On Fri, 21 Apr 2006 22:51:11 +0200
Bram Moolenaar [EMAIL PROTECTED] wrote:

  a[M:N] does truncate when N  len(a). However, this still gives an
  error when len(a) = 0. Can this be changed as well to return just an
  empty list? I appreciate your changing the previous behavior. It made
  things a lot simpler... I am presently aiming to release a beta
  version of vim-latex for vim7 around the same time you release vim7.
  The code has reduce about 30% (!!!) using the list/dictionaries and
  expanded functions of vim7.
 
 I think trying to get items from an empty list should produce an error
 message.

FWIW it doesn't cause an error in python, it returns an empty list.  
Wouldn't it be more consistent to automatically handle any out of range
issues for a[M:N] or give an error for all of them?   Handling N  len(a)
except when a happens to be 0 seems a bit counterintuitive.

Sean


Re: a[M:N]

2006-04-21 Thread Georg Dahn

Hi!

 Handling N  len(a) except when a happens to be 0 seems a bit
 counterintuitive.

No: Let's assume, that you have an empty list a. Then M in a[M:N] is
always out of bounds, which should produce an error. Analogously, if a
is not empty, but M  len(a), an error should be produced, too. (BTW, is
an error produced in this case at the moment?)

And my opinion is, that an error should be produced, too, if N  len(a)
and a is not 0. A programmer should take care of the bounds. If an index
is out of bounds, I consider it as wrong not to produce an error. But
this is, as I have said already, just my humble opinion.

The following situation would be different: If M were the starting point
and N the number of items, one could say, that a[M:N] should return at
most N items starting with the M'th item.

Just my 2 cents.

Best wishes,
Georg







___ 
24 FIFA World Cup tickets to be won with Yahoo! Mail http://uk.mail.yahoo.com


Re: pushkeys() patch, add keys to typeahead buffer, simple

2006-04-21 Thread Nikolai Weibull
On 4/21/06, Bram Moolenaar [EMAIL PROTECTED] wrote:

 Yakov Lerner wrote:
[send_keys() patch]

 The second argument is optional, you should check if it's there.

 I don't want to change input_available() this way, I can't oversee what
 the implications are.

 Also, it's not clear what was already in the input buffer, that makes
 the effect rather unpredictable.

Is this comment related to the change to input_available()?   If not,
how is using pushkeys() any different from remote_send()?

 This will have to wait until later.

:-(

/me makes a vim alias to always start as a server and uses remote_send() instead

 nikolai


Re: a[M:N]

2006-04-21 Thread sean
On Fri, 21 Apr 2006 23:33:07 +0200
Georg Dahn [EMAIL PROTECTED] wrote:

Hi Georg,

 No: Let's assume, that you have an empty list a. Then M in a[M:N] is
 always out of bounds, which should produce an error. Analogously, if a
 is not empty, but M  len(a), an error should be produced, too. (BTW, is
 an error produced in this case at the moment?)
 
 And my opinion is, that an error should be produced, too, if N  len(a)
 and a is not 0. A programmer should take care of the bounds. If an index
 is out of bounds, I consider it as wrong not to produce an error. But
 this is, as I have said already, just my humble opinion.

Yes, my point was just that it should be consistent.   Either, N  len(a)
should always generate an error or it shouldn't any of the time, even if 
len(a) happens to be 0.  It's the counterintutive mixing of both policies 
that I think is suboptimal.

 The following situation would be different: If M were the starting point
 and N the number of items, one could say, that a[M:N] should return at
 most N items starting with the M'th item.

Having used python a lot, i actually quite enjoy being given the freedom
to use out of bound ranges and simply get an empty list in return.   I handle
the out of bound case by testing or processing an empty list after the fact.
It tends to lead to somewhat easier to read code in some cases.   That said,
having to test the ranges before every slice is workable, but it should be
consistent.

Cheers,
Sean



gm command

2006-04-21 Thread mzyzik
All,

I use gm, H, M, L commands often. I noticed that gm aims at
half the screenwidth, rather than half the line width. I realized that
if it aimed at half the line width, it would be more useful.
Could it be considered to change the behavior of gm. Is there any good
reason why it functions the way it does now?

Thanks.

--Matt