I'm looking for a project management system for Emacs

I'm looking for a project management system for Emacs

[Marcin Borkowski]

Hello all,

as stated in the subject line, I'm looking for a project management
system in Emacs.  Since there are quite a few of them, I thought I
could ask here.  I don't have /strict/ requirements, but rather a few
problems I'd like that system to address, and a few features I'd
probably need.

1. When I have many files open, switching to another buffer is a bit
cumbersome, even when using Ido.  I'd like that system to have
something like "ido-switch-buffer-within-project".

2. Files of the project might not be located in one folder (so
e.g. Projectile probably won't work for me).  Rationale: there may be
a few files somehere down the ~/Documents hierarchy and /one/ file in
~/org.  On the other hand, I'd like to be able to specify that "this
file and all files in that directory belong to this project", without
manually listing all the files in "that directory".  It would then be
best if adding a file into the specified directory (or tree) would add
it /automatically/ to the project.

3. One file may belong to more than one project.  Rationale: see above.

4. It would be great if I could mark some /global/ variables
project-dependent, i.e., each variable would have its "project
instance", and switching between projects would mean changing its
value accordingly.  (It would probably also need some kind of
persistence, too.)  Rationale: org-clock-history;).

5. Of course, I'd like to be able to visit/kill all files/buffers
related to the project with one command.  Also, adding a project (and
a file/files to an existing project) should be possible in some
interactive way (though using some Elisp variable for that might be
acceptable).

6. On the other hand, window configuration management is not a must
for me - currently I work 98% of the time on a small netbook and
usually have only one window open anyway.  I'm planning to use a
larger monitor in some time, though, so while not necessary, this
would be a nice bonus.

Is there anything in existence that would help me?  Are there any
potentially useful features I did not think of that people find
useful?

TIA,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: I'm looking for a project management system for Emacs

[Thorsten Jolitz]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> Is there anything in existence that would help me?  Are there any
> potentially useful features I did not think of that people find
> useful?

This might be useful for you:

,----------------------------------------
| http://www.emacswiki.org/emacs/FileSets
`----------------------------------------

I discovered it when I wanted to call an elisp function on a group of
selected files just like I would call a shell command on marked files in
dired. 

-- 
cheers,
Thorsten

Re: I'm looking for a project management system for Emacs

[Marcin Borkowski]

Dnia 2014-03-29, o godz. 10:35:08
Thorsten Jolitz <tjolitz@gmail.com> napisał(a):

> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
> 
> > Is there anything in existence that would help me?  Are there any
> > potentially useful features I did not think of that people find
> > useful?
> 
> This might be useful for you:
> 
> ,----------------------------------------
> | http://www.emacswiki.org/emacs/FileSets
> `----------------------------------------
> 
> I discovered it when I wanted to call an elisp function on a group of
> selected files just like I would call a shell command on marked files
> in dired. 

Thanks for this link, I didn't know about it.  (I guess it was added
to Emacs too recently for me to catch it while reading all the manual,
which I did more than 10 years ago;)...)

However, this is not exactly what I meant.  Still, potentially useful,
so thanks again!

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

RE: I'm looking for a project management system for Emacs

[Drew Adams]

> I'm looking for a project management system in Emacs...
> 
> 1. When I have many files open, switching to another buffer is a bit
> cumbersome, even when using Ido.  I'd like that system to have
> something like "ido-switch-buffer-within-project".
> 
> 2. Files of the project might not be located in one folder (so
> e.g. Projectile probably won't work for me).  Rationale: there may be
> a few files somehere down the ~/Documents hierarchy and /one/ file in
> ~/org.  On the other hand, I'd like to be able to specify that "this
> file and all files in that directory belong to this project", without
> manually listing all the files in "that directory".  It would then be
> best if adding a file into the specified directory (or tree) would add
> it /automatically/ to the project.
> 
> 3. One file may belong to more than one project.  Rationale: see above.
> 
> 4. It would be great if I could mark some /global/ variables
> project-dependent, i.e., each variable would have its "project
> instance", and switching between projects would mean changing its
> value accordingly.  (It would probably also need some kind of
> persistence, too.)  Rationale: org-clock-history;).
> 
> 5. Of course, I'd like to be able to visit/kill all files/buffers
> related to the project with one command.  Also, adding a project (and
> a file/files to an existing project) should be possible in some
> interactive way (though using some Elisp variable for that might be
> acceptable).
> 
> 6. On the other hand, window configuration management is not a must
> for me - currently I work 98% of the time on a small netbook and
> usually have only one window open anyway.  I'm planning to use a
> larger monitor in some time, though, so while not necessary, this
> would be a nice bonus.
> 
> Is there anything in existence that would help me?  Are there any
> potentially useful features I did not think of that people find
> useful?

Icicles offers several features that you can use in various ways to
support various definitions of projects and project management.
This page is a good starting point to info about some of these.  It
also points to info about using Dired and Emacs bookmarks for
project definition and management.

http://www.emacswiki.org/emacs/Icicles_-_Support_for_Projects

Others will perhaps provide info about all-in-one predefined
approaches.  Icicles, Bookmark+, and Dired+ offer instead a
toolbox of features that you can put to use as you like.

See also the EmacsWiki CategoryProject page, which is a table of
contents for the wiki pages about project-mgt support.  It is a
good starting place when thinking about defining projects and
your own project-management system:

http://www.emacswiki.org/emacs/CategoryProject

Re: I'm looking for a project management system for Emacs

[Marcin Borkowski]

Dnia 2014-03-29, o godz. 08:22:55
Drew Adams <drew.adams@oracle.com> napisał(a):

> > I'm looking for a project management system in Emacs...
> Icicles offers several features that you can use in various ways to
> support various definitions of projects and project management.
> This page is a good starting point to info about some of these.  It
> also points to info about using Dired and Emacs bookmarks for
> project definition and management.
> 
> http://www.emacswiki.org/emacs/Icicles_-_Support_for_Projects

Thanks!  From a quick glance I can see that Icicles is (are?)
incompatible with Ido.  I'd like to ask "which is better", but this is
probably not a good idea;), so let me ask: are there any people here
who switched from Ido to Icicles?  If yes, why?  (I've been using Ido
for only a few months now, but I find it indispensable.  OTOH, I
probably use only a small fraction of its features.  And it is well
possible that Icicles will give me all I need from Ido.)

> Others will perhaps provide info about all-in-one predefined
> approaches.  Icicles, Bookmark+, and Dired+ offer instead a
> toolbox of features that you can put to use as you like.

A toolbox of features to combine into a tailor-made solution is fine
for me.  Especially that my requirements might not be exactly common
(especially the scattering of the "project" files around many
directories).

> See also the EmacsWiki CategoryProject page, which is a table of
> contents for the wiki pages about project-mgt support.  It is a
> good starting place when thinking about defining projects and
> your own project-management system:
> 
> http://www.emacswiki.org/emacs/CategoryProject

I've seen that page, and that's why I wrote here: I hoped for a
positive number of answers taking into account /my/ requirements;).

Regards,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: I'm looking for a project management system for Emacs

[Jai Dayal]

Helm and flx are somethings I've been using to find files both in my
project and outside my project. They have great incremental fuzzy search.

I want to find main.cpp in project "project1"?

C-x C-f project1 main.cpp // it then lets me complete ~/project1/main.cpp

I want to find main.cpp in project "project2"?

C-x C-f project2 main.cpp // it then lets me complete ~/project2/main.cpp


It might take a second to work its way up the directory tree relative to
where you are, but helm and flx are great.


On Sat, Mar 29, 2014 at 2:21 PM, Marcin Borkowski <mbork@wmi.amu.edu.pl>wrote:

> Dnia 2014-03-29, o godz. 08:22:55
> Drew Adams <drew.adams@oracle.com> napisał(a):
>
> > > I'm looking for a project management system in Emacs...
> > Icicles offers several features that you can use in various ways to
> > support various definitions of projects and project management.
> > This page is a good starting point to info about some of these.  It
> > also points to info about using Dired and Emacs bookmarks for
> > project definition and management.
> >
> > http://www.emacswiki.org/emacs/Icicles_-_Support_for_Projects
>
> Thanks!  From a quick glance I can see that Icicles is (are?)
> incompatible with Ido.  I'd like to ask "which is better", but this is
> probably not a good idea;), so let me ask: are there any people here
> who switched from Ido to Icicles?  If yes, why?  (I've been using Ido
> for only a few months now, but I find it indispensable.  OTOH, I
> probably use only a small fraction of its features.  And it is well
> possible that Icicles will give me all I need from Ido.)
>
> > Others will perhaps provide info about all-in-one predefined
> > approaches.  Icicles, Bookmark+, and Dired+ offer instead a
> > toolbox of features that you can put to use as you like.
>
> A toolbox of features to combine into a tailor-made solution is fine
> for me.  Especially that my requirements might not be exactly common
> (especially the scattering of the "project" files around many
> directories).
>
> > See also the EmacsWiki CategoryProject page, which is a table of
> > contents for the wiki pages about project-mgt support.  It is a
> > good starting place when thinking about defining projects and
> > your own project-management system:
> >
> > http://www.emacswiki.org/emacs/CategoryProject
>
> I've seen that page, and that's why I wrote here: I hoped for a
> positive number of answers taking into account /my/ requirements;).
>
> Regards,
>
> --
> Marcin Borkowski
> http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
> Adam Mickiewicz University
>
>

RE: I'm looking for a project management system for Emacs

[Drew Adams]

> Thanks!  From a quick glance I can see that Icicles is (are?)
> incompatible with Ido.

See this page:
http://www.emacswiki.org/emacs/Icicles_-_Ido_and_IswitchB

Re: I'm looking for a project management system for Emacs

[lee]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> A toolbox of features to combine into a tailor-made solution is fine
> for me.  Especially that my requirements might not be exactly common
> (especially the scattering of the "project" files around many
> directories).

Multisearch might help you:

https://github.com/lee-/emacs/tree/master/multisearch


You can use an index file with it to specify various files to work with,
in this case to search them.  Searching is only one possible
application.  Multisearch has some powerful functions to create lists of
relevant files which may be useful for your purpose.  It remembers the
buffers it created, allowing you to kill them all when they are no
longer needed.


-- 
Knowledge is volatile and fluid.  Software is power.

Re: I'm looking for a project management system for Emacs

[Jude DaShiell]

Org-mode may be another possibility, http://www.org-mode.org/.  It's 
already built into emacs 24.3 and info org- will show you its 
documentation.

On Wed, 2 Apr 2014, lee wrote:

> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
> 
> > A toolbox of features to combine into a tailor-made solution is fine
> > for me.  Especially that my requirements might not be exactly common
> > (especially the scattering of the "project" files around many
> > directories).
> 
> Multisearch might help you:
> 
> https://github.com/lee-/emacs/tree/master/multisearch
> 
> 
> You can use an index file with it to specify various files to work with,
> in this case to search them.  Searching is only one possible
> application.  Multisearch has some powerful functions to create lists of
> relevant files which may be useful for your purpose.  It remembers the
> buffers it created, allowing you to kill them all when they are no
> longer needed.
> 
> 
> 

jude <jdashiel@shellworld.net>

Re: I'm looking for a project management system for Emacs

[Robert Thorpe]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> A toolbox of features to combine into a tailor-made solution is fine
> for me.  Especially that my requirements might not be exactly common
> (especially the scattering of the "project" files around many
> directories).

You could write some simple functions like this:

(defun project1 ()
  (interactive)
  (find-file "project1/*" t)
  (find-file "elsewhere/randomfile.txt")
  (find-file "..."))

(defun project2 ()
  (interactive)
  (find-file "project2/*" t)
  (find-file "project1/foo.txt"))

find-file can be used with wildcards, even in lisp programs.

BR,
Robert Thorpe

Re: I'm looking for a project management system for Emacs

[Alex Bennée]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
>
>> A toolbox of features to combine into a tailor-made solution is fine
>> for me.  Especially that my requirements might not be exactly common
>> (especially the scattering of the "project" files around many
>> directories).
>
> You could write some simple functions like this:
>
> (defun project1 ()
>   (interactive)
>   (find-file "project1/*" t)
>   (find-file "elsewhere/randomfile.txt")
>   (find-file "..."))
>
> (defun project2 ()
>   (interactive)
>   (find-file "project2/*" t)
>   (find-file "project1/foo.txt"))
>
<snip>


That's sort of the approach eproject takes. You define a generic project
template and then it can apply the same rules to any instance of that
project. e.g:

;; QEMU
(define-project-type qemu
  (generic-git)
  (look-for "qemu-log.c")
  :c-style "qemu-c-style")

(add-hook 'qemu-project-file-visit-hook 'my-eproj-is-c)
(add-hook 'qemu-project-file-visit-hook 'whitespace-mode)

-- 
Alex Bennée

Re: I'm looking for a project management system for Emacs

[Renato]

Some times ago, emacs has a strict collaboration with Taskjuggler, that 
is (i think) a very usefull and complet project management sw. there 
were some add that made TJ code auto colored, indented and so on.

Renato

On 29/03/2014 16:22, Drew Adams wrote:
>> I'm looking for a project management system in Emacs...
>>
>> 1. When I have many files open, switching to another buffer is a bit
>> cumbersome, even when using Ido.  I'd like that system to have
>> something like "ido-switch-buffer-within-project".
>>
>> 2. Files of the project might not be located in one folder (so
>> e.g. Projectile probably won't work for me).  Rationale: there may be
>> a few files somehere down the ~/Documents hierarchy and /one/ file in
>> ~/org.  On the other hand, I'd like to be able to specify that "this
>> file and all files in that directory belong to this project", without
>> manually listing all the files in "that directory".  It would then be
>> best if adding a file into the specified directory (or tree) would add
>> it /automatically/ to the project.
>>
>> 3. One file may belong to more than one project.  Rationale: see above.
>>
>> 4. It would be great if I could mark some /global/ variables
>> project-dependent, i.e., each variable would have its "project
>> instance", and switching between projects would mean changing its
>> value accordingly.  (It would probably also need some kind of
>> persistence, too.)  Rationale: org-clock-history;).
>>
>> 5. Of course, I'd like to be able to visit/kill all files/buffers
>> related to the project with one command.  Also, adding a project (and
>> a file/files to an existing project) should be possible in some
>> interactive way (though using some Elisp variable for that might be
>> acceptable).
>>
>> 6. On the other hand, window configuration management is not a must
>> for me - currently I work 98% of the time on a small netbook and
>> usually have only one window open anyway.  I'm planning to use a
>> larger monitor in some time, though, so while not necessary, this
>> would be a nice bonus.
>>
>> Is there anything in existence that would help me?  Are there any
>> potentially useful features I did not think of that people find
>> useful?
> Icicles offers several features that you can use in various ways to
> support various definitions of projects and project management.
> This page is a good starting point to info about some of these.  It
> also points to info about using Dired and Emacs bookmarks for
> project definition and management.
>
> http://www.emacswiki.org/emacs/Icicles_-_Support_for_Projects
>
> Others will perhaps provide info about all-in-one predefined
> approaches.  Icicles, Bookmark+, and Dired+ offer instead a
> toolbox of features that you can put to use as you like.
>
> See also the EmacsWiki CategoryProject page, which is a table of
> contents for the wiki pages about project-mgt support.  It is a
> good starting place when thinking about defining projects and
> your own project-management system:
>
> http://www.emacswiki.org/emacs/CategoryProject
>

Re: I'm looking for a project management system for Emacs

[Dan.Espen]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> Hello all,
>
> as stated in the subject line, I'm looking for a project management
> system in Emacs.  Since there are quite a few of them, I thought I
> could ask here.  I don't have /strict/ requirements, but rather a few
> problems I'd like that system to address, and a few features I'd
> probably need.
>
> 1. When I have many files open, switching to another buffer is a bit
> cumbersome, even when using Ido.  I'd like that system to have
> something like "ido-switch-buffer-within-project".
>
> 2. Files of the project might not be located in one folder (so
> e.g. Projectile probably won't work for me).  Rationale: there may be
> a few files somehere down the ~/Documents hierarchy and /one/ file in
> ~/org.  On the other hand, I'd like to be able to specify that "this
> file and all files in that directory belong to this project", without
> manually listing all the files in "that directory".  It would then be
> best if adding a file into the specified directory (or tree) would add
> it /automatically/ to the project.
>
> 3. One file may belong to more than one project.  Rationale: see above.
>
> 4. It would be great if I could mark some /global/ variables
> project-dependent, i.e., each variable would have its "project
> instance", and switching between projects would mean changing its
> value accordingly.  (It would probably also need some kind of
> persistence, too.)  Rationale: org-clock-history;).
>
> 5. Of course, I'd like to be able to visit/kill all files/buffers
> related to the project with one command.  Also, adding a project (and
> a file/files to an existing project) should be possible in some
> interactive way (though using some Elisp variable for that might be
> acceptable).
>
> 6. On the other hand, window configuration management is not a must
> for me - currently I work 98% of the time on a small netbook and
> usually have only one window open anyway.  I'm planning to use a
> larger monitor in some time, though, so while not necessary, this
> would be a nice bonus.
>
> Is there anything in existence that would help me?  Are there any
> potentially useful features I did not think of that people find
> useful?

The only clear requirement I get out of this is open all files in
a project.

The Makefile has to have the file list anyway.

Perhaps something like:

PROJ_SRC:=$(wildcard *.c)
PROJ_HDR:=$(wildcard *.h)

open_all:
        emacsclient $(PROJ_SRC) $(PROJ_HDR)

-- 
Dan Espen

Re: I'm looking for a project management system for Emacs

[Marcin Borkowski]

Dnia 2014-03-29, o godz. 13:11:33
despen@verizon.net (Dan.Espen) napisał(a):

> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
> 
> > Hello all,
> >
> > as stated in the subject line, I'm looking for a project management
> > system in Emacs.  Since there are quite a few of them, I thought I
> > could ask here.  I don't have /strict/ requirements, but rather a
> > few problems I'd like that system to address, and a few features I'd
> > probably need.
> >
> > 1. When I have many files open, switching to another buffer is a bit
> > cumbersome, even when using Ido.  I'd like that system to have
> > something like "ido-switch-buffer-within-project".
> >
> > 2. Files of the project might not be located in one folder (so
> > e.g. Projectile probably won't work for me).  Rationale: there may
> > be a few files somehere down the ~/Documents hierarchy and /one/
> > file in ~/org.  On the other hand, I'd like to be able to specify
> > that "this file and all files in that directory belong to this
> > project", without manually listing all the files in "that
> > directory".  It would then be best if adding a file into the
> > specified directory (or tree) would add it /automatically/ to the
> > project.
> >
> > 3. One file may belong to more than one project.  Rationale: see
> > above.
> >
> > 4. It would be great if I could mark some /global/ variables
> > project-dependent, i.e., each variable would have its "project
> > instance", and switching between projects would mean changing its
> > value accordingly.  (It would probably also need some kind of
> > persistence, too.)  Rationale: org-clock-history;).
> >
> > 5. Of course, I'd like to be able to visit/kill all files/buffers
> > related to the project with one command.  Also, adding a project
> > (and a file/files to an existing project) should be possible in some
> > interactive way (though using some Elisp variable for that might be
> > acceptable).
> >
> > 6. On the other hand, window configuration management is not a must
> > for me - currently I work 98% of the time on a small netbook and
> > usually have only one window open anyway.  I'm planning to use a
> > larger monitor in some time, though, so while not necessary, this
> > would be a nice bonus.
> >
> > Is there anything in existence that would help me?  Are there any
> > potentially useful features I did not think of that people find
> > useful?
> 
> The only clear requirement I get out of this is open all files in
> a project.

Well, I thought I was clear enough...

> The Makefile has to have the file list anyway.

Assuming that you use make, which is not necessarily true.  And even if
I do use make, then see point 2 above: I probably wouldn't include the
org file (which might contain TODOs etc. for many projects) anywhere in
the Makefile (at least I see no reason to do so, other than to put it
there so it contains a full list...)

I guess you are thinking of "a project" in terms of "a software
project".  This might be true or not, in my case (assuming a usual
definition of software;)).  Other kinds of projects I'm working on are:
LaTeX classes and packages (technically they /are/ software, but of a
rather specific kind) and books/problem sets/articles (for which you
have to stretch the definition of "software" considerably IMHO).

> Perhaps something like:
> 
> PROJ_SRC:=$(wildcard *.c)
> PROJ_HDR:=$(wildcard *.h)
> 
> open_all:
>         emacsclient $(PROJ_SRC) $(PROJ_HDR)

That's an interesting idea, though it does not solve my number one,
which is one of the most important (I guess there was a reason to call
it number one, though I might have done it unconsciously).

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: I'm looking for a project management system for Emacs

[Dan.Espen]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> Dnia 2014-03-29, o godz. 13:11:33
> despen@verizon.net (Dan.Espen) napisał(a):
>
>> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
>> 
>> > Hello all,
>> >
>> > as stated in the subject line, I'm looking for a project management
>> > system in Emacs.  Since there are quite a few of them, I thought I
>> > could ask here.  I don't have /strict/ requirements, but rather a
>> > few problems I'd like that system to address, and a few features I'd
>> > probably need.
>> >
>> > 1. When I have many files open, switching to another buffer is a bit
>> > cumbersome, even when using Ido.  I'd like that system to have
>> > something like "ido-switch-buffer-within-project".
>> >
>> > 2. Files of the project might not be located in one folder (so
>> > e.g. Projectile probably won't work for me).  Rationale: there may
>> > be a few files somehere down the ~/Documents hierarchy and /one/
>> > file in ~/org.  On the other hand, I'd like to be able to specify
>> > that "this file and all files in that directory belong to this
>> > project", without manually listing all the files in "that
>> > directory".  It would then be best if adding a file into the
>> > specified directory (or tree) would add it /automatically/ to the
>> > project.
>> >
>> > 3. One file may belong to more than one project.  Rationale: see
>> > above.
>> >
>> > 4. It would be great if I could mark some /global/ variables
>> > project-dependent, i.e., each variable would have its "project
>> > instance", and switching between projects would mean changing its
>> > value accordingly.  (It would probably also need some kind of
>> > persistence, too.)  Rationale: org-clock-history;).
>> >
>> > 5. Of course, I'd like to be able to visit/kill all files/buffers
>> > related to the project with one command.  Also, adding a project
>> > (and a file/files to an existing project) should be possible in some
>> > interactive way (though using some Elisp variable for that might be
>> > acceptable).
>> >
>> > 6. On the other hand, window configuration management is not a must
>> > for me - currently I work 98% of the time on a small netbook and
>> > usually have only one window open anyway.  I'm planning to use a
>> > larger monitor in some time, though, so while not necessary, this
>> > would be a nice bonus.
>> >
>> > Is there anything in existence that would help me?  Are there any
>> > potentially useful features I did not think of that people find
>> > useful?
>> 
>> The only clear requirement I get out of this is open all files in
>> a project.
>
> Well, I thought I was clear enough...

Yeah, I guess I only read it all once.

>> The Makefile has to have the file list anyway.
>
> Assuming that you use make, which is not necessarily true.  And even if
> I do use make, then see point 2 above: I probably wouldn't include the
> org file (which might contain TODOs etc. for many projects) anywhere in
> the Makefile (at least I see no reason to do so, other than to put it
> there so it contains a full list...)
>
> I guess you are thinking of "a project" in terms of "a software
> project".  This might be true or not, in my case (assuming a usual

Nope, big Gnumake fan here.
Any directory/project I do work in is going to have Makefile(s).


> definition of software;)).  Other kinds of projects I'm working on are:
> LaTeX classes and packages (technically they /are/ software, but of a
> rather specific kind) and books/problem sets/articles (for which you
> have to stretch the definition of "software" considerably IMHO).
>
>> Perhaps something like:
>> 
>> PROJ_SRC:=$(wildcard *.c)
>> PROJ_HDR:=$(wildcard *.h)
>> 
>> open_all:
>>         emacsclient $(PROJ_SRC) $(PROJ_HDR)
>
> That's an interesting idea, though it does not solve my number one,
> which is one of the most important (I guess there was a reason to call
> it number one, though I might have done it unconsciously).

Just cycle through all the files in a project?

Maybe you want some TAG files?

-- 
Dan Espen

Re: I'm looking for a project management system for Emacs

[Marcin Borkowski]

Dnia 2014-03-30, o godz. 00:29:53
despen@verizon.net (Dan.Espen) napisał(a):

> > Well, I thought I was clear enough...
> 
> Yeah, I guess I only read it all once.
> 
> >> The Makefile has to have the file list anyway.
> >
> > Assuming that you use make, which is not necessarily true.  And
> > even if I do use make, then see point 2 above: I probably wouldn't
> > include the org file (which might contain TODOs etc. for many
> > projects) anywhere in the Makefile (at least I see no reason to do
> > so, other than to put it there so it contains a full list...)
> >
> > I guess you are thinking of "a project" in terms of "a software
> > project".  This might be true or not, in my case (assuming a usual
> 
> Nope, big Gnumake fan here.
> Any directory/project I do work in is going to have Makefile(s).

Well, then I deduce that you are not a heavy LaTeX user.  (Am I right,
dear Watson? ;) )  The problem is that the make model (using
timestamps) is a bit too simplistic for LaTeX: due to the way
references (& friends) work, the .aux file basically depends on
itself, but only if it contains a line saying

> LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.

I guess that using a mixture of grep, some temp file and cleverness
one could overcome this, but it's simpler to use dedicated, make-like
software, like Arara (or Emacs + AUCTeX, in my case).

> Just cycle through all the files in a project?
> 
> Maybe you want some TAG files?

Well, maybe.  It seems, though, that I want properly configured
Icicles;).

Thanks anyway,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: I'm looking for a project management system for Emacs

[Dan.Espen]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> Dnia 2014-03-30, o godz. 00:29:53
> despen@verizon.net (Dan.Espen) napisał(a):
>
>> > Well, I thought I was clear enough...
>> 
>> Yeah, I guess I only read it all once.
>> 
>> >> The Makefile has to have the file list anyway.
>> >
>> > Assuming that you use make, which is not necessarily true.  And
>> > even if I do use make, then see point 2 above: I probably wouldn't
>> > include the org file (which might contain TODOs etc. for many
>> > projects) anywhere in the Makefile (at least I see no reason to do
>> > so, other than to put it there so it contains a full list...)
>> >
>> > I guess you are thinking of "a project" in terms of "a software
>> > project".  This might be true or not, in my case (assuming a usual
>> 
>> Nope, big Gnumake fan here.
>> Any directory/project I do work in is going to have Makefile(s).
>
> Well, then I deduce that you are not a heavy LaTeX user.  (Am I right,
> dear Watson? ;) )  The problem is that the make model (using
> timestamps) is a bit too simplistic for LaTeX: due to the way
> references (& friends) work, the .aux file basically depends on
> itself, but only if it contains a line saying

Right.  Latex is for printing isn't it?

I do a lot of documentation writing.
But HTML/CSS (and Makefiles) are my weapon of choice.
I have rules for content generation (like a TOC), uploading, thumbnail
creation, packaging...

-- 
Dan Espen

Re: I'm looking for a project management system for Emacs

[Marcin Borkowski]

Dnia 2014-03-30, o godz. 10:18:40
despen@verizon.net (Dan.Espen) napisał(a):

> >> Nope, big Gnumake fan here.
> >> Any directory/project I do work in is going to have Makefile(s).
> >
> > Well, then I deduce that you are not a heavy LaTeX user.  (Am I
> > right, dear Watson? ;) )  The problem is that the make model (using
> > timestamps) is a bit too simplistic for LaTeX: due to the way
> > references (& friends) work, the .aux file basically depends on
> > itself, but only if it contains a line saying
> 
> Right.  Latex is for printing isn't it?

Rather typesetting, usually to a pdf file (at least nowadays).  Of
course, most of the time this means that something will eventually find
its way to a dead tree.  (OTOH, there /are/ TeX-based engines which can
output HTML/XML, too.)

> I do a lot of documentation writing.
> But HTML/CSS (and Makefiles) are my weapon of choice.

This is a very good choice, /if/ you do not aim for high typographical
quality and/or atypical applications (typesetting of chemical
formulae, musical notation, dictionaries etc.).

Out of curiosity: are there /any/ HTML/CSS rendering solutions
(browsers, ebook readers etc.) which handle breaking paragraphs into
lines in an aesthetically satisfactory way (i.e., employ the
Knuth-Plass algorithm, for instance)?

> I have rules for content generation (like a TOC), uploading, thumbnail
> creation, packaging...

Do you aim for online browsing only, or for a printed version, too?  If
the latter, how do you handle the problem of (potentially) unstable
forward page references?

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University

Re: I'm looking for a project management system for Emacs

[hubert]

On Sun, 30 Mar 2014 21:14:02 +0200, Marcin Borkowski <mbork@wmi.amu.edu.pl> said:

[snip]

> Out of curiosity: are there /any/ HTML/CSS rendering solutions
> (browsers, ebook readers etc.) which handle breaking paragraphs into
> lines in an aesthetically satisfactory way (i.e., employ the
> Knuth-Plass algorithm, for instance)?

This is the main implementation that I'm aware of:
http://www.bramstein.com/projects/typeset/

-- 
Hubert Chathi - Email/Jabber: hubert@uhoreg.ca - http://www.uhoreg.ca/
PGP/GnuPG key: 4096R/113A1368 (Key available at pool.sks-keyservers.net)
Fingerprint: F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Re: I'm looking for a project management system for Emacs

[Dan.Espen]

Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:

> Dnia 2014-03-30, o godz. 10:18:40
> despen@verizon.net (Dan.Espen) napisał(a):
>
>> >> Nope, big Gnumake fan here.
>> >> Any directory/project I do work in is going to have Makefile(s).
>> >
>> > Well, then I deduce that you are not a heavy LaTeX user.  (Am I
>> > right, dear Watson? ;) )  The problem is that the make model (using
>> > timestamps) is a bit too simplistic for LaTeX: due to the way
>> > references (& friends) work, the .aux file basically depends on
>> > itself, but only if it contains a line saying
>> 
>> Right.  Latex is for printing isn't it?
>
> Rather typesetting, usually to a pdf file (at least nowadays).  Of
> course, most of the time this means that something will eventually find
> its way to a dead tree.  (OTOH, there /are/ TeX-based engines which can
> output HTML/XML, too.)
>
>> I do a lot of documentation writing.
>> But HTML/CSS (and Makefiles) are my weapon of choice.
>
> This is a very good choice, /if/ you do not aim for high typographical
> quality and/or atypical applications (typesetting of chemical
> formulae, musical notation, dictionaries etc.).

Yep, I can care less about paper, but the display quality is to
some extent a function of the browser.

> Out of curiosity: are there /any/ HTML/CSS rendering solutions
> (browsers, ebook readers etc.) which handle breaking paragraphs into
> lines in an aesthetically satisfactory way (i.e., employ the
> Knuth-Plass algorithm, for instance)?

Well, browsers do re-flow when you change window size.

Hmm, Google says there are some Javascript
implementations of Knuth-Plass.

>> I have rules for content generation (like a TOC), uploading, thumbnail
>> creation, packaging...
>
> Do you aim for online browsing only, or for a printed version, too?  If
> the latter, how do you handle the problem of (potentially) unstable
> forward page references?

When you identify your CSS there is a "media" option.
I do most of my work for browsing, but for the few people that
print, I do have a "print" CSS.

As for forward references, I just do "See X below".  If you print,
you've got to search.  If you are browsing, "See below" is a link.

I've adopted a convention so that headings point back to the next
higher level heading.  So, H2 points to the enclosing H1,
H3 points to it's parent H2, and so on.

It makes navigating, even big documents a breeze.

Each TOC only goes one level deep.
So the main TOC references the H1 headings.
If there are a few H2 headings, there is a nested TOC.

At the same time, I use DIVs to indent heading levels a little more.
This makes up for not having numbered sections.

I especially like the "Change History" section offering links to
the changes.  Someone that's just looking for new stuff gets there
pretty quickly.

A really neat HTML feature is a Javascript package I found that
makes <table>s sortable.  It's so neat to put a table into
a document and know the user can sort it on any of the columns.

I've been advocating for dumping Word and PDFs but people are
slow to change, so I lead by example.

-- 
Dan Espen

Re: I'm looking for a project management system for Emacs

[Marcin Borkowski]

Dnia 2014-03-30, o godz. 16:30:42
despen@verizon.net (Dan.Espen) napisał(a):

> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
> 
> > Dnia 2014-03-30, o godz. 10:18:40
> > despen@verizon.net (Dan.Espen) napisał(a):
> >
> >> >> Nope, big Gnumake fan here.
> >> >> Any directory/project I do work in is going to have Makefile(s).
> >> >
> >> > Well, then I deduce that you are not a heavy LaTeX user.  (Am I
> >> > right, dear Watson? ;) )  The problem is that the make model
> >> > (using timestamps) is a bit too simplistic for LaTeX: due to the
> >> > way references (& friends) work, the .aux file basically depends
> >> > on itself, but only if it contains a line saying
> >> 
> >> Right.  Latex is for printing isn't it?
> >
> > Rather typesetting, usually to a pdf file (at least nowadays).  Of
> > course, most of the time this means that something will eventually
> > find its way to a dead tree.  (OTOH, there /are/ TeX-based engines
> > which can output HTML/XML, too.)
> >
> >> I do a lot of documentation writing.
> >> But HTML/CSS (and Makefiles) are my weapon of choice.
> >
> > This is a very good choice, /if/ you do not aim for high
> > typographical quality and/or atypical applications (typesetting of
> > chemical formulae, musical notation, dictionaries etc.).
> 
> Yep, I can care less about paper, but the display quality is to
> some extent a function of the browser.

True.  And (as I hinted) not only display quality, but also display
/possibilities/.  Are there any browsers capable of displaying musical
scores or chemical formulae, to use abovementioned examples?  Or, for
that matter, rendering trees (like in a school-level probability
textbook), given their structure?  It's possible, but unlikely, since
these are rather niche use cases.  (You could probably do it with
JavaScript and SVG or something similar, of course.)

> > Out of curiosity: are there /any/ HTML/CSS rendering solutions
> > (browsers, ebook readers etc.) which handle breaking paragraphs into
> > lines in an aesthetically satisfactory way (i.e., employ the
> > Knuth-Plass algorithm, for instance)?
> 
> Well, browsers do re-flow when you change window size.
> 
> Hmm, Google says there are some Javascript
> implementations of Knuth-Plass.

Interesting - I'll look at it in some spare time.

> >> I have rules for content generation (like a TOC), uploading,
> >> thumbnail creation, packaging...
> >
> > Do you aim for online browsing only, or for a printed version,
> > too?  If the latter, how do you handle the problem of (potentially)
> > unstable forward page references?
> 
> When you identify your CSS there is a "media" option.
> I do most of my work for browsing, but for the few people that
> print, I do have a "print" CSS.
> 
> As for forward references, I just do "See X below".  If you print,
> you've got to search.  If you are browsing, "See below" is a link.

I see.  That means - basically - that you escape the problem;).  A
user of a printed version has no idea whether they should skip forward
two pages or two hundred pages...

> I've adopted a convention so that headings point back to the next
> higher level heading.  So, H2 points to the enclosing H1,
> H3 points to it's parent H2, and so on.
> 
> It makes navigating, even big documents a breeze.

Smart idea!  Though I prefer Emacs Info's `u' key for that;).

> Each TOC only goes one level deep.
> So the main TOC references the H1 headings.
> If there are a few H2 headings, there is a nested TOC.

Of course, this does make a lot of sense in an online document and not
too much in a printed book...

> At the same time, I use DIVs to indent heading levels a little more.
> This makes up for not having numbered sections.

Again - numbered sections in an online environment are a good idea.
Much worse in printed material.

> I especially like the "Change History" section offering links to
> the changes.  Someone that's just looking for new stuff gets there
> pretty quickly.

Of course.

> A really neat HTML feature is a Javascript package I found that
> makes <table>s sortable.  It's so neat to put a table into
> a document and know the user can sort it on any of the columns.

Nice!

> I've been advocating for dumping Word and PDFs but people are
> slow to change, so I lead by example.

Dumping Word is indeed a good idea;).  For PDFs - I can't agree.
HTML/CSS addresses a different problem than PDF.  Using PDFs for
browsing on a computer may be suboptimal (depending on circumstances).
For actual printing, it is much better, since it gives the author (or
the designer) complete control over the document.  With HTML/CSS, a
lot is dependent on the browser, user's settings, available fonts etc.
This is (usually) what you /do/ want on a web page and exactly what
you /don't/ want in a book (even if it were actually possible;)).

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Adam Mickiewicz University