How to make Emacs 'man' work over Tramp? - unix

I have a question regarding the use of M-x man in Emacs. I'm working with Tramp all the time and often the installed program base on the remote server differs significantly from my local setup. I see that invoking M-x man involves looking for the relevant manpages on the local machine. Is there a way to instruct it to use the environment on the other side of Tramp?
I know there's an Elisp variable tramp-remote-process-environment and I've tried adding an entry for MANPATH to it, but it doesn't seem to work (I'm afraid it's because I put it in the form /usr/share/man instead of /scpc:user#host:/usr/share/man but what I want is a generic solution to work on all remote hosts). Any ideas?

From the Man-start-calling macro in man.el:
(let (...
(default-directory
(if (and (file-directory-p default-directory)
(not (find-file-name-handler default-directory
'file-directory-p)))
default-directory
"/"))
That is, if there is a special file name handler for the current default directory, such as Tramp, it will use the root directory as the directory to start man from, and thus it will see man pages from the system that Emacs is running on.
There doesn't seem to be a way to disable this apart from changing man.el. Note that this is a macro, so you need to reload the macro and all the functions that use the macro.

From docstring of command man would expect it's able to read remote pages:
An explicit filename can be given too. Use -l if it might
otherwise look like a page name.
/my/file/name.1.gz
-l somefile.1
You may write a caller, which reads the environment and composes the needed argument.

Related

How to make Julia verbose at interpreter startup?

Like python -d (debug/verbose) spews lots of information at interpreter startup, how can I achieve something similar with Julia? (My specific problem is to find out why, when called from python (pyjulia), Julia 0.6dev can't load boot.jl).
There is no verbose startup mode. You can, however, run julia and/or the python process loading libjulia under gdb. Just spitballing, not being able to find boot.jl sounds like a path problem. I'm also somewhat surprised that libjulia would be trying to find or load boot.jl in the first place, since that file and many others are usually baked into a system image file with a .ji extension (sys.ji previously and inference.ji more recently).

Moving a buffer in vim across instances of vim

Is this possible to do?
Conceptually, a solution should apply across a lot of possible configurations, ranging from two vim instances running in separate virtual terminals in panes in a tmux window, to being in separate terminals on separate machines in separate geographical regions, one or both connected over network (in other words, the vims are hosted by two separate shell processes, which they would already be under tmux anyhow).
The case that prompted me to ponder this:
I have two tmux panels both with vim open and I want to use the Vim yank/paste to copy across the files.
But it only works if I've got them both running in the same instance of Vim, so I am forced to either:
use tmux's copy/paste feature to get the content over (which is somewhat tedious and finicky), or
use the terminal (PuTTY, iTerm2)'s copy/paste feature to get the content over (which is similarly tedious but not subject to network latency, however this only works up to a certain size of text payload to copy at which point this method will not work at all due to the terminal not knowing the contents of the not-currently-visible parts of the file), or
lose Vim buffer history/context and possibly shell history/context in reopening the file manually in one of the Vim instances in either a split buffer or tab and then closing the other terminal context (much less tedious than 1 for large payloads but more so with small payloads).
This is a bit of a PITA and could all be avoided if I have the foresight of switching to an appropriate terminal already running vim to open my files but the destiny of workflow and habit rarely match up with that which would have been convenient.
So the question is, does there exist a command or the possibility of a straighforwardly-constructed (shell) script that allows me to join buffers across independently running vim instances? Am having a hard time getting Google to answer that adequately.
In the absence of an adequate answer (or if it is determined with reasonable certainty that Vim does not possess the features to accomplish the transfer of buffers across its instances), a good implementation (bindable to keys) for approach 3 above is acceptable.
Meanwhile I'll go back to customizing my vim config further and forcing myself to use as few instances of vim as possible.
No, Vim can't share a session between multiple instances. This is how it's designed and it doesn't provide any session-sharing facility. Registers, on-the-fly mappings/settings, command history, etc. are local to a Vim session and you can't realistically do anything about that.
But your title is a bit misleading: you wrote "buffer" but it looks like you are only after copying/pasting (which involves "register", not "buffers") from one Vim instance to another. Is that right? If so, why don't you simply get yourself a proper build with clipboard support?
Copying/yanking across instances is as easy as "+y in one and "+p in another.
Obviously, this won't work if your Vim instances are on different systems. In such a situation, "+y in the source Vim and system-provided paste in the destination Vim (possibly with :set paste) is the most common solution.
If you are on a Mac, install MacVim and move the accompanying mvim shell script somewhere in your path. You can use the MacVim executable in your terminal with mvim -v.
If you are on Linux, install the vim-gnome package from your package manager.
If you are on Windows, install the latest "Vim without Cream".
But the whole thing looks like an XY problem to me. Using Vim's built-in :e[dit] command efficiently is probably the best solution to what appears to be your underlying problem: editing many files from many different shells.

XCode open file at error line for custom build script

I Apologize if this question has already been asked. i can't seem to find it anywhere if it has.
I have a custom build script use to syntax check some php files and upload them to a server, and this is executed as a part of the build process. since this script is used to parse inline php statements (embedded in objective c blocks using macros) it's fairly critical this script happens on each build. the actual execution is working fine, i'd just also like to be able to open a particular file when there is an error, and locate the cursor in the approximate location.
i have found that since xcode is configured on my system to open .php files by default (not sure if that's the norm or if i did it manually at some point), using
open filename.php
in a shell script opens the file.
i'd like to be able to specify the line number too.
eg something along the lines of
open filename.php --args --jump-to-line 1234
(--args is a switch for "open" meaning pass the arguments on to Xcode)
any ideas?
You can use the xed command. Only works for Xcode 3 though, not other editors. For Xcode 4, try this
See man xed

set environment variables for system() in R?

I've been using R in Ubuntu to make system calls using system() for things like spinning up Amazon EC2 instances, managing files on S3, etc. If I start R from the command line everything works fine. But if I start R from a script using Rscript, or from ESS, I have issues with environment variables not being set.
I think this is an issue with me not properly grokking where to set environment variables in Ubuntu. I thought the "right place" (for some definition of "right") was to set user environment variables in ~/.bashrc. This is where I set things like export EC2_HOME=/home/jd/ec2 but when I execute R from ESS and make system calls, the .bashrc script is not being run. I've tried Googing about and I see many an exegesis on environment variables in Ubuntu, such as this one. My knee jerk reaction is to try each recommendation in the aforementioned thread and stop giving a shit as soon as one of the options works. But then I end up with non-standard settings which bite me in the ass later.
So how should I set environment variables so that they are properly set when I run a system() call in R?
You can try to set them in R itself using Sys.setenv.
I think you are confusing the issue. I fear this may be about login shells versus non-login shells. See the bash manual page for the fine print ... which has driven me bonkers in the past.
That said, if you can set environment variables system-wide, you have a few options:
/etc/environment is a very good place as it is shell-agnostic should you ever use a different shell
for login versus non-login shells, the one way to get complete control that I found suitable was to put my changes into something like ~/.local_bashrc
the add . ~/.local_bashrc from and and all of
~./bashrc
~/.bash_profile
~/.profile`
etc pp.
You can precede the sourcing with a echo Hello from FILE where you replace FILE with the name of the file. That shows you the difference between shells starting from login (eg via gdm et al), via ssh connection, via new xterm etc terminals and so on.
You can force the system to read your .bashrc file by using the source command
source ~/.bashrc
Lots of inelegant and ugly ways to apply this

How to change the default behavior of the [TAB] key while calling an application from the shell?

The default behavior for the [TAB] key in the shell is to automatically auto-complete or list the files in the current directory. How to override this behavior in the shell for some chosen applications?
Edit: This is not related to the application that is being used, rather, it's the shell environment that needs to be customized! (Thanks to Anders Abel for clearing this point)
If you want to change the behaviour when creating the command line for starting the program, that's impossible from within the program. At that point your program is not yet started, so it's entirely up to the shell how to interpret [TAB] at that point.
Once your program is running you can of course handle [TAB] in whatever way you want, by using an appropriate API call.

Resources