Move Emacs from Linux to Windows - linux

I've had a break from programming the last two years and want to start up again. Right now I'm using a Windows computer, but my work and compiler is on my Linux computer.
My question is:
Is it possible to move my entire emacs work environment from Ubuntu to Windows 10? I did some changes in emacs back in the days that I got used to and would love to continue like that on my Windows computer.

Briefly...
The most important things to copy are your ~/.emacs.d directory and your init file (see C-hig (emacs)Init File for the different filenames this might have, or check with C-hv user-init-file).
See C-hig (emacs)Windows HOME regarding where the .emacs.d directory should live on your Windows system.
Note the comments in that Info node on the site-lisp directory as well, in case you've been using elisp libraries in there (possibly without realising), as they can form part of your Emacs configuration as well.
Any byte-compiled elisp (.elc files) should remain compatible so long as you're moving to an equal-or-newer version of Emacs (which sounds likely in this case). Natuarally things do change between releases, though, and it's possible to encounter incompatibilities when upgrading, but I wouldn't worry about that in advance -- try the latest version first, and if you run into problems that you can't solve (which shouldn't be very likely), you can always install the version of Emacs you were originally using.

Related

How is it possible for the terminal to automatically recognize newly installed modules as independent commands w/out being defined

On my PC I have quite a few aliases, path variables and modules like npm, scoop shims, go modules, powershell/bash functions/modules and my question is, does the pc search through all of these things the moment after I run a command? or is there some kind of registry that stores all of these values so they are quickly accessible? That would be my guess but both on my linux machine and my windows pc I have syntax highlighting on and it "knows" that a command is valid even prior to running it.
I was really curious about what process is taking place here earlier today when I installed gum (charmbracelets go TUI module) and it automatically recognized "gum -file" as a valid command when I hadn't explicitly defined it anywhere and it isn't prepended with "go" or "scoop" (assuming that I used one or the other to install the module)
I tried googling this question but I was inundated with pages of irrelevant stuff regarding basic questions about path errors and bloated articles about how to add stuff to your path.

Problem of Running Monodevelop-Stable on Linux

I've tried to install Monodevelop-Stable on Arch-Based Linux ( Manjaro ) and i'd fault 3 times, it wasn`t possible to build from Github sources or from AUR or Flatpak, so i decided to use monodevelop-stable-bin also from AUR, but when i tried to run my app , i got this problem
"$(MSBuildBinPath)\Microsoft.CSharp.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk (MSB4019)
Another words:
"MonoDevelop/7.0/MSBuild/2472_1/Microsoft.Csharp.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk (MSB4019)
But i have in my directory:
Microsoft.Csharp.Crosstargetting.targets
Notice , that this answer also wasn`t helpful:
this one
Question is indeed so popular on the internet , but i still haven`t found an answer , and i need some help
I have the same problem, I talked a bit more in detail in this answer, but the short of it is that, for now, it seems that there is no way to use Monodevelop on Arch based systems.
I recommend using a Ubuntu based distro for programming (there are many other similar problems with Arch). There Monodevelop should work just fine.
Of course, you can try to use other IDEs, like JetBrains Rider (I haven't personally tested it) or just use text editors with appropriate extensions, like VSCode or Atom.

TortoiseSVN update/cleanup error between Linux repository and Windows XP

For no reason that I can see, I can no longer run a TortoiseSVN Update on a development directory on my portable Windows XP Professional SP3 machine, getting the error:
Previous operation has not finished; run 'cleanup' if it was interrupted
Please execute the 'Cleanup' command.
If I try running cleanup, I get another error,
cannot process the following paths: cannot move $ROOT_DIR/.svn/tmp/tmp-... to $ROOT_DIR/path/where/thing/should/go: no such file or directory
I have verified that both files exist, and actually from CMD.EXE prompt I am able to issue a MOVE with those two filenames and have it work correctly. It's no use because next time SVN tries to repeat the operation itself after creating a different tmp file name, and while CMD succeeded, SVN fails.
UPDATE: the path lengths are in both cases well below PATH_MAX, target file system is NTFS, and permissions are OK. Maybe I'll now try with FileMon to see whatever TortoiseSVN is really up to.
I tried downgrading TortoiseSVN but to no avail. Other repositories work OK between the same machines.
TortoiseSVN 1.7.9, Build 23248 - 32 Bit , 2012/08/30 18:25:37
Subversion 1.7.6,
apr 1.4.6
apr-utils 1.3.12
neon 0.29.6
OpenSSL 1.0.1c 10 May 2012
zlib 1.2.7
Both server (OpenSuSE Linux 12.2) and client now run the latest version of SVN.
On Windows, I also cannot seem to get any more informative logs or information (I'm not very skilled with TortoiseSVN, I have always used the Linux command line version).
I might delete the local copy and run a checkout, but it's about 2 GB of data, and I'm on a slow connection, so it is really more of a "fly physically to server location and hook a copper Ethernet to the local network there" alternative. I'm reserving that as a sort of last ditch, nuclear option; I'd really rather understand what the problem is, for I fear it might happen again.
UPDATE
I've tried to delete remotely the subdirectory involved, committing the deletion on the server; deleting the subdirectory locally, and emptying the .svn/tmp subdirectory where I found sixteen tmp files, all copies of the one PNG causing problems.
I am still not able to perform any SVN subcommand, getting "Run cleanup!" error; on cleanup; I get a failed attempt to copy a tmpfile to the never-sufficiently-damned .PNG file, which no longer exists anywhere, into a directory that no longer exists anywhere.
I tried recreating the directory locally (but not the file!), no changes.
With FileMon, I traced the source PNG to 8e4c2389cf9d85c8b8ee54d49ea053c752a38187.svn-base in .svn/pristine subdirectory, tried removing it and got SVN complaining. I tried copying it to its intended destination (so that the file-as-it-should-be and the file-as-it-is are identical), no joy.
UPDATE
Well, this is weird. I decided to track everything that TortoiseSVN is doing using FileMon. I could see it checking the wc.db and search the item, checking for it in .svn/pristine (and finding it), copying it (unnecessarily if you ask me...) in .svn/tmp, and finally checking $DESTINATION_FILE (with correct case) using Windows Open() API. And getting PATH NOT FOUND. Yet the file is there, I can see it (and the name is less than 8.3 characters). And why PATH not found and not FILE not found?
Okay, it all boiled down to a directory that had been created remotely with a name ending with space. The file in itself was OK; the directory where it stood was not.
When updating, apparently, the directory got created but the name was shortened by Windows to exclude the final space.
To add to the difficulty of diagnosing, while TortoiseSVN did tell me what the problem was, it did so in the dialog box where the Arial font made the space in \path\to\your \file not clearly recognizable (it was, once I knew where to look, and compared that slash with the others. This one stood a little farther from the letter at its left).
Lesson learned: check really carefully the dialog file name, character by character (note to self: find a way of having it in Courier New if at all possible).
You may have two files in the repository that differ only in case. That's a problem on Windows. See this FAQ for details.

Vim plugin Align fails to work. Can it be installed without vimball?

I've happily installed the vim Align plugin on my home computer, but on the Red Hat servers at work, the installation doesn't work. The servers at work have a very old copy (2006) of vimball, which from Googling I know doesn't support more recent vimballs, including Align. I can't get the systems group (IT department) to upgrade vimball, so I thought perhaps I could simply copy the various files into ~/.vim/plugin by hand. I copied the 3 files from my home system AlignMapsPlugin.vim AlignPlugin.vim cecutil.vim, but when I attempt to use Align from within vim I get the following error message
E117: Unknown function: Align#Align
I know that it's seeing the plugin, because when I remove the plugin the error message is different (it says "Not an editor command Align").
Is there a workaround for this? I love "Align" and would sure like to use it at work as well as at home.
{rtp}/plugin is not the only location where plugin files can be placed. The name of the function suggests that there is at least one file in {rtp}/autoload named Align.vim (autoloaded functions must have names looking like path#to#file#with#function#without#leading#autoload#function_name(), this example is for function located in {rtp}/autoload/path/to/file/with/function/without/leading/autoload.vim). But I strongly suggest that if #LucHermitte’s solution is not acceptable, you should use something that supports holding plugins in separate directories. If you used VAM all you needed to do (assuming that you have already installed align using VAM) is to look for files in ~/.vim/vim-addons/Align%294 and copy all of them.
Update: Forgot to say, you may try to install newer vimball plugin into your ~/.vim. In order to do this you need copy a file placed in /usr/share/vim/vim73/autoload/vimball.vim to ~/.vim/autoload (there is another related file, /usr/share/vim/vim73/plugin/vimballPlugin.vim, but it is not likely to be changed). No need to make IT department to upgrade anything, unless the newest version uses the newest vim features.
Install a recent (/the latest) vim in your $HOME. I've been doing this for ages now. It's the easiest way to get the job done (i.e. to have a proper environment).

Cygwin/vim Windows 7 file access issue

It appears that on Windows 7 Cygwin/vim thinks all files are read only. You can edit the files fine in Textpad/Notepad but vim thinks they are read only. There are number of reported occurrences but I can't see a solution. ??
Update: Per accepted answer, created the file C:\cygwin\etc\fstab.d\myname with the entry below.
none /cygdrive cygdrive binary,posix=0,user 0 0,acl
Per the comment you'll see in C:\cygwin\etc\fstab, this statement is the default Cygwin mount, save for the acl which I added.
Cygwin tries to impose a POSIX compatibility layer over the windows access control lists, which often leads to many problems.
In older versions of Cygwin a cheap solution was to disable this POSIX compatibility layer by setting the environment variable "CYGWIN=ntsec". Nowadays it seems as one must set the "acl" option for your drive(s).
http://www.cygwin.com/cygwin-ug-net/using.html#mount-table
This has some drawbacks. If you try to run a secured cygwin installation for multiple users, then better use a real linux, this will save so much hassle.
I guess another solution would be to use the native version of Vim instead of the cygwin one.

Resources