emacs-csharp / csharp-mode Goto Github PK
View Code? Open in Web Editor NEWA major-mode for editing C# in emacs
License: GNU General Public License v3.0
A major-mode for editing C# in emacs
License: GNU General Public License v3.0
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)
i think this can be replaced with electric-pair-mode
which is built into emacs 24
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.
We should provide some class-skelotons based on AutoInsertMode when creating new files.
See Emacswiki for more details.
To Reproduce:
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.
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 is still an issue, and needs to be resolved somehow. Google code has several issues on this:
There might be more issues, but it only needs to be fixed once :)
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":
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
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.
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.
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?
As seen in the attached screenshot, csharp-mode highlights for
inconsistently. Most of the for
s are blue, but there's one that's the same shade of violet as the new
keyword above. I can (temporarily) make all the for
s 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.
Repro:
///
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.
See original page on Google-code for full contents.
Add to new README.md
or README.org
.
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?
I'm looking for documentation on available settings
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]
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?
List of issues can be found here.
Some seem like better candidates for getting started than others. For instance:
If issue is imported and fixed, post a reply on the original issue.
With this new thinned-down version of csharp-mode, the *compilation*
buffer no longer highlights or can find errors in msbuild’s output.
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.
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.
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?
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?
C# attributes currently don't have any highlighting. It's not terribly important, but it would be good to fix this.
This can seemingly be implemented without much fuzz.
See to PHP-mode for inspiration. Those tests are pretty nice and simple to write.
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:
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:
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
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.
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)
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:
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
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.
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
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.
C# has gained quite a few new reserved keywords since 2011.
Out of my head I can come up with the following ones:
Seems pretty easy to add based on this commit:
1119177
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).
Copy-pasted from a Google code issue
What steps will reproduce the problem?
- 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.
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?
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.
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.
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.
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.
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.
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.
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
Symbol's value as variable is void: <!DOCTYPE
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.
i have the same issue found here, it looks like a simple fix and i can probably submit a pull request in the morning
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.