On 09/09/2015 11:42, Graeme Geldenhuys wrote:
On 2015-09-08 23:16, Martin Frb wrote:
In respect to "fixed locally" (your comment below): How?
Does it use the storage that can be edited via the "windows" tab in
tools/opitons? (like breakpoints)?
That's another problem I have with Lazarus IDE...
In my haste to fix the annoyance (which was really bugging me at the
time) I simply used a local TINIFile in the Procedure List dialog, and
saved the relevant information to that standard lazarus primary config
directory.
Then IMHO it is not a papercut (though it may still be easy/moderate to
fix, but that depends how deep the new multi desktop changes go.)
- deleting some breakpoints after a debug session. I don't see the
point it forcing me to press an extra key between every delete action.
Also when the window is opened for the first time, why is the focus
set, but no selection. It is such little annoyances that I consider
"papercut bugs". Developers are creatures that like efficiency. ;-) At
least that is me.
Fixed/Improved
If you have a patch for the "first open" I am happy to apply it. Just
not going to search the code now, for where this needs to be done.
Can be solved via editor macro. But if you have a patch...
I use a few copies of Lazarus IDE - in various VM's. In two of them I
can't find any reference to Macros in the IDE menus or how to record a
new macros. Searching the wiki for "macros" brings up the paths and
filename macros - not what I wanted.
So I wrote a IDE add-on package which does what I want, and include it
in my local "custom-mods" branch.
Is macros support an IDE add-on package that must be installed? It is
such a useful feature of any IDE or text editor, so why can't Lazarus
IDE come standard with macros support, and put it right there in the
main menu, easy to find. See attached screenshot of EditPad Pro - can't
get more clear than that!
http://wiki.lazarus.freepascal.org/IDE_Window:_Editor_Macros
It should be installed by default. But maybe, if you did "svn up" from
an older version, then it was not installed.
Just adding them to mantis (patches subproject), and mention "patch" in
the subject.
That's find for the ones I have fixed, but what about the other 95
papercut bugs - that don't have patches yet. Could we have a separate
sub-section in Mantis to file these easy to fix (1-2 hours max) bugs -
or should we simply attach a tag to an existing Mantis report. Again I
know tags exist in Mantis, but I don't know how useful they are in real
life.
I have no preference.
Personally, I hardly use tags, but neither do I look at which subproject
a bug is in. I mainly look at the subject. (and the content, if needed)
The issue is not just if the can be fixed in a line or two, but also if
that is deemed the correct solution.
Obviously, and why it needs to be discuss - hence my preference to file
them in Mantis, instead of simply listing them in a Wiki page.
When it is bugs, always mantis. When it is improvements, then Mantis or
mail list (depends on how likely others see the need for such an
improvement and the ability to do it quick)
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
