Modify mode-compile.el to handle MS-Windows paths with imbedded blanks? - windows

Can anyone suggest a modification of mode-compile.el that will make it work better on Windows? My specific issue is handling of path names that contain blanks. I'm working on code in Ruby, using "GNU Emacs 22.2.1 (i386-mingw-nt5.1.2600) of 2008-03-26 on RELEASE" with mode-compile.el version: 2.29 (Last modified: 2006/12/01 13:52:47)
The command line generated by mode-compile.el to compile (run) my buffer a.rb is this:
c:/ruby/bin\ruby.exe -w c:/Documents and Settings/William/My Documents/src/a.rb
Which generates this error:
c:/ruby/bin\ruby.exe: No such file or directory -- c:/Documents (LoadError)
This works just fine:
c:/ruby/bin\ruby.exe -w "c:/Documents and Settings/William/My Documents/src/a.rb"
As a work-around, I can just move my directory tree so that the path has no embedded blanks. Looking at the code in mode-compile.el, it APPEARS that a function exists already to add the quotes, however, as I am NOT proficient in emacs-lisp, perhaps this actually does something entirely different (like just appending a nearly-empty par of double quote marks):
(if to-compile-fname
(if mc--build-op-args
(mc--build-output-args to-compile-fname)
(concat " " to-compile-fname)
)
" "))))
mode-compile.el comes from here:
http://perso.tls.cena.fr/boubaker/distrib/mode-compile.el
Thanks in advance!
William

I don't have time to test this really, but it appears to me that the function mc--shell-compile needs to be updated. The filename of the buffer is extracted by the following lines:
(shfile (or mc--remote-pathname (buffer-file-name)
(error "Compilation abort: Buffer %s has no filename"
(buffer-name))))
the fix should be to quote the buffer-file-name:
(shfile (or mc--remote-pathname (shell-quote-argument buffer-file-name)
(error "Compilation abort: Buffer %s has no filename"
(buffer-name))))
Can you have a try and report, please?
Cheers,
Daniel

Related

Bash: What does "file < FILE > FILE.extension &" means?

I was running AutoPhrase and after running it's auto_phrase.sh shell script, I am getting the following error:
After backtracing it's source, I found this line (line 32) which is causing the above mentioned error.
All I know is it is doing something like:
file < FILE > FILE.extension
However, I failed to understand what is happening in this line.
Can someone could explain it to me ? And how may I resolve this issue ?
The problem here seems to be that ./bin/tree-tagger does not exist. Note that ./bin is not the same as /bin.
That being said, the answer to your question of what file < FILE > FILE.extension does is unrelated, but these are redirects in bash. FILE is piped < into the $STDIN of file and the output is directed > to the file FILE.extension.
Locate ./bin/tree-tagger by installing it or redirecting its path appropriately to resolve the error.
As for the actual question in the title, the command means
./cmd/tree-tagger-english run this command ...
< ... with standard input from ...
$f ... an (incorrectly unquoted) variable which should contain a file name ...
> ... with standard output redirected to ...
$f.tagged ... a file named by the (still incorrectly unquoted) value of $f with the string .tagged appended at the end ...
& ... as a background job.
Apparently ./cmd/tree-tagger-english in turn attempts to execute a command which doesn't exist, many times.
Probably the instructions tell you to run the thing in a different directory than where you are actually running this; but this is obviously merely a speculation. Another fairly common scenario is that something failed during installation, but you failed to notice (and so some files which should exist in these locations do not actually exist ... disk full? Wrong permissions?)
The fact that the code contains quoting bugs suggests that it's also quite possible that the code is simply buggy.

Run emacs lisp script

I found the script and i need run it.
I tried to run it like this (i used eval-buffer command):
(require 'subr-x)
(require 's)
(load-file "~/git-graph.el")
(require 'git-graph)
(git-graph/to-graphviz-pretty
"git"
(git-graph/git-graph-head
"E:/GitStack/repositories/gitRepo.git"
"master"))
But get an error:
Loading e:/emHome/git-graph.el (source)...done
let*: Symbol’s function definition is void: first
picture
Please tell me what is wrong. And how i can run this script?
I'm new to this.
Why are you loading library git-graph twice?
What happens if you just remove either the load-library line or the require line -- do you still get an error?
With your original code, insert this line after the load-library line:
(message "After load-library")
And insert this line after the require line:
(message "After require")
See which message(s) you get: check buffer *Messages*. That should tell you which attempt to load the library (if either) led to the error. Maybe look for the text first in the library, to see if you notice anything funny.
If it doesn't look like the problem comes from loading that library then it likely comes from the expression after your require.
Do M-x toggle-debug-on-error, then do your M-x eval-buffer, and post the *Backtrace* output here. That will show us just where the error is raised.
You can also try M-x debug-on-entry git-graph/to-graphviz-pretty and step through the debugger using d (or c to skip details of a given step). That will eventually show you which code raised the error.

How to debug `Error while processing function` in `vim` and `nvim`?

TL;DR
How to find where exactly vim or nvim error started (which file?) when I'm interested in fixing the actual issue and not just removing the bad plugin? Anything better than strace and guesswork to find the error origin?
Issue
I often add a plugin to my vim or nvim config and end up getting errors on hooks (buffer open, close, write):
"test.py" [New] 0L, 0C written
Error detected while processing function 343[12]..272:
line 8:
E716: Key not present in Dictionary: _exec
E116: Invalid arguments for function get(a:args, 'exec', a:1['_exec'])
E15: Invalid expression: get(a:args, 'exec', a:1['_exec'])
The problem is, I have no idea where those come from, only get some line number of unknown file and I know it's not my vim/nvim config file.
Somewhere, you have a plugin that has defined a dictionary with anonymous-functions (check the help related to this tag).
For the curious ones, it's done this way:
let d = {}
function! d.whatever() abort
throw "blah"
endfunction
When you execute this function, you'll get the kind of error you're currently observing. That's why I stopped working this way to prefer:
let d = {}
function s:whatever() abort
throw "blah"
endfunction
let d.whatever = function('s:whatever') " a workaround is required for older versions of vim
" At least this way I'll get a `<SNR>42_whatever` in the exception throwpoint, and thus a scriptname.
That's the why. Now, back to your problem, AFAIK, the only things you'll be able to know are the two functions that have been called:
in line 12 of :function {343}, you've called
:function {272} which contains an error at line 8.
Thanks to these two commands (may be prefixed with :verbose, I don't remember exactly), you'll get the source code of the two functions, which you should be able to use in order to grep your plugins to know where it appears.

bash: wrong behavior in for... loop together with a test statement

I am trying to test if certain files, called up in a list of textfiles, are in a certain directory. Every once in a while (and I am quite certain I use the same statements every time) I get an error, complaining that the echo command cannot be found.
The textfiles I have in my directory /audio/playlists/ are named according to their date on which they are supposed to be used: 20130715.txt for example for today:
me#computer:/some/dir# ls /audio/playlists/
20130715.txt 20130802.txt 20130820.txt 20130907.txt 20130925.txt
20130716.txt 20130803.txt 20130821.txt 20130908.txt 20130926.txt
(...)
me#computer:/some/dir# cat /audio/playlists/20130715.txt
#A Comment line goes here
00:00:00 141-751.mp3
00:03:35 141-704.mp3
00:06:42 140-417.mp3
00:10:46 139-808.mp3
00:15:13 136-126.mp3
00:20:26 071-007.mp3
(...)
23:42:22 136-088.mp3
23:46:15 128-466.mp3
23:50:15 129-592.mp3
23:54:29 129-397.mp3
So much for the facts. The following statement, which lets me test if all files called upon in all of the textfiles in the given directory are actually a file in the directory /audio/mp3/, produces an error:
me#computer:/some/dir# for i in $(cat /audio/playlists/*.txt|cut -c 10-16|sort|uniq); do [ -f "/audio/mp3s/$i.mp3" ] || echo $i; done
 echo: command not found
me#computer:/some/dir#
I would guess bash wants to complain about the "A Comment"-line (actually " line ") not being a file, but why would that cause echo not to be found? Again, mostly this works, but every so often I get this error. Any help is greatly appreciated.
That space before echo isn't U+0020, it's U+00A0. And indeed, the command " echo" doesn't exist.

Why is LUA_PATH containing a bang (!) mangled on Windows?

I have a file main.lua:
require("hello")
and a file hello.lua in the directory foo bar! baz (with !) in it:
module(...,package.seeall)
print("hello from hello.lua")
when I set (on Windows) the environment variable LUA_PATH to the directory:
set LUA_PATH="C:\Programme\Lua\5.1\foo bar! baz\?.lua"
I get a strange error:
C:\Programme\Lua\5.1>lua main.lua
lua: main.lua:4: module 'hello' not found:
no field package.preload['hello']
no file '"C:\Programme\Lua\5.1\foo barC:\Programme\Lua\5.1 baz\hello.lua
"'
no file '.\hello.dll'
no file '.\hello51.dll'
no file 'C:\Programme\Lua\5.1\hello.dll'
no file 'C:\Programme\Lua\5.1\hello51.dll'
no file 'C:\Programme\Lua\5.1\clibs\hello.dll'
no file 'C:\Programme\Lua\5.1\clibs\hello51.dll'
no file 'C:\Programme\Lua\5.1\loadall.dll'
no file 'C:\Programme\Lua\5.1\clibs\loadall.dll'
stack traceback:
[C]: in function 'require'
main.lua:4: in main chunk
[C]: ?
See the very strange path C:\Programme\Lua\5.1\foo barC:\Programme\Lua\5.1 baz\hello.lua? What is so special about the exclamation mark (bang)? How to get that right in windows? On Mac this seems to be working fine.
"This substitution only happens the first time Lua sets the path
(either from LUA_PATH or from the default from luaconf). If you
set the path by other means, you can avoid the problem."
More info and potential alternatives: http://lua-users.org/lists/lua-l/2012-08/msg00052.html
The explanation is correct (it's documented behavior on Windows), but I can also offer a possible solution (or rather a workaround): since only the first exclamation mark is going to be replaced, instead of using set LUA_PATH="C:\Programme\Lua\5.1\foo bar! baz\?.lua", use:
set LUA_PATH="!\foo bar! baz\?.lua"

Resources