Hi,
On Tue, 30 Jan 2007 11:51:21 +0200, Karoliina.T.Salminen wrote:
> Hi,
>
>>> But I must say that the first thing that prevent to use the
>>device to
>>> do programm is the lack of a good editor adatpted to it.
>>
>>Slightly off-topic and maybe? a little bit flamebait, but I
>>have never found an editor adapted for programming that wasn't
>>a pain to use in UN*X.
>
> You mean graphical editor or text mode editor?
> I guess you dislike vi like I do, so here is a list of other editors:
> Modern graphical UI:
> - kate (KDE text editor, works fine on Gnome, this is my favourite, very
> similar to UltraEdit editor on Windows)
After reading your post, I must try that as soon as possible :)
[...]
> - emacs (the traditional editor for linux etc., some people love it,
> some hate
> it because of the commands being CTRL+X+CTRL+...+..., in my opinion
> still a lot more
> user friendly and intuitive than vi).
Well, even the author of vi admits that most of the weird stuff is in vi
because terminals back in the day were just too darn broken (losing/repeating
characters, 10bps slow, ...) ;-)
As for emacs, I guess with some major hacking on the configuration lisp code, I
could get it to drop the Ctrl-K stuck key thing. As I'm naturally lazy, I'd
like to avoid that ;-)
> - then there is the vi and vim for those who have different modes in their
> brain for typing and moving the cursor. You can play Kraftwerk-robot with
> this one.
heh ;-)
>>- command line option to jump to line/column number on load
>
> Well Kate don't have this most likely. However, when you load the text, you
> can CTRL+G and type the line number where you want to go.
Well, if it only misses that, I'm not against just adding it myself :-)
I automated most of the build and it's nice when the build system will
automagically fire up an editor at the exact line of mistake (which I
inevitable make lots of :)).
>>- interface for filling extra columns like:
>> - line number
>
> kate has this
>
>> - breakpoint (modifyable)
>
> you should check out some IDEs if you need breakpoints
I think you missed the part "interface to". All I ask it to support is giving
it another file with data for an extra column that I fill however I want (and
which is not saved into the original file).
I do see that the UNIX lots-of-small-tools philosophy is kinda outmoded and I
should just jump on the IDE bandwagon, creating/using an app that does
everything (and nothing of it well) :->
[...]
>> - misc user-defined flag
[...]
>> - line the other people viewing this file are currently on
>
> nope
I put this line in just to show what a simple extra column file could be used
for ;-)
>> - and so on...
>>- folding of blocks
>
> kate has this
Really? Nice :)
Installing it as we speak...
>
>>- virtual concatenation of files (I'd really prefer the
>>_filesystem_ to support that, but...)
> ??
Hmm. If you have lots of small files, it _could_ (ideally, I know, never going
to happen) concatenate them all into one large buffer, separated by a line
stating file name. Later when saving, it could split them again.
So you could do like "kate source/" (note: directory(!) path) and it would show
a great concatenated view of all the files in the directory (in one window, one
view, one buffer - making reading to get an overview and search&replace
straightforward):
+---------------------------------------+
| 1 a.c: ^|
| 2 #include <stdio.h> ||
| 3 #include "a.h" ||
| 4 ||
| 5 int a() ||
| 6 { ||
| 7 } ||
| 8 ||
| 9 a.h: ||
| 10 #ifndef _A_H ||
| 11 #define _A_H ||
| 12 int a(void); ||
| 13 #endif /* _A_H */ ||
| 14 ||
| 15 main.c: ||
| 16 #include "a.h" ||
| 17 ||
| 18 int main(int argc, char* argv[]) ||
| 19 { ||
| 20 return a(); ||
| 21 } v|
+---------------------------------------+
Yeah ok, so it's kinda sick ;-)
>>- every time someone writes "." and then pauses for 1 second,
>>call external tool (with all the text on stdin?) (Intellisense :))
>
> ???
Hehe, I am way too accustomed to think in tools, I fear. The editor would call
an external tool to implement intellisense with (which would do whatever magic
and return the result to the editor, which would just display it in a combo
box).
>>- every time I press the Newline key in order to create a new
>>line, repeat the leading whitespace from the line I came from
>>on the new line (and I mean, exactly, not expanding tabs, not
>>grouping spaces into tabs, not trying to backstab me, ...)
>
> kate puts indent characters there, which means spaces if the person
> likes to keep the file human readable with any editor / viewer etc.
By now kate finished installing, I tried it, it does it right: it repeats
indentation as-is from the original line on the new line. Nice.
I'm also pleased by the functionality so far (although it takes too long to
start up - 10 seconds -, I'm sure this is just because of the first launch).
>>- keep the file open while editing, so it shows up inside
>>/proc/<pid>/fd/ (or lsof). No really, nobody's gonna die of
>>that one file descriptor.
>>- double-clicking on a word selects it. A word is delimited by
>>one of " )}]>". If one really must make it more complex,
>>ignore (only) trailing punctuation in that selection.
>
> I think kate does pretty well with double click selecting, works about the
> same as in UltraEdit.
Definitely a cultural thing, then: I found it weird:
Double-clicking into text: "foo_bar", selects: "foo_bar". Good.
Double-clicking into text: "foo-bar", selects either "foo" or "bar". Bad.
Double-clicking into text: "(foo)" on the "o", selects "foo". Good.
Around here, "-" is called a "concatenation dash" and " - " (note: spaces) is
called a "thought dash". The concatenation dash is just for concatenation, and
consequently "foo-bar" is _one_ term. This also goes well with gtk (signals,
file names, tools, ...), lisp, dylan, ....
Oh well. Can't have everything.
Wonder why they got it right for "_", though ;)
>>User interface:
>>- no (control-..., whatever) key combinations for essential stuff
>
> The standard UI way in all modern desktop environments including Gnome,
> KDE, Windows, MacOSX is:
> CTRL-C for copy
> CTRL-X for cut
> CTRL-V for paste
> I am pretty sure you want to have the standard CTRL-something keys on
> place.
Yeah, that's ok. By essential stuff I meant saving, searching/replacing and
such (which is what I do most). I forgot about copy&paste, my bad. Lately I do
most copy&paste by middle click. Funny, when did I get used to that?
>>- no mode-change keys (that means you, vi) (having to change
>>mode 5 times or more in 1 minute is too much) (that does
>>include not having "stuck" keys like Ctrl-K)
>
> kate doesn't have different modes, it is always available
Nice.
>
>>- have function keys that actually do something (and I do mean
>>like Save, Search, ... and not inserting gibberish into the text ;))
>
> I think kate has this
Indeed:
F3 find text
F6 show extra column (ahaaa... now it got me curious :-))
F7 shell
F11 line numbers
>>- being able to move whereever I want on a line, also within
>>the empty (*cough* "non-existant") parts to the right
>>- Ctrl+Click on a word -> call a tool, passing the word, file
>>and position
To elaborate: This would be nice for full text search, cross reference tools,
documentation viewer tools, ...
>>- don't destroy the text buffer when the window is resized
>>(some versions of emacs did that)
>
> kate don't have the same set of bugs than emacs does
What? It's not bug-compatible? tsktsk ;-)
>>Nice to have but not essential:
>>- autosave
>
> kate has this
>
>>- backup files (I'd really prefer the _filesystem_ to support
>>that, but...)
>
> kate has this
>
>>- session saving support (remote saving, like the desktop
>>saying "save all now" to all applications so that some "make"
>>process uses the new version of the edited files)
>
> Kate has this
>
>>- usable without X/framebuffer/graphics terminal
>
> Aha, now you wrote this after getting on this mail this far.
Yes, but actually I don't care about this point too much, "Nice to have but not
essential". After all, it makes little difference whether I ssh with X
forwarding or ssh without X forwarding.
So after giving it some thought I take that point back and state that I don't
care whether it's usable without X/framebuffer/graphics terminal at all.
> kate does not do this since it is graphical text editor
> Your choices are very limited with this restriction.
> I always use nano when using text mode to e.g. fix xorg.conf when
> my unstable Ubuntu installation is broken,
nano has one of the strangest scrolling policies I ever saw :-) (scrolling
_only_ the one line one is on horizontally is... err... weird)
>but all other occasions,
> I use either gedit or kate. Except of course when I am hacking
> our EFIS code if Kate (not the editor but the person) has already opened
> the file to emacs - she loves emacs, so I use emacs occasionally because
> I don't bother sometimes to lauch my own editor - emacs is usable for me
> occasionally.
emacs is kinda nice from time to time, but the silly little bugs just get in my
way (like the destroy-the-buffer-when-window-is-resized bug, with my usage
model, that's BAD - because whenever a new window appears or disappears, all my
windows *resize* to ensure maximum size while not overlapping any windows).
> However, I am totally vi-impaired, I pretty much quit from vi with
> kill-command.
Sounds familiar. Although I can use it (you wouldn't believe what kind of
barebone computers at work - or at customer's - go as servers - they have
nothing else on it), I cringe when doing so... (I once even used a version that
had no cursor key support O_O).
(Then again, I could just fuse-sshfs from my computer to them instead... hmm...)
>>_Not_ to have:
>>- tabs -> the window manager, not the application, manages windows
>
> kate and gedit has tabs and I love that, that is one of the key features
> why I went from emacs to kate / gedit.
Well, I'm over the phase where I patched every application to support tabs and
instead just use a window manager that support tabs to begin with, thereby
making the entire issue moot. And now that I'm here I wonder why I ever did it
differently. Well, always easy to say in hindsight.
> So I disagree with this one.
Fair enough :-)
Having no tabs at all would be a handicap, but I just have something else that
takes care of the tab support.
>
>>- multiple buffers -> the process manager, not the
>>application, manages processes
>
> this is another feature that I want to *have*, couldn't live without
That, too, takes care of itself: I want another file, I launch another editor
instance. The window manager will rearrange the windows to ensure no windows
overlap.
(And I'm not allergic to file managers, so having the rudiments of a file
manager in a text editor is a lost case on me - just saw that in Kate - well,
it can be disabled, so it is, now :))
> So I disagree with this one even more.
I guess multiple buffers aren't that bad, but gedit style is crossing the line:
gedit will tell the running instance, hereby breaking any automated
postprocessing-after-editing-the-file one might have in place.
I'm not sure whether they fixed it, but try
export SVN_EDITOR="gedit"
svn ci
while you already had 15 tabs open in a running gedit instance, half of them
edited and not ready to be saved in that state.
Last time I tried it, svn hung around until I closed _every_ document (and
gedit itself), and only then proceeded with the "svn ci".
>>Hm, maybe with a little evil hacking I can get GtkTextView to
>>support most of that... I wonder... (the folding of blocks is
>>something that will hurt to implement, though...)
>
> kate has this feature and I love it and use it frequently
> I use a mixture of desktop enviroments which usually means
> Gnome desktop with some KDE apps that are currently
> missing from the Gnome desktop.
I see :)
Thanks for your help, I'll be trying kate for a bit, then. :-)
cheers,
Danny
_______________________________________________
maemo-users mailing list
maemo-users@maemo.org
https://maemo.org/mailman/listinfo/maemo-users
