I use the (byte-recompile-directory (expand-file-name "~/.emacs.d") 0) to generate .elc file ,it improve the emacs startup,but i wan to set byte-recompile-directory to use a cache folder not generate .elc files in same folder.and i want to know that do i need to declare emacs to use cache folder instead of el file？ Will emacs automatically load these ·.elc· files? like this
├── core
│ ├── core-keybinds.el
│ ├── core-provider.el
│ └── core.el
├── early-init.el
├── init.el
but when i use (byte-recompile-directory (expand-file-name "~/.emacs.d") 0)
├── core
│ ├── core-keybinds.el
│ ├── core-keybinds.elc
│ ├── core-provider.el
│ ├── core-provider.elc
│ └── core.el
│ ├── core.elc
├── early-init.el
|── early-init.elc
├── init.el
├── init.elc
maybe the best way like this
├── .cache
│ ├── core-keybinds.elc
│ ├── core-provider.elc
│ ├── core.elc
│ └── init.elc
│ └── early-init.elc
├── core
│ ├── core-keybinds.el
│ ├── core-provider.el
│ └── core.el
├── early-init.el
├── init.el
then how to let emacs to load these .elc files...i am new come to emacs.so need help.
You can set byte-compile-dest-file-function to a function that puts the files in the cache directory:
(defun my-bytecomp-dest-file (source)
(expand-file-name (file-name-nondirectory source) "~/.cache/"))
(setq byte-compile-dest-file-function 'my-bytecomp-dest-file)
You'll need to add the cache directory to the load path explicitly for the .elc files to be found:
(add-to-list 'load-path "~/.cache/")
Then you can load the files using e.g. (require 'core) or (load "core").
Related
I am trying to create a debian package for a postgreSQL extension Apache-age release 1.1.1 and created the directory structure using dh_make command.
The directory structure is as follows:
age-1.1.1 (project root)
├── debian
│ ├── changelog
│ ├── compat
│ ├── control
│ ├── docs
│ ├── examples
│ ├── links
│ ├── manpages
│ ├── menu
│ ├── postinst
│ ├── postrm
│ ├── preinst
│ ├── prerm
│ ├── rules
│ ├── source
│ └── watch
├── src
└── Makefile
The dpkg-buildpackage -b when run from project-root folder it looks for debian folder, then reads the rule file, then reads the Makefile located in the project root to build the package.
I want to change the directory structure to the following:
.project root
├── packaging
│ ├── debian
│ │ ├── control
│ │ ├── control.in
│ │ ├── changelog
│ │ ├── copyright
│ │ ├── pgversions
│ │ ├── rules
│ │ └── ...
│ └──
├── src
├── LICENSE
├── README.md
├── Makefile
└── ...
I want to change the directory structure so that the dpkg-buildpackage -b command can be run from the packaging folder and it should build the package.
Inside your Makefile
Modify the install paths accordingly. It should point to your packaging/debian/* where * is the filename.
This way the Makefile can point to the correct file path target inside the new folder structure.
I'm not sure if this is the best way to do this but it's working for me:
Here are the steps:
First run the dh_make_pgxs command from the project root directory.
Create a packaging directory in the project root and move the debian directory created in step 1 to this directory along with the Makefile, age.control and the age--1.1.1.sql.
Your file structure should look like this:
.project root
├── packaging
│ ├── debian
│ │ ├── control
│ │ ├── control.in
│ │ ├── changelog
│ │ ├── copyright
│ │ ├── pgversions
│ │ ├── rules
│ │ └── ...
│ ├── age--1.1.1.sql
│ ├── age.control
│ ├── Makefile
│ └── ...
├── src
├── LICENSE
├── README.md
└── ...
Change the file paths in the Makefile like:
src/backend/age.o should be ../src/backend/age.o.
./tools/ should be ./../tools/.
and so on.
Now you can simply run the dpkg-buildpackage -b command from the packaging directory to build the debian package.
Note: In step 1 we are running dh_make_pgxs in the project root first, this is to make sure that the project name in the control files and the version in the changelog file are correct. In this case the name/source in control, control.in & changelog files should be apache-age and the version number in changelog file should be 1.1.1-1.
Alternatively, you can run the command from the packaging directory and manually change the name and version in the control and changelog files.
When writing an Xcode extension, any commands you define automatically appear as one long list under Xcode's 'Editor/' menu.
For instance, if you define an extension called 'My First Xcode Extension' with eight commands, it appears like this...
Xcode
├── File Menu
├── Edit Menu
├── View Menu
├── Find Menu
├── Navigate Menu
└── Editor Menu
├── My First Xcode Extension <-- Your extension appears here
│ ├── Command1 <-- All your commands are listed here
│ ├── Command2
│ ├── Command3
│ ├── Command4
│ ├── Command5
│ ├── Command6
│ ├── Command7
│ └── Command8
└── Some Other Extension
├── CommandA
└── CommandB
However, some of the commands are related, so I want to group them, like this...
Xcode
├── File Menu
├── Edit Menu
├── View Menu
├── Find Menu
├── Navigate Menu
└── Editor Menu
├── My First Xcode Extension
│ ├── Command1
│ ├── Command2
│ ├── -------- <-- Need separator here
│ ├── Command3
│ ├── Command4
│ ├── Command5
│ ├── -------- <-- and here
│ ├── Command6
│ ├── Command7
│ └── Command8
└── Some Other Extension
├── CommandA
└── CommandB
Here's an example of what I'm after
class Extension: NSObject, XCSourceEditorExtension {
var commandDefinitions: [[XCSourceEditorCommandDefinitionKey:Any]] {
return [
[XCSourceEditorCommandDefinitionKey.classNameKey : String(reflecting:FirstCommandClass.self),
XCSourceEditorCommandDefinitionKey.identifierKey : "doSomething",
XCSourceEditorCommandDefinitionKey.nameKey : "Do something cool"],
[ // What goes here to create a separator...],
[XCSourceEditorCommandDefinitionKey.classNameKey : String(reflecting:SecondCommandClass.self),
XCSourceEditorCommandDefinitionKey.identifierKey : "doSomethingElse",
XCSourceEditorCommandDefinitionKey.nameKey : "Do something else just as cool"]
]
}
}
Is it possible to add a separator?
That’s not currently supported.
I have two SBT projects as outlined below.
├── Project 1
│ │
│ └── src
│ └── main
│ ├── scala
│ │ └── com
│ │ └── xyz
│ │ └── <*.scala>
│ └── resources
│ └── <Typesafe & Log4J config files>
│
│
└── Project 2
│
├── src
│ └── main
│ ├── scala
│ │ └── com
│ │ └── xyz
│ │ └── <*.scala>
│ └── resources
│ └── <Typesafe & Log4J config files>
│
├── resources
│ └── <JS, HTML, Image files etc.>
├── other-dir-1
│
├── other-dir-2
│
└── other-dir-3
Compiling Project 1 (actually running SBT exportedProducts task) produces the following directory structure. unmanagedResourceDirectories points to Project1/src/main/resources. I believe this is the default resourceDirectory (as mentioned in Customizing Paths). In other words, files in default resource directory are automatically added by exportedProducts
├── Project 1
└── target
└── scala-2.10
└── classes
├── com
│ └── xyz
│ └── <*.class>
└── <Typesafe & Log4J config files>
For Project 2, I want the following directory structure to be produced by exportedProducts.
├── Project 2
└── target
└── scala-2.10
└── classes
├── com
│ └── xyz
│ └── <*.class>
├── <Typesafe & Log4J config files>
│
└── resources
└── <JS, HTML, Image files etc.>
To do this I added the following to SBT build file in the appropriate project definition.
unmanagedResourceDirectories in Compile += baseDirectory.value
excludeFilter in unmanagedResources := HiddenFileFilter || "other-dir-*"
includeFilter in unmanagedResources :=
new SimpleFileFilter(_.getCanonicalPath.startsWith((baseDirectory.value / "resources").getCanonicalPath))
This correctly includes resources directory but doesn't include the files from Project2\src\main\resources. The target directory looks like the
├── Project 2
└── target
└── scala-2.10
└── classes
├── com
│ └── xyz
│ └── <*.class>
└── resources
└── <JS, HTML, Image files etc.>
Adding a custom resource directory in some way masks the content of the default resource directory. I tried something along the lines of what was mentioned in this SO post but wasn't successful.
The other thing that I tried was to set unmanagedResourceDirectories in Compile += baseDirectory.value / "resources" and remove both includeFilter and excludeFilter. This adds the files from Project2\src\main\resources correctly but adds the files & directories from Project2\resources directly to Project2\target\scala-2.10\classes. The target directory looks like the following
├── Project 2
└── target
└── scala-2.10
└── classes
├── com
│ └── xyz
│ └── <*.class>
├── <Typesafe & Log4J config files>
│
└── <JS, HTML, Image files etc.>
I want to create markdown with a directory tree listing automatically, in order to be shown in online repos like GitHub in every directory.
So, given that I'm going to use the Linux tree command that can be installed on MacOS X using brew install tree (see here for details), I came out with this solution:
tree --dirsfirst --noreport -I README.md > README.md;sed -i '' '1s/^/```/' README.md;echo \ >> README.md; sed -i '' -e '$s/$/```/' README.md
where the first sed -i '' '1s/^/```/' README.md is prepending the ``` chars – see Mastering (Github) Markdown for details about supported markdown.
The echo echo \ >> README.md; is adding a newline. Note here that I'm not using the sed equivalent sed -i '' -e '$a\' filename since this only adds a newline when it does not exists due to the $a pattern (see here).
While the last sed -i '' -e '$s/$/```/' README.md is adding a trailing ``` to the file.
The tree command tree --dirsfirst --noreport -I README.md is going to exclude some patterns, put directory first, ignore reporting file and dir count.
The result is going to be something like the following:
```.
├── bin
│ ├── Debug
│ │ ├── SampleLibrary.jar
│ │ ├── cooper.jar
│ │ ├── sugar.data.jar
│ │ ├── sugar.jar
│ │ └── swift.jar
│ └── Release
│ ├── SampleLibrary.jar
│ ├── cooper.jar
│ ├── sugar.data.jar
│ ├── sugar.jar
│ └── swift.jar
├── obj
│ ├── Debug
│ │ └── Android
│ │ ├── ClassLibrary2.elements.FilesWrittenAbsolute.txt
│ │ └── samplelibrary.jar
│ └── Release
│ └── Android
│ ├── ClassLibrary2.elements.FilesWrittenAbsolute.txt
│ └── samplelibrary.jar
├── ClassLibrary2.elements
└── ClassLibrary2.elements.user
```
You can see this markdown README.md here.
This solution is not so efficient and it is limited to -I pattern options of tree to filter out unwanted dirs (let's say build directories) or file names, etc. Also it does not work properly to update an existing README.md markdown.
The solution should work on MacOS X (where sed has some differences to that on Linux).
One way to get source code markup is to indent everything by four spaces:
tree --dirsfirst --noreport -I README.md | sed 's/^/ /' > README.md
To do it your way, adding a new first and last line with ``` on each, we can do
tree --dirsfirst --noreport -I README.md |
sed '1s/^/```'$'\n''/;$s/$/'$'\n''```/' > README.md
where inserting a newline in the replacement string is done with a C-style escape. Alternatively, we can use "$(printf '\n')":
tree --dirsfirst --noreport -I README.md |
sed '1s/^/```'"$(printf '\n')"'/;$s/$/'"$(printf '\n')"'```/' > README.md
These should both work with the sed on macOS.
With GNU sed, it would be a little simpler:
tree --dirsfirst --noreport -I README.md |
sed '1s/^/```\n/;$s/$/\n```/' > README.md
Have a look at this python module (I am the author).
It generats descriptive directory trees dynamically, and it has a markdown export format like the following:
.
├── example_folder\
│ ├── first_subfolder\ a documented folder
│ │ ├── sub-sub1\
│ │ │ └── file3.sh this is file 3
│ │ ├── sub-sub2\
│ │ │ └── file4.cpp this is file 4
│ │ └── random_file.rdm a documented file
│ ├── second_subfolder\ _a documented folder
│ ├── a_text_file.txt a text file
│ ├── my_javascript.js this is file 1
│ └── test.py a python script
└── README.md The main readme\
and an ASCII one of course
.
├── example_folder\
│ ├── first_subfolder\ (a documented folder)
│ │ ├── sub-sub1\
│ │ │ └── file3.sh (this is file 3)
│ │ ├── sub-sub2\
│ │ │ └── file4.cpp (this is file 4)
│ │ └── random_file.rdm (a documented file)
│ ├── second_subfolder\ (a documented folder with no documented files)
│ ├── a_text_file.txt (a text file)
│ ├── my_javascript.js (this is file 1)
│ └── test.py (a python script)
└── README.md (The main readme)
Create your markdown in VSCode and add Ascii Tree Generator extension from Marketplace.
Is there any de facto standard for the filesystem output layout of compiled CoffeeScript output?
Or: where should the .js and .map files end up?
I currently have a file watcher1 compiling the output to ./grounds/[whatever] to keep the source folder clean, so I end up with something like:
index.html
/js
├──foo.js
├──bar.js
/coffee
├──a.coffee
├──b.coffee
├──/grounds
│ ├──a.js
│ ├──a.map
│ ├──b.js
│ ├──b.map
├──/some-module
│ ├──c.coffee
│ ├──/grounds
│ │ ├──c.js
│ │ ├──c.map
Just curious if I missed the boat on some existing standard for the output file layout, or if folks generally just let them all be siblings in the same folder and are happy with that.
1: Pycharm
I don't think they is any standard, but for development, I use the same structure for the JS than for the coffee:
eg:
coffee
├── AdvancedStatsModule.coffee
├── board
│ ├── Board.coffee
│ ├── Card.coffee
├── controllers
│ ├── directives.coffee
│ ├── factory.coffee
│ ├── filters.coffee
│ ├── ListController.coffee
public/js
├── AdvancedStatsModule.js
├── board
│ ├── Board.js
│ ├── Card.js
├── controllers
│ ├── directives.js
│ ├── factory.js
│ ├── filters.js
│ ├── ListController.js
Advantages for this:
JS and coffee are not mixed
The coffee directory is not public
For production, I usually concat and minify my files anyway.
Update:
I use gulp for that. My Gulpfile:
var watch= require('gulp-watch');
var coffee= require('gulp-coffee');
gulp.src(paths.coffee)
.pipe(watch(function(files) {
return files.pipe(coffee())
.pipe(gulp.dest(paths.js));
}));