In Sublime Text, I'm used to accessing function names through the # symbol list. However, when using a project established from vue-templates, all the function names and data attributes in .vue files do not appear in this list.
This makes navigating .vue files tedious. I have installed all vue-related Sublime packages but none of them seem to fix this.
How can I get symbol indexing working properly with Vue files? Or, do you have any experience with other text editors that do this properly?
The symbol list in Sublime (visible via Goto > Goto Symbol... or Goto > Goto Symbol in Project...) is controlled primarily by the syntax definition for the language in question and secondarily by configuration metadata that tells Sublime what parts of the syntax are actually symbols that should be displayed in the symbol list.
In general:
Sublime runs an indexer over all of the files that are currently in your project
The indexer uses the rules in the syntax definition to break up the text into various scopes that describe the purpose of each bit of text (e.g. "This is a string", "this is a method call", etc)
A preferences file contains rules that indicate what scopes are considered symbols, both for the current file as well as project wide
The two parts of this need to work hand in hand in order for the symbol lists to populate correctly (as Sublime can't guess on its own), and both parts should be provided by the package or packages that are providing Vue support to Sublime.
The best course of action would be to raise an issue with the developers for the Vue package that's providing the Syntax definition. It's possible that the simple inclusion of an appropriate Symbol List.tmPreferences file by the syntax author would be enough to fix the issue.
It's also possible that the symbol list is not fully populated because sublime is still indexing all of the files in the project and so the data is not available yet.
You can check the status of the indexer in recent builds of sublime by selecting Help > Indexing Status... from the menu to see if that's the issue. However unless you have an extremely large set of files this is likely not the issue.
Related
I've been successful in using form.location.resx files to localize the strings associated with form controls. However, I don't see how to (safely!) add strings to the .resx file(s) and then access them for such things as message boxes.
If I try to add a string to the .resx file using Visual Studio (2017), I get a warning dialog pop-up telling me that this could corrupt the "project item" (form) or my changes could be lost if I change the associated form.
Also, if I use this method, would I need to manually add my strings to each language file separately?
Alternatively, I could create a bunch of Labels to the form with visible=false and then edit their strings in the .resx files and use something like:
msgbox(LabelSampleMessage.text,MsgBoxStyle.Information,LabelSampleMessage2.text)
But that seems like it would be massively inefficient.
For Windows Forms, the best way to do this is to go into the Designer and set the Language property on the form. This will create a formName.Designer.languagecode.resx file for you. Then you just edit the Text properties of the controls. The changes will go to the resx file for the language you're editing. You can even have different layout and control spacing for each language (useful if a label is short in English but translates to something long in German).
For MessageBox messages, you do the same thing with the Resources.resx file. Just put all the messages in your Resources and duplicate the resx file for each language. Then use the Resource editor to translate the message in the other languages. You can then look up the message using My.Resources.Default.SomeMessageKey
#David: Note that I'm the author of a commercial ".resx" localization program for VS (in the interest of full disclosure). Yes, dwilliss is correct, though the names he used are a little off. For Windows forms, you can't manually update the ".resx" files yourself (directly), hence the warning from VS (don't know why they did things this way - go figure). You won't get that warning for strings you put in "Resources.resx" however. Just manually add "Resources.[LangCode].resx" and update it on your own. You have to add the keys yourself (again, no warnings). You can then simply access each string via the static properties seen in the "code-behind" file "Resources.Designer.cs" (one static property exists for each string you add). These are what MSFT calls "strongly typed" resources. If you access, say, "YourApp.Properties.Resources.SomeMessage" for instance (from "Resources.Designer.cs"), it will be returned in whatever language is currently set in "System.Threading.Thread.CurrentThread.CurrentUICulture" (assuming that language's satellite assembly is installed of course). This is all a pain and highly error-prone for other reasons as well, hence the reason I wrote my program (shameless plug but MSFT's way does work, though it's very primitive for handling translation in general - a professional organization relying on an external translator will save a lot of problems and $ in the long run by using a 3rd-party translation program, not mine necessarily though it would be my tool of choice of course, but anything is better than handling it manually).
I am working on a Language Package in Atom and am curious about how to name items. For some reason, things like keyword.operator.langname as the name, yet it still doesn't highlight. I checked the HTML source and the span is there, but no coloring. I even compared my code to other languages code and the styles.less file used in atom and it appears that it should work. What am I doing wrong?
Also, is there any good place that has a list of the selectors as I can't seem to find any docs on them.
The regex I am using for anyone who is curious is:
'match': ':',
'name': 'keyword.operator.langname'
(langname being a psuedonym for the name of the language.)
It's likely that the syntax theme you're using doesn't support it. I know that keyword.operator shows up in language-javascript, but when I look at one-dark-syntax as an example, the coloring for that class combination only exists in language-specific files. I feel like the best path for people designing small language packages is to look in core syntax theme packages to figure out which classes to use. Don't get too hung up on the actual class names, since your user won't see them at all unless they look at them in the dev tools.
Some valid IDL files, build as IDL Projects and install but some or all of their contents do not appear in the SCA Explorer/Target SDR/IDL Repository. I believe that the IDL parser used to build the tree in the IDL Repository is different from that used by the omniORB idl2cpp (omniidl) during building and it rejects some valid IDL. The cases I have found all use a value of a const previously defined. e.g.,
const Algorithm ALG_NONE = 0
const Algorithm ALG_LPC = ALG_NONE + 3
The second line can occur in the same file or in a file that includes the file containing the first line.
The file containing the first line is accepted if the second line is not in the same file, but the file containing the second line is rejected and none of its contents appear in the IDL Repository tree. It appears that it rejects a const appearing as a value on the right side of an assignment statement. These files however are valid and are accepted as valid by omniidl. But they cannot be used in RedHawk because they cannot be selected for a component interface.
I am not very familiar with RedHawk IDE sources or Eclipse plugins and so have not been able to find where the syntax for the parser is specified. I see "eclipsecorba" appearing in plugin lists so I assume that RedHawk is using the Eclipse CORBA Plugin (aka ECP) and that its parser is the one being used to build the tree. So I suspect that the parser error is in that package rather than in code added by RedHawk.
Can anyone confirm this and suggest where I might look in the ECP code for this? Should I report this as a ECP bug to the ECP group on SourceForge? I am not sure how active it is since it appears that the latest version is from 2008.
This seems to be a bug in the IDL editor, the IDL you have is legal. Would recommend you to report this to ECP but given the long inactivity of that project probably it will not fixed soon. I do know that one of our Remedy IT engineers has created a more modern IDL editor for Eclipse but due to lack of funding this work is not available publicly.
I'm trying to get a Cocoa development environment working in Emacs, and I'm 80% of the way there. The one feature I miss is Xcode's "Open Quickly", which basically performs a fuzzy match of the string you type against the filenames referenced in the Xcode workspace and the symbols defined in those files.
My problem is that our project is huge: if I generate a TAGS file using etags for the .h and .m files in our project's sub-directories, the result is over a gig in size and Emacs complains "TAGS file is large. Really open?", and if I say yes, then Emacs hangs and becomes essentially unusable. Of course, this is before I've even considered indexing tags for system libraries. I've also tried projectile, but unfortunately it's similarly unusable on a project of my size (on the order of a full minute to find a match).
It occurs to me that all the indexing information I really want is in the Xcode projects themselves, so if I had an Emacs package that could parse them and traverse their dependencies, that might be a start, but I'm not aware of any such package.
Any suggestions/solutions in this respect?
I've never found a single function quite as convenient as Xcode's "Open Quickly", but these days I use
helm-projectile-git-grep when I want to match on strings I know to be in the filenames, and
helm-git-grep for quick searches through the contents of the files themselves.
I've found that this gets me really close to what I wanted in my original question.
I've recently developed a domain-specific language using flex and bison. I would like to create a user interface for editing script files using this language. In particular I would like to have common functionalities such as file handling, menus, buttons, syntax highlighting, error checking and so on. Do you know any tool which can be used to develop such kind of application? I would prefer one which can give me a prototype rapidly.
such as file handling, menus, buttons, syntax highlighting, error
checking
I think that file handling, menus, buttons and highlighting are your least concerns. What you call "error checking" on the other hand. That can be a tough nut. I will try to give you some pointers to how you can (in a somewhat primitive manner) detect errors on the fly as the user inputs source code in the editor.
I assume you wish for something like Eclipses (for java at least) real time analysis of the written code in the editor? I'm not familiar with how Eclipse work internally but this is probably done by some pre-compilation process that processes all source code again and again as you change it.
One way to prototype this (and indeed build a non-prototype as well) would be to use Flex and Bison, and I notice you already is familiar with these tools. You can build you grammar and create action code for all interesting parts so you can find syntax deviations fairly easy. After this you make your editor run the flex and bison generated c-code as the user writes the source code in you IDE and have some way of displaying the output. Either in a terminal-like status window or directly in the text-editing field (as Eclipse does) (the latter case is probably a pain to build but by no means impossible and would give you IDE a professional touch).
Suppose you would like to build an IDE for ADA 95 the following Flex and Bison (Actually Lex and Yacc) code could help you do exactly this (it's a decent syntax analyzer that reports errors (what and where)):
http://www.adaic.org/resources/add_content/standards/95lrm/lexer9x.l
http://www.adaic.org/resources/add_content/standards/95lrm/grammar9x.y
Hope this helps.
Edit:
to have cool error highlighting and such in the text-editor field of your IDE you could let your bison generated syntax analyser generate something thats easy to parse, like XML, that contains the type of error and where it lies (row and column for example) and then use that to display the errors... you simply embed an XML parser in the IDE (lots of free one available) and extract the data you need and change the display accordingly... That shouldn't be rocket science when I think about it.