I want Speedbar to display outlines (list of variables, functions and other "interesting" objects") I have in source files it doesn't understand yet. I have code to generate TAGS for the sources in question, where should I look for a hook / configuration to do that?
You can use speedbar-add-supported-extension function to add new files that speedbar doesn't understand by default.
From speedbar.el:
You should use the function 'speedbar-add-supported-extension' to add a new extension at
runtime, or use the configuration dialog to set it in your .emacs file.
If you add an extension to this list, and it does not appear, you may
need to also modify 'completion-ignored-extension' which will also help
file completion.
In addition to that, you may want to teach speedbar how to parse the tags for this new file using speedbar-fetch-etags-parse-list. For a C/C++ style language with a file extension .foo you might want to do something like this.
(speedbar-add-supported-extension ".foo")
(add-to-list 'speedbar-fetch-etags-parse-list
'("\\.foo" . speedbar-parse-c-or-c++tag))
Related
Is there any path-autocompletion extension for Markdown in VSCode?
I tried Path Intellisense but this seems to be effective only when using (double) quotation.
I want to use autocompletion when insert images stored in local directory, e.g.:
Yes, you can make that happen by using this extension on VS Code.
Relative Path extension
Juste type ctrl (or cmd on mac) + shift + H and type your file name.
It should be built-in to vscode soon, hopefully v1.64.
New setting: markdown.suggest.paths.enabled default is true
from Commit: Add basic markdown link completions
Only normal links for now. Will add reference links later. Should
support the forms:
[](dir/file.md)
[](./dir/file.md)
[](/root-dir/file.md)
[](#header)
[](./dir/file.md#header)
The paths suggestions work similarly to path IntelliSense in CSS and
HTML files. Paths starting with / are resolved relative to the current
workspace, while paths staring with ./ or without any prefix are
resolved relative to the current file. Path suggestions are
automatically shown when you type / or can be manually invoked by
using kb(editor.action.triggerSuggest).
Path IntelliSense can also help you link to headers within the current
file or within another Markdown file. Start the path with # to see
completions for all the headers in the file (depending on your
settings, you may need to use kb(editor.action.triggerSuggest) to see
these)
-from https://github.com/microsoft/vscode-docs/blob/vnext/release-notes/v1_64.md#markdown-path-intellisense
For anyone else stumbling upon this answer, the Markdown All in One extension is able to perform this sort of autocomplete.
Now my default file type of Visual Studio Code is Plain Text.
If I save a new file with name like a.in, it will save as a.in.txt. I have to change the dropdown to All Files.
I find the same problems in github: 1, 2. However, they seem not solve my problem.
This is not possible in the general case in VSCode.
The issue is that you cannot assign "no extension" to a language, and as per the links you mentioned, the All Files (*.*) option is disabled by upstream (electron).
Therefore, you will either have to remove the extension manually, OR you can create the file first (using the terminal, Explorer, an extension, etc.) and then open that existing file.
There is a way to change the default extension (but not to All Files)
Add the following line to your settings.json
"files.defaultLanguage": "<language>",
Replace <language> with the language of your choice.
Now, whenever you make a new a file, the default file language will be <language>.
A special value for <language> is ${activeEditorLanguage} which is the language of the file last opened (useful if, say, you copy a piece of code from one file to save as another).
Unfortunately, this does not fully answer the question, but provides a partial solution.
Is there a way to tell org-mode to load only the first N lines of a long text file? I would like to keep the whole file open to be able to search through it, but have org-mode display on the first N lines of my file, which is where I edit new content.
If you have a structured outline in org-mode, you can set the global file visibility with the #+STARTUP markup, or the visibility of any heading with the VISIBILITY property, see Visibility Cycling for details. The benefit of using the built-in org-mode properties is that it's easy to have a file open up in exactly the state you want.
I have my journal file set up to accomplish something similar what I think you're asking for using these org-mode properties. The "Today" section is opened so I can see everything, but older archives are collapsed.
I'm not sure the title really fits the description?
I think you just want use buffer narrowing, which lets you hide everything outside of the specified region for as long as necessary.
You can manually narrow the buffer by marking the region and typing C-xnn
Widen the display back to the full buffer with C-xnw
I guess you could use an eval Local Variable to automate this to a pre-defined region, if you really wanted to.
There's also narrow-to-defun (C-xnd) and narrow-to-page (C-xnp). If you throw a page break into your org file (C-qC-l), the latter might prove handy.
The Emacs extension markerpen.el (link text) allows you to hightlight arbitrary regions in your buffer. With this extension, the added highlighting is lost once you kill the buffer though. However, it would be nice to be able to highlight arbitrary regions of a file in a "persistent" way -- in the sense that the added hightlighting is not lost after I close the file.
Do you know of any way I could have such a "persistent" highlighting?
Thanks very much.
Try enriched-mode.
Yes, such a feature does exist. And you can add the highlighting in any number of ways, including sweeping the mouse marker pen-style.
http://www.emacswiki.org/emacs/HighLight#PermanentHighlighting
At the moment, no feature like this exists, so you'd need to create an extension to markerpen.el which created a metafile containing highlight points in each file that had them. (I'd suggest creating a metafile for each file)
When setting marks, each time one is added to markerpen-overlays you could update the related metafile.
When you load any file, you could check for the existence of the metafile (or when you invoked the markerpen library)
Then load the metafile and create the marks.
Someplace I saw a snippet of code which told vi to use soft tabs and set the size of a tab. If you put this snippet at the bottom of a source file, then vi would magically use those settings for that file.
What is the syntax and rules for including that snippet in a source file? Can emacs be made to use these settings as well?
You can put this in a comment in your source file:
ex: set softtabstop=4 shiftwidth=4 tabstop=4 expandtab:
The comment syntax depends on the type of the source file.
For C/C++/Java, this would be:
// ex: set softtabstop=4 shiftwidth=4 tabstop=4 expandtab:
For JSP, this would be:
<%-- ex: set softtabstop=4 shiftwidth=4 tabstop=4 expandtab: --%>
This works if it is placed at the beginning of the source file, but I'm not sure that this'll work if placed at the end of it too.
This will not work for emacs. There might be a different way of achieving the same for emacs.
Check out :h modeline.
Example:
/* vim: ai set sw=4 ts=4 */
See :h modelines for how many lines into a file Vim will check for modeline info. The default is to check the first 5 lines.
As far as I know, vi didn't have this capability. You're likely thinking of the modeline feature of Vim. There is similar functionality in emacs, where you can put local variables in the file.
Note that, at least in Vim, modelines have had a history of vulnerabilities. This is primarily due to problematic options being specifically blacklisted instead of only allowing a certain subset of variables to be set in modelines. I'd suggest using a plugin like securemodelines.
Put this in your C++ source file:
// vim: set ft=cpp
The modeline feature looks for the string "vim:" and then executes what follows. Note: this could open up potential exploits if you don't trust the files you are opening, so think twice before enabling this feature.
Okay, first of all, in real vi you do this in the .exrc file.
Second, use
set autoindent tabstop=8 shiftwidth=4
because otherwise vi will insert tabs it thinks are only 4 characters wide. The resulting text file will not look like it makes sense in any other editor.