vim

lp:~jonathonf/vim/+git/vim-upstream

Owned by Jonathon F
Get this repository:
git clone https://git.launchpad.net/~jonathonf/vim/+git/vim-upstream

Import details

Import Status: Reviewed

This repository is an import of the Git repository at https://github.com/vim/vim.git.

The next import is scheduled to run .

Last successful import was .

Import started on juju-98ee42-prod-launchpad-codeimport-0 and finished taking 5 minutes — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-5 and finished taking 5 minutes — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-4 and finished taking 5 minutes — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-1 and finished taking 6 minutes — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-0 and finished taking 4 minutes — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-1 and finished taking 4 minutes — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-0 and finished taking 5 minutes — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-5 and finished taking 4 minutes — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-1 and finished taking 4 minutes — see the log
Import started on juju-98ee42-prod-launchpad-codeimport-0 and finished taking 5 minutes — see the log

Branches

Name Last Modified Last Commit
master 2024-04-24 19:04:25 UTC
runtime(java): Improve the recognition of the "style" method declarations

Author: Aliaksei Budavei
Author Date: 2024-04-24 19:04:25 UTC

runtime(java): Improve the recognition of the "style" method declarations

- Request the new regexp engine (v7.3.970) for [:upper:] and
  [:lower:].

- Recognise declarations of in-line annotated methods.

- Recognise declarations of _strictfp_ methods.

- Establish partial order for method modifiers as shown in
  the MethodModifier production; namely, _public_ and
  friends should be written the leftmost, possibly followed
  by _abstract_ or _default_, or possibly followed by other
  modifiers.

- Stop looking for parameterisable primitive types (void<?>,
  int<Object>, etc., are malformed).

- Stop looking for arrays of _void_.

- Acknowledge the prevailing convention for method names to
  begin with a small letter and for class/interface names to
  begin with a capital letter; and, therefore, desist from
  claiming declarations of enum constants and constructors
  with javaFuncDef.
  Rationale:
    + Constructor is distinct from method:
      * its (overloaded) name is not arbitrary;
      * its return type is implicit;
      * its _throws_ clause depends on indirect vagaries of
        instance (variable) initialisers;
      * its invocation makes other constructors of its type
        hierarchy invoked one by one, concluding with the
        primordial constructor;
      * its explicit invocation, via _this_ or _super_, can
        only appear as the first statement in a constructor
        (not anymore, see JEP 447); else, its _super_ call
        cannot appear in constructors of _record_ or _enum_;
        and neither invocation is allowed for the primordial
        constructor;
      * it is not a member of its class, like initialisers,
        and is never inherited;
      * it is never _abstract_ or _native_.
    + Constructor declarations tend to be few in number and
      merit visual recognition from method declarations.
    + Enum constants define a fixed set of type instances
      and more resemble class variable initialisers.

Note that the code duplicated for @javaFuncParams is written
keeping in mind for g:java_highlight_functions a pending 3rd
variant, which would require none of the :syn-cluster added
groups.

closes: #14620

Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

11 of 1 result
This repository contains Public information 
Everyone can see this information.

Subscribers