Re: several issues + wishes

[Oswald Buddenhagen <ossi kde org>]

moin,

thx for the reply.

> > mc forgets to reset the x window title when it exits.
> 
> It was never meant to "reset" the title.  There was a discussion how
> to restore the original title, but no good solution was suggested.
> 
too bad. is the problem that xterm does not provide a title query
sequence?

> > a cmdline switch to replace the "mc" prefix in the window title would be
> > very helpful. i usually have dozens of xterms with mc open, some of them
> > are root consoles and some on remote hosts. it's impossible to manage
> > them if they are all titled "mc - ...".
> 
> I think an environment variable would be better.  Something like PS1, but
> specific to mc.  Then you would set it in .profile on the remote host.
>
no. a) it complicates things like "xterm -e su -c 'mc --title root'", as
i need to set up the variable first somehow (note that sh does not
source any files in non-interactive mode by default) and b) i don't want
a "remotehost" title when i'm working locally on the other host.
i'm not saying that an env var is bad, but a cmdline switch is still
required and should take precedence.

> > a single esc keypress should be translated to esc esc after some
> > timeout. the timeout could be made dependent on the "slow terminal"
> > setting and/or could be automatically adopted based on measurements of
> > previous key sequences. dunno if this is simply doable with curses ...
> 
> Sometimes it's useful when Escape doesn't time out.  Users don't have to
> use three fingers to run the "Find File" dialog.  Also, Escape+number is
> the last resort if the functional keys don't work.
> 
indeed, i forgot that case. this smells like a good candidate for an
option.

> > the text viewer should support syntax highlighting.
> 
> I have no idea how to do it.  The syntax highlighting used in the
> internal editor is tied to a memory model used in the editor. 
>
"there is no problem in IT that cannot be solved by adding another layer
of indirection" ... :)

> The viewer uses mmap() on files, so it can read huge files without
> loading them into memory.  I think this feature is more important than
> syntax highlighting.
> 
[disclaimer: these observations apply to mc 4.55]
this "huge file support" is rather theoretical. open /dev/hda and see it
explode. switching to line break mode (and, beware, start scrolling
backwards), switching to hex mode, etc. - all trigger(ed) incredible
memory/cpu consumption.

fwiw, it would also be possible to let the editor keep unmodified chunks
of text as references to a mmaped file. that would make appending to a
gigant file actually doable (especially if some options like "don't
compute line numbers if file is > ... mb" would be added). keeping the
file writeout consistent would be a bit tricky, though (don't overwrite
fragments that are still needed).

> How portable is "file -z"?
>
i don't know. sound like a ./configure candidate. falling back to
calling zip manually shouldn't be that hard.

> > c is treated like c++. that's somewhat annoying.
> 
> It's annoying for a reason.  Calling a variable "new" or "class" is not a
> good idea.
> 
that's nonsense. it's a bad idea to do so in interfaces that can be
included in c++ sources, but not in plain .c files. i think treating .h
always as c++ is acceptable, especially given that there is hardly a way
to find out if it is. that does not apply to .c, though.
fwiw, i sometimes miss a menu entry to explicitly set the highlight
style.

now for something esotheric: nested language syntax highlighting, for
example perl embedded into a shell script. the plain text yielded from
"de-quoting" the "outer" language would be passed into the next
highlighter. no, this is not very urgent; i just wished it existed when
i was editing one of my highly unreadable bash scripts the other day. :)

> > complex sh syntax highlighting, in particular bash syntax is totally
> > screwed. see these examples:
> >   cont=$((${delay2[i]}+$now-$(date '+%s')))
> >   "${mailclasses:1:$((${#mailclasses}-2))}"
> >   fil=$(egrep -i "/([0-9]{2,3} - )?${i% $dsh *}( $dsh |( $dsh [^/]+)?(/.+)?/([0-9]{2,3} - )?)${i##* $dsh }\$" /tmp/xm-$$ | tr '\n' '\\')
> >   dfil="$ddir/$i - ${sartist:+$(escape "${artist[cntr]}") $dsh
> }$(escape "${title[cntr]}").$ext"
> 
> The current syntax highlighting code cannot deal with such complex
> expressions.
>
too bad. :-(  any ETA?

oh, and perl syntax highlight, esp. wrt. the various uses of the $ char
is majorly broken. yes, to highlight it correcty, one needs to keep
incredible amounts of context information ...
btw, is it intentional, that %hashes are not highlightet (as oposed to
@arrays)?

> > the type of white-space used by auto-indent should not be based on the
> > "fill tabs with spaces" setting. instead, the leading whitespace from
> > the above line should be copied. otherwise it's impossible to use a
> > tabbing style like
> > <tab>if (...)
> > <tab><tab>if (cond1 && function(par1,
> > <tab><tab>                      par2))
> > <tab><tab><tab>statement;
[to say it in words: tab for indentation, space for padding]
> > (which is _the_ tabbing style).
> 
> I have no idea what you mean.
>
preserving the already present indentation style as much as possible.
take the above example and imagine i want to add par3 to the function
call. when i press enter on the first closing paren, the new line should
be identical to the par2 line up to the point where the cursor is placed
(below the p of par2, obviouly).

> I normally use indent for indentation and don't waste my time writing
> indented code,
>
i don't use indent. i tried several times and it always messed up the
indentation at some point (especially in complex expressions and data
structure definitions + initializations).
also, it does not support the above tabbing style, afaik.

> unless I'm trying to emulate the original indentation of the code, but
> it's manual work anyways.
> 
yes, but it's considerably less work if your editor helps you.

oh, highlighting tabs would be very helpful in the context. also, a
"show whitespace errors" mode that highlights tabs after leading spaces
and trailing whitespace would be fine. the last one was even in cvs for
a moment, but was backed out again - seems so, that the syntax
highligher needs to cope with config variables.  hello vim ...

two other nice options are "strip trailing space" and "automatically
convert leading whitespace to tab preference" (the latter being in the
exactly opposite spirit to the whitespace-preserving auto-indent i'm
requesting above).

another nice feature would be saving editor options based on file name
patterns (on the whole path + file or file name only). more specific
defs would take precedence. i very often end up toggling between two
option sets.

mcedit also misses a "redo" function.
btw, would it be possible to bind alt(gr)-backspace to undo and
shift-alt(gr)-backspace to redo or are these key combos beyond
recognizability in a console?

> > "intelligent home" which alternates between column 1 and the first
> > column with non-whitespace on it would not hurt.
> 
> You probably need an editor designed for programmers from the beginning
>
yes, but this request does not indicate this, if you ask me.

> > dunno if this is simply an issue of terminfo: a lot of advanced key
> > combinations (in particular [shift-]ctrl-<move>) are not recognized in
> > xterm, even though they produce keycodes.
> 
> That's already in TODO.  Some keys were hardcoded for xterm and rxvt, but
> the right solution is to read the definition from mc.lib.  To read
> definitions for keys with modifiers, the format of mc.lib should be
> changed.
> 
ah, ok.
fwiw, ctrl-\ (here ctrl-altgr-ß) doesn't work in the linux console.

why i don't use kate ...?
- as all other kde apps it has a startup time beyond acceptability on my
  box. given that i don't miss that many features from mcedit, the time
  lost is not worth it for now.
- almost all features that are not part of the default config are
  utterly broken. for example a broken persistent selection mode is a
  show-stopper.
- i need a text-mode application. it has to behave (almost) identically
  both in the console and under x.
i also tried vim and emacs, but my built-in state machine sucks, so i'm
unable to use either of them. :}
the only IDE-specific feature i miss from mcedit is invoking a build
command + parsing its output for warnings/errors.
i guess i should try some of the roughly 732 other editors around, but
somehow i'm too lazy. :)

greetings

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.