Reading through http://invisible-island.net/ncurses/terminfo.src.html it sounds as if it should be possible to assign multiple entries (e.g. "ansi+erase" and "ansi+cup") to the TERM environment variable.
Is it possible to specify multiple entries?
How are entries separated (e.g. spaces, commas)?
A terminfo entry is compiled, making an entry in the terminal database. The entries mentioned (ansi+erase and ansi+cup) are convenient building-blocks which can be combined along with miscellaneous capabilities to make a terminfo entry. About ten percent of the entries in the terminal database are building blocks.
Once compiled, you cannot modify an entry unless you make changes to the source and recompile it. Usually one modifies an entry by
dumping it to a source file using infocmp,
editing the source file, and
recompiling using tic
When modifying an entry, you could reuse the same name, or change the name. Of course, if you reused the same name, your changes would be lost the next time the terminal database was reinstalled (or recompiled).
Related
I share Sublime prefs between two machines (home, work) using Git.
My monitor at work has a higher DPI than my monitor at home, so in one of the two machines I'd like to override font_size.
I was hoping for:
The possibility to override using a command-line flag (to do something like subl --override-pref font_size=15), like kitty --override does.
Another level of prefs cascading below User.
, but I don't think any of this exists in Sublime. Language-specific config is not what I'm looking for, I want something global, but only in one of the two machines.
Ideas? Workarounds? Thanks.
The general mechanism at play for settings files is that when Sublime loads a sublime-settings file by name, it pulls all of the similarly named files across all of the known packages and combines them together (the same also happens for many other resource files) with content from later files overriding anything that appears in an earlier file.
The order that's imposed here is lexically by package, with Default always being first and User always being last. That's why the default settings are in the Default package and your custom settings are in the User package. Additionally syntax specific settings also apply (as do settings specific to projects).
Apart from this mechanism there's no direct way to override settings without some sort of manual intervention on your part. Potential solutions for this sort of problem include the following examples:
Don't sync the Preferences.sublime-settings file
If the file isn't synced across multiple machines, then this problem becomes moot because each machine can easily have it's own unique settings. The downside to that is that each machine then has it's own unique settings, which is a pain in the butt if you often move from machine to machine and things don't quite work the same way.
Use separate git branches
An alternative here if you're using git such as you are is to try and keep separate branches per host or per host type (like hi_dpi and reg_dpi or some such). Then on each machine check out the appropriate branch.
The obvious downsides here are having to try and cross-sync desired settings changes (for both User as well as any packages you might install) between branches, which is less than ideal unless you really love git.
Use extra Preferences.sublime-settings files
Here the idea is that you don't include the font_size setting in your User/Preferences.sublime-settings file at all. Instead, you use Browse Packages from the command palette to open the Packages folder, then create a new folder there with some arbitrary name. Inside of that folder include a Preferences.sublime-settings file that contains only the font_size setting.
Doing this on multiple machines, you can sync the settings in your User folder across machines without also syncing the preference that contains the font_size. As a note, if you create the file while Sublime is already running, you may need to quit and restart to get it to notice that the settings file exists; this only applies the one time, though.
Use a plugin
Looking at the link provided above, the ultimate trump card for any setting is a setting that's been applied directly to a view. Given that, you can use a plugin that selectively always applies a specific font size to any newly created or opened file:
import sublime
import sublime_plugin
import socket
class CustomFontListener(sublime_plugin.EventListener):
hostname = socket.gethostname()
def on_new(self, view):
if self.hostname in ("host1", "host1.example.com", "host2"):
view.settings().set("font_size", 20)
on_load = on_new
Now any time you open a file or create a new buffer, if the current hostname is in the list you've configured the view will immediately get an appropriate font_size applied; otherwise the one from the preferences would be used instead.
You could also extend this to be configurable via it's own settings file, apply a different font size depending on the host name, etc.
Settings in views are persisted in the sublime-session file and also in the workspace files associated with sublime-project files, so these settings will remain in place even across restarts.
Something to keep in mind is that the internal commands for changing the font size (via Preferences > Font or via the mouse wheel keyboard shortcuts) work by writing a new font_size to your user preferences.
If you're using separate preference files, then doing this will add font_size to your User settings and you will need to manually remove it and modify the other settings file.
If you're using the plugin, then these shortcuts won't seem to do anything because it applies a font_size that overrides the User preference, but in fact as outlined above your preferences file end up being changed and you may not notice right away.
So whichever way you go, if you tend to use those you may need to make manual adjustments to settings files in the aftermath. It's also possible to create smarter versions of those commands as well, if this is the sort of thing that happens often.
I've tried to use cg_annotate to include a dictionary by use --include flag. However, no matter what I typed after --include=, it always shows the manual (indicating that my path is wrong).
for example, I typed ".util" after --include= but it shows the manual:
the sceenview
The official manual says:
-I --include= [default: none] Adds a directory to the list in which to search for files. Multiple -I/--include options can be given to add multiple directories.
There is no 'dictionnary' of directories stored somewhere, you always have
to give the list of directories each time you launch cg_annotate.
So, in your case, the mandatory argument cachegrind-out-file is not provided in your command. This causes cg_annotate to stop and show its usage.
You might possibly use kcachegrind (and --tool=callgrind), as kcachegrind has some support for specifying source directories (if ever that is needed, as normally kcachegrind+callgrind will find automatically the source files).
To add some directories in kcachegrind, you can use the menu entry Settings->Configure Kcachegrind and add directories in the Annotations tab.
I'm looking at starting to use Gitflow. I notice that by default the branches end in forward slashes.
I.e.
hotfixes/
releases/
Etc.
Does the forward slash cause any problems as git uses a forward slash as a folder delimiter.
Will it cause any problems with deployment from git with the forward slashes in it?
Could we use another prefix such as hyphen?
What are the pros and cons of either method.
Thanks in advance
I'm going to re-order these questions a bit.
Could we use another prefix such as hyphen?
You can use any name format you want, as long as you respect the limitations of your own OS (operating system—Windows, MacOS, Linux, and so on). Using a hyphen does not fix the limitations.
Does the forward slash cause any problems as git uses a forward slash as a folder delimiter.
Git doesn't use it this way; it's your OS that does. The file path name a/b means "find name b within directory a", even on Windows.
Will it cause any problems with deployment from git with the forward slashes in it?
Not if you avoid one your OS's limitations. Let's take a quick look at those.
Background
Git will, at various times, write branch names (or any other reference names) into a path rooted in the .git/refs/ directory. The "full name" of any branch B is refs/heads/B, e.g., refs/heads/master, refs/heads/develop, refs/heads/feature/tall, refs/heads/bugs/short. These will wind up creating files named .git/refs/heads/master, .git/refs/heads/feature/tall, and so on. In each of these files, Git stores a simple value: the hash ID of the target object (a commit hash, for branch names).
At other times, Git will write all these names into a single "flat file": essentially, a really poor substitute for a key-value store database. Whenever Git uses its own database, rather than the operating system's file system, Git avoids the OS's limitations. But since this is not all the time, you must respect your OS's limitations.
A directory (or "folder") is never a file, and vice versa
Suppose you have a branch named x. This means Git sometimes creates a file named .git/refs/heads/x to hold the tip commit hash ID for x.
If you now try to create a branch named x/y, Git may need to create a file named .git/refs/heads/x/y to hold the tip commit hash ID for x/y. But there is already a file named x, so it becomes impossible to create a directory named x holding a fie named y.
This means you must avoid using one name that becomes a prefix of the other when / is treated as a path name separator.
(This same rule applies to the names of remotes. You may, if you like, name two different remotes hq/a and hq/b, but if you do that, you must not name any remote hq.)
Case folding
Suppose your OS folds case. That is, suppose that you create a file named ReadMe.txt and then ask to open or view or create-or-write a file named readme.txt. Does this make a new file readme.txt that is different from the existing ReadMe.txt, or does it re-use the existing ReadMe.txt? If your OS re-uses the existing ReadMe.txt, your system folds case: it retains the uppercase and lowercase mix you use when you first create a file or directory, but from then on, use of any name that resembles the original name, but has a different mix of upper- and lower-case letters, will wind up re-using the original case.
That means that if you create a branch named master, and then try to create another branch named MASTER, your OS will re-use the lowercase name. This will, in a sense, "confuse" Git: Git thinks that master and MASTER are different branches, but your OS insists that the two different branch values be stored in a single file.
The same applies to directory names within the path. If you name one branch feature/tall and a second branch Feature/wide, Git will think that the second branch should always be named Feature/wide—but when Git goes to create a new file .git/refs/heads/Feature/wide, your OS says to itself: "Aha, I should re-use the existing lowercase-f feature directory and create this as .git/refs/heads/feature/wide." This once again confuses Git.
When this situation occurs, the behavior is somewhat hard to predict. If your OS does case folding on files,1 you should avoid the situation entirely. A good practice here is to pick one case—usually lower-case only—and stick with that.
1Modern OSes, including Linux and MacOS, actually choose whether to do case-folding on a per-file-system basis. This means you can set up a file system that is fully case-sensitive—file readme.txt is entirely different from file ReadMe.txt—and use that, to work around problems with branch names. However, Linux defaults to fully case sensitive for all its native file systems anyway.
Unicode normalization
Case folding, as performed by operating systems, tends to be limited to ASCII: they may not have a concept of an uppercase é, for instance. This is especially true if they use Unicode to represent "non-ASCII" characters (accented characters, Arabic, Chinese, Cyrillic, Hangul, Hebrew lettering, and so on). But if the OS supports Unicode at all for these wider character sets, it often uses UTF-8 encoding,2 which "hides" the Unicode encoding from the OS-level operations, which treat path names as strings-of-bytes. The "higher order" non-ASCII characters, even encoded, never clash with the ordinary ASCII characters such as /, so that when the OS uses / to choose to make or use a directory, this does not affect the non-ASCII characters.
The process of Unicode normalization is a bit mysterious to those who have not experienced it. See the Wikipedia page on Unicode equivalence for details, but in short, consider the idea that ü might be expressed as a single character "u with umlaut", or as the combining sequence "umlaut, u". If the OS wants to fold case, it probably should also treat these two distinct byte-sequences as naming the same file.
MacOS performs Unicode normalization to deal with this (NFD in HFS+; see this StackOverflow posting and its various links). This too affects Git (which, since Git version 2.1, has code to deal with it, though there was a bug fix as late as Git 2.8.4). I have no experience with it, but in general I would just advise avoiding the problem: stick with simple ASCII branch (and other reference) names.
2Windows uses UTF-16-LE, but the effect is similar.
The only problem I encountered is that if you have master branch you cannot create a branch named master/foo/bar because it starts with an already branch name.
I use [fix/feature|path]/{issue-number}/[description/]{destination} pattern
examples:
fix/42/master tells that this branch/pr is a fix of issue number 42 on master branch
feature/23/1.4 tells that this is a feature 23, for next minor release 1.4
and again
feature/123/create-red-button/master add a red button (the card number 123) on master branch
and so on
Currently you can set a different suffix when initialize gitflow with git flow init like this:
❯ git flow init
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/] feature-
Release branches? [release/] release-
Hotfix branches? [hotfix/] hotfix-
Support branches? [support/] support-
Version tag prefix? [] v
As you can see, in brackets are the default values (forward slash as suffix), but you can overwrite it with yourbranchname- (dash at the end)
We have two vobs which are "voba" and "vobb". And there is a directory "abc" in both vob and contains the same .h / .cpp files.
Usually, the files in "abc" dir in "voba" are updated quite frequently. And from time to time, I would like to update all files in "abc of vobb" from "abc of voba", which means:
Checkout the updated files in vobb.abc, overwrite them and then check in.
Copy the newly created files to vobb.abc, create element.
Delete the deleted files in vobb.abc by corrspoding to voba.abc.
If it is a common linux directory, I think cp -u and achieve that. But when it comes to the clearcase, I can only do the above 1-3 by hand.
Is there any easy way to finish that update automatically?
This is called in ClearCase a clearfsimport (potentially used with the -mirror option)
Since the elements in the directories abc of the two vobs are completely different (different oid, with different history), what you can do is import the content of abc from one vob into another: clearfsimport will automatically checkout, update and checkin only the files that have evolved in the source, and need to be updated in the destination.
Note, this recent thread (March 2013) also points out to the perl script ClearCase::SyncTree
It is superior to clearfsimport in many respects, especially in its evil twin avoidance (it will try with the proper options to link suitable entries from non visible versions).
Description:
This module provides an infrastructure for programs which want to synchronize a set of files, typically a subtree, with a similar destination subtree in VOB space. The enclosed synctree script is an example of such a program.
The source area may be in a VOB or may be a regular filesystem; the destination area must be in a VOB.
Methods are supplied for adding, subtracting, and modifying destination files so as to make that area look identical to the source.
Symbolic links are supported, even on Windows (of course in this case the source filesystem must support them, which is only likely in the event of an MVFS->MVFS transfer). Note that the text of the link is transported verbatim from source area to dest area; thus relative symlinks may no longer resolve in the destination.
Any tips on how to store large amounts of text, such as programming code. So I need to retain the tabs, spaces, etc?
Also how could i keep versions like say someone edits one line, i can see the changes that have been made?
That's what various revision control systems are for.
Any of git, cvs, rcs, subversion and a host of others will work.
I agree with other posters that you probably want to use what has already been done. Sometimes rolling your own can be fun.
You could write a wrapper for the command line diff utils. Each user could have their own config to choose their preferred editor. The script would made a copy of the file, so you would have an orig and new. When done editing the script would kick off a diff and store that to disk and delete the original backup of the file. This way, you would only store the latest versions plus all diffs so you can revert back and also see the changes.
I would keep a log of all diffs created and tag them in a csv with the userid of the person who modified the file and the timestamp of the modification.