Some times I have tasks to create text tree, for example:
(*) Root1 (1)-┐
├ step1 (create some) (2)
├ step2 (create some other type) (3)-------┐
| (*) Root2 (8)
├ step3 make some action(4) ├
step1 create obj (9)
And accordingly I try to find some emacs modes to edit text tree, but find nothing.
There is a lot of tree for show files and directories and other structures.
(neotree, ztree and other ...)
Also there is artist-mode that can help create ascii art. Tree can be doing with it.
But is there extension to edit tree with ability to add/delete/edit nodes ?
It is not required to edit text directly, ability to create not text tree and
export it to text also will be good.
In my opinion there is should be something created with such things as:
Hierarchy.el (https://emacs.cafe/emacs/guest-post/2017/06/26/hierarchy.html).
Related
In Eclipse you can enable/disable "Compute deep outgoing state for folders" in Window | Preferences | Team | SVN | Label Decorations (or in other versions apparently -> Window | Preferences | Team | SVN | Performance).
The Documentation provides very little information about the functionality of this. ("Specifies if the computing of deep outgoing state is enabled.")
I was wondering what exactly does it do? What is a deep outgoing state?
By default a dirty (changed but not committed) file is prefixed with >. Folders that contains the dirty file are also prefixed with >. Here is an example where only the file Project/path/to/file.txt is dirty:
Without Compute deep outgoing state for folders the same example looks like this:
To compute the > dirty label for folders, the subtree of the folder have to be checked/visited for dirty files. By disabling Compute deep outgoing state for folders no subtrees need to be checked/visited, but dirty files are harder to find, especially when an ancestor folder is collapsed.
I would like a co-author to edit a lyx file I created. He doesn't have knitr installed and he is going to edit only text and equations parts of the document where knitr generated content is not present. I would still like him to be able to generate the pdf file from lyx though. Under Documents / settings / modules, I can delete the Rnw (knitr) module. But then there are errors appearing.
I posted a sample lyx file under knitr_iris.lyx.
When the knitr module is activated, Pdf generation works fine, but when you deselect the knitr module under Documents / settings / modules, the following errors pop up:
! You can't use `macro parameter character #' in horizontal mode.
! Missing $ inserted.
These are due to the use of $ and # in R. How to tell Lyx that knitr chunks are not latex code but something else that it should ignore?
You can do what you want to do by using LyX branches. First, highlight an ERT or knitr chunk (there are two ways to insert knitr in LyX) and go to Insert > Branch > Insert New Branch. Call the branch as you like, for example "knitrChunks". Now highlight the rest of the ERT or knitr chunks and go to Insert > Branch > knitrChunks (this branch exists now that you created it). When you see an "X" in front of the branch, that means it's deactivated. So when your co-author edits and wants to compile, he/she can just right-click on the branch inset and go to "deactivate branch" and remove the module. To reverse that, you can right click and go to "activate branch" and add the module back.
I was trying to move my workspace root around and did clear workspace mappings in p4v. What this did was clear every subfolder from the mappings. Then when I try to include the whole tree, it only includes the selected folder, since all the subfolders were cleared. Is there a way around this?
It may not list them, but if you are including the top folder "recursively" (i.e. follow the directory name with a slash and "..."), it includes all subdirectories without listing them explicitly.
To add the top directory in the "View Workspace Mappings as Tree" view, navigate to your depot or the highest-level directory you want to add. Right-click the directory and choose "Include Tree". Expand the tree views to verify that they are included.
If you're used to the "Workspace mapping as text", add the depot and client paths of the top-level directory that contains the subdirectories you want. Make sure the mappings are "recursive" and include all files and directories below by appending "..." after each side.
Ex:
Suppose you want to include dir1 and dir2, both of which reside under top_dir. Add this line to your workspace mapping:
//depot1/top_dir/... //myclient/top_dir/...
This will include //depot1/top_dir/dir1 and //depot1/top_dir/dir2, and all other files and directories under "top_dir".
element * CHECKEDOUT
element /test_ari/karthik/... ... /karthik_omna/LATEST
element /test_ari/karthik/... /main/2 -mkbranch karthik_omna
element * /main/LATEST
I have written the above code and it worked so right.I am so happy for that.But i want to clear somethings from u guys. What does that 3 dots mean in this syntax
/test_ari/karthik/...
and the other 3 dots means
... /karthik_omna/LATEST
And last question but it got great importance. Why should we always use * CHECKEDOUT in the beginning? what happens if we dont use it?
/test_ari/karthik/...
It means that the selection rule which follows (i.e .../karthik_omna/LATEST) will apply to the karthik directory, and to all the subdirectories and files, recursively.
If the selection path had been /test_ari/karthik/* (star instead of three dots), the selection rule would have applied to the subdirectories and files, but not to the karthik directory itself
.../karthik_omna/LATEST
This is a selection rule instructing ClearCase to select the LATEST version of the branch karthik_omna, without worrying on top of what other branch karthik_omna has been created.
If the selection rule had been (for example) /main/karthik_omna/LATEST, it would have selected the LATEST version of that branch only if said branch was created on top of 'main'.
Contrary to the previous '...', there is no '*' for a selection rule.
(*/karthik_omna/LATEST doesn't exist)
As I explained in "How to create a branch", selection rules are read in order and the first one that fits make ClearCase apply it (and ignore the others) for a particular file or directory.
This is why you will always find:
element * CHECKEDOUT
as the first rule, because when you notify ClearCase of your intention to modify that file, it (the file) acquires a special version called CHECKEDOUT which needs to be selected in order for you to be able to modify and then check-in that file.
If that rule was too far down below, ClearCase might select another version, and you wouldn't be able to check-in anything since that file would not be considered checked-out in your view.
When you select a variable in NetBeans 7, working with PHP (works with other languages too), the program highlights all the places inside the file where the same variable is used.
I know how to change the color of the actual highlighted text (in Options->Fonts & Colors->Syntax->PHP->Mark Occurrences), but NetBeans also marks the matches in a vertical bar to the right of the editor scrollbar. This is the color I want to change, because this bar also marks the diffs when using version control, and the "mark occurrences" matches are not very clear when there's a lot of diffs.
First I got the RGB color codes I needed to find, 175, 172, 102 (html #AFAC66)
Apparently, the color that is used to highlight occurrences in the vertical bar is hard coded in the Netbeans sources, so it is not possible to change it the settings or any configuration file.
Here is how the vertical bar looks by default when marking occurrences:
The PHP module gets the highlighting color from the class:
org.netbeans.modules.csl.editor.semantic.MarkOccurrencesHighlighter.java
The mentioned class is located in the module/jar:
$installation_folder/netbeans-8.0/ide/modules/org-netbeans-modules-csl-api.jar
You view the source of that class in http://hg.netbeans.org/, or you could use a decompiler.
To change the color, you could get the source and recompile the module, or you could just simply modify the bytecode. Personally, because I only wanted modify 3 values(RGB), I chose to alter the bytecode. To do this you can follow the next steps:
Make a copy of org-netbeans-modules-csl-api.jar in another folder (I’m going to refer to that folder as $folder).
Extract the class org.netbeans.modules.csl.editor.semantic.MarkOccurrencesHighlighter.class from org-netbeans-modules-csl-api.jar. For simplicity, be sure that you extract the package/folder hierarchy in the same folder ($folder) where the copy of the jar is located, so that you get:
$folder/org/netbeans/modules/csl/editor/semantic/MarkOccurrencesHighlighter.class
$folder/org-netbeans-modules-csl-api.jar
Open the class in a decompiler, I used JD ( http://jd.benow.ca/ )
Locate the code you want to modify (ES_COLOR):
Open the class in a bytecode editor, I used reJ ( http://rejava.sourceforge.net/ ), and locate the values 175, 172, 102. (You will have to change the opcode bipush to sipush if you want to use a value greater than 127)
Modify the values, I chose blue(0,0,255):
Save the modified .class, and verify with the decompiler that the values have been changed:
In a terminal or command line, navigate to $folder, and execute the following command to replace the modified class in the jar:
jar -uf org-netbeans-modules-csl-api.jar org/netbeans/modules/csl/editor/semantic/MarkOccurrencesHighlighter.class
Now, you can use the decompiler to verify that the jar was indeed modified with the altered .class
Finally, you can copy the modified jar/module to the original location $installation_folder/netbeans-8.0/ide/modules/ or you can copy it to the $user_directory/modules folder. The latter seems better as it doesn’t modify the installation.
Start Netbeans and enjoy the new color.
Here is how the vertical bar looks now when marking occurrences:
If you want to change the color that is used to highlight occurrences in the vertical bar for the Java module, you would have to modify another class org.netbeans.modules.java.editor.semantic.MarkOccurrencesHighlighter.java located inside
$installation_folder/netbeans-8.0/java/modules/org-netbeans-modules-java-editor.jar, following the same steps.
If I missed something, or if there is an easier way to alter the colors shown in the vertical bar, feel free to add it.
(Tested with Netbeans 8.0)