emacs-csharp / csharp-mode Goto Github PK

From MELPA pull-request: melpa/melpa#2225 (comment)

Purcell said:

Couple of things I noticed:

• You should remove the debug (message "Loading ...") forms.
• You might like to wrap the top-level yasnippet code in (eval-after-load 'yasnippet ...)
• Relatedly, using eval-after-load inside a function won't have the results you expect

Hope that helps! :-)

Look into these issues. Get things fixed.

Copy-pasted from a Google code issue

What steps will reproduce the problem?

1. open c# program with a line of code such as:

string[] dirs = Directory.GetDirectories(@"\path\ending\with\backslash");

This can still be reproduced with our current builds.

This is still an issue, and needs to be resolved somehow. Google code has several issues on this:

• https://code.google.com/p/csharpmode/issues/detail?id=1
• https://code.google.com/p/csharpmode/issues/detail?id=9

There might be more issues, but it only needs to be fixed once :)

In Visual Studio, at least with Resharper, comments containing certain prefixes (TODO:, HACK:, BUG:, etc) gets fontified in a different way. They are rendered in bold with a darker, more noticeable colour.

I think this would be a nice addition, but I have zero experience with fonitification so I'm not sure how easy it will be to implement.

Any takers?

Is there any setting to change how syntax is highlighted? I really think the current highlighting is too colorful. I would be happy if csharp-mode just highlighted types, keywords and strings (like Visual Studio basically).

If your file looks like this

using System;

namespace MyApp
{
    public class MyClass
    {
        public void HasComment() // test
        {
        }

        public void HasNoComment()
        {
        }
    }
}

Only HasNoComment will be indexed as a function.

i have the same issue found here, it looks like a simple fix and i can probably submit a pull request in the morning

No big deal, but thought I'd log it anyway.

C# attributes currently don't have any highlighting. It's not terribly important, but it would be good to fix this.

I realize this is a matter of taste, but take the example below?

using System;

namespace MyApp
{
  public class MyClass
  {
    public void MyMethod()
    {
      using (var myScopedVariable = GetDisposable())
    {
      // why are the braces indented?
    }
    }
  }
}

Why is the braces and indentation in the using-statement in MyMethod different from the rest of the class?

As far as I know, this differs from regular C# conventions, and definitely from how VS does things. I'm for changing this, but I won't go overboard with this if people actually wont it to behave this way.

Any opinions?

They don't check for other important factors like line-numbers and project-file.

Doing so would be an improvement and increase the value of the regression-tests we currently have.

Example code:

class ImenuMatcherTests : IDisposable
{

...
    void IDisposable.Dispose()
    {
        Console.WriteLine();
    }
}

Dispose() does not get indexed.

Currently this works for interface-prefixed properties, so the support is somewhat inconsistent...

Fix this, consider performance when writing regexps and create a better test-suite covering a wider array of imenu tes-cases.

Run M-x check-parens on the file it will point to csharp--imenu-remove-param-names-from-paramlist

I have sources from melpa, 2015-12-01.

Looking at the provided flymake-intergration it seems pretty weak, and (IMO) doesn't really provide much in the terms of real-world C# development.

I also see that Omnipsharp-Emacs has proper build-integration with solution files and everything. So there's a partial overlap here.

I'm for just ripping out the code we don't need or wont be using/maintaining, and this seems like a prime candidate. Any opinions?

Creating an empty buffer and starting csharp-mode with csharp-want-imenu set to t produces:

Error in menu-bar-update-hook (imenu-update-menubar): (wrong-type-argument stringp nil)

The imenu indexing is needlessly complex. It's a finite state machine trying to be a proper c#-parser, which it just isn't. And as long as we're not at 100%, we will keep getting issues related to it.

Right now this is causing issues with either parsing failing entirely for complete documents, or partially where methods just "disappear":

• #51
• #26

And why do we have this complexity? Part of this is to be able to shorten down method signatures from void DoSomething(SomeType someParamName, OtherType otherParam) to void DoSomething(SomeType, OtherType).

Giving this some thought I'm not sure I really appreciate this. Especially combined with helm-imenu it would be nice to be able to search based on actual parameter-names, but if we strip those out, that information is just gone.

So we have extra complexity for the sake of removing possible interaction-modes. And I don't think that makes sense at all.

If we simplified the indexing to report void DoSomething(SomeType someParamName, OtherType otherParam) as just that without any more fuzz, we should be able to remove quite a bit of complexity, and not to mention reduce the possible amount of failure modes.

Based on the feedback from this issue, I'm going to assume people are OK with this, but before going ahead and doing anything about it, I'll be polite enough and double-check :)

Any opinions?

CC: @wasamasa @binki @jesse-black @ymarkovitch @BrunoQC @nosami @sp3ctum

Some issues we have highlights a somewhat the schizophrenic relationship between csharp-mode and omnisharp-emacs.

As a result of that relationship, csharp-mode is currently suffering from a light identity-crisis:

• should it be complete enough to work as a standalone module and provide the minimums expected from such modes by itself, even though this often overlaps features found in other commonly used modules, and more often than not, inferiorly so?
• should it rely on other emacs-modules like omnisharp-emacs for what is often considered "basic" features (like imenu)? If so, code-duplication can be removed and focus can be used on providing one good and complete implementation.

I would be happy to join forces with the omnisharp-emacs-team if they also agree that this is a good direction to take the package.

If so, should we be daring enough to even try to merge these two packages into one?

Opinions?

CC: @wasamasa @jesse-black @binki @nosami @sp3ctum

It would be nice to have a generic prog-mode-hook to also be invoked for csharp-mode, and it would be nice to have all c-family language customizations handled under a generic subsection in your prog-mode-hook like this:

(when (is-derived-mode-p 'c-mode)
    ;; my stuff
    )

Look into how much work it is to get inheritance done properly.

Emacs 25 complains a bit:

csharp-mode.el: `flet' is an obsolete macro (as of 24.3); use either `cl-flet' or `cl-letf'. [2 times]

Currently the old package is being hosted. See https://marmalade-repo.org/packages/csharp-mode

It would be confusing for packages built from different repos shared the same name in the same Emacs package-listing.

Investigate how to get our package to supercede this one and get things done.

When using special characters in the tittle of a "#region" like double quote (") or apostrophe (') csharp-mode interpret the character as part of the code, so the syntax highlight marks all the text after the character as "string".

Example:

public static String someFunction() {
    return "jajajaa";
}

#region programingfrik's functions
public static String test(String name) {
    // this whole function will be marked as string.
    return "This function is a joke!";
}
#endregion

public static int addiction(int me, int drug)
    // this too is marked as part of the string
    // that started in the #region
    return me + drug;
}

I'm seeing this bug in the cshap-mode downloaded from ELPA version 20150714.138 in Gnu-Emacs 24.5.1 (i686-pc-mingw32)

See issue found on Google code. This can still be reproduced.

Minibuffer also mentions something about which-func-ff-hook error: (scan-error "Unabalanced parantheses" 18 54) before freezing.

At mode startup, there are two interesting hooks that run:
`c-mode-common-hook' is run with no args, then `csharp-mode-hook' is run after
that, also with no args.

Does csharp-mode runs c-mode-hook? or maybe c-mode-common-hook does it.

I have (add-hook 'c-mode-hook 'irony-mode) and irony-mode is loaded with .cs while it shouldn't.

C# has gained quite a few new reserved keywords since 2011.

Out of my head I can come up with the following ones:

• var
• in/out (for co-variant/contra-variant generics)
• async/await
• yield (not sure it's currently in there)
• Linq-keywords (from, let, where, select, orderby, ascending, descending)

Seems pretty easy to add based on this commit:
1119177

See original page on Google-code for full contents.

Add to new README.md or README.org.

I'm looking for documentation on available settings

Repro:

• Type ///

Expected result:
I get three lines prefixed with /// and uniform indentation

Actual result:
I get three lines prefixed with /// and non-uniform indentation. More specifically, the first line is indented at the same level as the method while the remaining two lines are indented a level deeper. Using TAB does not fix the indentation level, so it's likely the fault of the indentation code and not the command.

71b0e96 broke the CI, 829ad4d fixed it again. I'm not sure how to interpret these results, perhaps something is deeply wrong about font-lock in the test environment or the tests aren't really run. Another weird thing is that using make clean && make all doesn't match the results of the CI, we should look into that, too.

Further experimentation for this can go on in a separate branch to avoid changing the state of the CI badge because it is run on all branches.

To Reproduce:

1. Ensure that csharp-mode is loaded: (require 'csharp-mode)
2. Open file etc/compilation.txt
3. Look for Microsoft in this file. Find the error message example: "1>test_main.cpp(29): error C2144: syntax error : 'int' should be preceded by ';'" The 1> is highlighted as part of the filename when it should not be included.

Practically csharp-mode when loaded will prevent clicking on an error message from devenv.com going to the file. Instead it will attempt to go to a file with the incorrect name.

presumably the first steps are to contact the original maintainer and author and if they can't be contacted, then the package has to be renamed. what other steps are required?

When byte-compiling csharp-mode with emacs from git source, you get the following output::

-*- mode: compilation; default-directory: "~/build/csharp-mode/" -*-
Compilation started at Tue Sep 15 11:51:28

make clean && make all
rm -f ../csharp-mode-0.8.10.tar
rm -rf ./.tmp/csharp-mode-0.8.10
rm -rf csharp-mode.elc csharp-mode-tests.elc
"/home/jostein/bin/emacs" -Q -batch -L . -f batch-byte-compile csharp-mode.el

In csharp--at-vsemi-p:
csharp-mode.el:432:15:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp--move-back-to-beginning-of-something:
csharp-mode.el:1700:37:Warning: looking-back called with 1 argument, but
    requires 2-3
csharp-mode.el:1699:36:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp-move-back-to-beginning-of-defun:
csharp-mode.el:1726:19:Warning: looking-back called with 1 argument, but
    requires 2-3
csharp-mode.el:1732:39:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp--on-defun-close-curly-p:
csharp-mode.el:1744:17:Warning: looking-back called with 1 argument, but
    requires 2-3
csharp-mode.el:1746:12:Warning: looking-back called with 1 argument, but
    requires 2-3
csharp-mode.el:1745:47:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp--on-ctor-close-curly-p:
csharp-mode.el:1754:12:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp--on-class-close-curly-p:
csharp-mode.el:1762:17:Warning: looking-back called with 1 argument, but
    requires 2-3
csharp-mode.el:1762:47:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp--on-intf-close-curly-p:
csharp-mode.el:1771:12:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp--on-enum-close-curly-p:
csharp-mode.el:1779:12:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp--on-namespace-close-curly-p:
csharp-mode.el:1787:12:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp--on-defun-open-curly-p:
csharp-mode.el:1792:14:Warning: looking-back called with 1 argument, but
    requires 2-3
csharp-mode.el:1794:9:Warning: looking-back called with 1 argument, but
    requires 2-3
csharp-mode.el:1793:44:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp--on-class-open-curly-p:
csharp-mode.el:1799:14:Warning: looking-back called with 1 argument, but
    requires 2-3
csharp-mode.el:1799:44:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp--on-genclass-open-curly-p:
csharp-mode.el:1805:9:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp--on-namespace-open-curly-p:
csharp-mode.el:1810:9:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp--on-ctor-open-curly-p:
csharp-mode.el:1815:9:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp--on-intf-open-curly-p:
csharp-mode.el:1820:9:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp--on-prop-open-curly-p:
csharp-mode.el:1825:14:Warning: looking-back called with 1 argument, but
    requires 2-3
csharp-mode.el:1825:44:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp--on-indexer-open-curly-p:
csharp-mode.el:1831:9:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp--on-enum-open-curly-p:
csharp-mode.el:1836:9:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp-move-fwd-to-end-of-defun:
csharp-mode.el:1886:13:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp-move-back-to-beginning-of-class:
csharp-mode.el:1926:19:Warning: looking-back called with 1 argument, but
    requires 2-3
csharp-mode.el:1932:39:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp-move-back-to-beginning-of-namespace:
csharp-mode.el:1978:19:Warning: looking-back called with 1 argument, but
    requires 2-3

In csharp--imenu-create-index-helper:
csharp-mode.el:2403:14:Warning: looking-back called with 1 argument, but
    requires 2-3
csharp-mode.el:2441:16:Warning: looking-back called with 1 argument, but
    requires 2-3
csharp-mode.el:4093:21:Warning: reference to free variable
    ‘compilation-error-regexp-alist-alist’
csharp-mode.el:4093:21:Warning: assignment to free variable
    ‘compilation-error-regexp-alist-alist’
csharp-mode.el:4094:21:Warning: reference to free variable
    ‘compilation-error-regexp-alist’
csharp-mode.el:4094:21:Warning: assignment to free variable
    ‘compilation-error-regexp-alist’

In csharp-mode:
csharp-mode.el:4232:6:Warning: (lambda nil ...) quoted with ' rather than with
    #'
csharp-mode.el:4232:6:Warning: (lambda nil ...) quoted with ' rather than with
    #'

In end of data:
csharp-mode.el:4307:1:Warning: the following functions might not be defined at
    runtime: c-make-font-lock-search-function, c-skip-comments-and-strings,
    c-font-lock-invalid-string, c-font-lock-declarators,
    c-fontify-recorded-types-and-refs, c-define-abbrev-table,
    c-make-inherited-keymap, c-mode, c-initialize-cc-mode,
    c-populate-syntax-table, c-common-init
csharp-mode.el:4307:1:Warning: the following functions are not known to be
    defined: csharp-is-square-parentasis-block-p, imenu--subalist-p, cadar
"/home/jostein/bin/emacs" -Q -batch -L . -f batch-byte-compile csharp-mode-tests.el

In toplevel form:
csharp-mode-tests.el:28:7:Warning: assignment to free variable ‘debug-res’
csharp-mode-tests.el:185:20:Warning: assignment to free variable
    ‘orig-content’
csharp-mode-tests.el:185:33:Warning: assignment to free variable
    ‘indented-content’
csharp-mode-tests.el:185:14:Warning: reference to free variable ‘orig-content’
csharp-mode-tests.el:185:14:Warning: reference to free variable
    ‘indented-content’

In end of data:
csharp-mode-tests.el:188:1:Warning: the following functions are not known to
    be defined: caddr, cadddr
"/home/jostein/bin/emacs" -Q -batch -L . -l csharp-mode-tests.el -f ert-run-tests-batch-and-exit
Running 7 tests (2015-09-15 11:51:29+0200)
   passed  1/7  activating-mode-doesnt-cause-failure
   passed  2/7  activating-mode-triggers-all-hooks
Test build-warnings-and-errors-are-parsed backtrace:
  (while --dolist-tail-- (setq test-case (car --dolist-tail--)) (let* 
  (let ((--dolist-tail-- (list (list "./test-files/msbuild-warning.txt
  (lambda nil (let ((--dolist-tail-- (list (list "./test-files/msbuild
  ert--run-test-internal([cl-struct-ert--test-execution-info [cl-struc
  ert-run-test([cl-struct-ert-test build-warnings-and-errors-are-parse
  ert-run-or-rerun-test([cl-struct-ert--stats t [[cl-struct-ert-test a
  ert-run-tests(t #[385 "\306�\307\"\203G

This function used to have these parameters as optional, but now they are mandatory:

11:44 < wasamasa> ,df looking-back
11:44 < fsbot> looking-back is a compiled Lisp function in `subr.el'.
11:44 < fsbot> (looking-back REGEXP &optional LIMIT GREEDY)
11:44 < fsbot> Return non-nil if text before point matches regular expression REGEXP.
11:44 < fsbot> Like `looking-at' except matches before point, and is slower.
11:44 < fsbot> LIMIT if non-nil speeds up the search by specifying a minimum
11:44 < fsbot> starting position, to avoid checking matches that would start
11:44 < fsbot> before LIMIT. ..[Type ,more]

Fixing it to use the mandatory parameters should be possible to do in a backwards compatible way. Make it so?

As seen in the attached screenshot, csharp-mode highlights for inconsistently. Most of the fors are blue, but there's one that's the same shade of violet as the new keyword above. I can (temporarily) make all the fors look consistent by invoking M-x font-lock-fontify-buffer to re-fontify the buffer, but the inconsistency returns after I scroll around or I switch to another frame and switch back to this one.

Calling imenu in a buffer containing this in a class:

        public void foobar(bool b = true) {
        }

results in the message: csharp--imenu-remove-param-names-from-paramlist: unexpected char (C)

This does work as expected:

        public void foobar(bool b) {
        }

This code has never been part of the official csharp-mode package (which only contains csharp-mode.el, csharp-mode-autoloads.el and csharp-mode-pkg.el), and has never been cleared of "experimental" status.

Besides the NRefactory-based refacting-code seems redundant when we have things like omnisharp-emacs.

When running cask, I get the following error:

https://travis-ci.org/OmniSharp/omnisharp-emacs/builds/58865093#L1903

Is this a known issue? Could it be with cask?

You can do this with tagging your commits with a version number, e.g. 5.4

See here:
https://github.com/milkypostman/melpa#stable-packages

Consider the following file:

public class Testee
{
    public Testee()
    {
        var subee1 = new Subee1();
        var subee2 = new Subee2();
    }

    private class Subee1
    {
    }

    private class Subee2 : IDisposable
    {
    }
}

Classes Subee1 and Subee2 are detected as properties in imenu, with their corresponding names Subee1 and IDisposable.

Methods and properties inside private classes are also not indexed.

Consider the two different files:

using System;

public interface IImenuTest
{
    string InterfaceString { get; }
}

and

using System;

namespace TestNS
{
    public interface IImenuTest
    {
        string InterfaceString { get; }
    }
}

The first file will not have it's interface-members indexed, while the second file will.

There's probably some bad recursion logic going on in this general area.

Nothing serious but should be considered fixed while looking into other ATD (attention to detail) type imenu-issues.

List of issues can be found here.

Some seem like better candidates for getting started than others. For instance:

• csharp-mode should also run a prog-mode-hook in Emacs 24
• Compilation errors with emacs 23.3.1

If issue is imported and fixed, post a reply on the original issue.

This can seemingly be implemented without much fuzz.

See to PHP-mode for inspiration. Those tests are pretty nice and simple to write.

We should provide some class-skelotons based on AutoInsertMode when creating new files.

See Emacswiki for more details.

With this new thinned-down version of csharp-mode, the *compilation* buffer no longer highlights or can find errors in msbuild’s output.

So, in my contribution #34, seems it doesn't work and matches the wrong parts of the error if the error message is made to have characters like [ or ] in it. See how it parses the compilation example at https://gist.github.com/binki/8774f9cc4bed0a547d75. For all but the second error, the 1> is included as part of the filename.

I could probably figure out what’s happening, but I don’t have the time to work on it at the moment. Maybe if the error is obvious enough, this gist can be added to the testsuite and fixed.

i think this can be replaced with electric-pair-mode which is built into emacs 24

get travis-ci to check that all commits and pull requests can be byte-compiled and to run any automated testing to be written later. some tools that can be used:
https://github.com/cask/cask for loading packages, but i don't think this will be needed as it only depends on cl and cc-mode
https://github.com/ecukes/ecukes for writing tests

In the typical and idiomatic C# use-case one file has one class only, contained in a file with one namespace only:

using System;

namespace DemoNS
{
    public class DemoClass
    {
        public int DemoField;

        public string DemoPropety { get; set; }

        public DemoClass()
        {
        }

        public void DemoMethod()
        {
        }
    }
}    

The current csharp-mode imenu implementation will create one hierarchical level for each hierarchical C# construct:

DemoNS
|- DemoNS.DemoClass
   |- DemoField
   |- DemoProperty
   |- ctor()
   |- DemoMethod()

This feels convoluted and inefficient to work with. Even when using helm-imenu, most of the screen is consumed by the constants namespace DemoNS / class DemoNS.DemoClass and it gets worse the longer namespaces and class-names you have.

The most useful way for imenu to index this file would be to simply include class-members and nothing else in a flat list:

• DemoField
• DemoProperty
• ctor()
• DemoMethod()

Now obviously there will be exceptions to this rule where you for whatever reason have more than one class in a file (Interface and implementation, nested private classes, enums and other "small" types related to the main class, etc) so we should probably still accommodate for that need.

We should however strive to make the defaults better for the average use-case:

• Namespace should be removed entirely as its own type of node. The class-declaration contains the namespace anyway, so this is still searchable.
• Class-level should be flattened out (as in removed) when a file contains only one class.

I'm not going to jump on this issue immediately, but having some feedback on the issue would be nice :)

cc: @wasamasa @binki @jesse-black @sp3ctum

Symbol's value as variable is void: <!DOCTYPE

I've been looking at the font lock code and noticed there's some code for handling .aspx/.ashx/.ascx files. I loaded up an aspx file in csharp-mode and it doesn't work at all, it highlights almost everything wrong. So I think we should get rid of this to simplify the font lock code. web-mode handles these files much better.

Tested on the SignalR/Owin codebase we have this class.

Notice how the following method does not show up in the imenu-list:

[SuppressMessage("Microsoft.Maintainability", "CA1506:AvoidExcessiveClassCoupling", Justification = "This class wires up new dependencies from the host")]
private static IAppBuilder UseSignalRMiddleware<T>(this IAppBuilder builder, params object[] args)

This indicates there are more things which causes our parses to just skip out from whatever it's working on.