Hi!
I feel that trac makes it difficult (for me) to write and structure the text for
a ticket. I am forced to manually enter [[BR]] to break lines!
Can this be "turned-on" to be "entered" automatically? Everything that a user
will write, and especially lines of code, is "merged" in one line. That is
annoying.
Thanks, Nikos
Hi,
2013/3/20 Nikos Alexandris <nik@nikosalexandris.net>:
I feel that trac makes it difficult (for me) to write and structure the text for
a ticket. I am forced to manually enter [[BR]] to break lines!
putting extra empty line do the job for me. For preformatted text use
`` (one line) or {{{ }}}.
Check the help page [1] 
Martin
[1] http://trac.osgeo.org/grass/wiki/WikiFormatting
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Martin Landa wrote:
2013/3/20 Nikos Alexandris <nik@nikosalexandris.net>:
> I feel that trac makes it difficult (for me) to write and structure the
> text for a ticket. I am forced to manually enter [[BR]] to break lines!putting extra empty line do the job for me. For preformatted text use
`` (one line) or {{{ }}}.Check the help page [1]
..
Indeed, but I still don't find it very convenient. I should put a new line
for all of the following then:
[1] http://www.cs.umd.edu/~mount/Projects/ISODATA/
[2]
http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//009z000000pn000000.htm
[3]
http://geospatial.intergraph.com/fieldguide/wwhelp/wwhimpl/js/html/wwhelp.htm
[4]
http://www.exelisvis.com/portals/0/tutorials/envi/ClassificationTutorial.pdf
[5] http://www.pcigeomatics.com/products/pdfs/Geomatica_Core_1032.pdf
[6] http://www.clarklabs.org/products/upload/IDRISI-Selva-GIS-Image-
Processing-Specifications.pdf
[7] http://cran.r-project.org/web/packages/biOps/index.html
[8] http://www.opticks.org
and after each "# comment" when posting code
?
Example of my *very ugly looking* ticket:
<http://trac.osgeo.org/grass/ticket/1906>
and Markus' 1st reply on it as well.
It seems the bullet-ed-list (*) is lost?
Thanks, Nikos
Hi Nikos,
I can understand that it is not easy to know that you can use
trac-wiki formatting. I've tried open new ticked and you have to go
through one other article to get to the WikiFormatting page:
https://trac.osgeo.org/grass/newticket
https://trac.osgeo.org/grass/wiki/TracTickets
https://trac.osgeo.org/grass/wiki/WikiFormatting
The WikiFormatting link is only in the "Add comment".
The problem is that I've recently discovered that it is possible to
highlight code, what a nice feature!
BTW, I'm not able to find "edit a ticket", although I think that it is
possible. (There are some projects which don't want to change original
ticket descriptions.)
On 20 March 2013 15:59, Nikos Alexandris <nik@nikosalexandris.net> wrote:
Martin Landa wrote:
2013/3/20 Nikos Alexandris <nik@nikosalexandris.net>:
> I feel that trac makes it difficult (for me) to write and structure the
> text for a ticket. I am forced to manually enter [[BR]] to break lines!putting extra empty line do the job for me. For preformatted text use
`` (one line) or {{{ }}}.Check the help page [1]
..
Indeed, but I still don't find it very convenient. I should put a new line
for all of the following then:[1] http://www.cs.umd.edu/~mount/Projects/ISODATA/
[2]
http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//009z000000pn000000.htm
[3]
http://geospatial.intergraph.com/fieldguide/wwhelp/wwhimpl/js/html/wwhelp.htm
[4]
http://www.exelisvis.com/portals/0/tutorials/envi/ClassificationTutorial.pdf
[5] http://www.pcigeomatics.com/products/pdfs/Geomatica_Core_1032.pdf
[6] http://www.clarklabs.org/products/upload/IDRISI-Selva-GIS-Image-
Processing-Specifications.pdf
[7] http://cran.r-project.org/web/packages/biOps/index.html
[8] http://www.opticks.org
Not sure what is the proper way to do references. May be just the numbered list
1. Item 1
1. Item 2
or with explicit numbers. [ and ] with number creates a link to a ticked.
and after each "# comment" when posting code
{{{
# some function
def my_code(here):
pass
}}}
should help.
?
Example of my *very ugly looking* ticket:
<http://trac.osgeo.org/grass/ticket/1906>and Markus' 1st reply on it as well.
It seems the bullet-ed-list (*) is lost?
If I remember correctly, it is and there is no way how to preserve it.
The only way is to use Preview.
Vaclav
Thanks, Nikos
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Wednesday 20 of March 2013 16:11:19 Vaclav Petras wrote:
BTW, I'm not able to find "edit a ticket", although I think that it is
possible. (There are some projects which don't want to change original
ticket descriptions.)
Believe me, I was looking for it too, right after I submitted, of course 
Nikos
On Wed, Mar 20, 2013 at 3:59 PM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:
Martin Landa wrote:
2013/3/20 Nikos Alexandris <nik@nikosalexandris.net>:
> I feel that trac makes it difficult (for me) to write and structure the
> text for a ticket. I am forced to manually enter [[BR]] to break lines!
Please don't... it becomes really unreadable.
...
Indeed, but I still don't find it very convenient. I should put a new line
for all of the following then:[1] http://www.cs.umd.edu/~mount/Projects/ISODATA/
[2] http://help…
...
Remember that a bugtracker is not a typesetting system. Simple formatting
is preferred as well as using the trac Wiki features. A numbered list
could be easily generated, IMHO no need to have the (overly) fancy
brackets. The shorter, the better 
Best
Markus
Nikos Alexandris:
>> > I feel that trac makes it difficult (for me) to write and structure the
>> > text for a ticket. I am forced to manually enter [[BR]] to break
>> > lines!
Markus Neteler:
Please don't... it becomes really unreadable.
...
Nikos A:
> Indeed, but I still don't find it very convenient. I should put a new
> line for all of the following then:
> [1] http://www.cs.umd.edu/~mount/Projects/ISODATA/
> [2] http://help…
...
Remember that a bugtracker is not a typesetting system. Simple formatting
is preferred as well as using the trac Wiki features. A numbered list
could be easily generated, IMHO no need to have the (overly) fancy
brackets. The shorter, the better
Sure, but why I see for example the supposed list build with a * in front of
each line not being a list? (shrug)
e.g. http://picpaste.com/in_trac_asterisks_not_building_a_list-NHQQRYVm.png
Shouldn't the list be built automagically?
Best, N
On 20 March 2013 18:33, Nikos Alexandris <nik@nikosalexandris.net> wrote:
Sure, but why I see for example the supposed list build with a * in front of
each line not being a list? (shrug)e.g. http://picpaste.com/in_trac_asterisks_not_building_a_list-NHQQRYVm.png
Shouldn't the list be built automagically?
The space before the star is mandatory.
Different syntax than other systems, sorry.
Maybe, it is time to some markup support overview...
On 20 March 2013 20:31, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On 20 March 2013 18:33, Nikos Alexandris <nik@nikosalexandris.net> wrote:
Sure, but why I see for example the supposed list build with a * in front of
each line not being a list? (shrug)e.g. http://picpaste.com/in_trac_asterisks_not_building_a_list-NHQQRYVm.png
Shouldn't the list be built automagically?
The space before the star is mandatory.
Different syntax than other systems, sorry.
The first level is the same for Wikimedia, Markdown and ReST,
unfortunately not for Trac.
* This is item 1
* This is item 2
http://docutils.sourceforge.net/docs/user/rst/quickref.html#bullet-lists
http://en.wikipedia.org/wiki/Markdown#Lists
http://en.wikipedia.org/wiki/Help:Wiki_markup#Lists
Trac uses MoinMoin
* This is item 1
* This is item 2
http://moinmo.in/HelpOnMoinWikiSyntax#Lists
If you really want to use ReST it is possible to to use
WikiPreprocessors at Trac.
{{{
#!rst
* This is item 1
* This is item 2
}}}
https://trac.osgeo.org/grass/wiki/WikiProcessors
With textile installed it would support also textile. With some Trac
Markdown extension, Trac would support also Markdown preprocessor. I
wouldn't vote for textile, but Markdown can be considered since it is
supported also by Doxygen (however, not used in grass sources). But
basically, there is no point to not use ReST.
It is bad that you need to know Mediawiki syntax and Trac Wiki or ReST
syntax to contribute to GRASS. Even worse that for manual pages you
need to know some basic HTML and for programming manual Doxygen
syntax. Currently, I don't see any way to avoid it.
And I forgot, Trac of course supports also HTML preprocessor:
{{{
#!html
<ul>
<li></li>
</ul>
}}}
Vaclav Petras wrote:
..
I didn't read the whole post of yours -- will do. Thank you for your energy
spent/invested Vaclav.
It is bad that you need to know Mediawiki syntax and Trac Wiki or ReST
syntax to contribute to GRASS. Even worse that for manual pages you
need to know some basic HTML and for programming manual Doxygen
syntax. Currently, I don't see any way to avoid it.
I have the feeeling it is eating-up energy, most importantly time from all of
you devs. Why don't we (the community I mean) moves in using a nice, all-in-
one (except for the tickets which is under the osgeo umbrella) and *beautiful*
system like the stackexchange fora :-p -- Just kidding...
(To-myself: I wonder why I didn't complain in the past about trac -- I
remember creating several tickets. :-?)
Anyway, it's the way it is currently. Sorry for the noise folks.
Nikos
StackExchange uses Markdown, by the way
Your thoughts are 100% valid. We must remember that programmers
usually (or ideally?) use several languages, so using several markups
is natural, too. However, for non-programmers (users) it is usual to
know zero or one markup language because they usually see the new
syntax/language as a new problem (programmers ideally see new syntax
as a way of saying the same thing in the same way). Fortunately, GRASS
people are powerful and they have learned all the markups required.
Sorry for saying something which is obvious or just personal thoughts
but it is worth to remember that for some people it can be harder to
learn the second or third markup just because they think in different
way. Consequently, if it is too hard for someone, he or she will
create ugly ticked or even worse, no ticked (documentation, wikipage)
at all.
Just a small update. The situation will be hopefully improved some
day. Trac 0.12 supports live preview. From the change log [1]:
* Usability improvements for the Wiki, with a nice side-by-side edit
mode with automatic preview
* Usability improvements for the Ticket module, with automatic
preview of comments while you type and possibility to edit or remove
them later
I don't see the preview in the demo for 0.12 (maybe it is turned off
by default) but 1.0 (last stable is 1.0.1.) has it [2].
The different syntax problem will be still there but it will be much
more convenient to check your syntax.
We are using Trac 0.11.7.
[1] http://trac.edgewall.org/wiki/ChangeLog#a0.12Babel
[2] http://trac.edgewall.org/demo-1.0/newticket
Hi Vaclav,
On Thu, May 2, 2013 at 4:14 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
Just a small update. The situation will be hopefully improved some
day. Trac 0.12 supports live preview. From the change log [1]:
Please update this ticket:
http://trac.osgeo.org/osgeo/ticket/592
thanks
Markus
