Re: vim9script syntax highlight bug
Christian, On Wed, 3 Jul 2024 at 06:52, Christian J. Robinson wrote: > > This script doesn't highlight properly: > vim9script > > def Out(in: bool): bool > > if in > echo "yay!" > else > echo "boo!" > endif > > return in > enddef > > This one does: > vim9script > > def Out(in: bool): bool > if in > echo "yay!" > else > echo "boo!" > endif > > return in > enddef > > The only difference is a blank line after the def line. > I can't reproduce this with vim --clean and the latest version of the syntax file (June 21). I did kludge around a possible bug in the syntax highlighter that exposed itself in a recent change to the def/function body definitions. So I wasn't entirely surprised to see your report. I'd probably expect to see it in legacy-script functions as well if it was related to that change. Thanks, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoB3dBTPzbokmw_gDmUSFRqGumCRxQh87vGrSfJu2NREGA%40mail.gmail.com.
Re: syntax keywords with '[' character
G'day Ron, On Sun, 3 Sept 2023 at 22:33, Ron Aaron wrote: > I was just given a bug report for a new version of my syntax file, and > the problem is that a syntax keyword with a lone '[' doesn't work (it > causes an error message E789) > > I have 'syn iskeyword 33-255' (because everything except a space is a > valid keyword identifier) but the syntax parser in vim doesn't like it. > > I have other keywords with [ but they pair with a ], and my guess is that > these are being (improperly) treated as character classes. > > How can I get a keyword like SQL[ to be recognized? > I don't believe you can. We ran into the same issue with the Forth syntax file and just use syn-match for words that include '['. The [...] matches an optional sequence like %[..] in a pattern. There's actually a help entry for E789. It could be changed to respect the 'isk' value(s) over the optional sequence but I'm not sure one is better than the other. It's not inconceivable that the pattern might be heavily used even though '[' is included in 'isk' for a small number of keywords. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoBo9q6iYQYJeKQv%2B80KmudZq1qXj6FZ%3D0%2BbaDUbnsm56g%40mail.gmail.com.
Re: vim9class: accessing statics from outside the class
On Sun, 3 Sept 2023 at 02:31, Ernie Rael wrote: > AFAICT, it doesn't work. Is anyone working on this? > > I've run into it while working https://github.com/vim/vim/pull/13007. > > I am taking a look, but I don't want duplicate efforts. > You can read them and write them at top-level but, from a quick test, only read them within a class definition. I am not looking into this at the moment. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoDHR59Yby1nGBa%3DXarJr7-x3QAEEcwxsvBdTXiv5QuDwQ%40mail.gmail.com.
Re: Updates on the Vim project
On Thu, 24 Aug 2023 at 06:18, Christian Brabandt wrote: > Hi, > this is a small update over what happened the last few weeks. > > Over the last days, I have been merging mostly runtime file changes, > small improvements to the Vim9 class implementations and bug fixes. > > If you check the Milestone¹ for the release 9.1, most of the remaining > changes are small runtime changes, for which I'd like to get an > ACK/NACK. > Did you have a rough date in mind for the release? Are we looking at weeks or months? Thanks, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoCG-kW%2BgBNvWHObdiow8T%3DwtMaPeH-YqfpOcea5SgydUA%40mail.gmail.com.
Re: Vim9: Default object member access
On Mon, 28 Aug 2023 at 00:23, Yegappan Lakshmanan wrote: > Hi Doug, > > On Sun, Aug 27, 2023 at 7:14 AM Doug Kearns wrote: > > > > > > On Fri, 25 Aug 2023 at 23:50, Yegappan Lakshmanan > wrote: > >> > >> Hi all, > >> > >> From the email thread > >> https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1 > >> and the following items in the todo.txt file: > >> > >> - Change access: public by default, private by prefixing "_". > >> Check for error: can't have the same name twice (ignoring "_" > prefix). > >> > >> This is not yet implemented. We cannot change this after releasing Vim > 9.1. > >> Should we make this change now? > > > > > > I expect this will be an unpopular opinion but I'd strongly consider > releasing 9.1 > > without significant changes to Vim9 script from the 9.0 release. Then > the object model > > could be released with Vim 10. > > > > Once Vim 9.1 is released, we cannot break backward compatibility. > This means that > we cannot change the current accessibility of the object/class members > and methods. > Right, but Vim 9 didn't have classes. Are we beholden to unofficial patch releases? Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoBdc%2Bx_x38%2B%2BNYRBt3%2BfwEYmC4jJhmK73zNhpARRUXdTw%40mail.gmail.com.
Re: Vim9: Default object member access
On Fri, 25 Aug 2023 at 23:50, Yegappan Lakshmanan wrote: > Hi all, > > From the email thread > https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1 > and the following items in the todo.txt file: > > - Change access: public by default, private by prefixing "_". > Check for error: can't have the same name twice (ignoring "_" > prefix). > > This is not yet implemented. We cannot change this after releasing Vim > 9.1. > Should we make this change now? > I expect this will be an unpopular opinion but I'd strongly consider releasing 9.1 without significant changes to Vim9 script from the 9.0 release. Then the object model could be released with Vim 10. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoDD87x87nngFSsF2WaS_RbZt-8OL80S1i%2BxBejqG9f%2BCQ%40mail.gmail.com.
Re: Support for Private class/object methods
On Fri, 25 Aug 2023 at 15:21, Ernie Rael wrote: > On 23/08/24 9:10 PM, Doug Kearns wrote: > > On Fri, 25 Aug 2023 at 13:18, Yegappan Lakshmanan > wrote: > >> Hi all, >> >> The following item is in the todo.txt file for implementing private >> methods in a class: >> >> - Private methods? >> either: private def Func() >> or: def _Func() >> Perhaps use "private" keyword instead of "_" prefix? >> >> Function and method names always start with an uppercase letter. So >> if we use the >> "_" prefix for a private method name then it will diverge from that. So I >> have >> implemented this using the "private" keyword. >> >> Any opinions? >> > > Thanks very much for keeping the ball rolling on this. > > For others, there was some previous discussion[1] about it on the list > when Bram asked for opinions. My recollection is that both you and he were > in favour of the "_" prefix for call-site identification purposes? > > My personal preference would be for the modifier keyword with a symmetric, > even if possibly redundant, "public". > > Is it only redundant, or is there some semantic meaning or change? > Referring only to functions? > It's redundant if there's no 'readonly' access. It's common for languages to include an access modifier keyword for the default case so I'd prefer there was a modifier keyword for 'readonly' as well if that's the default. However, I'd be inclined not to offer a default. I don't find declaration keywords to be a burden. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoBEcANUoSw7rP7_rPBajKy4i%3DBFyoh319FA%2BNJZ3yB5Ug%40mail.gmail.com.
Re: Support for Private class/object methods
On Fri, 25 Aug 2023 at 13:18, Yegappan Lakshmanan wrote: > Hi all, > > The following item is in the todo.txt file for implementing private > methods in a class: > > - Private methods? > either: private def Func() > or: def _Func() > Perhaps use "private" keyword instead of "_" prefix? > > Function and method names always start with an uppercase letter. So > if we use the > "_" prefix for a private method name then it will diverge from that. So I > have > implemented this using the "private" keyword. > > Any opinions? > Thanks very much for keeping the ball rolling on this. For others, there was some previous discussion[1] about it on the list when Bram asked for opinions. My recollection is that both you and he were in favour of the "_" prefix for call-site identification purposes? My personal preference would be for the modifier keyword with a symmetric, even if possibly redundant, "public". I think this is justifiable on the grounds of it meeting the "less weird" requirement for Vim9 script. While I'm sure there are others, JavaScript is the only language I can think of off the top of my head that defaults to public and uses a sigil for private access. Thanks again, Doug 1. https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1 -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoBnoV9pM47k%2BGsSDApk3Xciu4RgGrSQJKbc0V1e8NAJjw%40mail.gmail.com.
Re: Where is Bram?
On Wed, 9 Aug 2023 at 04:52, Christian Brabandt wrote: > > On Mi, 09 Aug 2023, Doug Kearns wrote: > > > Runtime file updates often include test updates (e.g., filetype > detection tests) and changes to runtime infrastructure (e.g., > runtime/ftplugin.vim) are also arguably worth a version bump. > > > > Bram's distinction here actually makes a lot of sense but may, I > understand, not be tenable. > > Yes indeed. So https://github.com/vim/vim/issues/12722 shall increase the > minor or not? In an ideal world I think file type detection improvements like this should get a bump. It feels like core functionality and is tested by the main test suite. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoBO%2BaYYaTUvPuirxxZ_q_TFrrN32xBgxyYOk9HutNMwew%40mail.gmail.com.
Re: Where is Bram?
On Wed, 9 Aug 2023 at 03:56, Christian Brabandt wrote: > > On Di, 08 Aug 2023, Yegappan Lakshmanan wrote: > > > I am not suggesting a separate minor release for each runtime file > update here. > > Otherwise, we will have too many minor releases. Can we make a minor > release > > only for PRs that change the C code and not the runtime files (still > > merge the runtime changes as separate PRs)? > > Yes, that should be possible. We can merge runtime files directly, > without incrementing the minor patch number and only increment the minor > patch number for changes to the source (including diff, libvterm, xxd or > the test suite) > Runtime file updates often include test updates (e.g., filetype detection tests) and changes to runtime infrastructure (e.g., runtime/ftplugin.vim) are also arguably worth a version bump. Bram's distinction here actually makes a lot of sense but may, I understand, not be tenable. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoC5POrwToUac18EcfsBfgPa9Nu9BuF%2B955fMDXq1x8QgA%40mail.gmail.com.
Re: Where is Bram?
On Tue, 8 Aug 2023 at 06:12, Dominique Pellé wrote: About point #9 i.e. "Incorporating the runtime file updates" > I've always found it odd that some changes were split into > a commit in src and another commit later in runtime. It > often caused confusion, with PR author asking "part of > my change was not included?!" and the response being > "it will be in the next runtime update". Perhaps that's > something worth revisiting? > I assume you're aware of how it worked but for others, user-maintained runtime file additions and updates didn't receive a patch number and were batched in a periodic "Update runtime files" commit. However, any related changes to the core runtime like filetype detection were committed separately with priority as these did receive a patch number. I discussed this with Bram a couple of times over the years and the distinction was intentional. I don't have a strong view on it but I agree that it's quite confusing for new and casual contributors. There might also be other unrelated changes > which were pending in the next runtime update > that never happened. Often Bram responded > with "I'll include it" when people reported > corrections to the docs for example. > It seems that there hasn't been an update of the user maintained runtime files since June 11[1] so there's likely to be a significant number of submissions that have been dropped. For example, Bram didn't respond to my last emailed update on July 6. Perhaps we should make a request for these to be resubmitted by PR at some stage. Regards, Doug 1. https://github.com/vim/vim/commit/10e8ff9b26078994cae57c2422b145d37aaf714e -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoBUMUf6mXLCd6euqBYm2-jzvRCjHT1AyY_5LL%2Bfw_dpSQ%40mail.gmail.com.
Re: Where is Bram?
In Sat, 5 Aug 2023 at 22:53, Maxim Kim wrote: > https://groups.google.com/g/vim_announce/c/tWahca9zkt4 > It is with deep sadness that I receive this news. There is no one in our field that I have more respect for and I'm grateful I was able to express that sentiment to him not long ago. Adopting his "son" will be no small task for the community. He will be greatly missed. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoCdOWcELZkna-ZyYAx0%3DKTS2i92T_sfUru29LRQHwzBew%40mail.gmail.com.
Re: Class implementation
On Sun, 15 Jan 2023 at 02:34, Bram Moolenaar wrote: > > Most of the implementation of classes has been done. Feel free to give > it a try. You might run into something that is still a todo item, or a > bug. Please report this in a reproducible way. > > This is a good moment to evaluate the current choices. Although the > syntax and semantics are similar to popular languages, there are also > some differences. Hopefully they are easy to understand. > I notice that it's planned to allow classes to "specify" an interface. Does this not make interfaces themselves redundant? I can't see any utility to them over abstract classes that specify an interface. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoDX2efLbX7JBdiji9XS4NDX%3D-Q0_4TDe%2B-iY6dtFy3XEA%40mail.gmail.com.
Re: Class implementation
On Fri, 3 Feb 2023 at 04:28, Bram Moolenaar wrote:
>
> Doug Kearns wrote:
>
> > I was just looking at the constructor documentation and noticed that the
> > default constructor includes parameters for each field in the order they
> > were declared. Having to change all the constructor call sites when
> > reordering field declarations seems like a probable source of bugs,
> > particularly when switching fields of the same type. This seems like a
> > feature that really needs named-parameter support.
>
> Good point. Although I doubt it would happen often, it can be difficult
> to figure out what went wrong when it does happen.
>
> What we could do:
>
> 1. Do not change how it works, add remarks to the help warning for
>changing the member ordering.
>
> 2. Make the default new() method not accept arguments. The caller must
>set the fields after calling new(). This is safe, but requires
>several extra lines.
> var obj = Class.new()
> obj.line = 5
> obj.column = 0
>
This is probably the 'standard' approach.
> 3. Add a mechanism to name the members in the call, e.g.
> var obj = Class.new(line = 5, column = 0)
>This is similar to 2. but puts it in one line.
>It requires marking a method to not use positional arguments.a
>
> Although 3. looks like a good solution, it requires implementing a new
> mechanism. And disallowing positional arguments might be considered
> weird, I cannot think of a language that has this functionality.
>
Swift does this for structs and calls them memberwise initializers. It
creates a default initializer (constructor) with named fields if no
initializer is otherwise specified.
struct Foo {
var x: Int
var y: Int
}
let bar = Foo(x: 1, y: 2)
Classes don't currently create the default memberwise initializer (there's
a proposal for this) but named parameters are either specified or created
automatically for declared initializers.
Swift actually defaults to named parameters and the mechanism is a little
more elaborate than usual as argument labels can be specified that differ
from the parameter names. Unnamed parameters are allowed but these must
be explicitly specified with an argument label of "_".
I've never used Swift in anger; it was just the first search result of
interest. Here are the details -
https://docs.swift.org/swift-book/LanguageGuide/Initialization.html
Regards,
Doug
--
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/CAJ1uvoCakFg4TaHuF_w-f76kFNygeTypcppF7XaXDF0ZAzg_BA%40mail.gmail.com.
Re: Class implementation
On Sun, 15 Jan 2023 at 02:34, Bram Moolenaar wrote: > > Most of the implementation of classes has been done. Feel free to give > it a try. You might run into something that is still a todo item, or a > bug. Please report this in a reproducible way. > > This is a good moment to evaluate the current choices. Although the > syntax and semantics are similar to popular languages, there are also > some differences. Hopefully they are easy to understand. > I was just looking at the constructor documentation and noticed that the default constructor includes parameters for each field in the order they were declared. Having to change all the constructor call sites when reordering field declarations seems like a probable source of bugs, particularly when switching fields of the same type. This seems like a feature that really needs named-parameter support. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoAK-wS7soa%3DZTcujFBLPW72JyUxGnJ2%2B%2BmeSwN0_JUkxA%40mail.gmail.com.
Re: Class implementation
On Mon, 23 Jan 2023 at 23:53, Bram Moolenaar wrote:
>
> I expected a lively discussion about alternatives for the class
> implementation, but nothing much happened.
Some of us are old soldiers with too many scars. :)
I'm a bit short on time today but I have a few thoughts, some of which may
be partially reiterated from the previous related thread, to keep the ball
rolling.
= Field and Method Declaration Syntax =
I still find the difference between field and method declaration styles
quite jarring after playing with them for a while. In my experience most
languages reuse their variable and function declaration syntax, with some
additions, for this. TypeScript and JavaScript are exceptions that spring
to mind.
I think it's reasonable, though unnecessary, to introduce new syntax for
member declarations but we're currently only doing so for fields.
So my preference would be to use one of the following.
# Syntax-1
class Foo
this.bar: number = 42
this.Baz(qux: number): number {
return this.bar + qux
}
endclass
# Syntax-2
class Foo
var bar: number = 42
def Baz(qux: number): number
return this.bar + qux
enddef
endclass
I think we could get away with curly braces in the Syntax-1 version as
they're already used for lambda blocks and others.
Using Syntax-2, fields are declared as variables would be in other contexts
and then qualification with "this" could be required to access them. Then,
the only new syntax rule is the qualification requirement. This was also
proposed in the earlier thread by Maxim but didn't seem to garner any
comment.
var this.bar: number = 42 has been proposed but that is also jarring as
declarations of qualified identifiers aren't allowed in any other context
and the qualification is redundant.
Syntax-2 is what I would have guessed the class declaration syntax would
look like after having previously worked with Vim9 script. I think
anything else is an unnecessary complication so it would be my strong
preference.
= Underscore for Private Access =
The current implementation's asymmetry with regard to the private
underscore prefix and public modifier keyword isn't particularly elegant.
I note that it largely disappears with your newly proposed change of
defaulting to public access.
Irrespective, I'd prefer keywords were used for access modification. A
leading underscore is used for many ad-hoc purposes such as reserved words,
member fields, pseudo private fields and generally to work around perceived
deficiencies in a language. It has a lot of baggage and I wouldn't like to
see it become semantically significant.
Dart uses this scheme for library level access but they later introduced a
@protected annotation. Keyword modifiers are more flexible and future
proof.
JavaScript uses the even uglier # sigil but IIRC that was largely done for
JavaScript specific reasons that aren't pertinent.
Leading underscores are also ugly, to my eye, and I'd consider it an
unfortunate addition after the identifier prefix requirements were cleaned
up for Vim 9.
For example, when it's paired with required this qualification we get the
following from the help section on private members:
def GetLnum(): number
if this._lnum > this._lineCount
return this._lineCount
endif
return this._lnum
enddef
rather than the infinitely more readable:
def GetLnum(): number
if lnum > lineCount
return lineCount
endif
return lnum
enddef
The "this" qualification and "_" prefix are both useless to me when reading
or writing this so some of those lines are almost 50% noise. That's a
simple method, I think it can only get worse.
= Miscellaneous =
A few other questions that occurred to me:
- Is it intended that public fields can have the same name (ignoring the
underscore) as private fields?
- Are private methods planned? I don't think I noticed any reference to
these one way or the other in the help.
- Are final fields planned?
Regards,
Doug
--
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/vim_dev/CAJ1uvoAMZ%3DipT_Fy0gCWUY8yfzm%3DrBMQ8TXPwrLbxB9T3O0BGg%40mail.gmail.com.
nvim + vim9script: how Rust made it happen
Here's an update on the vim9script -> lua transpiler that TJ Devries has been working on for some time. https://www.youtube.com/watch?v=zPQSST-M3fM Nice work TJ. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoA1qfOfSmkr0sGg8sCQjwV_H5b799LhZTK_N9epTGnfeQ%40mail.gmail.com.
Re: Choices for Vim9 class implementation
On Mon, 26 Dec 2022 at 02:02, Bram Moolenaar wrote: [...] > > This following currently defines a field and is, without context, > > indistinguishable from any other assignment. Is that intended? > > With "var" it's indistinguishable from another declaration, I don't > think it matters much that it looks like an assignment otherwise. > There's only one declaration per class assuming either a qualified name is used in the declaration or normal shadowing rules apply. So, ignoring subjective aesthetic issues, this would allow for tooling to more easily identify the declaration. [...] > > It seems from the documentation that static fields can be referenced as > > bare identifiers? This feels a bit unexpected to me given that instance > > fields are always qualified. > > Static fields (class members) are totally different from object members. > I have always found it confusing, in many languages it's hard to tell > them apart, especially if the declaration is further away. Always using > "this" for object members helps a lot for this. I would not know what > to use for class members. The only thing I have seen is using the class > name, which can be long (and gets tricky when using inheritance). > I believe most languages access class members directly, without a > prefix. > I think they're much the same in terms of the problems the required "this" qualifier is attempting to address. Static fields also need disambiguation in shadowed contexts and could, arguably, also use better identification. Are methods going to need to be qualified too? Cards on the table, I'm not in favour of requiring qualified references. I just found it surprising that only unqualified instance fields were considered a problem. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoBEMBLsh1%2B8y-b%2BPw8uLi3VZtRNAob-PNV22ugNNt9fdQ%40mail.gmail.com.
Re: Choices for Vim9 class implementation
On Mon, 19 Dec 2022 at 00:33, Bram Moolenaar wrote: > > One thing I'm not yet sure about is the declaration. Currently it works > like this: > > this.name: string > this.gender: Gender > > Notice that there is no "var" keyword. It's not needed to recognize the > declaration. I can't think of a good reason to add "var" here, other > than that a declaration would be expected to always have "var". Well, I > don't have that expectation. This following currently defines a field and is, without context, indistinguishable from any other assignment. Is that intended? this.name = "Somebody" As methods still require :def I think it would be more consistent to not special case field declarations and still require the :var. For class members most languages use the "static" keyword. It's a bit > of a weird word, but I suppose most people are used to it, and I can't > find a popular language that has a good alternative. > > If we leave out "var" for object members, I suppose we should also leave > it out for class members. We then get: > > static oneClassMember: number > static twoClassMember: string > > I think this looks fine. Any objections? > It seems from the documentation that static fields can be referenced as bare identifiers? This feels a bit unexpected to me given that instance fields are always qualified. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoD%2BS7WmQiORM2_agzWWjy-72p%2B07QhEcWmmg1TZJ-YrOw%40mail.gmail.com.
Re: [vim/vim] No closures for the for loop [var1, var2] variables? (Issue #11094)
On Mon, 12 Sept 2022 at 05:14, Bram Moolenaar wrote: > Let's try to summarize: This sounds good to me. Thanks, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoBXz2KXN5wN%3Dmm%2B%3DpRpNr%3DfBbkcrLs8d%3DDk%3DL-64PzEMQ%40mail.gmail.com.
Re: Reva ftplugin patch
Bram, It looks like this patch may have slipped through the cracks? Thanks, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoAktZtkLcf8jfQvkzZuOnA_U0KCwGzUG6s%2BAWMPCkA7sg%40mail.gmail.com.
Re: changes to the hg mirror
On Tue, 5 Apr 2022 at 22:32, Bram Moolenaar wrote: > > > > I found one on https://book.mercurial-scm.org/. Not sure if it's the > same or the best, but it looks useful. > https://www.mercurial-scm.org/guide is the same page and includes a link to the book. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoB7CNdhQ_WOWrHQJVSVQsiw3PiP%3DC5%2BL2C1XV8GDYBUfQ%40mail.gmail.com.
Re: changes to the hg mirror
On Tue, 5 Apr 2022 at 21:32, Christian Brabandt wrote: > Oh and it looks like the Mercurial guide > https://mercurial.selenic.com/guide/ vanished, so please also remove the > link to that guide. > The guide is still there at https://mercurial.selenic.com/guide. Drop the trailing forward slash. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoDYpoM6JfFkOV1kfeJu0dP3EW8Dpymxx2vopZjjUm%2B9xg%40mail.gmail.com.
Re: Vim9 script feature-complete
On Thu, 13 Jan 2022 at 04:55, Manuel Ortega wrote: > Ah, it seems I misremembered the details. But my point remains pretty much > the same. I'd said it was unexpected for the comment char of vim9script to > be '#'; it's at least as unexpected for it to be '#', and even > more unexpected for it to be "'#', unless it's the start of the line". > That makes things worse than the old way, not better. Is this a practical problem? A quick search of my system suggests that tail comments are very rarely used without leading whitespace. The primary counter example being the idiomatic use of ;# in Tcl. Most, maybe all, of the other cases I came across are exceptions to the predominant style of the file. Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoCMVsFBPtVUqmJbmRoziuJ%3DMSZc2amoaqTmMrU1U2rbMQ%40mail.gmail.com.
Re: syntax/vim.vim question -- should vim's heredocs be highlighted with comment support?
On Mon, 20 Sept 2021 at 11:44, Charles Campbell wrote: > > Hello, > > Its been brought to my attention (thanks, Naruhiko Nishino) that vim's > heredoc's syntax highlighting may not need to support commenting, either > old-style or vim9 style. Some of the examples show vimL use, where > comment support is nice, but other examples are just plain text. I'm > leaning towards removing the comment highlighting support inside vim's > heredoc syntax highlighting. Comments? Yes, I'd remove it. It implies that those lines might not be included in the list. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoBNp-JV_nOiR55Y89GFf1NoA6a%3D10V1odqcNDxLDXKdvw%40mail.gmail.com.
Re: 8th syntax patches
On Mon, 20 Sept 2021 at 14:01, Ron Aaron wrote: > > Changes to the existing 8th syntax and ftplugin files: > > diff --git a/runtime/ftplugin/8th.vim b/runtime/ftplugin/8th.vim > index 14301187d..60a7b0cb4 100644 > --- a/runtime/ftplugin/8th.vim > +++ b/runtime/ftplugin/8th.vim > @@ -1,7 +1,7 @@ > " Vim ftplugin file > -" Don't load another plugin for this buffer > +" Don't load another 8th plugin for this buffer > let b:did_8thplugin = 1 Is there a reason to set this rather than the standard b:did_ftplugin? I'd assumed it was a search and replace error. See :help ftplugin_overrule (point 3) and :help ftplugin (DISABLING) No other ftplugin is using a filetype specific variable name for this purpose. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoA_VtiOoaV3DPBxL1T9i9LeDQu_o_sX-34yMG7s_fG8ww%40mail.gmail.com.
Re: My contributions to the Vim development
On Sun, 13 Jun 2021 at 15:23, Yegappan Lakshmanan wrote: > Hi all, > > I have been using Vim for more than 25 years and contributing to > the Vim development for 20 years. I have captured my contributions > to Vim over the years in the following page: > > https://gist.github.com/yegappan/4f4cbea5c018693159a8b61e3668ff8e > Thanks very much for all your efforts but especially for the less glamorous refactoring and testing work. Have you got another twenty years in you? :) Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoCD9rw6Juu0ozu__NG93r14OJKDMPzzjD1ekjPnr-4wSA%40mail.gmail.com.
Re: Wrong % behaviour (with matchit) when "language messages en" is within the scope on an if statement
On Sun, 11 Apr 2021 at 22:53, Bram Moolenaar wrote: > It is possible to only match "endif" at the start of the line or after a > bar: > > '\:\%(^\||\)\s*el\%[seif]\>:\%(^\||\)\s*en\%[dif]\>,' > > But then the cursor will move to the start of the line or the bar. > Putting in \zs to position the cursor doesn't work, because the plugin > uses \zs itself. Using a lookbehind works here. E.g., \ '\:\:\%(\%(^\||\)\s*\)\@<=\,' . You might be able to come up with a more general solution by extending the match_skip test. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoDcK3UvA4%3DYOsFe6uundWTPbUsZh7UTJn9gPKiQRLiACA%40mail.gmail.com.
Runtime file maintainers and GitHub's code owners feature
G'day all, I have noticed that there are often pull requests for updates to runtime files created against the main repo rather than being directed to the appropriate maintainers. GitHub apparently has a feature[1] that allows for file ownership. If adopted this would cause the maintainer to be notified of any such pull requests and be required to review the change. I fear the unintended consequences but it might give Christian and others a break from issuing the constant reminders. :) Regards, Doug 1. https://github.blog/2017-07-06-introducing-code-owners/ -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoCkw-%2BgH5%3DudJPRH%3DexH_Uwn%3DeJm80%3D5ch_kWWKgc9Qug%40mail.gmail.com.
Re: Bulk ftplugin updates - browsefilter GTK support
On Sat, 15 Aug 2020 at 00:44, Bram Moolenaar wrote: > > Doug Kearns wrote: > > > I've noticed that most of the ftplugins that support browsefilter don't > > test for the "gui_gtk" feature. > > > > Is there a process in place for executing bulk ftplugin updates in a case > > like this or should I just contact all the maintainers? > > I'm afraid contacting the maintainers is needed. I can include some > changes, but when a maintainer sends me a new version, it might overrule > them. Thus I rather have the maintainer make the change and then send > me the latest version. > Then that is what I will do. :) Thanks, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoBn8m9vLtZ9fRf_1x9gKpmEXDmNd-t91kPnMYEEOrY4mA%40mail.gmail.com.
Bulk ftplugin updates - browsefilter GTK support
G'day all, I've noticed that most of the ftplugins that support browsefilter don't test for the "gui_gtk" feature. Is there a process in place for executing bulk ftplugin updates in a case like this or should I just contact all the maintainers? Thanks, Doug -- -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/CAJ1uvoCYzsSMHSmf0a%2BPMpCLj97%2B9k0Jv4u_ANsfeFmWKhVkbQ%40mail.gmail.com.
[patch] Trivial :help syn-iskeyword fix
Please see attached. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. diff --git a/runtime/doc/syntax.txt b/runtime/doc/syntax.txt index 41e2f9f..5f90f18 100644 --- a/runtime/doc/syntax.txt +++ b/runtime/doc/syntax.txt @@ -3521,8 +3521,8 @@ SYNTAX ISKEYWORD SETTING *:syn-iskeyword* and also determines where |:syn-keyword| will be checked for a new match. - It is recommended when writing syntax files, to use this command - to the correct value for the specific syntax language and not change + It is recommended when writing syntax files, to use this command to + set the correct value for the specific syntax language and not change the 'iskeyword' option. DEFINING KEYWORDS *:syn-keyword*
Re: Segfault on 7.4 caused by syntax :on with Ruby file
On 14 August 2013 05:03, Dominique Pellé wrote: > I could narrow it down further. I can reproduce it with: > > # Create a file (6 space and a x, bug does not happen with less than 6 > spaces): > $ echo " x" > foo > $ valgrind --log-file=valgrind.log vim -u NONE -N -c 'syn on' foo > > Then in Vim-7.4 (huge, Linux x86_64) search for: > /\%(\%(\.\@\%(\s*(\)\@! > > and observe errors in valgrind.log. > Above regexp is actually used in syntax/ruby.rb: > > syn match rubyPredefinedConstant > "\%(\%(\.\@\%(\s*(\)\@!" Bug aside that pattern has been 'simplified' recently so the OP may like to try out the latest ruby.vim syntax file (not included in 7.4). Regards, Doug -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: ruby syntax broken on 7.3.1182
On 14 June 2013 13:37, 陈云杰 wrote: > after ruby code: > > 'asdf'<<"||"<<'asdfasdf' > > syntax highlight has broken That appears to be broken with much earlier versions. E.g. 7.3.638 Of course, formatting it 'nicely' fixes the problem. 'asdf' << "||" << 'asdfasdf' The heuristic to differentiate heredocs from string concatenation might be something that can be improved. I'll take a look at it. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Slow ruby syntax highlight with 7.3.1163
On 12 June 2013 15:13, Ben Fritz wrote: > On Monday, June 10, 2013 8:47:35 PM UTC-5, Hiroshi Shirosaki wrote: >> >> rubyPredefinedConstant pattern looks much slower with this file. >> >> syntime result: >> >> :set re=0 >> >> TOTAL COUNT MATCH SLOWEST AVERAGE NAME PATTERN >> 0.073358 1870 0.0015260.000392 rubyPredefinedConstant >> \%(\%(\.\@ > Isn't that first bit much too complicated? That does look suspiciously like cultivated nonsense. I'll take a look. Regards, Doug -- -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: PHP Omnicompletion
On Thu, Aug 5, 2010 at 3:20 AM, Shawn B. wrote: > As per numerous requests I've been told to post here to get my updated > phpcomplete.vim script (http://www.vim.org/scripts/script.php? > script_id=3171) included as the default in 7.3. How does one go about > doing that? In general you'd contact the maintainer of the currently provided script and see if you can have your changes included. Alternatively, and if the above has failed for some reason, is there some general consensus that your version is superior to the currently provided script? Regards, Doug -- 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
Re: Google Summer Of Code
On 3/12/09, Roberto Miura Honji wrote: > Vim will participate? > > I'm thinking to try a project with vim if it's possible. > Someone know something about this? There has been some recent discussion regarding GSoC on this list. Regards, Doug --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: PATCH: dynamically load Python on Solaris
On 2/15/09, Danek Duvall wrote: > If > there are any Python script torture tests I should run, let me know; I'm > not sure what the best python scripts are to play with. You could play with the distributed Python omni completion: autoload/pythoncomplete.vim Regards, Doug --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Create vimballs from the command-line
On 2/11/09, Tom Link wrote: > > Hi folks, > > Maybe somebody has some use for this. I wrote a small ruby script that > allows the creation of vimballs (plain text or gzipped) from the > command line. It's still young and fresh and experimental. I ran it > over my own plugins and the generated vimballs are identical to those > created by vimball.vim. Tested with ruby 1.8 (cygwin). > > Raison d'être: I wanted something that can run from a makefile and > that doesn't care about the runtimepath. You can specify the base path with the final arg to MkVimball. Regards, Doug --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: rubypath should be global in ftplugin/ruby.vim
On 1/15/09, Yasuhiro MATSUMOTO wrote:
>
> Hi all.
>
> Starting vim with arguments '*.rb' is very slow. It cause vim search
> ruby path from system call in 'ftplugin/ruby.vim'.
> 'ftplugin/perl.vim' check perlpath as global variable with
> exists('perlpath'). I use poor spec machine, and I wrote followingin
> my vimrc to ignore search .
>
> let g:perlpath = ''
>
> I think that ruby.vim should check global variable like 'perl.vim'
>
> below is a patch. please check and include.
Thanks. I'll add that or something similar.
Regards,
Doug
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: Has remove() always thrown an error if idx is beyond the end of list?
Nikolai, On 10/21/08, Nikolai Weibull <[EMAIL PROTECTED]> wrote: > > Has remove() always thrown an error if idx is beyond the end of list? > > Either way, what's the reasoning behind it doing so? If the items > aren't there to begin with, then great, that's precisely what I want. Ignoring the pivotal issue of your patch generating technique, I think you'll find Bram based Vim Script's lists/dicts on Python. The 7 release says as much: "Vim script supports Lists and Dictionaries (similar to Python)" Regards, Doug --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Searching for Vim scripts
On 9/4/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > I have now added a search box to the search page on www.vim.org where > you can specifically search for Vim scripts, anywhere on the internet. > This uses Google Code Search. Excellent! Thanks Bram. Regards, Doug --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Proposal: "Modes" for Vim
G'day Martin, On 8/27/07, krischik <[EMAIL PROTECTED]> wrote: > My proposal (if you have not guessed already) is to merge more > separate plug ins into modes. We do something similar with http://vim-ruby.rubyforge.org/ which distributes all of the 'official' Ruby related runtime files in a single package. > What do you think about the idea? In general I think it's a good idea but what exactly are you proposing? How would this work in practice? Regards, Doug --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug: Nested, transparent syntax regions
On 8/1/07, hamlen <[EMAIL PROTECTED]> wrote: > > Bug: A nested, transparent syntax region loses its transparency when > extending its containing region. This looks like the bug I reported back in February so Bram is aware of it. It's listed in todo.txt. Regards, Doug --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: Bug: Nested, transparent syntax regions
On 8/1/07, hamlen <[EMAIL PROTECTED]> wrote: > > Okay, sorry for the repeat. No problem. You couldn't have been sure from the TODO description anyway I suspect. :) > Where can I see todo.txt? :help TODO or :help known-bugs Regards, Doug --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
