When editing a C file in emacs with semantic-mode, Is there a way to prevent semantic to recursively parse included files, and only allow it to parse the current buffer?
I like some functionalities of semantic that only require parsing the current buffer (highlighting...), while I use rtags for navigation. I do not want to turn semantic off, but since parsing is extremely slow and blocks emacs, I would like to avoid it.
Related
I am using https://github.com/emacs-mirror/emacs/blob/master/lisp/savehist.el for saving the history of filesets-data. Yet in my savehist-file all sets of files are listed in one single very long line. Is there a way of indenting or, more generally, formatting the output so that it is more readable (and, potentially, more easily modified manually)?
As described here, emacs-lisp-mode provides for special handling of s-expressions in docstrings that start in the first column. This requires them to be escaped with a backslash to avoid mucking up font-lock later on in the file.
This may be a feature for elisp, but is unfortunate in other lisp modes that reuse emacs-lisp-mode for convenience that don't have special handling of expressions in docstrings, as described/shown here.
My question is, is there any way for such "descendant" modes to configure emacs-lisp-mode to disregard "calling convention expressions" in docstrings?
The short answer is no.
The longer answer is that those other modes are simply broken. They should adapt to Emacs Lisp in this regard. There is no reason not to, is there? It is simply a bad idea to use workarounds (e.g. indent all doc-string lines), such are suggested in the link you provided (and its linked duplicate post).
Emacs doc string are not trivial strings. They have several special properties, including the handling of \\[...], \\{...}, and \\<...>, as well as the property you mention here.
If some mode cannot adjust to Emacs doc strings then it should use macros that define the things it needs without creating Emacs doc strings for them but by handling a different string argument in the special way desired. IOW, create pseudo doc strings that correspond to what the mode wants instead of what Emacs wants.
Of course, that means that you cannot directly take advantage of the Emacs documentation features. You would need to also define mode-specific doc commands that would, for example, wrap the existing doc functions such as describe-function with code that picks up the mode's pseudo-doc string and DTRT, following the mode's conventions instead of the Emacs doc-string conventions.
But I would think that the easiest approach would be to just adapt the mode to the existing Emacs behavior, so that it DTRT.
Many Emacs programming modes, and various Lisp modes are no exception, have been implemented based on parsers with regular expressions. This, unfortunately, gives the editor little idea of the document being edited. Eclipse, for example, has a very different idea of how to edit code, which is more structured, and JetBrain MPS editors are even more rigid and structured in this sense (almost like spreadsheets).
This makes Emacs modes faster and easier to implement, but it also means the code that supports the proper indentation, syntactic validation and highlighting has to re-parse more text every time it is being edited. CEDET, afaik, is trying to address this issue.
Thus, historically, there had been conventions designed to reduce the amount of code to parse on each edit. Parenthesis in the first column is one such convention. However, it also has been known to be an annoyance some times, that's why there's a open-paren-in-column-0-is-defun-start variable one can set to nil to inhibit this behaviour.
But It's hard to say what exactly the performance issues you may face when changing this setting. Lisp grammar is very regular, unless you are using many reader macros, so, perhaps, that won't be a problem.
If beginning-of-defun-function is set accordingly, i.e. checking if inside a comment or string, should be no need for such escaping.
I am using the glew and freeglut libraries (both of which include huge numbers of functions and constants declarations) to write opengl programs under Emacs. I use the CEDET's default semanticdb as the back end of auto-complete at first. However the Emacs freezes and it cost about 20 seconds to pop the candidates of auto-complete when I typing gl(since there is many GL_XXX constants and glxxx function in the header files of glew and glut). the pop-up of the candidate is too slow, is there a way to speed it up still using the CEDET? or is there another way to walk around it? by using the gtags? how?
Since there are so many functions and constants declarations in the header files, I am heavily rely on the auto completion. I am using the CEDET 1.1, does the new version of CEDET solve the problem?
Use of gtags should potentially speedup calculation of alternatives. Does slow completion happens always, or only on first use? This could be caused by parsing header files, etc., and later this should be caches in semanticdb (if you've enabled it)
For the past year and a half, I've maintained a monolithic buffer in Org Mode for my engineering notes with my current employer. Despite containing mostly pointers to other documents, this file has become quite large by human standards (48,290 lines of text), while remaining trivially searchable and editable through programmatic means (read: grep and Org Mode tag search).
One thing bothers me, though. When I perform a tag search using Org Mode 6.33x, Org's sparse tree view retains the folded representation of unmatched trees within the buffer (that is, content preceded by a single asterisk, *). This is generally useful for smaller buffers or those better organized into a single tree with multiple branches. However, this doesn't work especially well for documentation where each new tree is generated chronologically, one for each day, as I've been doing.
.
Before I continue, I'll note that my workaround is inherent in what I've just asked, as are the obvious alterations in my documentation habits with this buffer. However, the following questions remain:
1) Why does Org Mode organize trees in this manner when performing sparse tag searching? The technical details are self-evident, the UX decisions less so.
2) If I wished to correct this issue with a script written in Emacs Lisp, what hooks and commands should I explore in more detail to restructure the document view? Writing overrides for the standard commands (for example, org-match-sparse-tree) is already self-evident.
.
Thank you in advance.
As you already noticed the problem only affects the top level headings. The good thing is that in org-mode you can demote easily all headings with simple keystrokes. This way you can avoid the problem. Also cleaning up afterwards are just some simple keystrokes.
Step-by-step instructions:
Mark the full buffer
Call M-right (for outline-demote)
Input * root\n at the beginning of the file
Now, build up your subtree and do what you want with it.
When done you can remove * root\n at the beginning of the file and promote the headings again with M-left
I have got the impression that you can even leave the overall-heading where it is for your application.
In noweb mode, I would like to make the doc chunks and code chunks easier to distinguish. I'm already using font-lock-mode, but it applies the same face to strings in R and strings in tex, so doesn't distinguish the code and doc chunks very well.
For example, a slightly different background color for the code chunks.
One possibility would be to define a new face for the minor mode of the code chunk, but then that face would also apply when editing a buffer in that mode.
Another possibility would be to create an overlay for the code chunks.
Also, somewhat related, org-mode can be configured to use different background colors for source blocks.
Update: I now use polymode to achive this.
You can use noweb-font-lock-mode from ESS to get syntax highlighting for both code and documentation chunks. I'd recommend you also use noweb-mode from ESS too, because it has some improvements.
One option would be mmm-mode, with which you can define regions that are in a different mode -- it also applies a face to the entire sub-mode region, which you can use to easily distinguish those regions within the parent file.
I personally use this for Ruby within IRB, Javascript and CSS within HTML etc. There's an example for javascript in my emacs config.
The MuMaMo extensions allows different rules for different parts of the file. Getting the nXhtml package will give you the mode and I think you can configure it to do what you want.